Cryptographic facility environment backup/restore and replication in a public key cryptosystem

Abstract

A computer apparatus, program and method function in a data processing system to replicate a cryptographic facility. The system includes a first cryptographic facility containing a portable part which personalizes the first cryptographic facility. The system also includes a second cryptographic facility which is linked to the first cryptographic facility by a public key cryptographic system. The portable part of the first cryptographic facility is encrypted and transferred to the second cryptographic facility, where it is decrypted and used to personalize the second cryptographic facility to enable replication of the first cryptographic facility. In one application, personalization of the second cryptographic facility can be in response to the detection of a failure in the first cryptographic facility. In another application, multiple cryptographic facilities can be brought on-line for parallel operation in the data processing system.

Claims

What is claimed is:

1. In a data processing system which includes a first cryptographic facility containing configuration information for configuring said first cryptographic facility and coupled to a second cryptographic facility in a public key cryptographic system, a method for duplicating a configuration of said first cryptographic facility, comprising the steps of:

generating a public key and a private key as a pair in said second cryptographic facility;

transferring said public key to said first cryptographic facility;

encrypting at least a portion of said configuration information under said public key forming a configuration token at said first cryptographic facility;

transferring said configuration token to said second cryptographic facility;

decrypting said configuration token using said private key forming a duplicate configuration information at said second cryptographic facility; and

configuring said second cryptographic facility with said duplicate configuration information to duplicate a configuration of said first cryptographic facility.

2. The method of claim 1, which further comprises:

said configuration information including secured information and non-secured information;

said secured information including a master key of said first cryptographic facility;

said encrypting step further comprising encrypting said secured information under said public key;

transferring a cryptographic key data set to said second cryptographic facility, containing an operating key encrypted under a key expression formed as an exclusive OR product of said master key and a control vector for said operating key.

3. The method of claim 1, which further comprises the steps of:

detecting a failure condition of said first cryptographic facility, prior to said configuring step;

said configuring step being performed in response to said detecting step.

4. The method of claim 1, which prior to said configuring step, further comprises the steps of:

generating a second public key and a second private key as a second pair, in said first cryptographic facility;

transferring said second public key to said second cryptographic facility;

encrypting a representation of said configuration information under said second private key forming a digital signature at said first cryptographic facility;

transferring said digital signature to said second cryptographic facility;

decrypting said digital signature using said second public key forming a reference representation of said configuration information at said second cryptographic facility;

comparing said reference representation of said configuration information with a representation of said duplicate configuration information at said second cryptographic facility to confirm receipt thereof from said first cryptographic facility; and

said configuring step being performed in response to said comparing step.

5. The method of claim 4, which further comprises the steps of:

detecting a failure condition of said first cryptographic facility, prior to said configuring step;

said configuring step being performed in response to said detecting step and said comparing step.

6. The method of claim 1, wherein said step of transferring said public key further comprises:

transferring said public key and a control vector to said first cryptographic facility, said control vector specifying limitations on use of said public key to include said step of encrypting at least a portion of said configuration information under said public key forming said configuration token at said first cryptographic facility.

7. In a data processing system which includes a first cryptographic facility containing configuration information for configuring said first cryptographic facility and coupled to a second cryptographic facility in a public key cryptographic system, a method for duplicating a configuration of said first cryptographic facility, comprising the steps of:

generating a public key and a private key as a pair at said second cryptographic facility;

transferring said public key to said first cryptographic facility;

generating a key encrypting key at said first cryptographic facility;

encrypting at least a portion of said configuration information under said key encrypting key forming a configuration token at said first cryptographic facility;

transferring said configuration token to said second cryptographic facility;

encrypting at least said key encrypting key under said public key forming an encrypted key lock at said first cryptographic facility;

transferring said encrypted key block to said second cryptographic facility as a received encrypted key block;

decrypting said received encrypted key block using said private key forming a recovered key block including a recovered key encrypting key at said second cryptographic facility;

decrypting said configuration token using said recovered key encrypting key forming a duplicate configuration information at said second cryptographic facility; and

configuring said second cryptographic facility with said duplicate configuration information to duplicate a configuration of said first cryptographic facility.

8. The method of claim 7, which further comprises:

said configuration information including secured information and non-secret information;

said secured information including a master key of said first cryptographic facility;

said first said encrypting step further comprising encrypting said secured information under said public key;

transferring a cryptographic key data set to said second cryptographic facility, containing an operating key encrypted under a key expression formed as an exclusive OR product of said master key and a control vector for said operating key.

9. The method of claim 7, which further comprises the steps of:

detecting a failure condition of said first cryptographic facility, prior to said configuring step;

said configuring step being performed in response to said detecting step.

10. The method of claim 7, which prior to said configuring step, further comprises the steps of:

generating a second public key and a second private key as a second pair, in said first cryptographic facility;

transferring said second public key to said second cryptographic facility;

encrypting a representation of said encrypted key block under said second private key forming a digital signature at said first cryptographic facility;

transferring said digital signature to said second cryptographic facility;

decrypting said digital signature using said second public key forming a reference representation of said encrypted key block at said second cryptographic facility;

comparing said reference representation of said encrypted keyblock with a representation of said received encrypted key block at said second cryptographic facility to confirm receipt thereof from said first cryptographic facility; and

said configuring step being performed in response to said comparing step.

11. The method of claim 7, which prior to said configuring step, further comprises the steps of:

generating a second public key and a second private key as a second pair, in said first cryptographic facility;

transferring said second public key to said second cryptographic facility;

encrypting a representation of said key block under said second private key forming a digital signature at said first cryptographic facility;

transferring said digital signature to said second cryptographic facility;

decrypting said digital signature using said second public key forming a reference representation of said key block at said second cryptographic facility;

comparing said reference representation of said key block with a representation of said recovered key block at said second cryptographic facility to confirm receipt thereof from said first cryptographic facility; and

said configuring step being performed in response to said comparing step.

12. The method of claim 11, which further comprises the steps of:

detecting a failure condition of said first cryptographic facility, prior to said configuring step;

said configuring step being performed in response to said detecting step and said comparing step.

13. The method of claim 7, wherein said step of transferring said public key further comprises:

transferring said public key and a control vector to said first cryptographic facility, said control vector specifying limitations on use of said public key to include said step of encrypting at least said key encrypting key under said public key forming said encrypted key block at said first cryptographic facility.

14. The method of claim 7, wherein said encrypted key block is formed comprising the steps of:

computing a hash value of a representation of said configuration information at said first cryptographic facility;

concatenating said hash value with said key encrypting key, forming an argument value at said first cryptographic facility; and

encrypting at least said argument value under said public key forming said encrypted key block at said first cryptographic facility;

and wherein said configuring step is performed in response to the steps comprising:

separating said hash value from said key encrypting key in said recovered key block, as a received hash value, at said second cryptographic facility;

computing a reference hash value of a representation of said duplicate configuration information, at said second cryptographic facility;

comparing said reference hash value with said received hash value, at said second cryptographic facility;

said configuring step being performed in response to said comparing step.

15. The method of claim 7, wherein said encrypted key block is formed comprising the steps of:

accessing a master key value at said first cryptographic facility;

computing a hash value of a representation of said configuration information at said first cryptographic facility;

logically combining said master key with said key encrypting key forming a product value, using an invertible logical operation;

concatenating said product value and said hash value forming an argument value at said first cryptographic facility; and

encrypting at least said argument value under said public key forming said encrypted key block at said first cryptographic facility;

and wherein said recovered key encrypting key is formed, comprising the steps of:

separating said product value from said recovered key block at said second cryptographic facility;

transferring said master key to said second cryptographic facility; and

logically combining said master key with said product at said second cryptographic facility, forming said recovered key encrypting key, using an inverse of said logical operation.

16. A computer program in a data processing system which includes a first cryptographic facility containing configuration information for configuring said first cryptographic facility and coupled to a second cryptographic facility in a public key cryptographic system, the computer program when executed in said data processing system, performing a method for duplicating a configuration of said first cryptographic facility, comprising the steps of:

generating a public key and a private key as a pair in said second cryptographic facility;

transferring said public key to said first cryptographic facility;

encrypting at least a portion of said configuration information under said public key forming a configuration token at said first cryptographic facility;

transferring said configuration token to said second cryptographic facility;

decrypting said configuration token using said private key forming a duplicate configuration information at said second cryptographic facility; and

configuring said second cryptographic facility with said duplicate configuration information to duplicate a configuration of said first cryptographic facility.

17. The computer program of claim 16, which further comprises:

said configuration information including secured information and non-secret information;

said secured information including a master key of said first cryptographic facility;

said encrypting step further comprising encrypting said secured information under said public key; said method performed by the computer program transferring a cryptographic key data set to said second cryptographic facility, containing an operating key encrypted under a key expression formed as an exclusive OR product of said master key and a control vector for said operating key.

18. The computer program of claim 16, wherein said method performed thereby further comprises the steps of:

detecting a failure condition of said first cryptographic facility, prior to said configuring step;

said configuring step being performed in response to said detecting step.

19. A computer program in a data processing system which includes a first cryptographic facility containing configuration information for configuring said first cryptographic facility and coupled to a second cryptographic facility in a public key cryptographic system, the computer program when executed in said data processing system, performing a method for duplicating a configuration of said first cryptographic facility, comprising the steps of:

generating a public key and a private key as a pair of said second cryptographic facility;

transferring said public key to said first cryptographic facility;

generating a key encrypting key at said first cryptographic facility;

encrypting at least a portion of said configuration information under said key encrypting key forming a configuration token at said first cryptographic facility;

transferring said configuration token to said second cryptographic facility;

encrypting at least said key encrypting key under said public key forming an encrypted key block at said first cryptographic facility;

transferring said encrypted key block to said second cryptographic facility as a received encrypted key block;

decrypting said received encrypted key block using said private key forming a recovered key block including a recovered key encrypting key at said second cryptographic facility;

decrypting said configuration token using said recovered key encrypting key forming a duplicate configuration information at said second cryptographic facility; and

configuring said second cryptographic facility with said duplicate configuration information to duplicate a configuration of said first cryptographic facility.

20. The computer program of claim 19, which further comprises:

said configuration information including secured information and non-secured information;

said secured information including a master key of said first cryptographic facility;

said first said encrypting step further comprising encrypting said secured information under said public key;

said method performed by the computer program transferring a cryptographic key data set to said second cryptographic facility, containing an operating key encrypted under a key expression formed as an exclusive OR product of said master key and a control vector for said operating key.

