Forward-secure commercial key escrow systems and escrowing methods thereof

Abstract

The present invention discloses a software-based commercial key escrow system (KES) for the PKI environment that enables an entity such as the court to monitor communications of users suspected of unlawful activities while protecting the privacy of law-abiding users.

Description

FIELD OF THE INVENTION

[0001] The present invention relates generally to the cryptosystems and more particularly to a forward-secure commercial key escrow system that is interoperable with the PKI (Public Key Infrastructure) environment. More specifically, the present invention relates to a forward-secure commercial key escrow system that enables a given entity to monitor communications of users suspected of unlawful activities while protecting the privacy of law-abiding users.

DESCRIPTION OF THE RELATED ART

[0002] A rapid growth of digital communication over internet have resulted in the development of information technology, Network security and particularly cryptographic technology. Cryptographic technology is widely used to ensure the privacy and authentication of messages communicated over insecure channels such as internet.

[0003] Cryptography can be used to protect the confidentiality of information by limiting access to the plain text data.

[0004] It has many advantages of using cryptography in electronic commerce and contracts over the internet for privacy and user authentication. But, the following problems may arise from the encryption key management.

[0005] First of all, a genuine user himself might not be able to access his information due to the loss or the damage of the decryption key.

[0006] Secondly, from the aspect of a company, there is a latent threat that can be caused by the misuse of the cryptosystem. For example, a rogue employee may encrypt the critical information of a company and then request money for releasing the decryption key.

[0007] Finally, from the aspect of a government, it sometimes happens that the government needs to have the right of an access to a key or plaintext with legal reasons such as the criminal investigation. Actually, the suspect can disturb the legal investigation by encrypting the information that has a relation to the crime.

[0008] The problems of the user's aspect can be solved if a commercial KES that provides services such as key-backup is used.

[0009] Furthermore, the second issue from the aspect of a company or a government can be solved if a mandatory KES is employed as a security policy.

[0010] Many countermeasures such as lawful restriction for the usage of a cryptosystem with a hidden trapdoor have been studied to prevent the cryptographic side effects. Among them the KES is a typical solution.

[0011] In general, the key escrow system can be defined as a cryptosystem that allows an authorized person to retrieve the decryption key under the pre-determined condition.

[0012] Here, the predetermined condition means user's request for the description key when a desirable KES (Key Escrow System) satisfy the opposite features between protecting user's privacy and guaranteeing law enforcement. But practically, it is not an easy task to fulfill these requirements at the same time.

[0013] As a prior art in the field of the key escrow system for the PKI environment, the KES technologies from Netscape, VeriSign, and Entrust have been disclosed. They are very popular PKI-based key escrow system. The detailed descriptions of the above-mentioned company's KES technology will be provided in the following in order to understand the shortcomings of the prior art.

[0014] First of all, let us summarize the meaning of the terminology used in the conventional KES. The user is defined as an entity using PKI-based commercial key escrow system. The registration authority, which is abbreviated as RA, is a server that registers or vouch for the identity of users to a CA that then issues certificates.

[0015] The certification authority, which is called as CA in short, is a server that manages certificates for encryption and authentication.

[0016] The key management agent (KMA), is a trusted server coordinating the key recovery agents (KRA). The KRA is a server or an administrator to provide a key recovery information to a KMA.

[0017] FIG. 1A is a schematic diagram illustrating the workflow of the Netscape's certificate management system (CMS) for a commercial key escrow system as a prior art. The detailed description of the Netscape's CMS can be found in the Netscape certificate management system administrator's guide version 4.1 (http://docs.iplanet.com/docs/manuals/cms/41/adm_guid e/contents.html).

[0018] Referring to FIG. 1A, the user 10 generates an encryption key pair (SA, PA). Further, the user encrypts a private key (SA) with the public key (PKMA) of the KMA, which is called as data recovery manager by Netscape, and sends the encrypted key EPKMA (SA) as well as the user's public key (PA) to the RA 11 (step S100).

[0019] Thereafter, the RA forwards the user's encrypted key EPKMA(SA) together with the user's public key (PA) to the KMA 13 for requesting the key escrow (step S101).

[0020] Now, the KMA 13 decrypts the encrypted key EPKMA (SA) with the KMA's private transport key (SKMA), and checks that the user's private key (SA) corresponds to the user's public key PA.

[0021] Then the KMA encrypts the user's private key SA with the KMA's storage key (P′KMA) and stores the encrypted key in its internal database 17 (step S102 ).

[0022] Once user's private key has been successfully stored, the KMA digitally signs a token confirming that the key has been successfully stored.

[0023] The KMA's private key for storage is reserved in a software or hardware token and is protected by a PIN code.

[0024] The KMA 13 splits the PIN into n pieces with (m, n)-secret sharing scheme and then stores them encrypted with the passwords of n KRAs 14, 15, 17, respectively.

[0025] Referring to FIG. 1A again, the KMA 13 sends a digitally signed token with the KMA's private transport key to the RA 11. The signed token means that the escrow of the user's private key (SA) has been successfully completed (step S104 ).

[0026] Thereafter, the RA 11 verifies the signed token and sends the certificate request to the CA 12 (step S105). The CA 12 issues and returns the encryption certificate to RA 11 (step S106), which is forwarded to the user 10 (step S107).

[0027] FIG. 1B is a schematic diagram illustrating the key recovery process from the Netscape's CMS. Referring to FIG. 1B, when the user 10 requests that KMA recover his or her private key, KMA subjects the request to its policy checks (step S120).

[0028] If the request passes all the policy rules, the KMA 13 sends a confirmation messages to n KRAs 14, 16 (step S121).

[0029] After verifying the confirmation, the KRAs then send their individual identifiers and passwords PSWD1, PSWD2, . . . , PSWDn to the KMA 13 (step S122). After the verification process of checking if the required number of KRAs send their passwords, the KMA constructs the PIN for accessing the private key repository with the passwords of KRAs.

[0030] The KMA 13 retrieves the user's encrypted private key from its key repository and decrypts it with the private component of the storage key pair. Finally, the KMA securely sends the recovered private key to the user 10 (step S123).

