Portable cryptographic key

[0002] 1. Field of the Invention

[0003] This invention relates to a cryptographic key management system.

[0004] 2. Description of the Related Art

[0005] Copending U.S. patent application of D. B. Johnson et al., Ser. No. 08/629,815 (U.S. Pat. No. 5,815,573), filed Apr. 10, 1996, entitled “Cryptographic Key Recovery System” (“Johnson et al. I”), assigned to the International Business Machines Corporation, is incorporated herein by reference. This cited patent application describes a key recovery system using multiple key recovery agents.

[0006] Copending application of D. B. Johnson et al., Ser. No. 08/681,679 (U.S. Pat. No. 5,796,830), filed Jul. 29, 1996, entitled “Interoperable Cryptographic Key Recovery System” (“Johnson et al. II”), assigned to the International Business Machines Corporation, is incorporated herein by reference. This cited patent application describes another key recovery system.

[0007] Copending provisional application of Sekar Chandersekaran and Sarbari Gupta, Ser. No. 60/047,499, filed May 23, 1997, and the copending regular patent application derived therefrom, Ser. No. 08/971,204, filed Nov. 14, 1997, entitled “FRAMEWORK-BASED”. CRYPTOGRAPHIC KEY RECOVERY SYSTEM”, assigned to the International Business Machines Corporation, is incorporated herein by reference.

[0008] In recent times, cryptography has come into widespread use in meeting multiple security needs, such as confidentiality, integrity, authentication and non-repudiation. When data is encrypted using a particular cryptographic algorithm, data is fed into a cryptographic engine along with key material and encryption parameters. When decryption occurs, a similar process must occur and the two keys must match (they must be identical in the case of symmetric encryption and be mathematically related in the case of asymmetric encryption).

[0009] Currently, when a key has to be transported across multiple systems and/or over a network connection, there exists no standard technique to guarantee that the relevant and necessary information is transmitted to guarantee a successful decryption. Application in distributed environments, in particular, have to make assumptions about the way that encryption was done. They also have to make assumptions about the format of key data that they receive. We define a technique by which we encode all the appropriate information into a “portable key” so that only the data and the contents of the portable key are needed to guarantee successful decryption using the appropriate cryptographic engine.

[0010] The invention is a method, system, and computer program to transport an encrypted key across multiple, diverse systems which provides the relevant and necessary information to guarantee a successful decryption of the key. The method prepares an ASN.1 encoding file at the sender which contains the key. The method begins by creating the ASN.1 format for portable key information. The ASN.1 compiler is run, feeding the platform-independent ASN.1 file as input, and generating platform-specific output files. Then platform-specific data values are created representing the portable key information based on the platform-specific data structure definitions just generated. Then, the platform-specific ASN.1 encoding functions are used to create the ASN.1 encoded protocol data unit (PDU) corresponding to the portable key information. The ASN.1 encoded protocol data unit (PDU) is then sent to the receiver node.

[0011] At the time of decryption, the receiver performs the method to decode the ASN.1 encoded file. The method begins by creating the ASN.1 format for portable key information. The ASN.1 compiler is run, by feeding the platform-independent ASN.1 file as input, and generating platform specific output files. Then platform-specific data values are created representing the portable key information based on the platform-specific data structure definitions just generated. Then, the platform-specific ASN.1 decoding functions are used to decode the ASN.1 encoded protocol data unit (PDU) to obtain the platform-specific key information. The platform-specific key information is then used at the receiving node for normal cryptographic operations. In this manner, only the data and the contents of the portable key are needed to guarantee successful decryption.

[0012] FIG. 1A is a network diagram showing a sender and receiver nodes using the invention.

[0013] FIG. 1B illustrates the overall processing at the sender and receiver nodes.

[0014] FIG. 2 illustrates the format of the ASN.1 encoding file

[0015] FIG. 3A illustrates the encoding file for a symmetric key

[0016] FIG. 3B illustrates the encoding file for an asymmetric key

[0017] FIG. 4 illustrates the method to prepare the ASN.1 encoding file at the sender.

[0018] FIG. 5 illustrates the method to decode the ASN.1 encoding file at the receiver.

[0019] The International Standards Organization (ISO), the International Electrotechnical Commission (IEC) and the International Telecommunications Union—Telecommunications Sector (ITU-T) (formerly known as the International Telegraph and Telephone Consultative Committee (CCITT)) have established Abstract Syntax Notation One (ASN.1) and its encoding rules as a standard for describing and encoding messages.