21. In a data processing system which includes a first cryptographic facility containing configuration information for configuring said first cryptographic facility and coupled to a second cryptographic facility in a public key cryptographic system, a computer apparatus for duplicating a configuration of said first cryptographic facility, comprising:

generating means for generating a public key and a private key as a pair in said second cryptographic facility;

first transferring means coupled to said generating means, for transferring said public key to said first cryptographic facility;

encrypting means coupled to said first transferring means, for encrypting at least a portion of said configuration information under said public key forming a configuration token at said first cryptographic facility;

second transferring means coupled to said encrypting means, for transferring said configuration token to said second cryptographic facility;

decrypting means coupled to said second transferring means, for decrypting said configuration token using said private key forming a duplicate configuration information at said second cryptographic facility; and

configuring means coupled to said decrypting means, for configuring said second cryptographic facility with said duplicate configuration information to duplicate a configuration of said first cryptographic facility.

22. The computer apparatus of claim 21, which further comprises:

said configuration information including secured information and non-secured information;

said secured information including a master key of said first cryptographic facility;

said encrypting means encrypting said secured information under said public key;

third transferring means coupled to a storage means in said data processing system, for transferring a cryptographic key data set to said second cryptographic facility, containing an operating key encrypted under a key expression formed as an exclusive OR product of said master key and a control vector for said operating key.

23. The computer apparatus of claim 21, which further comprises:

detecting means coupled to said first and said second cryptographic facility, for detecting a failure condition of said first cryptographic facility;

said configuring means operating in response to said detecting means.

24. In a data processing system which includes a first cryptographic facility containing configuration information for configuring said first cryptographic facility and coupled to a second cryptographic facility in a public key cryptographic system, a computer apparatus for duplicating a configuration of said first cryptographic facility, comprising:

first generating means for generating a public key and a private key as a pair at said second cryptographic facility;

first transferring means coupled to said first generating means, for transferring said public key to said first cryptographic facility;

second generating means for generating a key encrypting key at said first cryptographic facility;

first encrypting means coupled to said second generating means, for encrypting at least a portion of said configuration information under said key encrypting key forming a configuration token at said first cryptographic facility;

second transferring means coupled to said first encrypting means, transferring said configuration token to said second cryptographic facility;

second encrypting means coupled to said first transferring means and said second generating means, for encrypting at least said key encrypting key under said public key forming an encrypted key block at said first cryptographic facility;

third transferring means coupled to said second encrypting means, transferring said encrypted key block to said second cryptographic facility as a received encrypted key block;

first decrypting means coupled to said third transferring means, for decrypting said received encrypted key block using said private key forming a recovered key block including a recovered key encrypting key at said second cryptographic facility;

second decrypting means coupled to said second transferring means, decrypting said configuration token using said recovered key encrypting key forming a duplicate configuration information at said second cryptographic facility; and

configuring means coupled to said decrypting means, for configuring said second cryptographic facility with said duplicate configuration information to duplicate a configuration of said first cryptographic facility.

25. The computer apparatus of claim 24, which further comprises:

said configuration information including secured information and non-secured information;

said secured information including a master key of said first cryptographic facility;

said first encrypting means encrypting said secured information under said public key;

fourth transferring means coupled to a storage means in said data processing system, for transferring a cryptographic key data set to said second cryptographic facility, containing an operating key encrypted under a key expression formed as an exclusive OR product of said master key and a control vector for said operating key.

26. The computer apparatus of claim 24, which further comprises:

detecting means coupled to said first, and said second cryptographic facility, for detecting a failure condition of said first cryptographic facility;

said configuring means operating in response to said detecting means.

Description

BACKGROUND OF THE INVENTION

1. Technical Field

The invention disclosed broadly relates to data processing systems and methods and more particularly relates to cryptographic systems and methods for use in data processing systems to enhance security.

2. Background Art

The following patents and patent applications are related to this invention and are incorporated herein by reference:

B. Brachtl, et al., "Controlled Use of Cryptographic Keys Via Generating Stations Established Control Values," U.S. Pat. No. 4,850,017, issued Jul. 18, 1989, assigned to IBM Corporation and incorporated herein by reference.

S. M. Matyas, et al., "Secure Management of Keys Using Control Vectors," U.S. Pat. No. 4,941,176, issued Jul. 10, 1990, assigned to IBM Corporation and incorporated herein by reference.

S. M. Matyas, et al., "Data Cryptography Operations Using Control Vectors," U.S. Pat. No. 4,918,728, issued Apr. 17, 1990, assigned to IBM Corporation and incorporated herein by reference.

S. M. Matyas, et al., "Personal Identification Number Processing Using Control Vectors," U.S. Pat. No. 4,924,514, issued May 8, 1990, assigned to IBM Corporation and incorporated herein by reference.

S. M. Matyas, et al., "Secure Management of Keys Using Extended Control Vectors," U.S. Pat. No. 4,924,515, issued May 8, 1990, assigned to IBM Corporation and incorporated herein by reference.

S. M. Matyas, et al., "Secure Key Management Using Control Vector Translation," U.S. Pat. No. 4,993,069, issued Feb. 12, 1991, assigned to IBM Corporation and incorporated herein by reference.

S. M. Matyas, et al., "Secure Key Management Using Programmable Control Vector Checking,"0 U.S. Pat. No. 5,007,089, issued Apr. 9, 1991, assigned to IBM Corporation and incorporated herein by reference.

B. Brachtl, et al., "Data Authentication Using Modification Detection Codes Based on a Public One Way Encryption Function," U.S. Pat. No. 4,908,861, issued Mar. 13, 1990, assigned to IBM Corporation and incorporated herein by reference.

D. Abraham, et al., "Smart Card Having External Programming Capability and Method of Making Same," Ser. No. 004,501, filed Jan. 19, 1987, assigned to IBM Corporation and incorporated herein by reference.

S. M. Matyas, "Technique for Reducing RSA Crypto Variable Storage", U.S. Pat. No. 4,736,423, issued Apr. 5, 1988, assigned to IBM Corporation and incorporated herein by reference.

S. M. Matyas, et al., "Secure Management of Keys Using Control Vectors with Multi-Path Checking," Ser. No. 07/596,637, filed Oct. 12, 1990, assigned to IBM Corporation and incorporated here by reference.

S. M. Matyas, et al., "Secure Cryptographic Operations Using Alternate Modes of Control Vector Enforcement," Ser. No. 07/574,012, filed Aug. 22, 1990, assigned to IBM Corporation and incorporated here by reference.

S. M. Matyas, et al., "Method and Apparatus for Controlling the Use of a Public Key, Based on the Level of Import Integrity for the Key," Ser. No. 07/602,989, filed Oct. 24, 1990, assigned to IBM Corporation and incorporated herein by reference.

S. M. Matyas, et al., "A Hybrid Public Key Algorithm/Data Encryption Algorithm Key Distribution Method Based on Control Vectors," Ser. No. 07/748,407, filed Aug. 22, 1991, assigned to IBM Corporation and incorporated herein by reference.

S. M. Matyas et al., "Generating Public and Private Key Pairs Using a Passphrase," Ser. No. 07/766,533, filed Sep. 27, 1991, assigned to IBM Corporation and incorporated herein by reference.

S. M. Matyas et al., "Public Key Cryptosystem Key Management Based on Control Vectors," Ser. No. 07/766,260, filed Sep. 27, 1991, assigned to IBM Corporation and incorporated herein by reference.

The cryptographic architecture described in the cited patents by S. M. Matyas, et al. is based on associating with a cryptographic key, a control vector which provides the authorization for the uses of the key intended by the originator of the key. The cryptographic architecture described in the cited patents by S. M. Matyas, et al. is based on the Data Encryption Algorithm (DEA), see American National Standard X3.92-1981, Data Encryption Algorithm, American National Standards Institute, New York (Dec. 31, 1981), whereas the present invention is based on both a secret key algorithm, such as the DEA, and a public key algorithm. Various key management functions, data cryptography functions, and other data processing functions are possible using control vectors, in accordance with the invention. A system administrator can exercise flexibility in the implementation of his security policy by selecting appropriate control vectors in accordance with the invention. A cryptographic facility (CF) in the cryptographic architecture is described in the above cited patents by S. M. Matyas, et al. The CF is an instruction processor for a set of cryptographic instructions, implementing encryption methods and key generation methods. A memory in the cryptographic facility stores a set of internal cryptographic variables. Each cryptographic instruction is described in terms of a sequence of processing steps required to transform a set of input parameters to a set of output parameters. A cryptographic facility application program (CFAP) is also described in the referenced patents and patent applications, which defines an invocation method, as a calling sequence, for each cryptographic instruction consisting of an instruction mnemonic and an address with corresponding input and output parameters.

Public key encryption algorithms are described in a paper by W. Diffie and M. E. Hellman entitled "Privacy and Authentication: An Introduction to Cryptography," Proceedings of the IEEE, Volume 67, No. 3, March 1979, pp. 397-427. Public key systems are based on dispensing with the secret key distribution channel, as long as the channel has a sufficient level of integrity. In a public key cryptographic system, two keys are used, one for enciphering and one for deciphering. Public key algorithm systems are designed so that it is easy to generate a random pair of inverse keys PU for enciphering and PR for deciphering and it is easy to operate with PU and PR, but is computationally infeasible to compute PR from PU. Each user generates a pair of inverse transforms, PU and PR. He keeps the deciphering transformation PR secret, and makes the enciphering transformation PU public by placing it in a public directory. Anyone can now encrypt messages and send them to the user, but no one else can decipher messages intended for him. It is possible, and often desirable, to encipher with PU and decipher with PR. For this reason, PU is usually referred to as a public key and PR is usually referred to as a private key.

One important feature of a public key cryptographic system is that it provides an improved method of key distribution, particularly in the case of a hybrid cryptographic system where it is desired to distributed DEA keys using the public key cryptographic system. To implement this key distribution feature, each user A, B, etc., has an associated public and private key pair (PUa,PRa), (PUb,PRb), etc. Any user, say B, who wishes to distribute a DEA key K to user A, merely encrypts K with PUa, the public key of A. Since only A has PRa, the private key of A, only A can decrypt and recover K. This ensures that only A (who has PRa) and the sender (who used PUa) have a copy of K. However, to make this protocol secure it is necessary for the sender to prove his or her identity to A. That is, if B is the sender, then B must prove his or her identity to A. Only then will A be sure that the key originated with B. (Note that B is already sure that only A can recover the key.) The means to accomplish this is for B to "sign" K or the encrypted key ePUa(K) or the message, with his or her private key PRb. Messages are signed using a cryptographic variable called a digital signature, as explained below. A method for distributing DEA keys using a public key algorithm is taught in co-pending patent application Ser. No. 07/748,407 ("A Hybrid Public Key/Data Encryption Algorithm Key Distribution Method Based on Control Vectors"), cited in the Background Art.