[0031] FIG. 2A is a schematic diagram illustrating the key escrow process of the VeriSign's Key Management Service product. More detailed information can be referred in a document “Onsite key management service administrator's guide (http://www.verisign.com)”

[0032] The feature of the VeriSign's key escrow system is that both the private key and the KMA 13 generate user's encryption key pair, which is called a key manager in the literature.

[0033] Referring to FIG. 2A, once the user 10 requests the certificate for encryption (step S130), the RA 11 forwards the request to the KMA 13 (step S131). The KMA 13 generates an encryption key pair as well as a unique triple DES key for the user.

[0034] Thereafter, the KRR (Key Recovery Record) and the KRB (Key Recovery Block) are constructed as follows.

[0035] Preferably, the KRR is constructed from the relation KRR=Ek(PRI), and the KRB from the relation KRB=&Egr;PKRA (K) where k is a triple DES Key, and PRI is the private key of the user while PKRA is the public key of the KRA 14. A KRB is the symmetric key encrypted using KRA's public key(triple DES key).

[0036] Additionally, the KMA 13 stores the created KRR and KRB in the database 17 together with the user's identifier and then the triple DES key is destroyed. Moreover, the KMA 13 sends the certificate request of the user to the CA 12 (step S133).

[0037] Consequently, the CA 12 sends the encryption certificate to the KMA 13 (step S134). Thereafter, the KMA 13 sends the private key for encryption and the certificate to the user 10 securely(step S135). Then, the KMA 13 destroys the private key of the user.

[0038] FIG. 2B is a schematic diagram illustrating the key recovery process of VeriSign's KMS product. Referring to FIG. 2B, when the user 10 requests that the KMA 13 recover his or her private key, the KMA 13 retrieves the KRB of the user from the database (step S141). Optionally, an organization may use two PINs (called “Emergency Recovery Codes”) , and thereby the level of security is enhanced from the requirement of the existence of a couple of KMA's administrators.

[0039] The retrieved KRB and the request for key recovery are transmitted to the KRA 14 (step S142). The KRA verifies if the KRB is valid and matches with two PINs. The KRA 14 then decrypts the KRB to recover the embedded triple-DES Key to decrypt the encrypted private key.

[0040] The KRA 14 returns the decrypted triple DES key to the KMA 12 (step S143). Thereafter, the KMA 13 decrypts the KRR (the encrypted private key) with the received triple DES key to recover the user's private key and then sends it to the user (step S144).

[0041] FIG. 3A is a schematic diagram illustrating the key escrow system of Entrust Corporation. The Entrust's key escrow system (KES) is described at “Administering Entrust/PKI 5.0 on UNIX”

[0042] Referring to FIG. 3A, the user sends a request for the encryption certificate to the RA 11 (step S150). The RA 11 then forwards the request to the CA 12 (step S151).

[0043] Now, the CA 12 generates the user's key pair upon the request. Furthermore, the CA 12 is responsible for the issuance of the encryption certificate.

[0044] The user 10's encryption key pair and the certificate are encrypted either with CAST-128 or with 3-DES, which are to be stored in the database 17 (step S152). In the meanwhile, the CA 12 forwards the user's private key and certificate to the user 10 via the RA 11 (step S153, S154).

[0045] FIG. 3B is a schematic diagram illustrating the key escrow process of Entrust's KES. Referring to FIG. 3B, the user requests the key recovery to the RA 11 (step S160), and then the RA 11 forwards the request to the CA 12 (step S161).

[0046] The CA 12 retrieves the encrypted private key of the user from the database 17 and decrypts the user's encrypted private key (step S162).

[0047] For the recovery of the encrypted private key at the step of S162, the passwords of the operating managers are needed and the number of operating managers participating in the recovery process of the escrowed key can be suitably chosen in accordance with the security policy.

[0048] Finally, the CA 12 forwards the decrypted private key to the user through the RA (step S163, S164).

[0049] As far as the user's privacy is concerned, the traditional commercial key escrow system proposed by either VeriSign or Entrust, however, have shortcomings in common. Namely, the user's private key for encryption is inevitably exposed to a third party at the initial step of generating a key in accordance with the prior art.

[0050] This is because anyone among the group of the user, the KMA, and the CA is capable of generating the user's key pair (including user's private key) according to the prior art.

[0051] Additionally, traditional KES (key escrow system) disclosed by VeriSign and/or Entrust is not practically applicable because the user's private key is not securely managed. For instance, the security of the user's private key relies on the KMA and/or the CA in case when either the KMA or the CA generates the user's private key.

[0052] Additionally, the KES disclosed by Netscape Corporation still has the similar problem because the KMA encrypts the user's private key with the KMA's transport key in order to verify the correspondence between the escrowed private key and the public key, which means that the user's private key is inevitably exposed to the KMA that is a third party.

[0053] Furthermore, the user's escrowed private key is encrypted with the key of the central server (for instance, the storage key of the KMA for Netscape, and CAST-128 or 3-DES key of the CA for Entrust) and stored in the database.

[0054] Even in the case of compromising the central server's long-term private key, there still exists a problem such as the reduction of the security of the user's escrowed private key.

[0055] Since KMA as a central server employs the CRS (Certificate Request Syntax) protocol in an effort to securely transmit the decrypted 3-DES key from KRM, KMA has overhead for using the CRS protocol.

[0056] In addition, the traditional commercial key escrow system still has the problem in a sense that the database is vulnerable to the concentrated attack. This is because the key is kept in a single database despite the fault tolerance due to the periodic back-ups.

SUMMARY OF THE INVENTION

[0057] In view of the above-mentioned problems, there is a need in the art for a key escrow system, which is not subject to these limitations.

[0058] Accordingly, it is an object of the present invention to provide a practical key escrow system that is interoperable with PKI (Public Key Infrastructure).

[0059] It is another object of the present invention to provide a key escrow system supporting a PKI-roaming service in addition to the key-backup service. Here, a PKI-roaming service means that the user moving in the wireless Internet environments is able to enjoy mobile PKI-service through downloading the private key with password, which is entered anywhere at client terminal.

[0060] It is still another object of the present invention to provide a key escrow system supporting a lawful access to the user's private key. In other words, it is an object of the present invention provide a key escrow system that does not allow a third party such as the KMA or the KRA, for instance, to have an access to the user's private key for encryption without the lawful permissions like the user's recovery request or the order from the court.

[0061] Yet it is another object of the present invention to present a key escrow system that provides the perfect forward secrecy and the practical utility. Here, a server with perfect forward secrecy implies the one that does not reduce the security of the user's escrowed key despite making compromise with its long-term private key.

[0062] Practically, the server's feature of the perfect forward secrecy is a very important factor because much more information regarding the encryption key is concentrated on the central managing server.

[0063] It is also another object of the present invention to present a key escrow system that provides the blindness of the KMA or the KRA, which means that the user's private key for encryption is invisible either to the KMA or to the KRA during the key recovery process.

[0064] It is still another object of the present invention to provide the key escrow system with the fault-tolerant database of the KMA.

[0065] It is further another object of the present invention to provide a key escrow system that is possibly implemented in software. The aspect of implementation in software is important because the commercial key escrow system has to be economical even with high quality. Thus software implementation would be better for further use in e-commerce.

[0066] In general, a high-performance key escrow system is built with a hardware providing a tamperproof. However, the present invention has a feature in a sense that the escrow system is implemented in software in order to satisfy the requirement both for the cost and for the utility in electronic commerce.

[0067] Yet it is another object of the present invention to present a key escrow system providing a privacy of the user even in the case when applicable to mandatory KES. In other words, the present invention insures the user's privacy as much as possible.

[0068] It is further another object of the present invention to present a key escrow system that enhances the credibility of the user and prevents the possible attack to a single KRA. The present invention provides a new system with a feature that authorization to the key recovery should be distributed over several servers.

[0069] Yet another object of the present invention is to provide a key escrow system preventing the large-scale wiretapping.

[0070] It is suggested as a solution to enable the legal individual to wiretap only the selected users, and to prohibit illegal massive wiretapping computationally. In accordance with a broad aspect of the present invention, provided is a software-based key escrow system for the PKI environment that is beneficial to both the user and the authority.