[0020] ASN.1 is a formal language for abstractly describing data to be exchanged between distributed computer systems. ASN.1 frees protocol designers to describe the layout of messages exchanged between application programs running in typically dissimilar hardware and software environments. The term abstract is used because ASN.1 doesn't describe the bits and bytes details of how messages are laid out while in transit between two machines; rather, it describes the message layout at a higher, more abstract level. Enclosing rules are sets of rules used to transform data specified in the ASN.1 language into a standard format that can be decoded by any system that has a decoder based on the same set of rules.

[0021] Relevant Citations

[0022] CCITT, Recommendations X.680, “Information Technology—Abstract Syntax Notation One (ASN.1)—Specification of Basic Notation, “Consultation Committee, International Telephone and Telegraph, International Telecommunications Union, Geneva, 1994.

[0023] CCITT, Recommendations X.690, “Information Technology—ASN.1 Encoding Rules—Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)” Consultation Committee, International Telephone and Telegraph, International Telecommunications Union, Geneva, 1994.

[0024] CCITT, Recommendations X.691, “Information Technology—ASN.1 Encoding Rules—Packed Encoding Rules (PER)” Consultation Committee, International Telephone and Telegraph, International Telecommunications Union, Geneva, 1994.

[0025] The invention disclosed herein defines an ASN.1 encoding file that can represent all keys and all possible parameters using unique object identifiers. FIG. 1A is a network diagram showing a sender and receiver nodes using the invention. A sender application in the sender node generates a key with a generate key function in the sender system's proprietary key format and passes it to the portable key encoder which outputs a portable key. Associated with the sender application at the sender node is an IBM Keyworks framework and an IBM Keyworks Cryptographic Service Provider, as is described in the above referenced copending patent application entitled “FRAMEWORK-BASED CRYPTOGRAPHIC KEY RECOVERY SYSTEM”. The Framework provides the required checks of the key from the generate key function. The portable key produced at the sender node is sent to the receiver node. A receiver application at the receiver node receives the portable key and the portable key decoder decodes it and outputs the decoded value in the receiver system's proprietary key format.

[0026] FIG. 1B illustrates the overall processing at the sender and receiver nodes. One of the common functions at the sender and receiver nodes is the ASN.1 compiler, that outputs a platform-independent ASN.1 definition file with the portable key information. Another common function at the sender and receiver nodes are the platform specific ASN.1 functions to encode and decode the portable key.

[0027] FIG. 1B also illustrates the sender functions on the sender platform, such as the Microsoft Windows 95 operating system running on an Intel Pentium processor. A platform specific data definition is input to create a platform specific data value and portable key information. The portable key information is then encoded from platform specific data into platform independent data, which is transmitted in the ASN.1 format to the receiver.

[0028] FIG. 1B also illustrates the receiver functions on the receiver platform, such as the IBM/AIX operating system running on an IBM RISC/6000 processor. The encoded portable key information which is received, is decoded from platform independent data to platform specific data.

[0029] FIG. 2 illustrates the format of the ASN.1 encoding file for a portable key, in accordance with the invention. The format includes portable key information that includes a portable key header and portable key data. FIG. 3A illustrates the format of the ASN.1 encoding file for a symmetric key. The format includes portable key information that includes a portable key header with a cryptographic algorithm identifier, algorithm usage, and related parameters, and the cryptographic key data format and related parameters. The portable key data includes the byte stream of the size specified in the format data. FIG. 3B illustrates the format of the ASN.1 encoding file for an asymmetric key. The format includes portable key information that includes a portable key header with a cryptographic algorithm identifier, algorithm usage, and related parameters, and the cryptographic key data format and related parameters. The portable key data includes the byte stream of the size specified in the format data.

[0030] The encoder/decoder functions corresponding to this ASN.1 definition have been generated using an ASN.1 compiler.