A corollary feature of public key cryptographic systems is the provision of a digital signature which uniquely identifies the sender of a message. If user A wishes to send a signed message M to user B, he operates on it with his private key PR to produce the signed message S. PR was used as A's deciphering key when privacy was desired, but it is now used as his "enciphering" key. When user B receives the message S, he can recover the message M by operating on the ciphertext S with A's public PU. By successfully decrypting A's message, the receiver B has conclusive proof it came from the sender A. Digital signatures can be produced either by decrypting the data to be signed with the private key, which works well when the data is short, or by first hashing the data with a strong one-way cryptographic function and decrypting the so-produced hashed value with the private key. Either method will work. Thus, in the above described method of DEA key distribution, B sends A two quantities: (1) the encrypted key, ePU(K), and (2) a digital signature e.g., of the form (a) dPR(ePU(K)) or dPR(hash(ePU(K))). A method for producing digital signatures based on the hash of the data to be signed is taught in co-pending patent application Ser. No. 07/748,407 ("A Hybrid Public Key Algorithm/Data Encryption Algorithm Key Distribution Method Based on Control Vectors"), cited in the Background Art. Examples of public key cryptography are provided in the following U.S. patents: U.S. Pat. No. 4,218,582 to Hellman, et al., "Public Key Cryptographic Apparatus and Method;" U.S. Pat. No. 4,200,770 to Hellman, et al., "Cryptographic Apparatus and Method;" and U.S. Pat. No. 4,405,829 to Rivest, et al., "Cryptographic Communications System and Method."

In the above example of DEA key distribution, where B sends A a DEA key K, the method is secure only if A can be sure that K has in fact originated from the party so stated (i.e., K originated from the party who has signed K or ePUa(K) or the message). Suppose that B signs K or hash(K), not ePUa(K) or hash(ePUa(K)), i.e., the signature is of the form dPRb(K) or dPRb(hash(K)). Suppose that the signature is of the form dPRb(hash(K)), so that inverting dPRb(hash(K)) with PUb to recover hash(K) does not reveal the value of K. Now, if an adversary with public and private key pair (PUx,PRx) could substitute PUx for PUa, thus causing B to encrypt K with PUx instead of PUa, then the adversary could defeat security by (1) intercepting ePUx(K) and dPRb(hash(K)), (2) decrypting ePUx(K) with PRx, (3) re-encrypting K with PUa to produce ePUa(K), and (4) sending ePUa(K) and dPRb(hash(K)) to A. In this case, A and B are unaware that the adversary has had a peek at K. If B instead signs ePUa(K) or the hash of ePUa(K), then the attack still works, but is a bit more complicated. However, if an adversary with public and private key pair (PUx,PRx) could substitute PUx for PUa and PUx for PUb, thus causing B to encrypt K with PUx instead of PUa and could cause A to validate the signature dPRx(ePUa(K)) with PUx instead of PUb, then the adversary could defeat security by (1) intercepting ePUx(K) and dPRb(hash(ePUx(K)), (2) decrypting ePUx(K) with PRx, (3) re-encrypting K with PUa to produce ePUa(K), (4) hashing ePUa(K) to form hash(ePUa(K)), (5) decrypting hash(ePUa(K)) with PRx to form digital signature dPRx(hash(ePUa(K))), and (6) sending ePUa(K) and dPRx(hash(ePUa(K))) to A. In this case, A validates dPRx(hash(ePUa(K))) with PUx and thus believes that ePUa(K) originates with B. A and B are unaware that the adversary has had a peek at K.

The methods of attack outlined above are thwarted by ensuring that A has a valid copy of PUb and that B has a valid copy of PUa. The common method for accomplishing this is to use a certification center which permits public keys to be registered with the certification center. The process works like this. A party, say A, produces a key pair (PUa,PRa). PUa is included in a message, often called a certificate. The certificate contains a public key and key-related data such as an identifier of the party creating and registering the key, in this case, party A, a key name, a start and end date and time when the key is active, etc. The certification center also has a key pair (PUcert,PRcert), where PUcert is distributed with integrity, in advance, to each of the other parties in the network serviced by the certification center, i.e., to A, B, C, etc. After the certification center is satisfied that a request for public key registration is "okay" (e.g., that party A is in fact the actual party to whom the to-be-registered public key belongs), then the certification center signs the certificate with its private key PRcert, i.e., the cryptographic quantity dPRcert(hash(certificate)) is produced, and the certificate and digital signature are returned to party A or stored in a central directory. Thereafter, the certificate and digital signature can be used as proof that PUa belongs to party A. For example, party B obtains the certificate and digital signature from party A or from the central directory and validates the signature with PUcert, the public key of the certification center. This proves to B that PUa belongs to A. In like manner, A can obtain and authenticate a digital signature and certificate containing B's public key PUb. This completely thwarts the above attacks wherein an adversary substitutes one public key for another, thereby causing A to use PUx instead of PUb and causing B to use PUx instead of PUa.

In most cryptographic systems, the keys belonging to a cryptographic device are encrypted with a single master key and stored in a cryptographic key data set. The master key is stored in clear form within the cryptographic hardware. The concept of using a single master key to encrypt keys stored in a cryptographic key data set is known as the master key concept. In order to electronically distribute keys from one device to another, e.g., to distribute a data-encrypting key as part of session initiation, each pair of devices shares a unique key-encrypting key under which all distributed keys are encrypted. Thus, a data-encrypting key encrypts many messages. A key-encrypting key encrypts many electronically distributed data-encrypting keys, and so forth. A master key encrypts many key-encrypting and data-encrypting keys stored in a particular system's cryptographic key data set. Key management design principles are discussed in a paper by S. M. Matyas et al. entitled "A key-management scheme based on control vectors," IBM Systems Journal, Volume 30, No. 2, 1991, pp. 175-191.

Most cryptographic systems make use of many different types of keys, so that information encrypted with a key of one type is not affected by using a key of another type. A key is assigned a type on the basis of the information the key encrypts or the use being made of the key. For example, a data-encrypting key encrypts data. A key-encrypting key encrypts keys. A PIN-encrypting key encrypts personal identification numbers (PINs) used in electronic funds transfer and point-of-sale applications. A MAC key is used to generate and authenticate message authentication codes (MACs).

At the time a key is generated, the user or user application determines, from among the range of options permitted by the key management, the form of each generated key. For example, a generated key can be produced (1) in clear form, (2) in encrypted form suitable for storage in a cryptographic key data set, or (3) in encrypted form suitable for distribution to a designated receiving device. Generally, cryptographic systems have different options for generating keys in these different forms. For example, the Generate Key Set (GKS) instruction described in U.S. Pat. No. 4,941,176 (cited in the Background Art) accepts a mode parameter which defines the output forms of a randomly-generated DEA key K. In the present invention, the key types are expanded to include a device key pair used for backup and recovery purposes. Also, at the time a key is generated, the user or user application determines, from among the range of options permitted by the key management, the type and usage of each generated key. Type and usage information are examples of a class of key-related information called control information. For example, in U.S. Pat. Nos. 4,850,017, 4,941,176, 4,918,728, 4,924,514, 4,924,515, and 5,007,089, and IBM dockets MA9-88-033 and BT9-90-018 the control information is embodied within a data variable called the control vector. The control vector concepts taught in these US Patents and IBM dockets is summarized in a paper by S. M. Matyas entitled "Key handling with control vectors," IBM Systems Journal, Volume 30, No. 2, 1991, pp. 151-174. In the case of the device key pair, the control information associated with the PU and PR keys is also stored with the keys within the CF, where its integrity is ensured.

In order for a DEA-based cryptographic system to be made operable, each device must first be initialized with a master key and at least one key-encrypting key. The master key permits keys stored in the cryptographic key data set to be encrypted, and the key-encrypting key establishes a key-distribution channel with at least one other network device. When key distribution is performed in a peer-to-peer environment, each device is initialized with a key-encrypting key for each other device with which it wishes to communicate. However, when key distribution is performed with the assistance of a key-distribution center (KDC) or key-translation center (KTC), each device is initialized with only one key-encrypting key shared with the KDC or KTC. Thereafter, additional key-encrypting keys are distributed electronically and initialized automatically using the KDC or KTC. The key-distribution channel can also be made unidirectional. That is, one key-encrypting key encrypts keys transmitted from a first device to a second device and another key-encrypting key encrypts keys transmitted in the other direction. As stated above, each cryptographic device is initialized with at least one key-encrypting key. Consider the process of installing keys between two devices A and B, where one device, say A, generates a key-encrypting key for installation at both A and B. At device A, a clear key-encrypting key KK is randomly generated, e.g., by coin tossing. The clear KK is then manually loaded into the cryptographic hardware where it is encrypted under the A's master key, or a variant key formed as the Exclusive-OR product of the master key and a control vector. The encrypted value of KK is then stored in A's cryptographic key data set. The clear value of KK is then transported to device B, e.g., using a courier. At device B, KK is manually loaded into the cryptographic hardware where it is encrypted under B's master key, or a variant key formed as the Exclusive-OR product of the master key and a control vector. The encrypted value of KK is then stored in B's cryptographic key data set. The encrypted copies of KK at A and B enable A and B to communicate cryptographically as described in U.S. Pat. No. 4,941,176. U.S. Pat. No. 4,941,176 also provides for the initial key-encrypting key KK to be defined as the Exclusive-OR product of two or more key parts. At device A, each key part is manually loaded into the cryptographic hardware. The separately entered key parts are combined within the hardware to form the final value of KK. Each key part can be transported to the receiving cryptographic device using a separate courier. At device B, each key part is manually loaded into the cryptographic hardware and combined to form the final value of KK.

In a hybrid cryptographic system, the key management is designed so that DEA keys are distributed under the encryption of a public key. That is, B distributes a key to A by encrypting the key under PUa, A's public key. A recovers the key by decrypting the received encrypted key with PRa, A's private key, as described above. Thus, the key-encrypting key or keys manually installed into the cryptographic devices of a DEA-based cryptographic system can now be electronically distributed using a public key algorithm.

Instead of manually installing a public and private key pair (PU,PR) at each device, (PU,PR) is generated inside the cryptographic device. The private key, PR, is stored within the cryptographic hardware or it is encrypted under a master key and stored in a cryptographic key data set. If the public key is to be used for key distribution purposes, then its integrity within the cryptographic network can be assured by registering it at a certification center and receiving a certificate and digital signature, as described above. This allows the cryptographic device to freely distribute the public key to other devices with the assurance that the other devices will accept the public key as genuine. Thus, the keys used with the public key algorithm are handled automatically using electronic means; there is no requirement for manual installation of these keys at the cryptographic devices within the network.

In some cases, the public and private keys belonging to a cryptographic device may be stored in clear form within the cryptographic hardware. As an alternative to this approach, keys may be stored outside the cryptographic hardware, e.g., encrypting the public and private keys with the master key, or a variant key derived from the master key, and storing them in key tokens together with other key-related data (i.e., a control vector), as described in co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors"). Thus, the prior art describes how, in a hybrid cryptographic system using a public key algorithm, to eliminate (1) couriers and (2) manual entry of clear key-encrypting keys. While this is an improvement over a DEA-based cryptographic system, the prior art does not teach how to eliminate a requirement for manual entry of clear keys altogether. Except in special situations, each cryptographic device will need several, and perhaps many, key pairs to perform the tasks of key management and data management. The most practical means for doing this is to make use of a system master key under which, at least, the private keys of the public key algorithm are encrypted for storage in a cryptographic key data set. It is also argued in co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors") that it is sometimes advantageous to encrypt the public keys for storage in a cryptographic key data set, even though this is not done to keep the public keys secret. Thus, it would be advantageous for the cryptographic system key management to be designed so that the need for manual entry of keys, including the master key itself, is completely eliminated. This would permit cryptographic systems to be used in places where it is impractical or infeasible for a secret master key to be manually loaded into the cryptographic device. In so doing, cryptographic systems could now be designed so that their initialization is fully automated, i.e., not requiring couriers and not requiring the manual entry of keys by humans.