[0071] As a result, it becomes possible to protect the user's privacy even with the extendibility to the PKI-roaming service and the practical utility in the commercial electronic applications.

BRIEF DESCRIPTION OF THE DRAWINGS

[0072] Further features of the present invention will become apparent from a description of the fabrication process in conjunction with the accompanying drawings of the preferred embodiment of the invention, which, however, should not be taken to be limitative to the invention, but are for explanation and understanding only.

[0073] In the drawings:

[0074] FIG. 1A is a schematic diagram illustrating the key escrow process of the Netscape Corporation as a prior art.

[0075] FIG. 1B is a schematic diagram illustrating the key recovery process of the Netscape Corporation as a prior art.

[0076] FIG. 2A is a schematic diagram illustrating the key escrow process of VeriSign Corporation as a prior art.

[0077] FIG. 2B is a schematic diagram illustrating the key recovery process of Verisign Corporation as a prior art.

[0078] FIG. 3A is a schematic diagram illustrating the key escrow process of Entrust Corporation as a prior art.

[0079] FIG. 3B is a schematic diagram illustrating the key recovery process of Entrust Corporation as a prior art.

[0080] FIG. 4A is a schematic diagram illustrating the key escrow process of a first embodiment in accordance with the present invention, an RSA (n, n)-commercial KES.

[0081] FIG. 4B is a schematic diagram illustrating the key recovery process of a first embodiment in accordance with the present invention, an RSA (n, n)-commercial KES.

[0082] FIG. 5 is a schematic diagram illustrating the key escrow and recovery processes of a second embodiment in accordance with the present invention, an RSA (n, n)-mandatory KES.

[0083] FIG. 6 is a schematic diagram illustrating the key escrow and recovery processes of a third embodiment in accordance with the present invention, an RSA (n, n)-mandatory KES.

[0084] FIG. 7A is a schematic diagram illustrating the key escrow process of a fourth embodiment in accordance with the present invention, a Diffie-Hellman (n, n)-commercial KES.

[0085] FIG. 7B is a schematic diagram illustrating the key recovery process of fourth embodiment in accordance with the present invention, a Diffie-Hellman (n, n)-commercial KES.

[0086] FIG. 8 is a schematic diagram illustrating the key escrow and recovery process of a fifth embodiment in accordance with the present invention, a Diffie-Hellman (n, n)-mandatory KES.

[0087] FIG. 9 is a schematic diagram illustrating the key escrow and recovery processes of a sixth embodiment in accordance with the present invention, a Diffie-Hellman (n, n)-mandatory KES.

[0088] FIG. 10A and FIG. 10B are a schematic diagram illustrating the key escrow and recovery processes of a seventh embodiment in accordance with the present invention, a Diffie-Hellman (t, n)-commercial KES.

[0089] FIG. 11 is a schematic diagram illustrating the key escrow and recovery processes of an eighth embodiment in accordance with the present invention, a Diffie-Hellman (t, n)-mandatory KES.

[0090] FIG. 12 is a schematic diagram illustrating the key escrow and recovery processes of a ninth embodiment in accordance with the present invention, a Diffie-Hellman (t, n)-mandatory KES.

DETAILED DESCRIPTION OF THE INVENTION

[0091] The present invention will be explained in detail with reference to the accompanying drawings.

[0092] Shown in FIG. 4A and FIG. 4B are the schematic representations of the key escrow and recovery process of a first embodiment in accordance with the present invention, an RSA (n, n)-commercial KES, respectively.

[0093] For the understanding of the features of the present invention, let us explain the notations used in the following context

[0094] PWD: user's password, which is supposed to be memorized, for the PKI-roaming service

[0095] VER: user's password verifier that is registered in the KMA.

[0096] KRB: user's key recovery block.

[0097] (e1, Ni): the public key of the KRAi for encryption (N1<N2< . . . <N1< . . . <Nn)

[0098] d1: the private key of the KRA1 for decryption.

[0099] Referring to FIG. 4A, the user 10 generates a pair of private/public keys (PRI, PUB) for encryption. The KRB (key recovery block) is constructed by the user and then forwarded to the RA 11 along with the PUB (step S201).

[0100] The present invention has a feature that the user himself encrypts PRI with PWD. In other words, the operation of C=EPWD(PRI) is performed by the user.

KRB=( . . . ((Ce1modN1)e2modN2) . . . )enmodNn  (1)

[0101] Referring to FIG. 4A again, the RA 11 sends the KRB and PUB to the KMA 13 (step S202). In the meanwhile, the KMA divides the key recovery block into l shares (KRB1, KRB2, . . . , KRBl) with (m, l)-SS (m<l) and stores each share with the user's identifier in the associate l databases 23 (DB1, DB2, . . . , DBl) , correspondingly.

[0102] Preferably, the KRB is then destroyed as long as the divided shares are stored in each database in an appropriate manner. Thereafter, the KMA 13 sends the notice permitting the issuance of encryption certificate to the RA 11 (step S203).

[0103] The RA 11 then exhibits the permission for the issuance to the CA 12 and requests an encryption certificate for the public key of the user 10 (step S204).

[0104] Accordingly, the CA 12 issues encryption certificate (step S205) and sends it to the RA 11 (step S206). Further, the CA 12 opens an encryption certificate in the directory server 19. Finally, the RA 11 forwards the encryption certificate to the user 10 (step S207).

[0105] FIG. 4B is a schematic diagram illustrating the key recovery process of a first embodiment in accordance with the present invention, an RSA (n, n)-commercial KES. Referring to FIG. 4B, the user 10 sends a request for the recovery of the private key for encryption to the KMA 13 (step S210).

[0106] After completing the step of identifying the user 10, the KMA 13 retrieves m key recovery blocks (KRB1, KRB2, . . . , KRBm) out of l KRB1 and reconstructs KRB through the (m, l)-SS. As a preferred embodiment in accordance with the present invention, the encrypted private key EPWD(PRI) is recovered by the KMA 13 through the following steps.

[0107] The KMA 13 randomly chooses a blind factor r (0<r<N1) and calculates KRB′ from the relationship of

KRB′=KRB·( . . . (re1modN1)e2modN2) . . . )enmodNn.

[0108] Now, the KMA 13 sends the KRB′ along with the request for the key recovery to the n-th key recovery server KRAn (step S211). In a reverse order from the n-th KRA to the first KRA (KRAn, KRAn−1, . . . , KRA1) , each KRAi decrypts the received message with its own private key (step S212 through to S216).

KRAn:KRB′(n)=(KRB′)dnmodNn  (2)

KRAn−1:KRB′(n−1)=(KRB′(n))dn−1modNn−1  (3)