[0031] At the time of encryption, the key material and corresponding parameters for the algorithm are fed into an encode function that produces a portable key. FIG. 4 illustrates the method to prepare the ASN.1 encoding file at the sender. The method begins by creating the ASN.1 format for portable key information as a file of type “asn” (e.g., RequiredPortableKeyInfo.asn). The appropriate tool is run, for example the ASN.1 compiler, by feeding the platform-independent ASN.1 file as input, and generating platform specific output files. Then platform-specific data values are created representing the portable key information based on the platform-specific data structure definitions just generated. Then, the platform-specific ASN.1 encoding functions are used to create the ASN.1 encoded protocol data unit (PDU) corresponding to the portable key information. The ASN.1 encoded protocol data unit (PDU) is then sent to the receiver node. This portable key bytestream may be distributed by an mechanism such as distributed file system, direct network connections, etc. An example of these steps is as follows:

[0032] InitializePDU (PortableKeyInfoName)

[0033] OpenPDU (PortableKeylnfoName)

[0034] EncodePDU

[0035] (Input: Platform-specific data,

[0036] Output: ASN.1 encoded data)

[0037] ClosePDU (PortableKeyInfoName)

[0038] At the time of decryption, the portable key is fed into the decoder function and the key material and corresponding parameters are created. In addition to this information, only the data to be decrypted is needed by the decryption algorithm to perform a successful decryption. FIG. 5 illustrates the method to decode the ASN.1 encoded file at the receiver. The method begins by creating the ASN.1 format for portable key information as a file of type “asn” (e.g., RequiredPortableKeyInfo.asn). The appropriate tool is run, for example the ASN.1 compiler, by feeding the platform-independent ASN.1 file as input, and generating platform specific output files. Then platform-specific data values are created representing the portable key information based on the platform-specific data structure definitions just generated. Then, the platform-specific ASN.1 decoding functions are used to decode the ASN.1 encoded protocol data unit (PDU) to obtain the platform-specific key information. The platform-specific key information is then used at the receiving node for normal cryptographic operations. An example of these steps is as follows:

[0039] InitializePDU (PortableKeyInfoName)

[0040] OpenPDU (PortableKeylnfoName)

[0041] DecodePDU

[0042] (Input: ASN.1 encoded data,

[0043] Output: Platform-specific data)

[0044] ClosePDU (PortableKeyInfoName)

[0045] The portable key bytestream may be distributed by any mechanism such as distributed file system, direct network connections, etc.

[0046] This method provides a uniform way to encode key-related information needed to encrypt and decrypt data with no reliance on additional methods to provide algorithm-specific information.

[0047] This portable key definition has been used to achieve interoperability in our IBM KeyWorks product suite which consists of:

[0048] 1. IBM KeyWorks Toolkit (cryptographic and certificate services framework+service providers)

[0049] 2. IBM Key Recovery Service Provider (key recovery service provider which generates key recovery blocks)

[0050] 3. IBM Key Recovery Server (server which recovers (portable cryptographic) keys when presented with key recovery blocks from authorized parties)

[0051] The ASN.1 specification for the Portable Key Structure is a generic structure, which covers all key types. The keyClass attribute in the PortableKeyInfo structure distinguishes symmetric keys for asymmetric keys (public/private keys are asymmetric, secret keys are symmetric keys).

[0052] A portable cryptographic key is encoded and decoded by following these steps:

[0053] 1. Software that processes the ASN.1 encoded data structure must be created for encoding keys (usually prior to sending) and decoding keys (usually after receiving)—This may be done manually by writing what is effectively an ASN.1 standard compliant parser. Alternatively, a ASN.1 compiler may be used to automate this process. ASN.1 compilers read in an ASN.1 encoding file and generate data structure definitions and encode/decode function (subroutine) source code in a given target language (c.g., C) for a given target machine (e.g., Windows NT).

[0054] 2. The encode function (previously generated by the compiler) must be called; its input is the language-specific, machine-specific data structure representing the key semantics; its output is a portable byte stream which can be decoded by the corresponding decode function (which may be implemented in a different language and a different machine type). E.g., the encode may be in C on Windows NT, but the decode may be in Java on the AIX operating system.

[0055] 3. When the portable byte stream is received, it is fed to the appropriate decode function to obtain the original key in a form usable on the target machine.

[0056] This invention is useful in any environment where cryptographic keys are used and portability is required. For example, it is very useful in the Internet environment where many different parties need keys to provide security services like confidentiality, message integrity, etc.

[0057] We use the portable cryptographic key in our IBM KeyWorks product suite so that we can generate keys on one machine type and recover it in a usable form on a different machine type.

[0058] Although a specific embodiment of the invention has been disclosed, it will be understood by those having skill in the art that changes can be made to that specific embodiment without departing from the spirit and scope of the invention.