Also note that if all manual entry of keys could be eliminated, this would allow a potential higher level of security to be established for the system, as no human, authorized or not, would be able to introduce known key values into the system which, if entered, would allow the possibility of off-line decryption of anything encrypted under the known quantity.

However, once a mechanism exists for the automatic generation of a system master key, this implies that the master key is not known to anyone or any device except the cryptographic device in which it is generated. This raises the potential that a cryptographic device may accidentally lose its master key due to a system malfunction (hardware malfunction, lighting strike, etc.) causing the master key to be accidentally erased or unusable. In such an event, the keys under which the master key are encrypted are, for practical purposes, lost. That is, the keys are lost in the sense that there is no way that the cryptographic system can now decrypt them, which is required before the keys may be used or processed within the secure boundary of the cryptographic hardware. Therefore, an automatically generated master key also requires a means for backup and recovery. In many cryptographic systems, such as described in U.S. Pat. Nos. 4,850,017, 4,941,176, 4,918,728, 4,924,514, 4,924,515, and 5,007,089, and co-pending patent applications Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors"), etc., the cryptographic hardware is initialized with configuration data as well as other cryptographic variables, including keys, such as the master key. The configuration data personalizes a device, e.g., uniquely identifies a device and restricts the processing options that the device is permitted to perform, including the possibility of crippling the ability to manually enter keys. Thus, in order for cryptographic devices to be easily recoverable in the event that a master key is lost, a means must be provided that permits the keys and configuration data stored in the cryptographic hardware to be ported from one cryptographic device for recovery in another cryptographic device.

OBJECTS OF THE INVENTION

It is therefore an object of the invention to provide an improved method of key management in a public key cryptographic system.

It is another object of the invention to provide a cryptographically secure method for the cryptographic environment of one cryptographic device to be backed up and recovered within another cryptographic device.

It is another object of the invention to permit the keys and cryptographic variables initialized within the cryptographic hardware of one device to be securely ported and reinitialized within the cryptographic hardware of another device.

It is another object of the invention to provide a cryptographically secure method for the cryptographic environment of one cryptographic device to be replicated within another cryptographic device or devices for the purpose of increased processing capability and/or reliability.

It is another object of the invention to permit the keys and cryptographic variables initialized within the cryptographic hardware of one device to be securely ported and replicated within the cryptographic hardware of another device or devices for the purpose of increased processing capability and/or reliability.

It is another object of the invention to provide a key management scheme in which no cryptographic keys need to be manually loaded within the cryptographic device.

It is another object of the invention to provide a key management scheme in which the system master key, used for encrypting keys stored outside the secure hardware, is generated within cryptographic hardware so that its value is not known outside the cryptographic hardware.

It is another object of the invention to provide a means for backup and recovery in situations where the master key is known only to the cryptographic hardware.

It is another object of the invention to provide a key management scheme in which the public and private key pairs generated at a cryptographic device are encrypted under a master key known only to the cryptographic hardware so that the private keys are also known only to the cryptographic hardware.

It is another object of the invention to provide a key management scheme in which the cryptographic devices within a cryptographic network can implement an authentication scheme based on digital signatures using private keys known only to the cryptographic hardware such that the digital signatures are generated only on cryptographic quantities produced within the cryptographic hardware as the result of executing a cryptographic instruction, and not on data supplied by the application program or the cryptographic software.

SUMMARY OF THE INVENTION

These and other objects, features, and advantages are accomplished by the invention disclosed herein.

Environment Description: FIG. 1 illustrates a network block diagram showing a communications network 10 to which is connected a plurality of data processors including data processor 20, data processor 20', and data processor 20". Also included in each data processor is a cryptographic system, as shown in FIG. 1. Data processor 20 includes cryptographic system 22, data processor 20' includes cryptographic system 22' and data processor 20" includes cryptographic system 22". Each data processor supports the processing of one or more applications which require access to cryptographic services, such as for the encryption, decryption and authentication of application data and the generation and installation of cryptographic keys. The cryptographic services are provided by a secure cryptographic facility in each cryptographic system. The network provides the means for the data processors to send and receive encrypted data and keys. Various protocols, that is, formats and procedural rules, govern the exchange of cryptographic quantities between communicating data processors in order to ensure the interoperability between them.

FIG. 2 illustrates the cryptographic system 22. In the cryptographic system 22, the cryptographic facility (CF) 30 has an input 37 from a physical interface. The cryptographic facility access program (CFAP) 34 is coupled to the cryptographic facility 30 by means of the interface 31. The cryptographic key data set (CKDS) 32 is connected to the cryptographic facility access program 34 by means of the interface 33. The application programs (APPL) 36 are connected to the cryptographic facility access program 34 by means of the interface 35.

A typical request for cryptographic service is initiated by APPL 36 via a function call to the CFAP 34 at the interface 35. The service request includes key and data parameters, as well as key identifiers which the CFAP 34 uses to access encrypted keys from the CKDS 32 at the interface 33. The CFAP 34 processes the service request by issuing one or more cryptographic access instructions to the CF 30 at the interface 31. The CF 30 may also have an optional physical interface 37 for direct entry of cryptographic variables into the CF 30. Each cryptographic access instruction invoked at the interface 31 has a set of input parameters processed by the CF 30 to produce a set of output parameters returned by the CF 30 to the CFAP 34. In turn, the CFAP 34 may return output parameters to the APPL 36. The CFAP 34 may also use the output parameters and input parameters to subsequently invoke instructions. If the output parameters contain encrypted keys, then the CFAP 34, in many cases, may store these encrypted keys in the CKDS 32.

FIG. 3 illustrates the cryptographic facility 30. The cryptographic facility 30 is maintained within a secure boundary 140. The cryptographic facility 30 includes the instruction processor 142 which is coupled to the cryptographic algorithms 144 which are embodied as executable code. The cryptographic facility environment memory 146 is coupled to the instruction processor 142. The physical interface can be coupled over line 37 to the CF environment memory 146, as shown in the figure. The instruction processor 142 is coupled to the cryptographic facility access program (CFAP) 34 by means of the interface at 31.

The instruction processor 142 is a functional element which executes cryptographic microinstructions invoked by the CFAP access instruction at the interface 31. For each access instruction, the interface 31 first defines an instruction mnemonic or operation code used to select particular microinstructions for execution. Secondly a set of input parameters is passed from the CFAP 34 to the CF 30. Thirdly, a set of output parameters is returned by the CF 30 to the CFAP 34. The instruction processor 142 executes the selected instruction by performing an instruction specific sequence of cryptographic processing steps embodied as microinstructions stored in cryptographic microinstruction memory 144. The control flow and subsequent output of the cryptographic processing steps depend on the values of the input parameters and the contents of the CF environment memory 146. The CF environment memory 146 consists of a set of cryptographic variables, for example keys, flags, counters, CF configuration data, etc., which are collectively stored within the CF 30. The CF environment variables in memory 146 are initialized via the interface 31, that is by execution of certain CF microinstructions which read input parameters and load them into the CF environment memory 146. Alternately, initialization can be done via an optional physical interface which permits cryptographic variables to be loaded directly into the CF environment memory 146, for example via an attached key entry device. The physical embodiment of the cryptographic facility secure boundary 140, incorporates the following physical security features. The physical embodiment resists probing by an insider adversary who has limited access to the cryptographic facility 30. The term "limited" is measured in minutes or hours as opposed to days or weeks. The adversary is constrained to a probing attack at the customer's site using limited electronic devices as opposed to a laboratory attack launched at a site under the control of the adversary using sophisticated electronic and mechanical equipment.

The physical embodiment also detects attempts at physical probing or intruding, through the use of a variety of electro-mechanical sensing devices. Also, the physical embodiment of the cryptographic facility 30 provides for the zeroization of all internally stored secret cryptographic variables. Such zeroization is done automatically whenever an attempted probing or intrusion has been detected. The physical embodiment also provides a manual facility for a zeroization of internally stored secret cryptographic variables. Reference to the Abraham, et al. patent application cited above, will give an example of how such physical security features can be implemented.