[0109] 1 KRA n : KRB ( n ) ′ = ( KRB ′ ) d n ⁢ mod ⁢   ⁢ N n ( 2 ) KRA n - 1 : KRB ( n - 1 ) ′ = ( KRB ( n ) ′ ) d n - 1 ⁢ mod ⁢   ⁢ N n - 1 ⁢ ⁢   ⁢ ⋮ ( 3 ) KRA 2 : KRB ( 2 ) ′ = ( KRB ( 3 ) ′ ) d 2 ⁢ mod ⁢   ⁢ N 2 ( 4 ) KRA 1 : KRB ( 1 ) ′ = ( KRB ( 2 ) ′ ) d 1 ⁢ mod ⁢   ⁢ N 1 ⁢ ⁢   = E P ⁢   ⁢ W ⁢   ⁢ D ⁡ ( P ⁢   ⁢ R ⁢   ⁢ I ) · r ⁢   ⁢ mod ⁢   ⁢ N 1 ( 5 )

[0110] The KRA1 sends the KRB′(1)=EPWD(PRI)·r modN1 to the KMA. Finally, the KMA 13 recovers C=EPWD(PRI)=KRB′(1)/r modN1.

[0111] More preferably, the KMA 13 that has the password verifier (VER) of the user 10 sends C=EPWD(PRI) to the user in a secure fashion such as the password-based private key downloading protocol (step S217).

[0112] FIG. 5 is a schematic representation illustrating the key escrow process of a second embodiment in accordance with the present invention, an RSA (n, n)-mandatory KES. For a mandatory KES of a second embodiment in accordance with the present invention, the RA has to check if the escrowed private key of the user for encryption has a correspondence to the public key of the user.

[0113] The second embodiment of the present invention discloses a technique that protects the privacy of the user simultaneously with checking capability of the validity of the key recovery block from the user.

[0114] Referring to FIG. 5, the user 10 generates a total of s passwords PWDj (j=1, . . . , s) and registers the s password verifiers VERj corresponding to each password to the KMA 13 (step S221).

[0115] Now, the user generates s pairs of private/public keys for encryption (PRIJ, PUBj) In other words, the user 10 generates a set of s private keys (PRI1, PRI2, . . . , PRIS) and a set of public keys (PUB1, PUB2, . . . PUBS). Thereafter the set of s private keys PRIj is encrypted with a set of password PWDj of the user (j=1, . . . , s).

[0116] In other words, CJ=EPWDJ(PRIJ) (j=1, . . . , s) is calculated. In this case, the encrypting step with PWD can be skipped preferably during the process of constructing the KRB when applicable to the key escrow system for the urgent wiretapping.

[0117] Now, the user constructs s key recovery blocks with a relationship of KRBJ=( . . . ((Cje1 modN1)e2modN2) . . . )enmodNn and sends them along with the public keys PUBj (j=1, . . . , s) to the RA 11 (step S222).

[0118] The RA 11 that has received the KRBj (j=1, . . . , s) and PUBJ (j=1, . . . , s) sends a random number of k 1≦k≦s to the user (step S223).

[0119] The user 10 opens (s−1) KRB except KRBk to RA 11. In other words, the password PWDJ and PRIj ∀j≈k, 1≦k≦s are sent to the RA 11 (step S224).

[0120] As a preferred embodiment in accordance with the present invention, the number s controls the strength of the security. More preferably, this scheme can be designed in such a way as a non-interactive KES with a hash function.

[0121] Further, the RA 11 that has received (s−1) KRBj except KRAk examines the validity of PRIJ and PUBj with the following equation.

KRBJ?( . . . ((Cje1modN1)e2modN2) . . . )enmod Nn  (6)

[0122] where ∀j≈k, 1≧j≧s.

[0123] Once the validity of the one-to-one correspondence between the PRIj, PUBj, and KRBj ∀j≈k, 1≧j≧s is checked, it is considered that it is still valid even when j=k. Then, the RA 11 sends the KRB=KRBk, and PUB=PUBk to the KMA 13 (step S225). The remaining steps S226 through to S230 are identical to the processes of the first embodiment.

[0124] FIG. 6 is a schematic diagram illustrating the key escrowing process of a third embodiment in accordance with the present invention, an RAS (n, n)-mandatory KES.

[0125] The third embodiment discloses a key escrow system wherein the private/public keys of the user are generated by the KMA 13, and encrypted with PWD of the user for transmitting to the user.

[0126] The third embodiment can be employed for the practical, safe, and robust key escrow system against shadow attack.

[0127] Referring to FIG. 6, the user 10 sends a request for encryption certificate to the RA 11 (step S231). Then the request is forwarded to the KMA 13 (step S232) through the RA 11.

[0128] In the meanwhile, the KMA 13 constructs a pair of the user's private/public keys (PRI, PUB) for encryption. The KRB is constructed and stored in the database as illustrated in the following description.

[0129] First of all, the KMA 13 encrypts the user's private key PRI with password PWD. In other words, the operation of C=EPWD(PRI) is performed, followed by a step of destroying the PRI. Now, the KRB is calculated with the following equation.

KRB=( . . . ((Ce1modN1)e2modN2) . . . )enmodNn  (7)

[0130] Additionally, the KMA 13 divides the KRB into l shares with (m, l)-SS (m<l) and stores each share (KRB1, KRB2, . . . , KRBl) along with the user's identifier in the l databases, DB1 21, DB2 22, . . . , DBl 23, respectively.

[0131] AS a preferred embodiment, the KRB is destroyed, after storing KRB1 in the database. The KMA 13 sends the notice permitting the issuance of encryption certificate along with (C, PUB) to the RA 11 (step S233).

[0132] The RA 11 then presents the permission to the CA 12 for the issuance and requests a encryption certificate for the public key PUB of the user 10 for encryption (step S234).

[0133] Accordingly, the CA 12 issues the encryption certificate (step S235) and sends it to the RA 11 (step S236). Further, the CA 12 open an encryption certificate in the directory server 19.

[0134] Finally, the RA 11 forwards the certificate to the user 10 (step S237). The escrowed private key of the user in the mandatory KES can be recovered through the process illustrated in FIG. 4B, and the KMA should mount a dictionary attack to recover the private key PRI of the user for encryption.

[0135] Now, let us review the features of the present invention with comparison to the prior art by referring to the following table. 1 TABLE 1 Comparison of features invention and prior art Netscape Verisign Entrust (Prior (Prior (Prior Art) Art) Art) Invention Commer- Lawful Poor Poor Poor Excellent cial Access KES Utility and Poor Poor Poor Excellent Perfect forward secrecy Blindness Poor Poor Poor Excellent Fault Good Good Good Excellent Tolerance of storage unit Feasibility Excellent Excellent Excellent Excellent with software Value-Added N/A PKI- PKI- PKI- service roaming roaming roaming service service service Mandatory Division of Good Good Good Excellent KES authority depending for key on recovery Security Policy) Large-scale Poor Poor Poor Excellent wiretapping

[0136] The present invention has a unique feature of lawful access because the private key of the user for encryption is encrypted with password PWD that is privately kept only to the user and then encrypted with the KRA's public key in a successive manner for transmittance.

[0137] Moreover, since the second embodiment in accordance with the present invention, an RSA (n, n)-mandatory KES, preferably employs the cut & choose method for checking the validity of the escrowed private key of the user, a lawful access is guaranteed due to the fact that the secret KRB that has not been made open to a third party is sent to the KMA.

