Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
  • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
  • H04L9/3006—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters
  • H04L9/3013—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters involving the discrete logarithm problem, e.g. ElGamal or Diffie-Hellman systems

Definitions

• the field of this invention is cryptography.
• This invention relates to cryptosystems, and in particular to the escrowing and recovering of cryptographic keys and data encrypted under cryptographic keys.
• the escrow and recovery process assures that authorized entities like law-enforcement bodies, government bodies, users, and organizations, can when allowed or required, read encrypted data.
• the invention relates to cryptosystems implemented in software, but is also applicable to cryptosystems implemented in hardware.
• PKC Public Key Cryptosystems
• E is used to encrypt messages, and only D can be used to decrypt messages. It is computationally impossible to derive D from E.
• party A obtains party B's public key E from the key distribution center. Party A encrypts a message with E and sends the result to party B. B recovers the message by decrypting with D.
• the key distribution center is trusted by both parties to give correct public keys upon request.
• a PKC based based on the difficulty of computing discrete logarithms was published in (T. ElGamal, "A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms", CRYPTO '84, pages 10-18, Springer-Verlag, 1985) .
• PKC's are highly convenient in terms of use, and permit users to conduct private communications over insecure channels. They may be used to initiate symmetric key systems like DES (Data Encryption Standard) . PKC's have a drawback, however. criminals can use PKC's in the course of criminal activity, since no provision is made to supply law enforcement with the necessary decryption keys and untappable criminal communications may result. It is therefore desirable to permit private communications exclusively to law abiding citizens.
• a general solution to this problem is to have each user submit a representation of his or her private key to trusted escrow authorities, or trustees . The shares are taken out of escrow in the event of a court authorized wire tap. Alternatively, key escrow provides a way to recover lost private keys in an organization, or keys of a file system.
• each user submits five shares to five central trustees (also known as "trusted third par- ties") to register a public key.
• This solution is therefore not very scalable, since it requires the use of a small number of trusted authorities, and is thus very centralized.
• the user constructs a key pair such that the private key is provably escrowed automatically. Hence, no trusted third parties are needed whatsoever.
• the escrowed information can be sent to one of a multitude of decentralized certification authorities (CA's).
• CA's decentralized certification authorities
• Micali ' s scheme each trustee verifies their respective shares. Provided the share is valid, the share is stored in a database.
• Each trustee then signs the values that were received and gives them to a key management center.
• the five authorities have the burden of securing and managing five private databases of shares .
• the key information is verified by a CA. Provided it has the correct form, the key is signed, and placed immediately in the database of public keys. There need only be one private database . Since only the CA is needed to manage user keys in the current embodiment, the least amount of communication overhead that is possible is achieved. In the Fair PKC's, only the trustees can verify that a key is escrowed properly. Verification is required since without it a user can easily generate keys which are not recoverable. In the current invention, everyone can verify this. This is particularly useful if, for example, a citizen suspects that a CA is failing to insure that its keys are properly escrowed.
• a shadow public key cryptosystem is a system that can be embedded in a key escrow system that permits conspiring users to conduct untappable communications .
• the flaw in the RSA FPKC lies in the fact that it is assumed that criminals will use the same secret keys that were provided to the escrow authorities.
• the shadow cryptosystems make use of what is known in the art as subliminal channels that exist in the public keys of the PKC's. These channels are used to display the public keys of the shadow PKC.
• the Kilian and Leighton paper discloses how to convert PKC's into Fail-safe Key Escrow (FKE) systems. Specifically, they disclose how to construct FKE systems for discrete-log based PKC's like Diffie-Hellman and DSS . In their expensive protocol, the user and the trusted authorities engage in a protocol to generate the user's public and private keys.
• Binding ElGamal approach If the PKI is unescrowed then user A can public key encrypt a message using user B's public key, and then send the resulting ciphertext message using Binding ElGamal. In this case, the proof simply serves to show that the trust- ees can recover this ciphertext, and therefore prevents law-enforcement from being able to monitor the communications of users suspected of criminal activity. When this abuse is employed, fraud is not detectable. This abuse is made possible because user B's private key is not escrowed. Software that abuses the Binding ElGamal scheme could be readily distributed and could severely hamper attempts at law enforcement on a large-scale.
• the present invention discloses a method of establishing an escrowed PKI, and is hence not subject to this drawback.
• the present invention employs the general technique of non-interactive zero-knowledge proofs, though the proofs of the present invention involve new technology.
• a heuristic for how to construct such proofs was shown in (A. Fiat, A. Shamir, "How to Prove Yourself: Practical Solutions to Identification and Signature Problems", CRYPTO '86, pages 186-194, Springer-Verlag, 1987).
• TTP trusted third parties
• TTP's require generation of cryptographic keys by TTP's.
• a corrupt or otherwise compromised TTP may put user security at risk by tampering or disclosing user's keys.
• the escrow system requires the least amount of protocol interaction between the escrow authorities, CA, and user, that is theoretically possible.
• CA escrow authorities
• To register a key a message need only be sent to one of a multitude of CA's. This mechanism is called a key registration based escrow system.
• a key registration based escrow system In comparison, in the prefered embodiment of Fair PKC's, five messages are sent from the user to the trustees, and then five more messages are sent to a key management center.
• the present invention is versatile enough so that either (a) or (b) can be chosen (namely, a software or hardware implementation) . In each case requirements (c) through (f) are met.
• the present invention introduces a new paradigm in cryptography.
• the present invention provides a method to verify that a user generated private key is contained within an encryption under the public key of the escrow authorities without excessive overhead. Furthermore, this verification can be performed by anyone in possession of the escrow authorities public key.
• the present invention consists of a setting up process and three functions which process signals in different ways. The functions are key generation, key verification, and key recovery.
• the participants agree upon a set of initial public parameters and the authorities generate an escrowing public key and corresponding private keys.
• the initial parameters and the escrowing public key are the public parameters of the system.
• the escrowing authori- ties, Certification Authority (CA) , and users of the system all have access to the public parameters.
• the method generates a user's public/private key pair, and a certificate of recoverabili- ty which is a string of information which includes an implicit encryption of the user's private key under the escrowing public key.
• the signal information containing the user's public key, and the certificate of recoverabili- ty can be transmited to any entity.
• the verification process the user transmits this signal to the verifier.
• the verification process takes the input signal, processes it, and outputs either true or false. A result of true indicates that the user's private key is recoverable from the certificate of recoverability by the escrow authorities.
• the invention is designed such that it is intractable for the user to generate a public key, and certificate of recoverability such that the key is not escrowed and such that it passes the verification process with a result of true.
• the users certify their public keys with registration authority of the certification authority (CA) who then signs their public key after successful verification.
• CA certification authority
• a public key together with a CA's signature on a string that contains the public key constitutes a certified public key.
• the CA upon receiving the user's public key, and certificate of recoverability, the CA verifies that the corresponding private key is recoverable. If it is, (namely, the verification process outputs true) the public key is certified and/or made publicly available by the CA.
• the user is only required to keep his public key and to have access to the public key database containing public keys of other users as in a typical PKI.
• the escrow authorities use the user's certificate of recoverability, which is obtained from the CA, as an input signal .
• the escrow authorities process the certificate of recoverability, and the corresponding user's private key or data encrypted using the corresponding public key is the resulting output signal.
• the present invention is useful in any environment that demands the recovery of private keys, or keys encrypted under these keys, or information encrypted under these keys. Such environments arise in law enforcement nationally and internationally, in the business sector, in secure file systems, etc.
• the successful escrowing of private keys implies the successful escrowing of public key encrypted information, and hence the present invention has many applications.
• the present invention is robust with respect to any underlying technology since it can be implemented in both hardware and software. When implemented in software it can be easily scrutinized to insure that it functions as desired and to insure that it does not compromise the security of its users.
• the software implementation allows for fast and easy dissemination of the invention, since it can be disseminated in source code form over diskettes or over a computer communication network.
• the present invention is also as communication-free as is theoretically possible. The only communication is the act of disseminating the software itself (or the hardware device itself) and the one-time transmission of a user's public key, certificate of recoverability, and additional information. The signals can be processed quickly and the signals themselves constitute a small amount of information.
• the invention does not require changes in communication protocols used in typical unescrowed PKI ' s (e.g., session key establishment, key distribution, secure message transmission, etc.).
• the invention is therefore compatible with typical PKI ' s .
• the present invention thus provides a very efficient way of escrowing and recovering cryptographic keys .
• FIG. 1 is a data flow diagram of the process of setting up the method of the invention for use with m escrow authorities.
• FIG. 2 is a flow chart of the basic steps of the process of generating a public/private key pair and certificate of recoverability using the invention.
• FIG. 3. is a data flow diagram of the process of verifying the recoverability of a private key.
• FIG. 4 is a data flow diagram of the process of registering a key using the invention.
• FIG. 5 is a data flow diagram of the process of private key recovery by the escrow authorities.
• FIG. 6 describes a generic public key system and its main components and operations
• FIG. 7 describes the escrowable public key system which results by employing the present invention and its main components and operations.
• the system setup of the prefered embodiment shown in FIG. 1 initiates the cryptosystem.
• An r of size 1024 bits is large enough for use in cryptographic systems. Such values of r, q, and p are not as easy to find as merely finding a prime number, but doing so is not intractable. What is needed is highly efficient algorithms which can be implemented using, say, a multi- precision library. Such algorithms include Karatsuba multiplication, Montgomery reduction, addition chains, and the Rabin-Miller probabilistic primality test (J. Lacy, D. Mitchell, W. Schell, "CryptoLib: Cryptography in Software, " AT&T Bell Laboratories, cryptolib@research.att.com).
• r mod 3 must be 2. It can't be 0 since then r wouldn't be prime. It can be 1 since then q would be divisible by 3. Also, r mod 5 must be 1 or 4. It can't be 0 since then r would be divisible by 5. It can't be 2 since then q would be divisible by 5. It can't be 3 since then p would be divisible by 5, etc.
• r mod 3 must be 2. It can't be 0 since then r wouldn't be prime. It can be 1 since then q would be divisible by 3.
• r mod 5 must be 1 or 4. It can't be 0 since then r would be divisible by 5. It can't be 2 since then q would be divisible by 5. It can't be 3 since then p would be divisible by 5, etc.
• Trial remaindering By performing trial remaindering, we can throw out values for r, q, and p quickly prior to performing trial divisions and probabilistic primality tests.
• 2q is a multiplicative group and has a generator, g and s are odd in the prefered embodiment.
• the values r, q, p, g, and gl are the systems initial parameters and are made publicly available with no loss of security. They can be chosen by the authorities themselves and/or anyone else.
• the m authorities proceed to collectively compute an escrow authority public key (Y, gl , 2q) , also called the escrowing public key, and escrow authority private keys z_l, z_2 , ... , z_m.
• authority i where i ranges from 1 to m, chooses a value z_i in ⁇ l, 2 , ... , 2r-l ⁇ at random and then sets Y_i to be gl raised to this value modulo 2q.
• At least one authority receives all of the information of the Y_i ' s from the m-1 other escrow authorities.
• authority i sends Y_i to authority 1.
• the sending of the Y_i ' s is depicted by step 11 in FIG. 1.
• Y is computed to be the product of the Y_i ' s modulo 2q by at least one of the authorities.
• Y is computed by authority 1.
• Authority 1 verifies that (gl/Y) is a generator of all values less than 2q and relatively prime to 2q. If it isn't then step 12 is executed. In step 12 the other m-1 authorities are told to choose new values for z, hence the procedure is restarted from the beginning of step 11.
• authority 1 chooses z_l over again also.
• at least 1 and less than m of the authorities generate new values for z. This process is continued as many times as necessary until (gl/Y) is a generator of all values less than 2q and relatively prime to 2q. Y is then published, or otherwise made available to the users and the CA, by one or more of the escrow authorities. This is depicted by step 13 in FIG. 1.
• FIG. 2 is a diagram showing the process of how a user's system generates a public/private key pair and a certificate of recoverability.
• the user system Having obtained the signal Y that is made available to users by the escrow authorities, the user system proceeds to generate an ElGamal key (Y' 9' P) ror tne user.
• the signal Y may a priori have been included in the invention.
• the invention proceeds by choosing a value k in ⁇ l, 2 , ... , 2r-l ⁇ randomly. This is depicted by step 2004 in FIG. 2.
• the invention computes the user's private key x to be ( (gl/Y) rasied to the k power) mod 2q.
• the invention also computes y to be (g raised to the x power) mod p.
• the system then proceeds to step 2007 and computes a certificate that can be used by any interested party to verify that the user's private key is properly encrypted within C.
• the certificate contains the value v, which is computed by the system to be g raised to the power w mod p, where w is ( (l/Y) raised to the k power) mod 2q.
• the public key parameter y can be recovered from g and v by computing v raised to the C power mod p.
• the system also processes three non-interactive zero-knowledge proofs as they are called in the art and includes them in the certificate. Let n denote the number of repetitions in each non-interactive proof. In the prefered embodiment, n is set to be 40.
• the first proof is designed so that the user can prove that he or she knows k in C.
• the second proof is designed so that the user can prove that he or she knows k in v.
• the last proof is designed so that the user can prove that he or she knows k in v raised to the C power mod p.
• the system proceeds as follows. It chooses the values e_l , 1 , e_l , 2 , ... , e_l , n, e_2 , 1 , e_2 , 3 , ... , e_2 , n, and e_3,l, e_3,2, e_3 , 3 , ... , e_3 , n in ⁇ l, 2 , ... , 2r-l ⁇ randomly. For i ranging from 1 to n, the system sets I_l,i to be gl raised to the e_l,i power mod 2q.
• the invention sets I_2 , i to be v raised to the d_i power mod p, where d i is Y raised to the -e 2,i power modulo 2q.
• the invention sets I_3 , i to be y to the t_i power mod p, where t_i is (gl/Y) raised to the e_3 , i power mod 2q.
• the invention then computes the value rnd to be the SHA hash of the set formed by concate- nating together the tuples (I_l,i, I_2,i, I_3,i) for i ranging from 1 to n.
• rnd is a function of all of the I values, using a suitably strong cryptographic hash function.
• the hash function can have an effective range of size different than 160 bits. A greater range of the hash function allows for significantly larger values for n.
• the system sets each of the bit-sized values b_l,l, b_l,2,..., b_l,n, b_2,l, b_2 , 2 , ... , b_2,n, b_3 , 1 , b_3 , 2 , ... , b_3 , n to be each of the corresponding 3n least significant bits of rnd.
• an embodiment can securely assign the bits of rnd to the values for b.
• the values for b are the challenge bits, and this method of finding them is known as the Fiat-Shamir Heuristic.
• the system then proceeds to compute the responses to these challenge bits. For i ranging from 1 to 3 and for j ranging from 1 to n, the invention sets z_i,j to. be e_i,j + (b_i,j)k mod 2r. This completes the description of step 2007 of FIG. 2.
• step 2008 the invention outputs the parameters C, v, y, (I_l,i, I_2 , i , I_3,i), and (z_l,i, z_2,i, z_3,i) for i ranging from 1 to n.
• the value k is output by the invention to the user.
• the user then has the option to later interactively prove that his or her private key x is recoverable by the escrow authorities. This will be ad- dressed in more detail later.
• the values b can be made a part of the certificate. This step is however, not necessary, since the values for b can be derived from the values for I alone.
• the description of the embodiment has thus far explained how the system is setup for use by the CA and authorities, and how the system is used by users (potential receivers) to generate public/private key pairs and certif- icates of recoverability. These certificates are strings showing to anyone presented with them that the key generated has the publicly specified properties.
• the following describes how the invention is used by the user to prove to a verifier that x is recoverable from C. This process is depicted in FIG. 3.
• the verifier can be the CA, an escrow authority, or anyone else who is part of the system.
• step 3009 the user generates a public/private key pair, encryption of x, and a certificate using the invention as described above.
• step 3010 the user transmits a signal containing these parameters to a verifier.
• step 3011 the verifier uses this signal to verify whether or not the user's private key is recoverable by the escrow authorities. To do so, the verifier uses the user's public key, the encryption C, the corresponding certificate, and the escrowing public key Y.
• the verifying system outputs a 0 if the public key and/or certificate are invalid, and a 1 otherwise.
• the invention may take subsequent action and indicate to the verifier that the public key is invalid in the event that 0 is returned. Similarly, the verifying system may inform the verifier of a validation that passes.
• the invention computes (b_l,i, b_2,i, b_3,i) for i ranging from 1 to n in the same way as performed during the certificate generation process. Recall that this process was described in regards to FIG. 2.
• w_i is 1/Y raised to the z_2 , i power mod 2q.
• v_i is l/Y to the z_2 , i power mod 2q. If any of these equalities fail, then the verifying system returns a value of 0. This completes the verification of the second non- interactive proof .
• w_i is (gl/Y) raised to the z_3 , i power mod 2q.
• v_i is (gl/Y) raised to the z_3 , i power mod 2q. If any of these equalities fails, then the verifying system returns a value 0. If all of the verifications pass, then the value 1 is output by the verifying system.
• step 4012 of this process the user certifies his or her public key with the CA.
• step 4012 of this process the user gener- ates his or her public key and certificate of recoverability, as previously described.
• the user transmits this signal to the CA.
• step 4014 the CA acts as a verifier and verifies that the user's private key is recoverable by the escrow author- ities. So far, steps 4012 through 4014 are identical to steps 3009 through 3011 in the key verification process of FIG. 3.
• the CA in addition, will make keys that pass the verification process available to others upon request and/or certify them. If the user's public key fails the verification process, then either the certification attempt is ignored, or alternatively the user is notified of the failed certification attempt.
• users may be required to submit extra information in order to register a public key and to certify that they know the private key portion without divulging it.
• Such information could be a password, social security number, previously used private key, etc.
• the CA can simply digitally sign the user's public key, and make the key along with the CA's signature of that key available on request. If the CA is not trusted, then the certificate should be stored in the public file and the certificate together with the certificate of recoverability should be given to the escrow authorities, which in turn can insure recoverability. This completes the description of the public key certification process. The last process to describe is the private key recovery process. This process is depicted in FIG. 5.
• the invention is used by the n escrow authorities to recover the user's private key based on C.
• all m of the escrow authorities obtain C, as depicted in step 5015 of FIG. 5.
• the CA transmits C and/or other parameters to one or more of the authorities. Thus they are already in possession of C.
• escrow authority i computes t_i to be C raised to the z_i power mod 2q. Recall that z_i is the private key of the ith escrow authority. This is done for i ranging from 1 to m.
• authorities 2 through m then send their respective values for t to authority 1, as depicted in step 5016.
• x is represented distributively among the authorities. These methods also allows the authorities to decrypt messages encrypted under the public key corresponding to x, without revealing x itself.
• FIG. 6 is a typical public key cryptosystem in a PKI environment .
• the following are the steps that are followed by the users. (1) The user first reads the CA's information and address. (2) The user generates a public/private key pair and sends the public key to the CA. The registration of the authority in the CA verifies the identity of the user, and publishes the public key together with the CA certificate on that key, identifying the user as the owner of that key.
• FIG. 7 schematically describes the ARC cryptosystem.
• the additional operations are as follows. (0) The authority generates the escrowing public key and gives it to the CA. Steps 1 and 2 are analogous, except that a proof is sent along with the public key. Steps 3 and 4 are the operation of the system and are identical. Steps 5 and 6 describe the case in which keys are recovered from escrow. (5) The escrow authority gets information from the CA. (6) The escrow authority recovers the user's private key.
• any large enough subset of the authorities can recover the private key x or messages encrypted under the public key corresponding to x without revealing x itself. This is done independently by receiving the appropriate values for t by the other authorities. This adds robustness in the case that some or all of the authorities cannot be completely trusted or are otherwise unavailable. Also, the authorities can require that that the certificate of recoverability be sent along with the public key and encryption so that the user's parameters can first be verified using the verification process. This completes the description of the private key recovery process .
• An alternate embodiment of this invention involves using an authority public key of the form (Y, g, 2 (q raised to the t power)), where t is some integer greater than 1.
• Y, g, 2 q raised to the t power
• t is some integer greater than 1.
• Another alternate embodiment is to use the product of two or more large primes as part of the public parameters .
• the exact structure of the moduli used can vary significantly without departing from the scope of the invention.
• the interactive versions of the three non-interactive proofs can be used. Such an embodiment requires that the system output k to the user during key generation.
• This value k is used during the interactive protocol, so that the verifier can be convinced that the user's private key is recoverable by the escrow authorities. Note that by outputing k, however, a shadow public key cryptosystem may result . This follows from the fact that ((gl, C, 2q) , k) is a valid ElGamal public/private key pair mod 2q.
• the CA takes the further action of blinding the user's public keys.
• the users publish their public keys which are used for key exchanges in a Diffie-Hellman like "key exchange" .
• key exchange a Diffie-Hellman like "key exchange”
• the following method can be used. Let a be user A's private key and let b be user
• the trustees can use either a or b to recover s, and hence the session key.
• the hashing algorithm selected is SHA (Schneier 2nd edition, pages 442-445) , though any cryptographic hashing algorithm will suffice in its place.
• SHA Schoteier 2nd edition, pages 442-445
• parameters are chosen uniformly at random from their respective groups or domains. Alternate embodiments include alterations of the probability distributions from which such values are chosen. Such choices based on random number generators or pseudo-random generators are available in the art.
• escrow authority i for 1 ⁇ - i -.- ⁇ m generates a private share D_i, and corresponding public share E_i .
• the private shares D_i form the shared private key D.
• Escrow authorities 2 through m send their E_i to escrow authority 1. This is depicted by step 11.
• Escrow authority 1 com- bines all the public shares E_i and computes the shared public key E.
• the value for E is published, by escrow authority 1, as depicted in step 13.
• Each authority i keeps D__i private.
• the escrow authorities can generate a strong prime p and a value g which generates ⁇ l, 2 , ... ,p-l ⁇ .
• E is the product of all the values E_i modulo p. Variations on joint generation of keys are possible, as well as an implementation with a single escrow authority.
• a process similar to FIG. 2 illustrates how a user's system generates a public/private key pair and a certifi- cate of recoverability. Having obtained (and verified as much as possible) the signal E that is made available to users by the escrow authorities, the user system proceeds to generate an ElGamal public key (y,g,p) for the user (T. ElGamal, "A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms", CRYPTO '84, pages 10-18, Springer-Verlag, 1985) .
• the user system chooses a private key x uniformly at random from ⁇ l, 2 , .. ,p-l ⁇ , and computes y to be (g raised to the x power) modulo p.
• This key generation process corresponds to step 2006.
• ENC(a,s,E) denote the public key encryption of the message a under public key E using randomness s.
• ENC is a semantically secure probabilistic public key encryption, where the string s is used for the randomness in the probabilistic encryption.
• ENC can be an ElGamal encryption, or an optimal asymmetric encryption (Bellare-Rogaway, "Optimal Asymmetric Encryption” , Eurocrypt '94).
• DEC be the corresponding public key decryption function which is performed in a shared fashion.
• DEC (ENC (a, s,E) ,D_1,D_2, ... ,D_m) a.
• P is constructed according to the following algorithm: 1.
• P ()
• C_i,l ENC(r_i, s_i,l, E) 7.
• C_i,2 ENC(r_i - x mod p-1, s_i,2, E)
• H is a suitable public one-way hash function (e.g., SHA) , so the b_i ' s can be recovered from P.
• the values for b are the challenge bits, and this method of finding them and using them is analagous to the Fiat-Shamir Heuristic.
• the user system outputs (y,x,P) in step 2008. Note that the user has the option to interactively prove that his or her private key x is recoverable by the escrow authorities. This will be addressed in more detail later.
• the description of the embodiment has thus far explained how the system is setup for use by the CA and authorities, and how the system is used by users (potential receivers) to generate public/private key pairs and certificates of recoverability. These certificates are strings showing to anyone presented with them that the private key corresponding to the public key generated is recoverable by the escrow authorities using P.
• the following describes how the invention is used by the user to prove to a verifier that x is recoverable from P. This process is depicted in FIG. 3.
• the verifier can be the CA, an escrow authority, or anyone else who knows the system parameters.
• the verification process of FIG. 3 is as follows.
• the user generates a public/private key pair, and a certificate using the invention as described above.
• the user transmits a signal containing these parameters to a verifier.
• the verifier uses this signal to verify whether or not the user's private key is recoverable by the escrow authorities.
• the verifying system takes y, the corresponding certificate P, and the escrowing public key E.
• the verifying system first checks that y ⁇ p.
• the verifying system checks that all of the values in P lie in the correct sets.
• the verifying system also checks that the values C_i,j for all i and j , do not contain any repetitions .
• the verifying system checks that none of the Q_i for all i are repetitious. If any of these verifications fail, then false is returned.
• the invention may take subsequent action and indicate to the verifier that the public key is invalid in the event that false is returned. Similarly, the verifying system may inform the verifier of a validation that passes (the verifying system returns true) .
• the user certifies his or her public key with the CA.
• the user generates his or her public key and certificate of recoverability, as previously described. The user transmits this signal to the CA. This corresponds to step 4013 of FIG. 4.
• the CA acts as a verifier and verifies that the user's private key is recoverable by the escrow authorities .
• steps 4012 through 4014 are identical to steps 3009 through 3011 in the key verification process of FIG. 3.
• the CA in addition, will make keys that pass the verification process available to others upon request and/or certify them. If the user's public key fails the verification process, then either the certifica- tion attempt is ignored, or alternatively the user is notified of the failed certification attempt.
• CA may be required to submit extra information in order to register a public key and to certify that they know the private key portion without divulging it.
• Such information could be a password, social security number, previously used private key, etc.
• the CA can simply digitally sign the user's public key together with the user's name and additional information, and make the key along with the CA's signature on this information available on request. If the CA is not trusted (which is not the typical assumption in PKI) , then the certificate should be stored in the public file and the certificate together with the certificate of recoverability should be given to the escrow authorities, who in turn can insure recoverability. This completes the description of the public key certification process.
• the CA keeps the certificate of recoverability, possibly in encrypted form under its own key with authentication information for integrity.
• the last process to describe is the private key recovery process.
• This process is depicted in FIG. 5.
• the invention is used by the m escrow authorities to recover the user's private key based on P.
• all m of the escrow authorities obtain y and P, as depicted in step 5015 of FIG. 5.
• the CA transmits y and P and/or other parameters to one or more of the authorities. Thus they are already in possession of y and P.
• escrow authorities use a subset of their shares D_l, D_2 , ... , D_m to decipher P to open all of the unopened C_i,j (using DEC for example.
• escrow authority i recovers the ith shares of the user's private key.
• escrow authority i extracts the M values for the unopened C_i,j from P and decrypts them using D_i .
• the resulting values are pooled with the values from the other escrow authorities, as depicted in step 5016 of FIG. 5.
• the pool is then used by the authorities to decrypt all of the unopened values C_i,j from P.
• all of the plaintexts corresponding to all C_i,j are known to the escrow authorities.
• the users of the system generate composite public keys.
• the user system generates n and s in the same way as described in the pending U.S. Patent 08/920,504 (by Young and Yung) .
• n is the product of two (preferably strong) primes p and q
• s is a string that can be used in conjunction with a public one-way function to derive the upper order bits of n.
• e and d denote the public and private exponents (e.g., for RSA) , respectively. The following is how P is constructed:
• v_i,2 (t_i raised to the a_i,2 power) mod n 11.
• Q_i (t_i, v_i,l, v_i,2)
• val H(P) 16. set b_l, b_2,...,b_M to be the M least significant bits of val, where b_i is in ⁇ ,l ⁇
• the verifying system is a bic different than before.
• the verifying system first checks that n was chosen from the correct set of values. Let u denote the integer corresponding to the k/2 upper order bits of n.
• the verifying system checks that all of the values in P lie in the correct sets. For example, the verifying system checks that the t_i fall within the range of H, and that a_i , j ⁇ n (or some function of n) where j is 1 or 2.
• the verifying system checks that elements of the tuple Q_i for each i does not contain repetitions, and also that the elements in the pair Z_i for all i does not have repetitions. If any of these verifications fails, then false is returned.
• the verifying system then computes b_l, b_2 , ... , b_M in the same way as in the certificate generation process. For i ranging from 1 to M, the verifying system verifies the following things:
• the escrow authorities recover the user's private key as follows. For i ranging from 1 to M, the authorities compute w_i to be the sum of the plaintexts corresponding to C_i,l and C_i,2. If a value w_i is found such that (t_i raised to the e(w__i) power) mod n equals t_i, then w_i constitutes a valid RSA private key corresponding to e . It is well known in the art how to factor n given such a value w_i .
• the RSA function is a homomorphic function and the above embodiment is applicable to homomorphic functions similar to RSA.
• this 'proof technique 1 for showing that a value is recoverable by the escrow authorities can be generalized to any homomorphic function.
• An application of this invention is an multi-escrow authority system where each escrow authority has its own CAs and users. When users from two different escrow authorities conduct secure communication the two escrow authorities can retrieve the user's messages or keys and exchange them through bilateral agreement. This is appli- cable to international multi-country scenarios.
• Another application of key escrow systems is a secure file system or file repository system with recoverable keys.
• a secure file system or file repository system with recoverable keys can be implemented based on the previous embodiments, in particular based on the preceding para- graph.
• user A can be the owner of the file
• user B can be the file server
• the trustees can be file recovery agents.
• An example of a file could be a password, in which case, the file recovery agents are password recovery agents.
• p 2q+l
• q 2r+l
• r 2s+l
• p, q, r, and s are all prime numbers.
• another innovative use of number theory is performing cryptographic operations in the exponent, where the operations are, for example, modular exponentiations.
• the second zero-knowledge proof in step 2007 of the first embodiment involves proving knowledge of k in v where v is equal to g raised to the w power mod p, where w is (Y raised to the -k power) mod 2q.
• the use of three or more domains in successive exponentiations adds flexibility and power to crypto- systems. Applications of this fact along the lines of the present invention, are readily available co those who are skilled in the art.
• An application of this invention is a hierarchical public key escrow system.
• a hierarchical public key escrow system is an escrow system that takes the form of a tree data structure.
• the escrow authorities at the root of the tree are able to decrypt the communications of all entities corresponding to the nodes of the rest of the three.
• the escrow authorities at any given node i in the tree are able to decrypt the communications of all entities corresponding to the nodes in the rest of the subtree for which node i is root.
• the leaf of the tree can form another subtree and act as an escrow agent (s) .
• the user can decide on a subset of escrow agents and generate its own preferred tree which is the chosen subset of escrow agents ordered by the relative size of their public keys in a line where the largest key is the root. This enforces a structure of the commitment, and assures that the subset needs to work together to recover a key or information encrypted under the key.
• Yet another application of this invention is a certified electronic mailing system.
• the sender sends a packet which includes the following: an encryption of an e-mail key under his own auto-certified public key, the receiver's name, an encryption of the e-mail message encrypted under the e-mail key, a header indicating a certified e-mail message, his own certified public key, and the CA's certificate on his certified public key, and other information.
• the packet is signed using the senders signature private key. Both the packet and the signature on the packet are sent to the receiver.
• the receiver forms a return receipt packet that consists of a fixed return receipt header, the received message (or the hash of the received message) , and additional information.
• This packet is signed using the receivers private signature key and is sent to the original sender.
• the original sender verifies the signature on the return receipt packet. If the signature is valid, the original sender sends the receiver the e-mail key encrypted under the receiver's certified public key. This message is sent along with a signature on it using the original sender's private signing key.
• the receiver verifies the signature on the encrypted e-mail key. If the signature is valid, the receiver decrypts the e-mail key using his private decryption key. The receiver then encrypts the result using the original senders certified public key.
• the e-mail key is regarded as authentic. This key is then used to decrypt and obtain the actual information that the original sender sent. If the receiver is for some reason unable to contact the original sender after the first packet is received, the receiver sends the return receipt and the first packer. to the escrow authorities. The escrow authorities will recover the e-mail key, provided the packet and return receipts are authentic and provided that the packet contains the corrects receivers name. The escrow authorities retain the return receipt and the packet. Provided the checks pass, the e-mail key is sent to the receiver.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computing Systems (AREA)
• Theoretical Computer Science (AREA)
• Storage Device Security (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Applications Claiming Priority (11)

Publications (1)

Family

ID=27542270

Family Applications (1)

Country Status (13)

Families Citing this family (12)

Family Cites Families (5)

• 1998
  • 1998-05-21 NZ NZ501273A patent/NZ501273A/en unknown
  • 1998-05-21 CA CA002290952A patent/CA2290952A1/en not_active Abandoned
  • 1998-05-21 BR BR9809664-8A patent/BR9809664A/pt not_active IP Right Cessation
  • 1998-05-21 EP EP98937934A patent/EP0997017A2/en not_active Withdrawn
  • 1998-05-21 WO PCT/US1998/010392 patent/WO1998054864A2/en not_active Application Discontinuation
  • 1998-05-21 AU AU86564/98A patent/AU737037B2/en not_active Ceased
  • 1998-05-21 CN CNB988066904A patent/CN1241353C/zh not_active Expired - Fee Related
  • 1998-05-21 PL PL98338018A patent/PL338018A1/xx unknown
  • 1998-05-21 KR KR19997011138A patent/KR20010013155A/ko not_active Application Discontinuation
  • 1998-05-21 IL IL13296198A patent/IL132961A0/xx unknown
  • 1998-05-21 JP JP50076699A patent/JP2002500842A/ja active Pending
  • 1998-05-21 CZ CZ19994106A patent/CZ9904106A3/cs unknown
• 1999
  • 1999-11-26 NO NO995811A patent/NO995811L/no not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events