Backup and Recovery Procedure: FIG. 4 is a block diagram illustration of the backup and recovery process involving two cryptographic devices, A and B. Cryptographic device A is the backed up device and cryptographic device B is the recovery device. Referring to FIG. 4, cryptographic device A contains, at least, cryptographic facility 30 and a key storage (i.e., cryptographic key data set) 32. Cryptographic facility 30 provides a set of callable cryptographic instructions (not shown) to the cryptographic facility access program (CFAP). Cryptographic facility 30 contains a cryptographic facility (CF) environment 146. The CF environment 146 represents that part of the cryptographic facility that can be configured and initialized with keys, cryptographic variables, and configuration data. In this sense, the CF environment 146 is that part which is personalized by the installation or the owner of the cryptographic device. The CF environment 146 consists of non-portable part 103 and a portable part 104. The non-portable part 103 represents that part of the CF environment that does not port as part of the backup and recovery procedure. The portable part 104, on the other hand, represents that part of the CF environment that does port as part of the backup and recovery procedure. More is said about the portable and non-portable parts below. The randomly generated master key 105 is one example of information contained in the portable part 104. Note that the randomly generated master key may be generated by a true random number generator or by a pseudorandom number generator where the seed values have been generated with sufficient variability to thwart attempts at guessing the seed values. Discussion of true random and pseudorandom number generators is found in the literature and in U.S. Pat. No. 4,941,176 and co-pending patent application Ser. No. 07/766,533 ("Generating Public and Private Key Pairs Using a Passphrase").

Key storage 32 (also called the cryptographic key data set) contains PU key tokens and PR key tokens. The key token contains a header, a control vector, and encrypted key record, and an encrypted authenticator record, as explained in detail in co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based On Control Vectors") cited in the Background Art. The key record contains either a public key PU or a private key PR, where PU and PR are the public and private keys associated with an asymmetric or public key algorithm. The key records and authenticator records are encrypted with randomly generated master key 105 using a method described in detail in co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based On Control Vectors") cited in the Background Art. However, because the master key is randomly generated within the CF 30, and not manually installed into the CF 30 by a human, randomly generated master key 105 is not known to any person or device except to CF 30. Thus, if randomly generated master key 105 should be accidentally erased or corrupted due to a hardware malfunction, then the public and private keys stored in the PU and PR key tokens in key storage 32 would not be recoverable within CF 30. Hence, for practical purposes, the public and private keys at device A would be unusable or unrecoverable. As a defense against the loss of randomly generated master key 105, and hence against the loss of the public and private keys stored in key storage 32, a backup and recovery procedure is made available at all cryptographic devices. FIG. 4 illustrates that the backup and recovery process involves porting the portable part 104 of cryptographic device A at step 107 to cryptographic device B. In addition, the backup and recovery process involves porting the key tokens in key storage 32 of cryptographic device A at step 106 to cryptographic device B. The process of porting the key tokens does not involve cryptography, since the keys are in a form that they can be safely transmitted from device A to device B. Mechanisms for sending, receiving, and installing these key tokens, of course, must be implemented and made available as part of the backup and recovery procedure. However, this part of the procedure is straightforward and is therefore not discussed in any great detail. The part of the backup and recovery procedure that involves porting the portable part 104, is more complicated. The portable part 104 contains both secret and non-secret information. The secret information must be protected between device A and device B, i.e., during the time when the secret information is exposed outside the secure hardware (i.e., the CF) at devices A and B. An adversary who intercepts the portable part at 107 must not be able to discern or recover any of the secret information contained in the portable part. Hence, encryption must be used between devices A and B to protect this secret information. This is accomplished by using device B's public device key to encrypt the secret information. Note that it is essential that device A be assured that it is actually a public device key that is used to encrypt the secret data (and not some other type of public key, especially a bogus public key where an attacker knows the associated private key), that it is device B's device key and not some other device's, and that device B is authorized to contain device A's environment information. In addition, the integrity of the secret and non-secret information must be ensured. An adversary who intercepts the portable part at 107 must not be able to modify the information or replace the portable part at 107 with information chosen by the adversary. Otherwise, without a means for device B to authenticate the portable part from device A, device B may import a portable part that has been changed and which does not represent the portable part originally at device A. For example, if an adversary could change the value of a public key to one of his own choosing, then when the portable part is recovered at device B the adversary would now have planted a false key in device B.

Referring again to FIG. 4, given a device to be backed up, say device A, and a device to be the recovery device, say device B, the backup and recovery procedure permits the portable part 104 of cryptographic device A to be safely and securely ported to cryptographic device B and initialized within the portable part 104' of device B. That is, the portable part 104 of device A replaces the portable part 104' of device B. In addition, the keys in key storage 32 of device A replace the keys in key storage 32' of device B. At device A, the portable part is exported using an Export Cryptographic Facility Environment Record (ECFER) instruction and, at device B, the portable part is imported using an Import Cryptographic Facility Environment Record (ICFER) instruction. The ECFER and ICFER instructions are also described in co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based On Control Vectors") cited in the Background Art.

FIG. 5 is a block diagram illustration showing the use of the ECFER and ICFER instructions in the backup and recovery process. Referring now to FIG. 5, cryptographic facility 30 at device A contains a non-portable part 103, a portable part 104, and an ECFER instruction 108. Cryptographic facility 30' at device B contains a non-portable part 103', a portable part 104', and an ICFER instruction 109'. Actually, cryptographic facility 30 at device A contains an ICFER instruction 109 (not shown) and cryptographic facility 30' at device B contains an ECFER instruction 108' (not shown), which makes the implementations symmetric. At device A, the ECFER instruction produces (1) a Cryptographic Variable (CVAR) 110 and (2) an External Crypto Facility Environment Record (XCFER) 111, from the portable part 104 and other information stored within CF 30 (not shown) and other information supplied as input to the ECFER instruction from outside the CF 30 (not shown), explained in greater detail below. The CVAR 110 is an authenticator that permits device B to authenticate the XCFER. In an alternate embodiment, the CVAR is an encrypted crypto facility DEA backup key record containing a DEA key used to encrypt the secret part of portable part 104 and an authenticator that permits device B to authenticate the XCFER. Each of these embodiments are explained in greater detail below. The XCFER 111 contains an encrypted secret part prepared from the secret part of portable part 104 and a non-secret part prepared from the non-secret part of portable part 104.

Note that, as described, the backup process may be used to allow recovery of the information on device A by device B when device A suffers a unrecoverable hardware or software failure. It may also be used as a method for initializing device B with the same configuration data as device A, even though device A has not experienced a failure. This would allow increased performance by allowing multiple servers and may possibly simplify the initialization step and ensure the configurations are the same. This would also enhance reliability as redundancy of cryptographic facilities would eliminate a source of single point of failure. Even beyond the initialization step, the backup and recovery process may be used to replicate (i.e., clone) the identifying characteristics and configuration of one system to one or more other systems. This could be done to allow dynamic reconfiguration of the physical components of the system to provide for increased performance and/or reliability as these requirements are identified.

FIG. 6 is a block diagram illustration of Crypto Facility Environment Record (CFER) 11 and External Crypto Facility Environment Record (XCFER) 111. CFER 11 consists of a header 12 containing length and displacement information and indicating the record is a CFER, a secret part 13, and a non-secret part 14. Secret part 13 is just the secret part of portable part 104. Non-secret part 14 is just the non-secret part of portable part 104. XCFER 111 consists of a header 112, an encrypted secret part 113, and a non-secret part 14. For practical purposes, header 112 is the same as header 12 except that it indicates the record is an XCFER instead of a CFER. Encrypted secret part 113 is formed by encrypting the secret part 13 in the CFER. The non-secret part 13 is the same in both the CFER and the XCFER.

Returning now to the FIG. 5, the CVAR and XCFER are returned to the CFAP 34 (i.e., the cryptographic software) at 107 and transmitted to cryptographic device B. At cryptographic device B, the XCFER is imported using an ICFER instruction. The ICFER instruction recovers the CFER, and hence the portable part 104, from the received XCFER supplied as an input and other information stored within CF 30' (not shown) and other information supplied as input to the ICFER instruction from outside the CF 30' (not shown), explained in greater detail below. The ICFER instruction also authenticates the XCFER, or equivalently the recovered CFER (containing portable part 104), using information stored within the CF 30' (not shown) and other information supplied as input to the ICFER instruction from outside the CF 30' (not shown), explained in greater detail below. If the step of authentication succeeds, the ICFER instruction continues; otherwise, if the step of authentication fails, the ICFER instruction is aborted and the recovered portable part 104 is not imported. The reader will appreciate that in some embodiments the step of authentication could be performed before the recovery of portable part 104 or could be performed after the recovery of portable part 104 (i.e., before or after the decryption step to decrypt and recover the clear secret part of portable part 104). The so-recovered portable part 104 is then used to replace the portable part 104' in cryptographic device B. The key tokens in the key storage at device A are also transmitted to device B and replace the key tokens in the key storage at device B, not shown in FIG. 5. Once portable part 104' has replaced portable part 104' and once the key tokens in key storage of device A have replaced the key tokens in key storage of device B, device B is for all intents and purposes now a replicated copy or clone of device A.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other objects, features, and advantages of the invention will be more fully appreciated with reference to the accompanying figures.

FIG. 1 illustrates a communications network 10 including a plurality of data processors, each of which includes a cryptographic system.

FIG. 2 is a block diagram of a cryptographic system 22.

FIG. 3 is a block diagram of a cryptographic facility 30.

FIG. 4 is a block diagram illustration of the backup and recovery process involving two cryptographic devices, A and B.

FIG. 5 is a block diagram illustration showing the use of the ECFER and ICFER instructions in the backup and recovery process.

FIG. 6 is a block diagram illustration of Crypto Facility Environment Record (CFER) 11 and External Crypto Facility Environment Record (XCFER) 111.

FIG. 7 is a block diagram illustration of the non-portable part 103 of a cryptographic facility environment.

FIG. 8 is a block diagram illustration showing the initialization of the non-portable part 103 of a cryptographic facility environment.

FIG. 9 is a block diagram illustration of portions of the cryptographic facility environments 146 and 146' at cryptographic devices A and B, respectively.

FIG. 10 is a block diagram illustration of the various information fields in portable part 104.

FIG. 11 is a block diagram illustration of a first embodiment of the subject invention in which cryptographic variable (CVAR) 110 is a digital signature generated on the secret and non-secret parts using the private device authentication key PRA of the sending or exporting device.

FIG. 12 is a block diagram illustration of a second embodiment of the subject invention in which cryptographic variable (CVAR) 110 is an encrypted crypto facility backup DEA key block (ECFBDKB).

FIG. 13 is a block diagram illustration of the EPUK instruction.

FIG. 14 illustrates the format of an external public key token.

FIG. 15 is a block diagram illustration of the IPUK instruction.