[0138] In the meanwhile, the prior art disclosed by VeriSign and Entrust corporations has a limitation in that the private key of the user can be exposed either to the KMA or to the CA during the generating and escrowing phase, not the recovering phase, because the KMA or the CA itself generates the private key of the user.

[0139] Furthermore, the prior art even from Netscape Corporation discloses a key escrow system wherein the private key of the user is encrypted with a key for transport of the KMA in order to examine the correspondence between the private key and the public key.

[0140] Therefore, it may happen that the private key of the user is exposed to the KMA during the generating and escrowing phase rather than the recovering phase.

[0141] Referring to the Table 1, the present invention has an overwhelming feature in terms of the utility and perfect forward secrecy. For instance, the prior art disclosed from Netscape and Entrust has a shortcoming in a sense that the escrowed key of the user is encrypted with the key of the server (i.e., DRM's storage key in Netscape and CA's CAST-128 key or triple DES key in Entrust) and once the private key of the server is made open to the public, the private key of the user for encryption will be in danger.

[0142] Moreover, the prior art disclosed from VeriSign Corporation still has a limitation because the key for the CRS protocol, which is employed for the encryption of the transmitted message, should kept in a secure fashion in order for the KMA to forward the decrypted 3-DES key to the KRA.

[0143] In the meanwhile, the present invention provides a technique that makes it possible to guarantee a perfect forward secrecy because it is not necessary for the KMA to administrate the extra private and public keys.

[0144] Moreover, it is not possible for the KMA to figure out the private key of the user either during the key generation and escrowing phase or during the key recovering phase since the private key of the user is encrypted with the user's own password that the KMA doesn't know.

[0145] Furthermore, the blind decoding algorithm in accordance with the present invention does not allow any KRA to find out the information of the user's private key during the recovering step of the key.

[0146] The key escrow system in accordance with the present invention has further a feature of fault tolerance of the storage unit.

[0147] The periodic back-ups of the database in the prior art disclosed by Netscape, VeriSign, and Entrust still does not provide a fault tolerance since a single unit of database is vulnerable to the hacker's attack.

[0148] To the contrary, the KMA in accordance with the present invention divides the KRB into a number of shares and each piece of KRB is separately stored in the multiple units of database.

[0149] Therefore, it becomes possible to decrease the chance of being attacked by a hacker for the preferred embodiments in accordance with the present invention.

[0150] More preferably, the proactive secure algorithm allows the security of the KES in accordance with the present invention to be enhanced.

[0151] For the reader's reference, the proactive secure algorithm can be referred in a paper titled “How to withstand mobile virus attacks,” by R. Ostrovski and M. Young, pp. 51-61, 10th ACM symposium proceeding, 1991.

[0152] In addition, the present invention has a feature of flexibility for implementation both in software and in hardware. The present invention also provides enough flexibility regardless of the platform when compared to the prior art like Clipper.

[0153] The technology for the Clipper is described in a paper titled with, “Escrow encryption Standard (EES),” FIBS PUB (federal information processing standards publication) published by NIST, 1994.

[0154] Referring to Table 1 again, the present invention has a feature of providing a PKI-roaming service due to the fact that the recovered key C=EPWD(PRI) is supposed to be transmitted to the user in a secure manner through the password-based private key downloading protocol.

[0155] Additionally, the key escrow system in accordance with the present invention, unlike the prior art such as the VeriSign's system, prevents the KRA from abusing its authorized power since the authorization for the key recovery is shared by many KRAs.

[0156] Furthermore, the present invention has a feature of preventing a large-scale wiretapping since the KMA recovers the private key of the user through the dictionary attack as in the partial KES.

[0157] More preferably, the speed of the recovery process of the key can be enhanced through employing the technique disclosed in the U.S. patent application Ser. No. 76/193,977 (High-speed RSA public key cryptographic method).

[0158] In general, the sender and the receiver make an agreement on their session key by Diffie-Hellman key exchange protocol. Once the user's long-term private key is disclosed, all the communications are insecure.

[0159] Therefore, the limitation of the period of the wiretapping becomes an important issue for the recovery of the key.

[0160] One approach to resolve the above-mentioned problem is to employ a protocol of distributing the session key suggested by A. K. Lenstra. Detailed description about the protocol of distributing the session key can be found in a literature “A key escrow system with warrant bounds,” pp. 197-207 of a book titled with “Advances in cryptology-crypto 95 published by Springer-Verlag, 1995”.

[0161] Now, the followings are the description about additional embodiments in accordance with the present invention, a Diffie-Hellman KES.

[0162] First of all, let us explain the notations used in the following context.

[0163] PWD: the user's password for PKI-roaming service, which is supposed to be memorized.

[0164] p: prime, P=qw+1, where q is a large prime and w is a smooth composite.

[0165] q: a generator of Gq, where Gq is the unique subgroup of Zp* of order q.

[0166] (X1, Yi) the KRA1's pair of encryption key, where yi=gX1modp.

[0167] FIG. 7A is a schematic representation illustrating the generating and escrowing process of the key of a fourth embodiment in accordance with the present invention, a Diffie-Hellman (n, n)-commercial KES.

[0168] Referring to FIG. 7A, the user 10 generates a pair of private/public keys (PRI, PUB) and transmits the KRB along with the PUB to the RA 11 (step S410).

[0169] Here, the user encrypts his private key PRI with his own password PWD. In other words, the user generates C with a relation of C=EPWD(PRI).

[0170] Thereafter, the user selects a random number z from the range 0<z<q. Moreover, the KRB is constructed from the following equation.