FIG. 16 illustrates the format of an internal PU key token.

FIG. 17 is a block diagram illustration of the computational steps performed by the ECFER instruction.

FIG. 18 is a block diagram illustration of the computational steps performed by the ICFER instruction.

FIG. 19 is a block diagram showing the production of an internal key token from a key record and the production of an external key token from a key record.

FIG. 20 is a block diagram showing the production of an internal key token from an internal key unit produced from a key record and the production of an external key token from an external key unit produced from a key record.

FIG. 21 is a block diagram illustration of the backup and recovery protocol between devices A and B.

FIG. 22 is a block diagram illustration of a first embodiment of portable part exporting means 303.

FIG. 23 is a block diagram illustration of a second embodiment of portable part exporting means 303.

FIG. 24 is a block diagram illustration of a first embodiment of portable part importing means 304'.

FIG. 25 is a block diagram illustration of a second embodiment of portable part importing means 304'.

DESCRIPTION OF THE BEST MODE FOR CARRYING OUT THE INVENTION

Non-Portable Part: FIG. 7 is a block diagram illustration of the non-portable part 103 of the cryptographic facility environment of device A, actually of any device A, B, C, etc. Non-portable part 103 contains a public device authentication key (PUA) 114, a private device authentication key (PRA) 115, and a device identifier (DID) 116. DID 116 is a value, of say 128 bits, that uniquely identifies the device within the network. The DID may even be chosen so that it uniquely identifies the device within multiple networks, according to some agreement among the parties who adhere to an agreed-to naming convention. The PUA key 114 and PRA key 115 are a public and private key pair associated with an asymmetric or public key algorithm, such as the RSA public key algorithm. The PUA and PRA keys play a special role in the backup and recovery process, as explained below. The unique feature of the PUA and PRA keys is that they are generated within the cryptographic hardware (i.e., the CF) in such a way that no person and no other cryptographic device ever knows the clear value of the private key PRA. The cryptographic hardware (i.e., the CF) has no means to permit the PRA key to be exported. On the other hand, the PUA key can be exported and shared with other cryptographic devices, as explained below. Note that even though the PUA key is termed a device authentication key and as such is used to verify the signatures produced by a device, it will also be used for encryption (for secrecy), either directly or indirectly, of the secret portion of the cryptographic facility environment record.

Initialization via the GDAK and LPID Instructions: FIG. 8 is a block diagram illustration showing the initialization of the non-portable part 103 of a cryptographic facility environment. Referring to FIG. 8, a Generate Device Authentication Key Pair (GDAK) instruction 117, which is one of the cryptographic instructions available within the CF 30, is used to initialize the PUA and PRA keys within non-portable part 103. When GDAK instruction 117 is invoked, it causes a (PUA,PRA) key pair to be generated within the CF 30. Note that the GDAK invocation requires use of a true random number generator or a pseudo-random number generator which has been seeded with sufficient variability to supply the arbitrary length random number from which the public and private key pair will be generated. See co-pending patent application Ser. No. 07/766,533 ("Generating Public and Private Key Pairs Using a Passphrase"), cited in the background art. The generated PUA key is stored as Public Device Authentication Key (PUA) 114 in non-portable part 103 of the CF 30. The generated PRA key is stored as Private Device Authentication Key (PRA) 115 in non-portable part 103 of the CF 30. The intention is that means do not exist permitting the PRA key stored at 115 to be exported or returned as a clear value to the cryptographic software (i.e., the CFAP). On the other hand, the intention is that means do exist (not shown here) permitting the PUA key stored at 114 to be exported or returned as a clear.

Referring again to FIG. 8, a Load Physical Device Identifier (LPID) instruction 118, which is one of the cryptographic instructions available within the CF 30, is used to initialize the device identifier within non-portable part 103. When LPID instruction 118 is invoked, it causes a device identifier specified as an input to the GDAK instruction, referred to as the DID value, to be stored as Device Identifier (DID) 116 in non-portable part 103 of the CF 30. The LPID instruction 118 also causes the same DID value to be stored as Logical Device Identifier (LDID) 119 in portable part 104 of the CF 30. The distinction between the Device Identifier (DID) and the Logical Device Identifier (LDID) is the following: when a device is backed up, the LDID value ports within the XCFER, whereas the DID value does not. The physical identifier of a device remains constant, whereas the logical device identifier may change. It is important that devices have both a physical and a logical identifier. The physical identifier identifies the physical device, which at times is an important aspect of ensuring the integrity of the cryptographic protocols used within a cryptographic network, including the backup and recovery protocol described here. For example, the DID identifies a device to its users. Thus, users can be certain that they are interacting with the correct device. The DID value can be read from a device using a device audit function, such as an Export Crypto Facility Audit Record (ECFAR) instruction described in co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors"), cited in the background art. On the other hand, the logical identifier identifies the logical device, which is also an important aspect of ensuring the integrity of the cryptographic protocols. For example, in situations where a public key algorithm is used to distribute DEA keys as part of a hybrid key distribution protocol, such as the hybrid key distribution protocol described in co-pending patent application Ser. No. 07/602,989 ("Method and Apparatus for Controlling the Use of a Public Key, Based on the Level of Import Integrity for the Key"), cited in the background art, the LDID value 119 is called an Environment Identifier (EID) and is used as an anti-reimport value. This is accomplished in the Generate Key Set PKA (GKSP) instruction by storing the value of EID of the generating device within the key block to be encrypted and transmitted to a receiving device. The Import DEA Key (IDK) instruction checks to ensure that the EID value in the recovered (decrypted) key block is not equal to the EID value (i.e., the LDID 119) in the CF 30. Consider another example wherein a public key algorithm is used to distribute DEA keys as part of a hybrid key distribution protocol and the protocol requires that the public keys to be first registered at a certification center so that certificates and signatures on those certificates prepared with the private key of the certification center can be produced and issued within the network. In such a case, the certificate will ordinarily contain the identifier of the owner or creator of the public key, which may be a device identifier. That is, the public key may be associated with a cryptographic device, in which case it is, or may be, necessary that the key be registered using a logical device identifier (not a physical device identifier). In that way, the certificates containing the logical device identifier will not be invalidated in the event that a device is backed up and recovered at another device. This is so, because the logical device identifier in the portable part 104 is ported in the XCFER to the recovery device. Likewise, the CF 30 is now able to confirm that a certificate containing an LDID value does or does not belong to this device by simply comparing the LDID value in the certificate with the LDID value stored in Logical Device Identifier 119 of the CF 30. The LPID instruction is explained in detail in co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors"), cited in the Background Art. Those skilled in the art will recognize that the descriptions of the GDAK and LPID instructions pertain to the initialization of any cryptographic hardware, whether it be device A, device B, etc.

FIG. 9 is a block diagram illustration of portions of the cryptographic facility environments 146 and 146' at cryptographic devices A and B, respectively. Referring to FIG. 9, at device A the GDAK instruction 117 and the LPID instruction 118 are, or have been used to initialize values PUAa, PRAa, DIDa, and LDIDa at 114, 115, 116, and 119, respectively. At device B the GDAK instruction 117' and the LPID instruction 118' are, or have been used to initialize values PUAb, PRAb, DIDb, and LDIDb at 114', 115', 116', and 119', respectively. From this configuration, the reader will see that for a given DID value, the value of PUA and PRA may change over time via subsequent executions of the GDAK and LPID instructions. However, there is no way for installation personnel or users to cause the cryptographic hardware (i.e., the CF) to generate and assign the same values of PUA and PRA to different values of DID, except as may occur by mere chance. However, for keys that are derived from more than 128 independently generated bits, which is ordinarily the case for keys used with an asymmetric key algorithm, the accidental chance of reproducing a key pair is so remote that, for practical purposes, it is of no concern whatsoever. The GDAK and LPID instructions are also implemented in such a way that neither instruction can be executed without executing the other, see co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors"), cited in the background art. Thus, for practical purposes, each different value of DID initialized within the cryptographic hardware (i.e., the CF) will have a different generated key pair (PUA,PRA). Consequently, in a network of cryptographic devices, each device with a unique assigned device identifier, DID value, also has a unique associated (PUA,PRA) key pair that can be used to "prove" its identity (i.e., the identify of the hardware device) to any other hardware device. Now, if device A is backed up and recovered at device B, the non-portable part 103' remains unchanged, i.e., value PUAb, PRAb, and DIDb are not altered. Only the portable part 104' at device B is changed. In that case, the value of LDIDb at 119' is replaced with the value of LDIDa at 119. Of course, there are many other values in the portable part 104 of device A that replace the portable part 104' of device B.

Portable Part: FIG. 10 is a block diagram illustration of the information fields in portable part 104. Those skilled in the art will recognize that portable part 104 can contain many other secret and non-secret fields without detracting from the spirit of the intended invention. Thus, those skilled in the art will appreciate that the described invention is not limited by, or in its use, to only those fields described in FIG. 10. Referring now to FIG. 10, portable part 104 contains a secret part 150 and a non-secret part 160. Secret part 150 contains master key registers 151 and pseudorandom number generator seed keys 152. Master key registers 151 may include new, current, and old master keys, as well as separate master keys for encrypting DEA keys and PKA keys. Pseudorandom number generator seed keys 152 consist of one or more seed keys used to initialize the pseudorandom number generator. Non-secret part 160 contains a logical device identifier (LDID) 119, also sometimes referred to as an Environment Identifier (EID), a configuration vector 161, a state vector 162, key import MDCs 163, program load MDCs 164, and PIN tables 165. Logical device identifier 119 has a ready been explained (see the descriptions of FIG. 8 and FIG. 9). Configuration vector 161 contains a set of encoded fields that define and limit the use of the CF. In many respects, the configuration vector is similar to a control vector, except that a control vector defines and limits the use of a cryptographic key whereas the configuration vector defines and limits the use of the entire cryptographic facility. For example, the configuration vector can "turn on" or "turn off" cryptographic instructions, so that a cryptographic instruction will execute only if it is "turned on." Another use of the configuration vector, as it relates to the use of the ECFER and ICFER instructions, is to limit the protocol modes permitted by the ECFER and ICFER instruction. As explained below, the ECFER and ICFER instructions have three different protocol modes, with differing degrees of cryptographic security (low to high). Through the configuration vector, an installation can set the protocol mode or modes permitted for backup and recovery, and thereby establish the minimum level of security under which backup and recovery may be performed. The configuration vector is described in greater detail in co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors"), cited in the background art. State vector 162 contains a set of encoded fields that describe the present state of the cryptographic facility. For example, the state vector contains flags indicating whether the master key or keys have been initialized or not. The state vector 162 may also contain history information such as cryptographic instructions that have been executed, and possibly a count of the number of executions, that may be used for auditing purposes. The state vector may also contain a flag to indicate whether the cryptographic facility is or is not a clone of another device. For example, the clone flag is set by the ICFER instruction at the time it executes to import an XCFER. Key import MDCs 163 consist of one or more MDCs (or cryptographic hash values) used as a means to import external key tokens (or external key units) received from other devices, such a external key tokens containing public keys. The Import Public Key (IPUK) instruction described in co-pending patent applications Ser. No. 07/602,989 ("Method and Apparatus for Controlling the Use of a Public Key, Based on the Level of Import Integrity for the Key"), and Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors"), cited in the background art, provides a means for importing public keys stored in external key units with an option to import only if an MDC value calculated on the external key unit matches an MDC value pre-stored in the cryptographic facility (i.e., in key import MDCs 163). Program load MDCs 164 consist of one or more MDCs (or cryptographic hash values) used as a means to securely load executable programs into the cryptographic facility. A program is loaded only if an MDC value calculated on the program matches an MDC value pre-stored in the cryptographic facility (i.e., in program load MDCs 164). PIN tables 165 consists of one or more PIN tables that contain configuration data specifying how the cryptographic instructions performing PIN manipulations are to be executed. The term PIN (for Personal Identification Number) is used in banking applications to refer to a 4 to 6 decimal digit value used to authenticate a banking customer to an automated teller machine. Instruction processor 142 in FIG. 3 contains a set of cryptographic instructions for performing a variety of cryptographic services, including data services, PIN services, key management and key handling services, etc. Co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors"), cited in the background art, lists and describes a set of cryptographic instructions for implementing public key cryptography.

First Embodiment: FIG. 11 is a block diagram illustration of a first embodiment of the subject invention in which cryptographic variable (CVAR) 110 is a digital signature generated on the secret and non-secret parts using the private device authentication key PRA of the sending or exporting device. The secret part of portable part 104 contained in the XCFER 111 is encrypted with the public device authentication key PUA of the receiving or importing device. Thus, if device A is being backed up for recovery at device B, then the digital signature is calculated using PRAa, the private key of device A and the secret part is encrypted with PUAb, the public key of device B. If the length of the secret part is greater than can be accommodated using one encryption of PUAb, it is necessary to divide the secret part into n blocks, where each block is capable of being encrypted with public key PUAb. The method of calculating the digital signature with private key PRAa is not important to the present invention, and any method described in the prior art will suffice. A method for calculating digital signatures is described in co-pending patent application Ser. No. 07/748,407 ("A Hybrid Public Key Algorithm/Data Encryption Algorithm Key Distribution Method Based on Control Vectors"), cited in the Background Art. In summary, the method consists of first calculating a hash value on the data to be signed, in this case the concatenation of the secret and non-secret parts (the order is unimportant). The hash algorithm must be a cryptographic one-way function that ensures it is not computationally feasible to find two data inputs that hash to the same output hash value. One such function that satisfies this cryptographic requirement is the MDC-2 algorithm described in U.S. Pat. No. 4,908,861 requiring 2 DEA encryption steps for each 64-bit block of input contained in the data to be signed. The MDC-2 algorithm is also described in a paper by S. M. Matyas entitled "Key Handling with Control Vectors," IBM Systems Journal, Volume 30, No. 2, 1991, pp. 151-174. The so-produced hash value is then formatted in a suitable signature block and decrypted with the private key used for signing (in this case PRAa) to produce the digital signature (referred to as DSIG). In the simplest case, the signature block consists of the hash value and padding data, as may be needed as part of the decryption process. Note that the term decryption is used when performing operations with the private key and the term encryption is used when performing operations with the public key. Actually, in some public key algorithms there is no difference between encryption and decryption except as may be distinguished by which key is being used. In those cases, it may be just as appropriate to say encryption with the private key or decryption with the public key, and those skilled in the art will recognize that these differences in naming and convention of usage do not detract from the spirit of the invention, and that these variations are covered by the present invention.

At the receiving device, the recovery operation proceeds as follows. The encrypted secret part is decrypted using PRAb, the private key of device B. Then the clear secret part and the non-secret part are authenticated using the digital signature. Different processes for signature verification do exist and can be used. These differences may depend on adherence to some digital signature standard, e.g., International Standards Organization draft international standard (ISO DIS) 9796, or may depend on the particular public key algorithm being used. The precise method of signature verification is again unimportant to the present invention, and those skilled in the art will recognize that the present invention does not intend to be limited to a particular method for generating or verifying digital signatures. However, one method is to encrypt the digital signature with PUAa, the public key of device A, to recover the signature block. Then, a hash value is calculated on the concatenation of the recovered secret part and the received non-secret part and the calculated hash value is compared for equality with the hash value in the recovered signature block. If the comparison is favorable (i.e., equal hash values), then the XCFER is valid; otherwise, if the comparison is not favorable (i.e., not equal hash values), then the XCFER is not valid. In an alternate embodiment, the digital signature is calculated on the XCFER itself, that is, on the concatenation of the encrypted secret part and the clear non-secret part. In either case, if the signature verification step succeeds, then the recovered secret part and the received non-secret part, which comprise the portable part 104 of device A replaces the portable part 104' of device B.

Second Embodiment: FIG. 12 is a block diagram illustration of a second embodiment of the subject invention in which cryptographic variable (CVAR) 110 consists of (a) an encrypted crypto facility backup DEA key block (ECFBDKB) 134 as described in greater detail in co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors"), cited in the background art, and (b) a digital signature generated on the encrypted crypto facility backup DEA key block using the private device authentication key PRA of the sending or exporting device 135. Basically, the ECFBDKB is produced by padding a clear crypto facility backup DEA key record (CFBDKR) as necessary to form a crypto facility backup DEA key block (CFBDKB), then encrypting the CFBDKB with PUAb, the public key of Device B. The CFBDKR is a record consisting of a DEA key K 130, authenticator 131, and other control fields (not shown in FIG. 12). The secret part of portable part 104 is encrypted with DEA key K 130 to form encrypted secret part 112. The authenticator 131 is a cryptographic one-way function of the concatenation of the secret part and the non-secret part. For example, authenticator 131 can be a 128-bit modification detection code calculated using the MDC-2 algorithm mentioned above.

At the receiving device, the recovery operation proceeds as follows. The ECFBDKB is first authenticated using the supplied digital signature, i.e., digital signature calculated on ECFBDKB using PRA of sending device A. Different processes for signature verification do exist and can be used. These differences may depend on adherence to some digital signature standard, e.g., International Standards Organization draft international standard (ISO DIS) 9796, or may depend on the particular public key algorithm being used. The precise method of signature verification is unimportant to the present invention, and those skilled in the art will recognize that the present invention does not intend to be limited to a particular method for generating or verifying digital signatures. One method for handling digital signatures has already been described above under the section describing a first embodiment of the invention. Assuming that the digital signature verifies properly, the ECFBDKB is then decrypted using PRAb, the private key of device B, to recover the clear value of CFBDKB and the process continues. Otherwise the process is halted. The CFBDKR containing the DEA key K 130 and authenticator 131 is then extracted from the CFBDKB. Then the encrypted secret part is decrypted using the DEA key K 130 extracted from the CFBDKR. Then the clear secret part and the non-secret part are authenticated using the authenticator 131 extracted from the CFBDKR. Different processes for authentication are possible, and those skilled in the art will recognize that the present invention does not depend on using a particular method of authentication. However, when authenticator 131 is calculated with a cryptographic one-way hash value, then the authentication process consists of re-calculating a hash value on the concatenation of the recovered secret part and the received non-secret part and comparing the calculated hash value for equality with authenticator 131 in the CFBDKR. If the comparison is favorable (i.e., equal hash values), then the XCFER is valid; otherwise, if the comparison is not favorable (i.e., not equal hash values), then the XCFER is not valid. In an alternate embodiment, the authenticator is calculated on the XCFER itself, that is, on the concatenation of the encrypted secret part and the clear non-secret part. In either case, if the authentication step succeeds, then the recovered secret part and the received non-secret part which comprise the portable part 104 of device A replaces the portable part 104' of device B.

When the cryptographic system contains both a symmetric and an asymmetric cryptographic algorithm, the second embodiment is the preferred embodiment. The reason for this is that encrypting a secret part that may be very long can be performed very quickly with a symmetric algorithm like the DEA. This is also advantageous since it introduces no requirement for encryption of long blocks, i.e., blocks longer than the block size of the algorithm, with the public key algorithm. Thus, it may be possible to implement the public key algorithm in such a way that only single block encryption and decryption needs to be supported. This will simplify the implementation of the public key algorithm.

Distribution of PUA Keys: In order that the ECFER and ICFER instructions can be made operable, it is necessary for the exporting and importing (i.e., the sending and receiving) cryptographic devices to exchange their respective PUA keys. For example, if device A is to be backed up and recovered at device B, then PUAa must be given to device B and PUAb must be given to device A. This is accomplished by using the Export Public Key (EPUK) and Import Public Key (IPUK) instructions described in co-pending patent applications with Ser. No. 07/602,989 ("Method and Apparatus for Controlling the Use of a Public Key, Based on the Level of Import Integrity for the Key") and Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors"), cited in the Background Art. FIG. 13 is a block diagram illustration of the EPUK instruction. The EPUK instruction permits, among other things, a PUA key stored internally within the CF 30 to be exported in the form of an external public key token. FIG. 14 illustrates the format of an external public key token. An external public key token consists of a header, a control vector, and a PU key record.