KRB=(C1, C2)=(gzmodP, C·(y1·y2· . . . ·yn)zmodP  (8)

[0171] In the meanwhile, the RA 11 transmits the KRB and PUB to the KMA 13 (step S411). Additionally, the KMA divides the KRB into l share (KRB1, KRB2, . . . , KRBl) with (m,l)-ss (m<l) and stores each share with the user's identifier in each database (DB1 21, DB2 22, . . . , DBl 23). After completing the storage, the KRB is destroyed.

[0172] The KMA 13 then sends the notice permitting the issuance of encryption certificate along with (C, PUB) to the RA 11 (step S412).

[0173] The RA 11 then presents the permission to the CA 12 for the issuance and requests a certificate for the user's public key PUB (step S413).

[0174] Accordingly, the CA 12 issues encryption certificate and open an encryption certificate in the directory server 19.

[0175] The CA 12 sends the certificate to the RA 11 (step S414). Finally, the RA 11 forwards the certificate to the user 10 (step S237).

[0176] FIG. 7B is a schematic diagram illustrating the recovering process of the key of a fourth embodiment in accordance with the present invention, a Diffie-Hellman (n, n)-commercial KES.

[0177] Referring to FIG. 7B, the user 10 sends a request for the recovery of the private key for encryption to the KMA 13 (step S550).

[0178] After completing the step of identifying the user 10, the KMA 13 retrieves m key recovery blocks (KRB1, KRB2, . . . , KRBm) out of l KRBi and reconstructs the KRB through the (m, l)-SS (m<l).

[0179] As a preferred embodiment in accordance with the present invention, the encrypted private key EPWD(PRI) is recovered by the KMA 13 through the following steps.

[0180] The KMA 13 randomly chooses a blind factor r (0<r<P−1) and calculates C1′ from the relation of C1′=C1rmodp.

[0181] Thereafter, the KMA 13 sends the calculated C1′ along with a request for the recovery of the private key to the key recovery agents (KRA1, KRA2, KRAn) .

[0182] In addition, each KRAi calculates C1″(1)=(C1′)x−modP and then sends C1″(i) to the KMA 13 (i=1, . . . , n).

[0183] The KMA 13 recovers the key C=EPWD(PRI) by calculating C2/(C1″(1)·C1″(2)· . . . ·C1″(n))1/rmodP. Finally, the KMA 13, which has a password verifier of the user 10, sends the recovered private key C=EPWD(PRI) to the user in a secure fashion such as the password-based private key downloading protocol.

[0184] FIG. 8 is a schematic diagram illustrating the generating and escrowing process of a fifth embodiment in accordance with the present invention, a Diffie-Hellman (n, n)-mandatory KES.

[0185] For a mandatory KES of a fifth embodiment in accordance with the present invention, the RA performs an additional step of checking the validity of the escrowed KRB.

[0186] Referring to FIG. 8, the user 10 generates a total of s passwords PWDj (j=1, . . . , s) and registers the s password verifiers VERj corresponding to each password to the KMA 13 (step S510).

[0187] Now, the user generates a total of s pairs of private/public keys for encryption (PRIj, PUBj). In other words, a set of s private keys (PRI1, PRI2, . . . , PRIS) and a set of s public keys (PUB1, PUB2, . . . , PUBs) are generated by the user 10.

[0188] Thereafter, a set of KRBj (j=1, . . . , s) is constructed and sent to the RA 11 along with PUBj (j=1, . . . , s). The private key PRIj is encrypted with the password PWDj of the user himself 10. In other words, CJ=EPWDj (PRI (j=1, . . . , s) is calculated.

[0189] Preferably, in the key escrow system that needs the urgent wiretapping, the encrypting step with PWD can be skipped during the generating step of the KRB. Additionally, a total of s random numbers z1 are chosen in a range of 0<zi<q (j=1, . . . , s) and the KRBj (j=1, . . . , s) is calculated from the following equation. 2 KRB j = ( C 1 ⁢ j , C 2 3 ) = ( g z j ⁢ mod ⁢   ⁢ P , C j · ( y 1 · y 2 · … · y n ) z 3 ⁢ mod ⁢   ⁢ P &AutoLeftMatch; ( 9 )

[0190] In the meanwhile, the RA 11 chooses k randomly in a range of 1≦k≦s and sends k to the user (step S512). Preferably, the security level of the system can be varied with s.

[0191] Referring to FIG. 8 again, the user 10 open (s−1) KRBj except the KRBk to RA 11 (step S513). In other words, the password PWDj, PRIj and zj ∀j≈k, 1≦j≦s are sent to the RA 11. Further, the RA 11, which has received (s−1) KRBs except the KRBk, examines the validity and the correspondence of PRIj, PUBJ, and KRBJ with the following equation.

KRBJ?(gzJmodP, CJ·(y1·y2· . . . ·yn)zJmodP  (10)

[0192] As a preferred embodiment in accordance with the present invention, the number S controls the strength of the security. More preferably, this scheme can be designed in such a way as a non-interactive KES with a hash function. Now the RA 11 sends KRB=KRBk and PUB=PUBk to the KMA 13 (step S514). The remaining steps S515 through to S518 are identical to the processes of the fourth embodiment.

[0193] The Sixth embodiment can be employed for the practical, safe, and robust key escrow system against shadow attack.

[0194] FIG. 9 is a schematic diagram illustrating the generating and escrowing process of a sixth embodiment in accordance with the present invention, a (n, n)-mandatory KES based on Diffie-Hellman.

[0195] Referring to FIG. 9, the user 10 sends a request for an encryption certificate to the RA 11 (step S630). The RA 11 forwards the request to the KMA 13 (step S631). The KMA 13 generates a pair of private/public keys (PRI, PUB), and constructs the KRB to store in a distributed database 21, 22, 23 (step S632).

[0196] The KMA 13 encrypts the user's private key PRI with user's password PWD. In other words, C=EPWD(PRI) is calculated. In this case, it is assumed that the password of the user 10 PWD has been pre-registered at the KMA 13.

[0197] Thereafter, a random number z is selected in the range of 0<z<q. The KRB is constructed from the following equation.

KRB=(C1, C2)=(gzmodP, C·(y1·y2· . . . ·yn)zmodp  (11)

[0198] Now, the KMA 13 divides the KRB into l shares (KRB1, KRB2, . . . , KRBl) with (m, l)-SS (m<l), and stores each share in the associated database (DB1, DB2, . . . , DBl) of l, correspondingly, with the identifier of the user. After storing KRB1 in the database, the KRB is destroyed.

[0199] The KMA 13 then sends the permission to issue the encryption certificate along with (C, PUB) to the RA 11 (step S633). The RA 11 then presents the permission to the CA 12 and requests a certificate for the public key of the user 10, PUB (step S634).

[0200] Accordingly, the CA 12 issues the certificate of encryption and makes it public at a directory server 19 (step S635). The CA 12 sends the certificate to the RA 11 (step S636). Finally, the RA 11 forwards the certificate to the user 10 (step S637).

[0201] For the fifth embodiment of this invention, the escrowed key can be recovered with the process depicted in FIG. 7B. In this case, the KMA can recover the private key of the user, PRI, by mounting a dictionary attack on the password of the user.

[0202] For the sixth embodiment of the present invention, the escrowed key can also be recovered with the process in FIG. 7B. In this case, the KMA can recover the private key of the user, PRI, by using the password available to the KMA.

[0203] Now, the following is a detailed description of another embodiment of this invention, (t, n)-commercial KES based on Diffie-Hellman (t<n). The unique feature of the preferred Diffie-Hellman (t, n)-commercial embodiment in accordance with the present invention is that t KRAs out of n are enough for the recovery of the escrowed key.

[0204] x1: a private key of KRA1 for 1≦i≦n.

[0205] y: a public key of the group of KRAs.

[0206] P: a prime, P=qw+1, where q is a large prime and w is a smooth composite.

[0207] g: a generator of Gq, where Gq is the unique subgroup of Zp* of order q.

[0208] Each KRAi=1, . . . , n chooses r1&egr;Rzq and makes y1=gr1modP public. Each KRAi selects a random polynomial f1&egr;Rzq[&khgr;] of degree (t−1) such that f1(0)=r1. Let fi(x)=ri+a1,i·x+a1,2·x2+ . . . +a1,t−1·xt−1modq, where ai,1, a1,2, . . . , a1,t−1&egr;Rzq. Then the KRA1 computes f1(j)modq ∀j≈i, 1≦j≦n and sends it to the KRAj securely.

[0209] Thereafter, each KRA1 computes, ga1,1modP, ga1,2modP and makes them public. Using received fj(i) ∀j≈i, 1≦j≦n , each KRAj verifies if gfJ(1)?yj·(gaJ,1)i1· . . . ·(gaJ,t−1)Jt−1modP Vj≈i, 1≦j≦n.

[0210] Let us define H as the set {KRA1|KRAi is an honest KRA satisfying the previous step.} Each KRAi computes its private key 3 X i = ∑ j ∈ H ⁢ f j ⁢ ( i )

[0211] (i) and keeps it secure. The KRAs compute and publish their group public key 4 y = ∏ j ∈ H ⁢ y j .

[0212] FIG. 10 is a schematic representation illustrating key generation, escrow process, and key recovery process of a seventh embodiment in accordance with the present invention, a (t, n)-commercial KES based on Diffie-Hellman.

[0213] Referring to FIG. 10A, the user 10 generates a pair of private/public keys (PRI, PUB), and sends the KRB along with the PUB to the RA 11 (step S710). The user 10 encrypts his private key, PRI, with his own password, PWD.

[0214] Thereafter, a random number z in the range of 0<z<q is selected. In addition, the key recovery block is computed from the following equation. 5 K ⁢   ⁢ R ⁢   ⁢ B = ( C 1 , C 2 ) = ( g z ⁢ mod ⁢   ⁢ P , C · y z ⁢ mod ⁢   ⁢ P ) &AutoLeftMatch; ( 12 )

[0215] In the meanwhile, the RA 11 sends the key recovery block, KRB, and the public key, PUB, to the KMA 13 (step S711). The KMA 13 divides the KRB into l shares (KRB1, KRB2, . . . , KRBl) with(m, l)-SS (m<l), and stores each share with user's identifier in each database (DB1, DB2, . . . , DBl)

[0216] After the completion of the storage, the KRB is destroyed. The KMA 13 then sends a permission to issue the certificate of the encryption (step S712). The RA 11 then presents the permission to the CA 12 and requests a certificate for user's public key, PUB (step S713).

[0217] Accordingly, the CA 12 issues the certificate of encryption and makes it public at a directory server 19. The CA 12 sends the certificate to the RA 11 (step S714). Finally, the RA 11 forwards the certificate to the user 10 (step S715).

[0218] Referring to FIG. 10B, the user 10 sends a request for the key recovery to the KMA 13 (step S850). After identifying the user 10, the KMA 13 retrieves m key recovery blocks (KRB1, KRB2, . . . , KRBm) out of l key recovery blocks and reconstructs the KRB through the (m, l)-SS (m<l).

[0219] As a preferred embodiment in accordance with this invention, the encrypted private key EPWD(PRI) can be recovered by the KMA 13 through the following steps. The KMA 13 randomly chooses a blind factor r (0<r<P−1) and calculates c1′ from the relation of C1′=C1rmodP.

[0220] Thereafter, the KMA 13 sends the calculated C1′ along with a request for the key recovery to the key recovery agents (KRA1, KRA2, . . . , KRAn).

[0221] In addition, each of t key recovery agents calculates C1″(ij)=(C1′)xlj modP and then sends (C1″(iJ), iJ) to the KMA 13 (1≧i1< . . . <iij< . . . <it≧n) The KMA 13 receives t (C1″(1), i) pairs from the KRAs of t, and recovers the encrypted private key C=EPWD(PRI) by calculating 6 C 2 / ∏ i ⁢ ( C 1 ″ ( i ) )   r - 1 ⁢ ∏ j ≠ i ⁢ z / ( j - i ) ⁢ mod ⁢   ⁢ P .

[0222] modP.

[0223] Finally, the KMA 13, which has a password verifier of the user 10, sends the recovered c=EPWD(PRI) to the user in a secure fashion using “password-based private key downloading protocol”.

[0224] Now, when we want to apply the (t, n)-commercial KES based on Diffie-Hellman to a mandatory KES having a protection against a large-scale wiretapping, the RA performs an additional step of checking the validity of the escrowed key recovery block.

[0225] In this case, cut & choose method as in the previous second embodiment can be preferably employed.

[0226] FIG. 11 is a schematic diagram illustrating the key generation and escrow process of an eighth embodiment in accordance with this invention, (t, n)-mandatory KES based on Diffie-Hellman.

[0227] Referring to FIG. 11, the user 10 generates a total of s passwords PWDj (j=1, . . . , s) and registers the s password verifiers VERj (j=1, . . . , s) corresponding to each password to the KMA 13 (step S910). Now, the user generates a total of s pairs of private/public keys for encryption (PRj, PUBj).

[0228] Thereafter, a set of KRBj (j=1, . . . , s) is constructed and sent to the RA 11 along with PUBj (j=1, . . . , s).

[0229] The private key PRIj is encrypted with the password PWDj of the user 10. In other words, CJ=EPWDJ(PRIj) (j=1, . . . , s) is calculated. Preferably, in the key escrow system that needs the urgent wiretapping, the encrypting step with PWD can be skipped in the generating step of the KRB.

[0230] Additionally, a total of s random number zj are chosen in the range of 0<zJ<q (j=1, . . . , s) and the KRBj(j=1, . . . , s) is calculated from the following equation.

KRBJ=(C1J, C2j)=(gzJmodP, CJ·(y)zJmodP  (13)

[0231] In the meanwhile, the RA 11 randomly chooses k in the range of 1≦k≦s and sends k to the user (step S912). Preferably, the security level of this system depends on the size of s.

[0232] Referring to FIG. 11 again, the user 10 opens (s−1) KRBj except the KRBk to the RA 11 (step S913).

[0233] In other words, the PWDj, PRIj, and for ∀j≈k and 1≦j≦s are sent to the RA 11. Further, the RA 11, which has received (s−1) key recovery blocks except the KRBk, examines the validity of the KRBj and the correspondence of PRIj and PUBj for ∀j≈k, 1≦j≦s.

[0234] As a preferred embodiment in accordance with this invention, this scheme can be designed in such a way as a non-interactive one with a hash function.

[0235] Now the RA 11 sends KRB=KRBk and PUB=PUBk to the KMA 13 (step S914). The remaining steps S915 through to S919 are identical to the processes of the fourth embodiment.

[0236] As a preferred embodiment for robust and practical (n, n)-mandatory KES based on Diffie-Hellman that is secure against the shadow public key attack, a sixth embodiment is disclosed wherein the private/public key of the user is generated and encrypted by the KMA and then sent to the user.

[0237] FIG. 12 is a schematic diagram illustrating the key generation and escrow process of a ninth embodiment in accordance with the present invention, (t, n)-mandatory KES based on Diffie-Hellman.

[0238] Referring to FIG. 12, the user 10 sends a request for the certificate of encryption to the RA 11 (step S1210). Then the RA 11 forwards the request to the KMA 13 (step S1211).

[0239] The KMA generates a pair of private/public keys (PRI, PUB) for the user, and constructs the KRB as illustrated in the following description.

[0240] The KMA 13 encrypts the private key of the user PRI with user's password PWD. In other words, C=EPWD(PRI) is calculated. In this case, it is assumed that the password of the user PWD has already been registered in the KMA 13. Thereafter, the KMA 13 selects a random number z in the range of 0<z<q.

[0241] Moreover, the KMA 13 constructs the KRB from the following equation.

KRB=(C1, C2)=(gzmodP, C·yzmodp  (14)

[0242] Additionally, the KMA divides the KRB into l shares (KRB1, KRB2, . . . , KRBl) with (m, l)-SS (m<l) and stores each share with user's identifier in each database (DB1 21, DB2 22, . . . , DBl 23). After, completing the storage, the KRB is destroyed.

[0243] The KMA 13 then sends a permission to issue the certificate of encryption along with (C, PUB) to the RA 11 (step S1212). The RA 11 then presents the permission to the CA 12 and requests a certificate for the public key of the user 10, PUB (step S1213).

[0244] Accordingly, the CA 12 issues the certificate of encryption and makes it public at a directory server 19. The CA 12 sends the certificate to the RA 11 (step S1214). Finally, the RA 11 forwards the certificate and C to the user 10 (step S1215).

[0245] For the eighth embodiment of this invention, the escrowed key can be recovered with the process illustrated in FIG. 10B. More preferably, the private key of the user, PRI, can be recovered by mounting a dictionary attack on the password of the user.

[0246] For the ninth embodiment of this invention, the escrowed key can also be recovered with the process illustrated in FIG. 10B. More preferably, the private key of the user, PRI, can be recovered with user's password that has been available with the KMA.

[0247] Although the present invention has been illustrated and described with respect to exemplary embodiments thereof, it should be understood by those skilled in the art that various other changes, omissions and additions may be made therein and thereto, without departing from the spirit and scope of the present invention.

[0248] It should be appreciated by those skilled in the art that the specific embodiments disclosed above may be readily utilized as a basis for modifying or designing other techniques and processes for carrying out the same purposes of the present invention.

[0249] It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims.

Claims

1. A method, under the PKI environment, of the key generation and escrow, comprising the steps of:

(a) having the user generate a password and register a password verifier of the user in a key management authority;

(b) having the user generate a pair of private/public keys;

(c) having the user encrypt his own private key with his own password (i.e.

C=EPWD (PRI, where PWD is user's password and PRI is user's private key)

(d) having the user generate a key recovery block through encryption of the encrypted private key C with a public key of a key recovery agents.

(e) sending user's key recovery block and public key to the key management authority; and

(f) having the key management authority store the key recovery block, or divide it into several shares, followed by storing the shares separately.

2. A method, under the PKI environment, of the key generation and escrow, comprising the steps of:

(a) having the user generate a password and register a password verifier of the user in a key management authority;

(b) having the user generate a pair of private/public keys;

(c) having the user encrypt his own private key with his own password (i.e. C=EPWD (PRI, where PWD is user's password and PRI is user's private key)

(d) having the user generate a key recovery block through encryption of the encrypted private key C with a public key of a key recovery agents.

(e) checking the validity of the key recovery block;

(f) sending user's validated key recovery block and public key to the key management authority;

(g) having the key management authority store the key recovery block, or divide it into several shares, followed by storing the shares separately.

3. The method as described in claim 2 wherein said step (c) is skipped and said step of (d) comprises a step of generating a key recovery block through the encryption of said user's private key with a public key of a key recovery agent by said user.

4. A method, under the PKI environment, of the key generation and escrow, comprising the steps of:

(a) having the user register his password in a key management authority(KMA);

(b) having the KMA generate a pair of private/public keys for the user;

(c) having the KMA encrypt the user's private key with the registered password of the user (i.e. C=EPWD (PRI) where PWD:user's password, PRI:user's private key);

(d) having the KMA generate a key recovery block(KRB) through the encryption of said encrypted private key C with a public key of a key recovery agents (KRAs); and

(e) having the KMA either to store the KRB, or to divide the KRB into several shares, followed by separately storing said shares.

5. A method, under the PKI environment, of the key recovery, comprising the steps of:

(a) having a key management authority (KRA) construct a key recovery block (KRB) for the corresponding user upon the request for the key recovery;

(b) having the KMA to blind the constructed key recovery block by employing a blind factor of said key management authority's own so that any KRA is not able to see said constructed key recovery block;

(c) having the KMA to send the blinded key recovery block along with a request for the key recovery to KRAs;

(d) having each KRA perform a decryption of the message received by employing a private key of its own;

(e) having each KRA send the decrypted message processed at step (d) to said key management authority; and

(f) having the KMA recover a encrypted private key C of said user by employing the message received from each key recovery agent and said blind factor of its own.

6. The method as described in claim 5 wherein said request for the key recovery at step (a) is the request either from said user or from the court.

7. The method as described in claim 5 wherein less than all of shares of the corresponding user's key recovery block are required to construct the key recovery block.

8. The method as described in claim 5 wherein less than all of the messages received from key recovery agents are required to recover the encrypted private key for the corresponding user.

9. The method as described in claim 5 further includes a step of having a key management authority send said recovered C to the key recovery requestor using the password-based private key downloading protocol.

10. The method as described in claim 5 wherein a key management authority or a trusted entity recovers the user's private key for encryption from C by mounting a dictionary attack.

11. The method as described in claim 5 wherein a key management authority or a trusted entity recovers the user's private key for encryption with the user's registered passwords.

12. A key escrow system for the PKI environment comprising:

a user who generates his own password, registers his own password verifier in a key management authority (KMA), generates a pair of private/public key pairs (PRI, PUB), encrypts his private key with said password (C=EPWD (PRI), and generates a key recovery block (KRB) through encrypting C with a public key of key recovery agents (KRAs)

a KMA that stores either said KRB or the divided shares of said KRB in a distributed manner, constructs said KRB from the divided shares at a key recovery phase, sends to KRAs a request for the key recovery along with a blinded KRB which is a multiplication of said KRB with a blind factor in order not to disclose said KRB to any of said KRAs, and recovers C with received messages from said KRAs and with said blind factor; and

KRAs that decrypt message sent from said KMA with the private key of their owns.

13. The key escrow system as described in claim 12 wherein said KRB generated by said user is checked for the validity.

14. A key escrow system for PKI environment comprising:

a user who registers his password (PWD) in a key management authority (KMA), comprising:

a KMA that generates a pair of private/public keys (PRI, PUB) for said user, encrypts said user's private key with said user's registered password (C=EPWD (PRI) generates a key recovery block (KRB) through encrypting C with the public key of the key recovery agents (KRAs), stores said KRB or the divided shares of said KRB in a distributed manner, reconstructs said KRB out of said divided shares upon the request for recovery, sends to KRAs a request for recovery along with a blinded KRB which is a multiplication of said KRB with a blind factor in order not to disclose said KRB to any of said KRAs, and recovers C with received messages for said KRAs and with said blind factor; and

KRAs that decrypt messages sent from said KMA with private keys of their own.

15. The key escrow system as described in claim 12 or claim 14 wherein less than all of shares of the corresponding user's key recovery block are required to construct the key recovery block.

16. The key escrow system as described in claim 12 or claim 14 wherein less than all of the messages received from key recovery agents are required to recover the encrypted private key for the corresponding user.