The external PU key token is similar to a PU key token, as described in co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors"), except that the external PU key token has no encrypted authenticator record and it contains a clear PU key record rather than an encrypted PU key record. Referring to FIG. 13, there is shown a CF 30 with an EPUK instruction 132, which executes in instruction processor 142, and a PUA key 114, which is contained in CF Environment 146. Instruction processor 142 and CF Environment 146 are not shown in FIG. 13. The EPUK instruction has an input parameter called PU-mode, which specifies to the EPUK instruction whether the public key to be exported is a PUA key contained within CF 30 (i.e., PU-mode=`PUA`) or a PU key contained in a PU key token (i.e., PU-mode=`not.sub.-- PUA`). When PU-mode=`not.sub.-- PUA` is specified, a PU key token is also supplied as an input to the EPUK instruction (not shown in FIG. 13). The EPUK instruction also has an option for producing a digital signature on the external PU key token using a private key contained in a PR key token supplied as an input to the EPUK instruction (not shown in FIG. 13). The EPUK instruction produces, as outputs, an external PU key token containing the exported public key and an optional length parameter indicating the length of the produced external PU key token. The inputs to the EPUK instruction of FIG. 13 are selected (i.e., PU-mode=`PUA`) so that the internal PUA key is exported. That is, the external PU key token produced by the EPUK instruction of FIG. 13 contains the PUA key of the device. Thus, in the example of devices A and B, device A executes an EPUK instruction to produce an external PU key token containing PUAa, the public device authentication key of device A, and device B executes an EPUK instruction to produce an external PU key token containing PUAb, the public device authentication key of device B. In the simplest case, device A sends the external PUAa key token to device B, where it is imported, and device B sends the external PUAb key token to device A, where it is imported. The method whereby devices A and B merely exchange their respective PUA keys is one method supported by the ECFER and ICFER instructions, and represents the lowest security mode permitted. Two other modes of PUA key exchange are supported by the ECFER and ICFER instructions. These additional modes are described below.

FIG. 15 is a block diagram illustration of the IPUK instruction. The IPUK instruction permits public keys stored in the form of external PU key tokens to be imported in the form of PU key tokens. For convenience, the PU key tokens described in co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors") shall be, at times, referred to as internal PU key tokens. Thus, the process of importing a public key consists of transforming an external PU key token into an internal PU key token. More specifically, the external PU key token containing a header, control vector, and clear key record is transformed into an internal PU key token containing a header, a control vector, and encrypted PU key record, and an encrypted authenticator record. This process consists of invoking the key record encrypt algorithm described in co-pending patent application Ser. No. 07/766,260 ("Public Key Cryptosystem Key Management Based on Control Vectors"), passing as arguments a control vector produced from the control vector in the external PU key token (as explained in co-pending patent application Ser. No. 07/602,989, "Method and Apparatus for Controlling the Use of a Public Key, Based on the Level of Import Integrity for the Key"), and the clear key record contained in the external PU key token. The outputs of the key record encrypt algorithm are the encrypted PU key record and encrypted authenticator record to be stored in the internal PU key token. The control vector stored in the internal PU key token is just the control vector passed as an input to the key record encrypt algorithm and the header stored in the internal PU key token is just the same header stored in the external PU key token except updated as necessary with length and displacement information permitting each of the fields to be accessed and recovered and updated to reflect that this is an internal PU key token instead of an external PU key token. FIG. 16 illustrates the format of an internal PU key token. The internal PU key token consists of a header, a control vector, an encrypted PU key record, and an encrypted authenticator record. Referring to FIG. 15, there is shown a CF 30 with an IPUK instruction 133, which executes in instruction processor 142. Instruction processor 142 is not shown in FIG. 15. The IPUK instruction has as inputs an external PU key token containing the public key to be imported and an optional length parameter indicating the length of the external PU key token. The IPUK instruction also has an option for verifying a digital signature produced on the external PU key token using a public key contained in an internal PU key token supplied as an input to the IPUK instruction (not shown in FIG. 15). The IPUK instruction produces, as outputs, an internal PU key token containing the imported public key and an optional length parameter indicating the length of the produced internal PU key token. Thus, in the example of devices A and B, device A executes an IPUK instruction to import an external PU key token containing PUAb, the public device authentication key of device B, and device B executes an IPUK instruction to import an external PU key token containing PUAa, the public device authentication key of device A. Thus, before the ECFER and ICFER instructions are executed, it is assumed that the appropriate cryptographic devices participating in backup and recovery have exchanged their respective PUA keys and that these PUA keys have been imported at the designated receiving devices using an IPUK instruction.

ECFER and ICFER Instructions: A description of the ECFER instruction is provided below:

    ______________________________________
    Export Crypto Facility Environment Record (ECFER)
    EQUATION:
    ______________________________________
    protocol-mode        /2b minimum/
    KM-mode              /1b minimum/
    KMP-mode             /1b minimum/
    hash-rule            /3b minimum/
    PU-key-token-length  /16b/
    PU-key-token         /unspecified/
    .fwdarw.
    xcfer-length         /32b/
    xcfer                /unspecified/
    cfbdkb-length        /16b/
    ePUAb(cfbdkb)        /unspecified/
    dsig-length          /16b/
    dsig                 /unspecified/
    CC                   /unspecified/
    ______________________________________


__________________________________________________________________________
    PARAMETER DEFINITIONS:
    __________________________________________________________________________
    INPUTS         DESCRIPTION
    __________________________________________________________________________
    PROTOCOL-MODE  The protocol-mode parameter specifies the
                   protocol used for export and import of the CF
                   environment, as follows:
                   o 0 :
                       reserved
                   o 1 :
                       CBKUP1 (certification-center protocol
                       where the imported PUA key is signed
                       with PRC, a private certification key
                       of the certification center).
                   o 2 :
                       CBKUP2 (certification center protocol
                       where the iported PUAb key is signed
                       with PRMb, a private key management
                       key belonging to the same device to
                       which PUAb belongs)
                   o 3 :
                       PBKUP (private protocol, i.e., the
                       imported PUAb key is imported with no
                       special restrictions)
                   Note that the control vector for PUAb (located
                   in the internal PU key token for PUAb) contains
                   a backup protocol field (called BKUP PROTOCOL)
                   that must match the protocol-mode parameter.
    KM-MODE        The KM-mode parameter indicates whether the
                   master key KM is required to be entered into the
                   new KM register at the receiving device via the
                   Load First Master Key Part (LFMKP) and Combine
                   Master Key Parts (CMKP) instructions:
                   o KM-Mode=0 : no
                   o KM-mode=1 : yes (load via KFMKP and CMKP)
                   NOTE: KM is a master key used to encrypt DEA
                   keys for storage (outside CF 30) in the
                   cryptographic key data set 32.
                   NOTE: The LFMKP and CMKP instructions are
                   discussed in co-pending patent application
                   serial number 07/766,260 ("Public Key
                   Cryptosystem Key Management Based on Control
                   Vectors"), cited in the Background Art.
                   NOTE: KM-mode=1 should be selected only if the
                   value of KM is known outside the crypto
                   facility, i.e., KM was originally loaded into
                   the CF of the sending device via the LFMKP and
                   CMKP instructions.
    KMP-MODE       The KMP-mode parameter indicates wheter the PKA
                   master key KMP is required to be entered into
                   the new KMP register at the receiving device via
                   the Load First PKA Master Key Part (LFPMKP) and
                   combine PKA Master Key Parts (CPMKP)
                   instructions:
                   o KMP-mode = 0 : no
                   o KMP-mode = 1 : yes (load via LFPMKP and
                      CPMKP)
                   NOTE: KMP is a master key used to encrypt PU
                   and PR key records for storage (outside CF 30)
                   in the cryptographic key data set 32.
                   NOTE: The LFPMKP and CPMKP instructions are
                   discussed in co-pending patent application
                   serial number 07/766,260 ("Public Key
                   Cryptosystem Key Management Based on Control
                   Vectors"), cited in the Background Art.
                   NOTE: KMP-mode=1 should be selected only if the
                   value of KMP is known outside the crypto
                   facility, i.e., KMP was originally loaded into
                   the CF of the sending device via the LFPMKP and
                   CPMKP instructions.
    HASH-RULE      Specifies the hash algorithm to be used to
                   calculate a hash value on ePUAb(cfbdkb) and on
                   the cfer. The encoding of the hash-rule is as
                   follows:
                   o hash-rule = 0 : MDC-2 algorithm
                   o hash-rule = 1 : MDC-4 algorithm
                   o hash-rule = 2-7 : reserved
                   NOTE: The MDC-2 algorithm (2 DEA encryption
                   steps per 64 bits of input) and the MDC-4
                   algorithm (4 DEA encryption steps per 64 bits of
                   input) are described in U.S. Pat. No. 4,908,861.
    PU-KEY-TOKEN-LENGTH
                   The length of PU-key-token in bytes.
    PU-KEY-TOKEN   An Internal PU Key Token containing PUAb of
                   device "b". Note that "a" is this device and
                   "b" is the other device.
    OUTPUTS        DESCRIPTION
    __________________________________________________________________________
    XCFER-LENGTH   The length of xcfer in bytes.
    XCFER          An External Crypto Facility Environment Record.
    CFBDKB-LENGTH  The length of cfbdkb and ePUAb(cfbdkb) in bits.
    EPUAB(CFBDKB)  cfbdkb encrypted with public key PUAb of device
                   "b". The Encrypted Secret Part (ESP) in xcfer
                   is encrypted with a key stored in cfbdkb.
                   cfbdkb also contains a 128-bit hash value (MDC)
                   calculated on cfer.
    DSIG-LENGTH    The length of dsig in bits.
    DSIG           A digital signature produced from a signature
                   record prepared by the ECFER instruction and a
                   private authentication key PRAa of device "a",
                   in accordance with section 6 of International
                   Standards Organization Draft International
                   Standard (ISO DIS) 9796. The signature record
                   contains, at least, a 128-bit hash value
                   calculated on ePUAb(cfbdkb).
    CC             Condition code indicating success or failure of
                   the instruction execution.
    __________________________________________________________________________

    ______________________________________
    Import Crypto Facility Environment Record (ICFER)
    EQUATION:
    PARAMETER DEFINITIONS:
    ______________________________________
    protocol-mode          /2b minimum/
    KM-mode                /1b minimum/
    KMP-mode               /1b minimum/
    PU-key-token-length    /16b/
    PU-key-token           /unspecified/
    xcfer-length           /32b/
    xcfer                  /unspecified/
    cfbdkb-length          /16b/
    ePUAb(cfbdkb)          /unspecified/
    dsig-length            /16b/
    dsig                   /unspecified/
    .fwdarw.
    CC                     /unspecified/
    ______________________________________


__________________________________________________________________________
    PARAMETER DEFINITIONS:
    INPUTS         DESCRIPTION
    __________________________________________________________________________
    PROTOCOL-MODE  The protocol-mode parameter specifies the
                   protocol used for export and import of the CF
                   environment, as follows:
                   o 0 :
                       reserved
                   o 1 :
                       CBKUP1 (certification center protocol
                       where the imported PUA key is signed
                       with PRC, a private certification key
                       of the certification center).