JPH11308213A - Encryption data recovery method and its system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To allow the system to approve data recovery by using a secret key only when a user receiving an issued public key certificate loses the secret key in pairs with an open key in the certificate by unifying the user management of a public key certificate and key recovery. SOLUTION: A certification authority CA 220 abolishes a 1st public key certificate on request of a user device USC 200 and issues a 2nd public key certificate. Furthermore, a data recovery device DRC 240 authenticates the user by using the 2nd public key certificate attached to a key recovery request according to the key recovery request of the USC 200 and uses a secret key in pairs with the public key of the 1st public key certificate deposited by a key deposit device KEC 230 to decode the data encrypted by the open key of the 1st public key certificate.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an encrypted data recovery technique for decrypting data encrypted with a user's public key in response to a request from the user, and more particularly, to an envelope (Envelope).
The present invention relates to a key recovery technique for releasing a session key encapsulated with a user's public key in response to a request from the user in a lope type cryptosystem.

[0002]

2. Description of the Related Art Cryptographic technology is a computer technology for preventing eavesdropping and falsification of information or impersonation of a user. One of the effects of encrypting data is that access to information (decryption) is limited to a user having a decryption key. Data encryption is
This can be said to be a means for easily realizing access control of confidential information without depending on the operation (on / offline) of the computer system and the platform (OS).

[0003] Regarding the storage of confidential information, the following conditions are usually imposed.

(1) Long term due to laws and organizational regulations
There is an obligation to preserve (eg yearly).

(2) Once stored, there is almost no access.

(3) At the time of an external or in-house audit, it must be possible to reliably submit (decrypt).

[0007] Therefore, if confidential information is attempted to be submitted but cannot be decrypted, it is expected that the organization or department in charge will be disadvantageous. Reasons for the inability to decrypt include key management problems, such as when the confidential information that was supposed to be stored cannot be found, when the decryption key is lost, or when the location of the key is lost due to a change in the person in charge. There are some cases.

Conventionally, key management of a cryptographic system is often left to voluntary management by a user or a system operator (especially, a person responsible for storing confidential information). Therefore, as encryption of confidential information becomes more widespread, it is expected that troubles related to key management will frequently occur.

Therefore, a backup system has been proposed in which a decryption key is centrally managed by a system, not by a user, and is taken out in an emergency. This technique is called a key recovery technique. In particular, among the key recovery techniques, a method of depositing a user's private key with the system is called a key deposit method.

In the key escrow system, a user terminal, a key escrow device
We are building a distributed system in which specialized computer devices are arranged for each function, such as (key storage devices) and data recovery devices. As a known example of such a key recovery system, there is, for example, "encrypted data recovery method, key registration system and data recovery system (Japanese Patent Application No. 9-80081)".

In a system using a public key cryptographic algorithm, a certification authority, which is a specialized organization that issues public key certificates, is established in order to manage the security of private keys and ensure the reliability of public keys. A user authentication technology for performing authentication using a public key certificate issued by a certificate authority has been proposed.
According to this technology, a user can authenticate a partner and confirm the integrity of a message by trusting a certificate authority and a public key certificate. As a publicly known example of such a user authentication method, for example, a public key registration method in cryptographic communication and a public key certificate issuing authority (Japanese Patent Laid-Open
-160198) ".

[0012]

The above-described conventional key recovery system and user authentication system have the following problems.

Conventionally, an organization (key recovery system) for depositing keys and recovering data using the deposited keys and a certificate authority for issuing public key certificates are provided separately and independently. For this reason, when attempting to escrow a private key paired with a public key certified by a public key certificate, the user must first have the certification authority issue a public key certificate, and then The public key of the certificate and the private key of the pair to the key recovery system. That is, the user separately and independently performs procedures for the certificate authority and the key recovery system.

Therefore, the certificate authority and the key recovery system manage each user independently of each other (binary management). For this reason, the key recovery system
Loss the private key paired with the public key of the public key certificate issued by the certificate authority (the loss here means that the private key is stored in addition to the case where the IC card storing the private key is physically lost). (For example, when the user forgets the password for opening the key file, including the state in which the private key cannot be used, etc.), the user requests the key recovery center to transmit the encrypted data using the lost private key. Decryption will be requested. In this case, since the certificate authority manages the user independently of the key recovery system, the fact from the user (the public key of the public key certificate issued by the certificate authority and the secret Key is lost), it cannot be known.

Further, there is no assurance that the user who requests the decryption of the encrypted data using the lost secret key has been issued a public key certificate of a public key paired with the secret key. That is, there is no guarantee that the users registered in the certificate authority and the key recovery center are the same person.

The present invention has been made in view of the above circumstances, unifies user management in a certificate authority and a key recovery system, and provides a user who has been issued a public key certificate by a certificate authority. It is another object of the present invention to provide a data recovery method for permitting data recovery using the private key when the private key paired with the public key of the public key certificate is lost.

[0017]

In order to solve the above-mentioned problems, a first aspect of the present invention provides a method for encrypting data encrypted with a public key of a public key certificate issued by a certificate authority and a private key paired with the public key. A method for recovering encrypted data, comprising: a certificate authority issuing a first public key certificate in accordance with a user's request; and a first public key certificate in accordance with the user's request. A second step of abolishing the key certificate and issuing a second public key certificate; and the data encrypted by the public key of the first public key certificate from the user and the second public key certificate. A third step of receiving a key recovery request using the second public key certificate, and in accordance with the key recovery request received in the third step, the second public key certificate attached to the key recovery request A fourth step of authenticating the user using And when the user is authenticated in the fourth step, a private key paired with the public key of the first public key certificate is searched from the deposited key. And a sixth step of recovering the encrypted data attached to the key recovery request using the secret key retrieved in the fifth step,
It is characterized by having.

[0018] According to the first aspect, the certificate authority comprises:
If the user who issued the public key certificate (for data encryption / decryption) loses the public key of the certificate and the private key, the certificate will be abolished only when requested by the user. Then, a second public key certificate (for authentication) is issued to the user.

Then, by authenticating the user using the second public key certificate, only the user who has issued the second public key certificate can receive the first public key certificate. Data decryption using a private key paired with a public key (for example, decapsulation of a session key) is permitted.

By doing so, the key recovery is permitted only to the user of the public key certificate. Therefore, the authentication / registration means of the user of the public key certificate and the authentication of the user of the key recovery. -Since the registration means can be shared, user management can be unified. Also, only to the user who has been issued a public key certificate by a certificate authority, if the public key of the public key certificate and the private key paired with it are lost,
Data recovery using the secret key can be permitted.

In the first aspect, the fifth
The step of, when a plurality of the first public key certificates have been issued to the user, the expiration date of each of the plurality of first public key certificates and the cryptographic key attached to the key recovery request The encryption key may be compared with the encryption time of the encrypted data to search for a secret key used to encrypt the encrypted data.

By doing so, for example, when a user has issued a plurality of first public key certificates for data encryption / decryption from a certificate authority, the other party sends one of the public keys. When data encrypted by using the key is received, even if the corresponding private key is lost and the data cannot be decrypted, the data can be recovered by making a key recovery request to the certificate authority.

According to a second aspect of the present invention, data encrypted with a private key paired with a public key of a public key certificate issued by a certificate authority is transferred to a key recovery center to which the private key is deposited. A method for recovering encrypted data, comprising: a certificate authority issuing a first public key certificate in accordance with a user's request; and a first public key certificate in accordance with the user's request. A second step of revoking the key certificate and issuing a second public key certificate, and a private key paired with the public key of the first public key certificate abolished in the second step are shown. A third step of sending the escrow key identifier to the user, and at the key recovery center, the data encrypted by the public key of the first public key certificate and the escrow key identifier from the user. To the data linked to A fourth step of accepting, as a key recovery request, data signed with a private key paired with the public key of the certificate, and the signature attached to the key recovery request accepted in the fourth step, A fifth step of authenticating the user by verifying using the public key of the second public key certificate; and
A sixth step of, when the user is authenticated, searching for a secret key indicated by a deposited key identifier attached to the key recovery request received in the fourth step from the deposited keys, And a seventh step of recovering the encrypted data attached to the key recovery request using the secret key retrieved in the sixth step.

In the second aspect of the present invention, as in the first aspect, the means for authenticating and registering the user of the public key certificate and the means for authenticating and registering the user for key recovery can be shared. Since it is possible, user management can be unified. In addition, only a user who has been issued a public key certificate by a certification authority is allowed to recover data using the private key if the private key paired with the public key of the public key certificate is lost. be able to.

In the second aspect, the second
Using the public key certificate for user authentication and data encryption. In the seventh step, the recovered data is re-encrypted using the public key of the second public key certificate, and May be provided.

By doing so, it is possible to improve the security when notifying the user of the recovered data.

In the second step, an expiration date of key recovery using a public key of a revoked first public key certificate and a secret key paired with the public key is set, and in the fifth step, If the key recovery request received in the fourth step has passed the expiration date set in the second step, the data recovery processing may not be performed.

Alternatively, in the third step,
A deposited key identifier indicating a public key and a private key paired with the public key of the first public key certificate abolished in the second step, the expiration date being set to the deposited key identifier, and sent to the user; In the fifth step, the encryption time of the encrypted data attached to the key recovery request received in the fourth step exceeds the expiration date of the deposited key identifier attached to the key recovery request. If so, the data recovery process may not be performed.

By doing so, it is possible to limit the key recovery and the data recovery to be permitted only during a predetermined period from the issuance of the second public key certificate (that is, the abolition of the first public key certificate). it can.

[0030]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, a first embodiment of the present invention will be described.

FIG. 1 is a schematic configuration diagram of a system to which the first embodiment of the present invention is applied.

The system to which this embodiment is applied is shown in FIG.
As shown in the figure, the user device (USC: User Security Co
mponent) 200 and a certificate authority (CA: Certificate Auth) that issues a public key certificate in response to a request from USC 200
ority) 220 and a key escrow device (KEC:
Key Escrow Component (230) and a data recovery device (DRC: Data Recovery Component) 24 that releases the encapsulated session key using a secret key deposited to KEC 230 in response to a key recovery request from USC 200.
0.

In this embodiment, the KEC 230 is the CA 22
0 back-end device. In this regard,
Differs from conventional certificate authorities and key recovery systems. In FIG. 1, the CA 220, the KEC 230, and the DRC 24
0 is shown separately as a separate device, but this is so indicated for convenience in order to clarify the difference from the configuration of the conventional certificate authority and key recovery system. Only. By realizing the CA 220, the KEC 230, and the DRC 240 on a single device, the CA may have a key recovery function.

In the computer device 201, the USC 200 includes an electronic signature program 202, an encryption / decryption program 204, a public key certificate application / update program 206,
In addition, the encrypted data key recovery / re-encryption 208 is loaded on the memory and executed by the CPU.

These programs are, for example, CD-R
A storage medium such as an OM may be provided to the computer device 201. Alternatively, it is stored in a storage medium having a calculation function such as an IC card, and
When the storage medium is mounted on the storage medium, the storage medium itself may execute these programs.

In the CA 220, a user authentication program 226 and a public key certificate application / update program 228 are loaded on a memory in a computer 221 having a database (DB) 222 for storing a public key certificate. This is realized by being executed by.

The KEC 230 stores a secret key registration device 230a for registering a secret key to be deposited and a secret key registered by the secret key registration device 230a.
And a key storage device 230b that searches for a stored secret key in accordance with an instruction from the secret key registration device 230a.

The secret key registration device 230a is the computer device 2
At 31, the secret key sent from CA 220 is
A secret key escrow program 235 for registering (depositing) in the key storage device 230b, additional information (key escrow identifier) as proof that the private key has been escrowed, and a public key certificate for a public key paired with the secret key Key escrow information table 23 storing data in which identifiers indicating
The key escrow information table reference / registration / update program 236 for performing the reference / registration / update processing of No. 4 is loaded on the memory and executed by the CPU.

The key storage device 230b is a computer device 232
In accordance with the instruction from the secret key registration device 230a, a secret key search program 237 for searching for a predetermined secret key from the stored secret key is loaded on the memory,
This is realized by being executed by the CPU.

The secret key registration device 230a and the key storage device 230b may be realized on one device.

The DRC 240 uses the computer device 241 to authenticate the user who made the key recovery request using the USC 200, and a recovery person authentication program 242, and the encapsulated session key sent from the USC 200. And the encrypted data key recovery / re-encryption program 243 for re-encrypting the key is loaded on the memory and executed by the CPU.

Next, the processing procedure of the above-described system will be described.

The processing procedure of this embodiment is such that the user
The processing procedure from requesting the issuance of the first public key certificate to 220 to having the certificate abolished and having the second public key certificate reissued, Second received
And the processing procedure until the session key encapsulated with the public key of the abolished first public key certificate is decapsulated by being authenticated using the public key certificate of
You can think separately.

First, a processing procedure from when a user requests the CA 220 to issue a first public key certificate, until the user abolishes the certificate and has the second public key certificate reissued. Will be described with reference to FIG.

FIG. 2 shows a first embodiment of the present invention.
It is a flowchart for demonstrating the processing procedure after issuing a 1st public key certificate, revoking the said certificate, and reissuing a 2nd public key certificate.

First, the USC 200 executes an encryption / decryption program 204 in accordance with a key generation instruction from a user to generate a public key and a secret key in public key cryptography (step 100). For example, when a user inputs a random number using an input device such as a keyboard and a mouse provided in the computer device 201, the computer device 201 uses the random number as a seed for a key to generate a public key and a private key of a public key cryptosystem. It is generated and stored as a key file in a storage device such as a hard disk included in the computer device 201.

Next, the USC 200 starts the execution of the public key certificate application / update program 206 and proceeds to step 10.
The public key and the private key generated in “0” are sent to the CA 220. As a result, an application for issuing a first public key certificate is applied (step 102). The method of transmitting the public key and the secret key may be either online or offline as long as appropriate user authentication can be used in the CA 220.

Upon receiving the application request for the first public key certificate from the USC 200, the CA 220 starts executing the public key certificate application / update program 226 and issues the first public key certificate. Is returned to USC200. Also, the issued first public key certificate is stored in the database 222.
(Step 104).

Next, in the USC 200, the CA 220
When it is confirmed that the public key certificate has been issued, the user is prompted for an instruction as to whether or not the public key of the certificate and the private key paired with the certificate should be deposited. Then, the received instruction is CA
220 is notified (step 108). Thereafter, the execution of the public key certificate application / update program 206 is temporarily ended.

If the notification received from the USC 200 indicates that it is to be deposited, the CA 220 returns to step 102
And the first key issued in step 104
Is sent to the KEC 230 (step 110). Thereafter, the execution of the public key certificate application / update program 228 is temporarily ended.

Upon receiving the secret key and the first public key certificate (or the identifier of the certificate), the KEC 230 executes the secret key escrow program 235 and sends it to one or both of the key storage devices 230b. The secret key is stored (step 110). At this time, in order to further improve security, the secret key is divided into data that cannot be inferred by the secret key and stored using an encryption technique called Secret Sharing, and the secret key is synthesized as necessary. The secret key may be restored.

Note that the processing in step 110 is actually performed by the KEC 23 located on the back end of the CA 220.
0 goes, but to the user it looks like CA 220 is keeping the private key.

Next, the KEC 230 executes the key escrow information table reference / registration / update program 236 to add the additional information (key escrow identifier) as evidence of the key escrow and the first
Is stored in the key deposit information table 234 in association with the identifier of the public key certificate.

Here, when a third party or a user of the USC 200 performs data encryption using the public key of the first public key certificate (step 120), specifically, the data is encrypted with the session key. It is assumed that a session key (step 124) encapsulated using the public key of the first public key certificate is attached to the data (step 122). Then, consider a case where a user of USC 200 decodes this data.

If the private key paired with the public key of the first public key certificate has not been lost (step 112), the USC 20
0 decrypts the encrypted data by executing the encryption / decryption program 204 in accordance with the decryption instruction from the user. Specifically, the session key encapsulated by the public key of the first public key certificate is decapsulated using the public key of the first public key certificate and the secret key paired with the public key. The encrypted data is decrypted using the obtained session key.

On the other hand, if the private key paired with the public key of the first public key certificate has been lost (step 112), the U
The SC 200 cannot decapsulate the session key encapsulated by the public key of the first public key certificate.

In this case, the public key certificate reissuing process shown in step 130 is executed.

First, the USC 200 executes the public key certificate application / update program 206 again in accordance with the public key certificate reissue instruction from the user, and sends the first certificate issued in step 104 to the CA 220. Of the public key certificate is invalidated (aborted) (step 131).

When the CA 220 receives the invalid application of the first public key certificate, the CA 220 executes the public key certificate applying / updating program 228 again, and executes the first public key certificate stored in the database 222. Update the content to an invalid state,
Reply to USC 200 that the certificate has been abolished. further,
CA220 has established CRL (Certificate Revo
cation list) (step 13)
2).

Next, the USC 200 executes the encryption / decryption program 204 in accordance with the key generation instruction from the user, and generates a public key and a secret key in the public key encryption as in step 100 ( Step 133) Then, according to the public key certificate application / update program 206,
As in step 102, the public key and secret key generated in step 133 are sent to CA 220. As a result, an application for reissuing the public key certificate (issuing the second public key certificate) is applied (step 134). It should be noted that whether or not it is necessary to attach the revocation notice of the first public key certificate performed in step 132 or attach the revoked first public key certificate itself in this reissue request depends on the system operation. Needless to say. In the present embodiment, a case where no attachment is made is described.

Next, when the CA 220 receives the application for reissuing the public key certificate from the USC 200, the CA 220 issues a second public key certificate by the public key certificate application / update program 226 and sends this to the USC 200. Send back. Further, the issued second public key certificate is stored in the database 222 (step 135). This second public key certificate is
This is a certificate for the public key generated in step 133. Further, in step 135, the CA 220 deposits the private key paired with the public key of the first public key certificate with the KEC 230 by either a method of combining with the second public key certificate or a method of separately sending it. Information indicating the evidence and the key escrow identifier indicating the secret key
Send to 0. Then, the flow ends.

In the flow shown in FIG.
02, the public key and the private key are collectively
0, and after confirming the issuance of the first public key certificate, it is determined in step 108 whether or not the private key is to be deposited. However, step 108 may be performed at the stage of step 102, that is, at the stage of applying for the issuance of the first public key certificate. Alternatively, in step 102, only the public key is submitted, and in step 108, the USC 200 executes the electronic signature program 202 to generate a signature verifiable with the public key of the first public key certificate, and together with the signature, A secret key may be deposited.

Next, the flow of data in step 130 (public key certificate update processing) described above will be described.

In the following description of the figures, encrypting data X using key K is described as E [K] (X).

FIG. 3 is a diagram conceptually showing a data flow in step 130 (public key certificate update procedure) in FIG.

In FIG. 3, the USC 200 is a CA22
0, a first public key certificate invalidation request 301 is transmitted. The request 301 includes a request CertRevoke-req, which is generally called a revocation request, encrypted with a random number r, and a request obtained by encapsulating the random number r with the public key CApub of the CA 220.

Upon receiving the first public key certificate revocation request 301, the CA 220 receives the private key CApri of the CA 220.
To extract the random number r, and further apply for CertRevoke-req
Is decrypted. Then, the contents of the application CertRevoke-req are examined, and if OK, a response 3 of invalidation is sent to the USC 200.
Returns 02. The response 302 includes an application result notification CertRe.
voke-res is included. At this time, the USC 200 does not yet have a reliable public key. Therefore, as means for realizing a one-time authentication procedure, for example, USC2
Application result notification Cert based on random number r sent from 00
Preferably, Revoke-res is encrypted.

Next, USC 200 transmits to CA 220 a request 311 for reissuing a public key certificate (issuing a second public key certificate). The request 311 includes a request CertRenewal-req, which is generally called a renewal request, encrypted with a random number r ₂ and a newly generated public key User _A newPub.
(The optional secret key User _A newpri) are included to those encapsulation and those encrypted with the random number r _2, the random number r ₂ with the public key CApub of CA220.

Upon receiving the public key certificate reissue (issue second public key certificate) request 311, CA 220
Remove the random number r ₂ by using a secret key CApri of the A220, to further decode the application CertRenewal-req. Here, if the first public key certificate revocation request 301 and the public key certificate reissue request 311 are performed in the same session, the same random number r ₂ as the random number r can be used. Good.

Next, the CA 220 sends the decrypted application CertRe
Examine the contents of newal-req, and if OK, KEC230
Then, the key recovery validity request 321 for the public key of the revoked first public key certificate and the paired private key is transmitted. The request 321 includes an application KECActive-req for enabling decryption using the public key User _A oldPub of the revoked first public key certificate and the private key paired with the public key, and a random number r. ₃ and a random number r ₃ encapsulated with the KECpub public key KECpub.

Upon receiving the key recovery validity request 321, the KEC 230 extracts the random number r ₃ using the secret key KECpri of the KEC 230, and further decrypts the application KECActive-req.

Next, the KEC 230 sends the decrypted application KECA
After examining the contents of ctive-req, if OK, CA220
, A response 322 to the key recovery validity request 321 is returned. The response 322 includes an application result notification KECActive-res
Is included. Further, a key escrow identifier KE-Id _A indicating a private key paired with the public key of the revoked first public key certificate is included. At this time, in order to limit the response 322 to the key recovery effective request 321 to one time, for example, the CA 22
On the basis of the random number r ₃ that has been sent from 0, the application result notification KECAc
It is preferable to encrypt the tive-res.

[0073] Further, KEC230 is stored in the key escrow information table 234, the first public key certificate associated with the key escrow identifier KE-Id _A (or an identifier of a first public key certificate) Is updated to the key recovery enabled state.

When CA 220 receives a response 322 to key recovery validity request 321 from KEC 230, CA 220
200, a response 312 to the public key certificate reissue request 311 is returned. The response 312 includes the application result notification CertRenewal-res. Further, the re-issued public key certificate (second public key certificate) Certficate and the key escrow identifier KE-Id _A are included. At this time, since the first public key certificate has been abolished, there is no reliable public key in the USC 200. Therefore, as a means for implementing the one-time authentication procedure, for example, the random number r ₂ sent from the USC ₂₀₀ is used. It is preferable to encrypt the application result notification CertRenewal-res.

As described above, in the public key updating procedure shown in FIG. 3, the public key certificate reissue request 31
When the key recovery request 321 is received, the key recovery request 321 is notified to the KEC 230 as an extension. This is different from the conventional public key update procedure.

In FIG. 3, the key recovery is enabled after confirming both the invalidation of the first public key certificate and the issuance of the second public key certificate (reissue of the public key certificate). To do
In response to the public key certificate reissue request 311, a key recovery validity request 321 is activated. However, the key recovery validity request 321 may be activated in response to the first public key certificate invalidation request 301 instead of the public key certificate reissue request 311.

The processing procedure from issuing the first public key certificate to reissuing the certificate and reissuing the second public key certificate has been described above.

Next, the user is authenticated using the re-issued second public key certificate, and the first
About the processing procedure until the session key encapsulated with the public key of the public key certificate of
This will be described with reference to FIG.

FIG. 4 shows a first embodiment of the present invention.
FIG. 10 is a flowchart for explaining a processing procedure from authenticating a user to decapsulating a session key encapsulated with a public key of a revoked first public key certificate.

First, upon receiving a request from a user to release a session key encapsulated by the public key of the abolished first public key certificate, the USC 200 recovers the encrypted data key.
By executing the re-encryption program 208, the target envelope data (including the session key encapsulated with the public key of the abolished first public key certificate and the data encrypted with the session key) ) And CA22
0, a request for a key recovery request including a key escrow identifier KE-Id _A indicating a public key of a revoked first public key certificate and a pair of secret keys is created. Next, the digital signature program 202 is executed to sign the application using the public key of the public key certificate (the second public key certificate) reissued by the CA 220 and the private key, and to the DRC 240 Send it (step 140).

When receiving the request for the key recovery request, the DRC 240 executes the recovery person authentication program 242, and stores the public key certificate (the second public key certificate reissued by the CA 220) attached to the application. The signature of the application is verified using the written public key (step 142). As a result, if it is found that the signature is not based on the public key of the public key certificate attached to the application and the private key of the pair,
Error processing is performed (step 148).

On the other hand, if it is determined that the signature is based on the private key paired with the public key of the public key certificate attached to the application, the sender of the application has the key recovery authority. It is verified whether the user is a user as necessary (step 144). Verification of whether or not the user has the key recovery authority is performed using, for example, a key escrow identifier. In the present embodiment, in step 135 of FIG.
0 is the key escrow identifier KE-Id sent to USC200
_A is converted from the USC 200 to the DR in step 140.
C240. Therefore, if it is determined in step 142 that the signature is based on the private key paired with the public key of the public key certificate attached to the application, the DRC 240 determines that the key escrow identifier KE −Id
_A is transmitted to the KEC 230. In response, KEC2
30 executes the key escrow information table reference, registration and update 236, referring to the key escrow information table 234, the received key escrow identifier KE-Id public key certificate associated with the _A (first It is determined whether or not the public key certificate) is in a state where key recovery may be performed (key recovery is valid). Then, the user authentication is performed by including the determination result in the return value of the recovery person authentication program 242.

In step 144, if the user is authenticated as a user having the recovery authority, that is, the key is stored in the KEC 230 by referring to the key escrow information table 234 using the key escrow identifier KE-Id _A provided by the user. If it is determined that the key is recovered and the key can be recovered, a session key recovery process shown in step 150 is performed (step 146). On the other hand, if the user is not authenticated as a user having the recovery authority, an error process shown in step 148 is performed (step 146).

In the session key recovery processing in step 150, the DRC 240 starts executing the encrypted data key recovery / encryption program 243, and instructs the KEC 230 on the key (first key) identified by the key escrow identifier KE-Id _A. Request to retrieve the public key of the public key certificate and the private key of the pair). In response to this, KEC230 executes the secret key search program 237 searches the key identified by the key escrow identifier KE-Id _A (step 152). In the present embodiment, since it is assumed that the escrow key identifier is unique, the search can be performed based on the escrow key identifier itself or an identifier (storage key identifier) derived from the escrow key identifier.

Next, the DRC 240 is attached to the application form for the key recovery request sent from the USC 200 using the private key paired with the public key of the first public key certificate found in step 152. Decrypted session key (the key encapsulated in the public key of the first public key certificate) (step 1
54).

Next, the DRC 240 not only decapsulates the session key attached to the key recovery request application, but also
It is determined whether or not to decrypt the encrypted data attached to the application form (step 160). This decision, for example,
If both the encapsulated session key and the data encrypted with the session key are attached to the key recovery request application, it is determined that the encrypted data is to be decrypted, and the encapsulated session key is determined. If only "" is added, it may be determined that the decryption of the encrypted data is not performed.

If it is determined that the encrypted data attached to the application form for the key recovery request is to be decrypted, the encrypted data decryption and re-encryption processing shown in step 170 is performed. On the other hand, if it is determined not to do so, the flow ends.

At step 170, the DRC 240
Decrypts the encrypted data attached to the key recovery request application using the session key decrypted in step 154 by the encrypted data key recovery / encryption program 243 (step 172). Next, a session key for re-encryption is generated (step 174), and the data (plaintext) decrypted in step 172 is encrypted using the session key for re-encryption (step 176). further,
For the user of USC 200, the session key for re-encryption is encapsulated using the public key of the second public key certificate reissued by CA 220, and this is encapsulated in step 17
Attach to the data encrypted in 6. Thereby, envelope data is generated (step 178). And
The generated envelope data is sent to USC 200, and the flow ends.

Although the flow shown in FIG. 4 has been described with respect to envelope data, it goes without saying that the same processing can be performed in an encryption scheme in which a session key and encrypted data are separately transmitted.

Next, the flow of data in steps 144 to 170 (key recovery procedure) of the above-described flow of FIG. 4 will be described.

FIG. 5 is a flowchart showing step 14 of the flow shown in FIG.
It is the figure which showed notionally the data flow in 4-step 170 (key recovery procedure).

First, the USC 200 sends a key inquiry to the DRC 240 as to whether or not the key recovery using the public key of the abolished first public key certificate and the paired private key is possible. The request 401 for recoverability confirmation is transmitted. The request 401 includes a status inquiry application? CanKRS-req and a deposited key identifier KE as to whether or not the key recovery using the private key paired with the public key of the abolished first public key certificate is possible. -Id _A encrypted with random number r and random number r with D
Included is the one encapsulated with the public key DRCpub of RC240.

Upon receiving the key recovery possibility confirmation request request 401, the DRC 240 extracts the random number r using the DRC secret key DRCpri, and further decrypts the application? Can KRS-req and the deposit key identifier KE-Id _A. Then, an inquiry is made to the KEC 230 as to whether the key recovery using the deposited key indicated by the deposited key identifier KE-Id _A (a secret key paired with the public key of the first public key certificate) is in a valid state. Is transmitted, the deposit key ID validity confirmation request 421 is transmitted. The request 421 includes a deposit key identifier.
KE-Id to those obtained by encrypting the applicant KECStatus-req for key recovery inquires whether it is effective and deposit key identifier KE-Id _A random number r ₂ with _A, a random number r ₂ of KEC230 Included with the public key KECpub.

[0094] KEC230 receives the deposit key ID valid check request 421 extracts the random number r ₂ using the private key KECpri the KEC, further decodes the applicant KECStatus-req and deposit key identifier KE-Id _A. Then, with reference to the key escrow information table 234, the public key certificate (first public key certificate) associated with the decrypted key escrow identifier KE-Id _A may perform key recovery (key recovery). (Valid) state. Then, a response 422 to the deposited key ID validity confirmation request 421 is returned to the DRC 240. This response contains a valid / invalid determination result notification KECStatus-res for key recovery by (a secret key of the public key paired with the first public key certificate) secret key indicated by the key escrow identifier KE-Id _A It is. At this time, as a means for realizing one-time authentication procedures, for example, based on the random number r ₂ sent from DRC, the judgment result notification KECStatus-res is preferably encrypted.

The DRC 240 sends a response 4 from the KEC 230.
Receiving 22, a response 402 to the key recovery possibility confirmation request request 401 is returned to the USC 200. The response 402 includes an application result notification? Ca corresponding to the determination result notification KECStatus-res included in the response 422 from the KEC 230.
and nKRS-res, and key escrow identifier KE-Id _A, are included and the random number r _3. At this time, as means for realizing the one-time authentication procedure, for example, a random number r sent from the USC 200
Notification of application result? CanKRS-res, key escrow identifier KE-I
Preferably, d _A and the random number r ₃ are encrypted. Alternatively, encryption may be performed using the public key User _A newpub of the second public key certificate issued to the user of the USC 200.

Next, the USC 200 transmits the application result notification? CanKRS-res included in the response 402 from the DRC 240 to
If the key recovery using a key identified by the key escrow identifier KE-Id _A is shown to be effective, the DRC240, the key recovery request with the key identified by the key escrow identifier KE-Id _A 411 Send The request 411 includes the encrypted data Ci.
phertext (Plaintext encrypted with session key SK,
An application indicating the key indicated by the deposit identifier KE-Id _A (including the key encapsulated with the public key of the first public key certificate and the private key User _A oldpri) and a key recovery request KeyRe
The covery-req and the escrow key identifier KE-Id _A are encrypted with a random number r ₃ included in the response 402, and the random number r ₃ is converted to a DRC.
240 public key DRCpub.

Upon receiving the key recovery request 411 from the USC 200, the DRC 240 receives the private key DRCpri of the DRC 240.
Random number r ₃ is extracted using, and further applied for KeyRecovery-r
Decrypt eq and the deposit key identifier KE-Id _A. Here, the key recovery possible confirmation request 401 and the key recovery request 4 described above are described.
11 is performed in the same session, the random number r ₃ is the random number r used in the key recovery possibility confirmation request request 401.
May be the same as

Next, the DRC 240 sends the deposited key identifier KE-Id _A included in the response 422 received from the KEC 230.
It checks the validity / invalidity determination result notification KECStatus-res for key decryption using the key specified by, and sends a session key recovery request 431 to the KEC 230 if the content of the notification is valid. The request 431 includes the session key SK encapsulated by the public key User _A oldPub of the first public key certificate, an application KECReocvery-req indicating permission to decrypt, and a deposit key identifier KE. -Includes what encrypted Id _A with random number r ₄ and what encapsulated random number r ₄ with public key KECpub of KEC 230.

[0099] KEC230, upon receipt of the session key recovery request 431 from the DRC240, remove the random number r ₄ by using a secret key KECpri of KEC230, further application KEC
Reocvery-req, escrow key identifier KE-Id _A , and public key User
Decrypt the session key SK encapsulated in _A oldPub.
Next, a key (a private key User _A oldpri paired with the public key of the first public key certificate) specified by the escrow key identifier KE-Id _A is searched, and the session key SK is encapsulated using this key. Open.

[0100] Then, the KEC 230 is
, A response 432 to the session key recovery request 431 is returned. The response 432 includes an application result notification KECReocvery-res indicating whether or not key recovery has been performed, and the session key SK whose capsule has been released. At this time, in order to limit the response 432 to the session key recovery request 431 to the one-time, for example, based on the random number r ₄ sent from DRC240, encrypting application result notification KECActive-res, and the session key SK Is preferred.

The DRC 240 sends a response 4 from the KEC 230.
32, the key recovery request 411 from the USC 200 using the session key SK included in the response 432.
Decrypts the encrypted data Ciphertext contained in to the plaintext Plaintext. Then, the key recovery request 411 is sent to the USC 200.
412 is returned. In the response 412,
And application result notification KeyRecovery-res included in the response 432 received from KEC230, the random number r ₅ plaintext Plaintext
In those encryption and public key User _A of the second public key certificate that has been re-issue a random number r ₅ to the user of the USC200 newPu
Included in b. At this time, as means for realizing a one-time authentication procedure, for example, U
Based on the random number r ₃ sent from SC200, it is preferable to encrypt the application result notification KeyRecovery-res.

As described above, in the key recovery procedure shown in FIG.
Upon receiving the key recovery possibility confirmation request 401 from the USC 200, the DRC 240 uses the escrow key identifier attached to the request 401 to identify the key specified by the identifier (the public key of the first public key certificate, It is determined whether the key recovery using the secret key is effective. If it is valid, the session key is decapsulated using the key, the data encrypted with the session key is decrypted, and the decrypted data is re-encrypted with the new session key. Then, the new session key is re-encapsulated using the public key of the second public key certificate issued when the first public key certificate is abolished. This is different from the conventional key recovery procedure.

As described above, the user is authenticated using the re-issued second public key certificate, and the first
The processing procedure until the session key encapsulated with the public key of the public key certificate is decapsulated has been described.

In the above embodiment, the CA 220 is the first
If the user who issued the public key certificate (for data encryption / decryption) loses the public key of the certificate and the private key, the certificate will be abolished only when requested by the user. Then, a second public key certificate (for data encryption / decryption and authentication) is issued to the user.

Then, the DRC 240 authenticates the user using the second public key certificate, so that only the user who has issued the second public key certificate can confirm that the user is the first public key certificate. When a public key certificate is issued, key recovery using a private key paired with a public key deposited with the KEC 230 is permitted.

As described above, in the present embodiment, the user having the key recovery authority is authenticated by using the second public key certificate issued to the user, so that it is necessary to register the key recovery user. Absent. In other words, authentication of the public key certificate user
Registration and key recovery user authentication / registration can be centrally managed. In addition, only a user who has been issued a public key certificate by CA 220 is allowed to recover the key using the private key when the public key of the public key certificate and the private key paired with the public key certificate are lost. Can be.

In the present embodiment, the DRC 240
At the request of the user having the key recovery authority, after decrypting the encrypted data using the recovered session key, the decrypted data is re-encrypted with a new session key,
This new session key is encapsulated using the public key of the second public key certificate reissued to the user by the CA 220, and transmitted to the USC 200 of the user.

In this way, security when notifying the user of the recovered data can be improved.

As described above, the first embodiment of the present invention has been described.

Next, a second embodiment of the present invention will be described.

In the first embodiment, the user is authenticated by using the second public key certificate issued to the user, and when the user is authenticated, the key recovery is permitted. On the other hand, in the present embodiment, the expiration date of the key recovery is set, and even if the authentication is successful, the key recovery is not permitted if the expiration date has expired.

This embodiment is different from the first embodiment in the processing in step 135 shown in FIG. 2 and the processing in step 152 shown in FIG. For others,
Since it is the same as the first embodiment, only the processing corresponding to step 135 shown in FIG. 2 and step 152 shown in FIG. 4 will be described, and the other description will be omitted.

FIG. 6 shows a second embodiment of the present invention.
FIG. 3 is a flowchart for explaining processing in step 135a corresponding to step 135 in FIG. 2.

First, when the CA 220 receives a request for reissuing a public key certificate from the USC 200, the CA 220 starts execution of the public key certificate application / update program 226.
The system settings defined in advance for the key recovery period are read (step 500). This system setting is given in the form of a file, and includes information on the expiration date data, the method of sending the expiration date data (with or without extension of the public key certificate, other methods), a list of users who do not allow key recovery Is described. This system setting file is assumed to be stored in advance in the storage device of the computer device 221.

Next, the CA 220 determines whether or not to attach an expiration date to the public key certificate according to the system settings read in step 500 (step 502).
If not attached, select send separately (step 51
0). Store the expiration date on the storage medium and use the US offline
It is sent to the USC 200 by the user of C200, or online separately from the transmission of the public key certificate. At this time, it is preferable that the signature be performed using the secret key of the CA 220.

On the other hand, when attaching to the public key certificate, it is further determined whether or not the format of the public key certificate is extended (step 504).

When the format of the public key certificate is extended, a public key certificate is created and the public key certificate
Information on the expiration date of key recovery is added as an extended format of the public key certificate (step 506). For example, information of a deposit key identifier KeyEscrowIdentifier and a key recovery expiration date KeyRecvoeryUsagePeriod is attached as an extension of the public key certificate x.509 Version3.

When the format of the public key certificate is not extended,
A public key certificate is created, and the validity period of the public key certificate is set to the validity period of key recovery.
Instead of Period (Step 507).

Next, CA 220 re-issues the created public key certificate as a second public key certificate, and
Reply to C200. Further, the issued second public key certificate is stored in the database 222 (step 50).
8). In addition, the CA 220 uses either the method of combining with the second public key certificate or the method of separately sending the public key of the first public key certificate and the secret key paired with the KEC 230.
The additional information indicating the evidence deposited and the key deposit identifier indicating the secret key are sent to the USC 200.

According to the above flow, the expiration date of the key recovery is set when the public key certificate is reissued.

In step 507, the expiration date of the public key certificate is not used directly as the expiration date of the key recovery. CA2 is an evaluation expression in which the key recovery expiration date is set to expire till the expiration date of twelve (or the first 30 days if the expiration date of the public key certificate is one year).
20 and the DRC 240 may be exchanged.

In the above step 510, C
A220 sends to the USC 200 information on the expiration date of the key recovery signed by itself. Therefore, US
The user of C200 adds his / her signature to the expiration date information signed by CA 220,
Will be notified. However, step 510
In the above, the information on the expiration date of the key recovery signed by the CA 220 may be directly transmitted from the CA 220 to the DRC 240.

FIG. 7 shows a second embodiment of the present invention.
FIG. 5 is a flowchart for explaining processing in step 152a corresponding to step 152 in FIG.

First, the DRC 240 starts the execution of the encrypted data key recovery / re-encryption program 243, and the administrator reads the system settings defined in advance for the key recovery period (step 550). This system setting is the same as the system setting in step 500, and is assumed to be stored in the storage device of the computer device 241 in a file format in advance.

Next, the DRC 240 determines whether the expiration date of the key recovery is attached to the public key certificate according to the system setting read in step 550 (step 552). If it is not attached, it is selected to send separately (step 560). The user waits for the storage medium storing the expiration date to be sent offline from the user of the USC 200 or to be sent online separately from the public key certificate. At this time, it is preferable that the user of the USC 220 signs the signature using, for example, the public key of the reissued second public key certificate and a pair of private keys.

On the other hand, if the expiration date of the key recovery is attached to the public key certificate, it is further determined whether or not the format of the public key certificate is extended (step 55).
4).

If the format of the public key certificate is extended, information on the expiration date of key recovery added as an extended format to the second public key certificate is read (step 55).
6). For example, a deposit key identifier KeyE attached as an extension of the public key certificate x.509 Version3 extension
scrowIdentifier and key recovery expiration date KeyRecvoeryUs
Read agePeriod information.

If the format of the public key certificate is not extended, the validity period Validity of the second public key certificate is read as a key recovery validity period KeyRecvoeryUsagePeriod or a parameter for specifying the key recovery validity period. (Step 557).

Next, the DRC 240 determines whether or not the expiration date of the key recovery obtained in the above steps has passed, and only when the expiration date has not passed, the DRC 240 sends the key escrow identifier KE- Key identified by Id _A (first
Request to retrieve the public key of the public key certificate and the private key of the pair). In response to this, KEC230 executes the secret key search program 237 searches the key identified by the key escrow identifier KE-Id _A (step 152). As described above, since the escrow key identifier is assumed to be unique, it is possible to search based on the escrow key identifier itself or an identifier (storage key identifier) derived from the escrow key identifier.

According to the flow described above, key recovery is performed only when the key recovery request is within the validity period of key recovery.

As described above, the second embodiment of the present invention has been described.

Next, a third embodiment of the present invention will be described.

In the second embodiment, the key recovery expiration date information is attached to the second public key certificate reissued by the CA 220, or the key recovery expiration date itself is separately sent, so that the key The expiration date of the recovery is set. On the other hand, in the present embodiment, the expiration date is set using the deposit key identifier.

This embodiment differs from the first embodiment in the processing in step 150 shown in FIG. Others are the same as the above-described first embodiment,
Only the processing corresponding to step 150 in FIG. 4 will be described, and the other description will be omitted.

FIG. 8 shows a third embodiment of the present invention.
FIG. 5 is a flowchart for explaining processing in step 150a corresponding to step 150 in FIG.

Step 150a shown in FIG. 8 differs from step 150 of FIG. 4 in that step 600 is provided as preprocessing of step 152. Therefore, hereinafter, only the processing in step 600 will be described.

First, the DRC 240 starts execution of the encrypted data key recovery / encryption program 243, and determines whether or not the key recovery expiration date is set to be unlimited for the key escrow identifier KE-Id _{A (} see FIG. 14). Step 601). As a determination method, in the process at step 135 shown in FIG. 2, the expiration date of key recovery is set to unlimited / limited according to a predetermined standard, and this information is added to the deposited key identifier and sent to the USC 200. In advance, the validity period information of the key recovery is extracted from the deposited key identifier received from the USC 200 and determined, or the storage key included in the computer device 221 and the deposited key identifier sent to the USC 200 and according to a predetermined standard. A method in which key recovery expiration information set to unlimited / limited is stored in association with the key recovery expiration information, and key recovery expiration information corresponding to the deposited key identifier received from the USC 200 is extracted from the storage device and determined. And so on.

In step 601, if the key recovery expiration date information is unlimited, the process proceeds to step 152. On the other hand, if the time is not unlimited, the current time (or the time at which the user requests key recovery depending on the system operation rules) is Tcurrent, and the period during which the deposit key must be kept after the suspension of the deposit Predetermined period Tl
imit is acquired (step 612). Next, a deposit start time ID-t1 and a stop time ID-t2 of the deposit key identifier are obtained (step 614). Here, the deposit start time ID-t1 of the deposit key identifier is the time at which the CA 220 issued the first public key certificate, or the KEC 230 describes the secret key paired with the public key of the first public key certificate. Means the time at which the deposit identifier was issued, and the deposit stop time ID-t2 is the CA
The time when 220 abolished the first public key certificate, or the KEC 230 used the private key paired with the public key of one public key certificate when the CA 220 reissued the second public key certificate. It means the time when the deposited key information table 234 is updated so that the key recovery becomes effective.

Next, the DRC 240 obtains the time t at which the encrypted data targeted for key recovery was encrypted (step 616). For example, if the encrypted data is stored in a file format, the creation date of the file is input.

Next, the DRC 240 determines that the time t obtained in step 616 is within the range from the deposit start time ID-t1 to the deposit stop time ID-t2 plus the period Tlimit for which there is a storage obligation after the deposit is stopped. It is determined whether or not it is included (step 618).

If not included, it is determined that the key cannot be recovered and an error process is performed (step 630). On the other hand, if it is included, the time Tcurrent acquired in step 612 is
It is determined whether or not the time is included in a range from the deposit stop time ID-t2 to a period obtained by adding a period Tlimit of a storage obligation after the deposit stop to the deposit stop time ID-t2 (step 61).
9). If not included, key recovery is determined to be impossible and error processing is performed (step 630). On the other hand, if it is included, the key recovery is permitted (step 620).
Move to step 152.

According to the above-described flow, key recovery is performed only when the key recovery request is within the validity period of the key recovery.

In the above flow, the expiration date of the key recovery is set uniformly, but it goes without saying that the expiration date may be changed according to each system operation. For example, it may be modified as follows.

(A) Online recovery is limited to a uniformly set expiration date, and offline recovery is determined by interviews with professional staff.

(B) For a user having a specific authority (for example, when the public key certificate indicates that the user has authority of an arbitrary class or more), the expiration date of key recovery (ie, Tlimit for the storage obligation after the suspension of deposit)
Is set longer.

(C) For a user who does not have a specific right, recovery in an off-line manner is in principle excluded from the applicable range of this processing.

(D) The expiration date of key recovery according to the type of encrypted data (that is, the period during which storage is obliged after the suspension of deposit)
Tlimit) setting.

According to the present embodiment, private key escrow starts /
Suspension can be handled at the user's own risk. Also,
After the suspension of the deposit, the setting of the period for storing the deposit key shall be DRC2
It can be determined at the responsibility of 40 managers. In addition, only when the user loses the key deposited with KEC 230,
Key recovery using the key can be provided to the user.

As described above, the third embodiment of the present invention has been described.

Next, a fourth embodiment of the present invention will be described.

An expiration date is usually set in the public key certificate. After the expiration date, the public key certificate is abolished and a second generation public key certificate is issued. That is, in the above embodiment, the first public key certificate for data encryption / decryption may exist for many generations.

In such a situation, when the user submits each of the private keys paired with the public key of the first public key certificate issued for a plurality of generations to the KEC 230, It is preferable to manage using the same escrow key identifier, rather than managing them with separate escrow key identifiers.

The deposit key identifier is confidential data for assuring that the user has the authority to recover the key, and it is desired that the deposited key identifier be stored and stored in an IC card or the like. However, I
With the storage capacity of a medium such as a C card, it is often difficult to store a plurality of deposited key identifiers and public key certificates (for example, 512 BYTE) (for example, 1K BYTE). Therefore, based on the deposited key identifier issued when the private key paired with the public key of the first public key certificate issued first is issued, the first public key issued after the first time is issued. It is desirable to manage the escrow of the public key of a key certificate and a pair of private keys.

When a user receives data encrypted using one public key of one of the first public key certificates issued for a plurality of generations, the corresponding private It is also conceivable that the key is not known and the data cannot be decrypted.

In the present embodiment, such a case is assumed, and a separate escrow key identifier is assigned to each of the public key and the pair of private keys of the first public key certificate issued in multiple generations. It is possible to manage the escrow of these private keys without attaching them. Further, when the user has deposited the public key of the first public key certificate issued for a plurality of generations with the KEC 230 as a pair with a secret key, the secret key for the user to perform key recovery is Even if you do not know, you can recover the key.

This embodiment is different from the above-described first embodiment in that the first public key certificate (for data encryption / decryption) issued for a plurality of generations in the process at step 110 shown in FIG. When each key and a pair of secret keys are deposited, the same deposited key identifier is added to these secret keys, and the processing in step 152 shown in FIG. 4 is different. Others are the same as those in the first embodiment, and therefore only the processing corresponding to step 152 in FIG. 4 will be described, and the other description will be omitted.

FIG. 9 shows a fourth embodiment of the present invention.
FIG. 5 is a flowchart for explaining processing in step 152b corresponding to step 152 in FIG.

First, the KEC 230 executes the secret key search program 237 to determine whether there are a plurality of versions in the deposited key identifier received from the USC 200 (Step 710). As a determination method, step 1 shown in FIG.
In the process at 10, when the same deposit key identifier is added to each of the public key of the first public key certificate and a pair of secret keys issued for a plurality of generations, version (generation) information is added to the deposit key identifier. And a method of determining whether or not the escrow key identifier received from the USC 200 includes version information, or the same as the escrow key identifier received from the USC 200 (but the version information is different) is the proof key of the KEC 230. A method of determining whether or not a plurality of information tables 234 are stored may be considered.

In step 710, if there is no version information (for example, the version number is set to 0), the flow shifts to step 700 to perform the same processing as step 152 in FIG. Search for a secret key specified by the key identifier. Specifically, US
The function f () using the escrow key identifier received from C200 as an input variable is calculated, and the storage location of the secret key (for example, the record number of the database provided in the computer 232)
Is determined, and a secret key is obtained from the determined storage location (step 700). Here, for example, a one-way function is used as the function f (). It is preferable that the storage location can be registered and referred to as a hash table search.

On the other hand, in step 710, if there is version information (for example, the version number is set to 1 or more), the flow shifts to step 712 to encrypt the key recovery target encrypted data. Get time t. For example, if the encrypted data is stored in a file format, the creation date of the file is input.

Next, the escrow key identifier received from the USC 200 is sequentially analyzed to find out which version of the secret key to retrieve from among the first to n-th versions.

First, the KEC 230 executes the key escrow information table reference / registration / updating program 236 to refer to the key escrow information table 234, and, for the escrow key identifier received from the USC 200, for each version number i = 1 to every n
It is determined whether key recovery is permitted (step 71)
4). If the valid key recovery, and the registration time T _i of the deposit key identifier that version number i is attached, the next version number i = i + 1
Then, the registration time T _{i + 1 of} the deposited key identifier appended with is added (step 716). On the other hand, if invalid, the process proceeds to step 722 in order to acquire information on the next version number i = i + 1.

After the processing in step 716 is completed, KEC2
30 is acquired in step 716, during the registration time T _i of the deposit key identifier version number i is attached, the registration time T _{i + 1} of the deposit key identifier version number i + 1 is assigned, step 71
It is determined whether or not the time t acquired in step 2 is included (step 718). If it is included, it is determined that key recovery using the secret key specified by the deposited key information identifier of the version number i is possible, and the process proceeds to step 720.

On the other hand, if it is not included, it is determined that key recovery using the secret key specified by the escrow key information identifier of the version number i is impossible, and The process proceeds to step 722 to obtain

In step 720, the KEC 230 calculates the same function f () as in step 700 using the deposited key identifier of the version number i and the registration time Ti of the identifier as input variables, and stores the secret key storage location (for example, The record number of the database provided in the computer 232 is determined, and the secret key is obtained from the determined storage position.

At step 722, it is checked whether or not the next version number i + 1 is less than or equal to the maximum number n.
i is incremented by one (step 724), and the process returns to step 714. On the other hand, if the next version number i + 1 exceeds the maximum number n, the process ends as an error process (step 7).
30).

The fourth embodiment of the present invention has been described.

In each of the above embodiments, a case has been described in which a user uses a lost secret key to release a session key encapsulated with a public key paired with the secret key. The present invention is not limited to this, and it goes without saying that the present invention can be applied to all cases where a user uses a lost secret key to decrypt data encrypted with a public key paired with the secret key.

Lastly, a case will be described in which each embodiment of the present invention described above is applied to an electronic commerce system.

FIG. 10 is a schematic configuration diagram of an electronic commerce system to which each embodiment of the present invention is applied.

As shown, this system comprises a transmitting device 801, a receiving device 802, and an encrypted data storage device 8
13, an accounting auditor 861, a key recovery agency 851,
And a communication path 800 for performing communication between the transmitting device 801 and the receiving device 802.

[0172] The key recovery agency 851 is the CA 220 of FIG.
It corresponds to the KEC 230 and the DRC 240. The receiving device 802 corresponds to the USC 200 in FIG.
02, 204, 206, and 208, a storage program for storing encrypted data in the storage device 803 is installed.

The transmitting device 801 has a program for encrypting the transaction data using the public key (public key of the first public key certificate) by the user of the receiving device 201 and transmitting the encrypted data to the receiving device 201. It is installed. Accounting Auditor 860
Performs audit procedures on e-commerce.

Normally, in electronic commerce, encrypted transaction data is decrypted immediately after reception. However, in the example shown in FIG.
Upon receiving the transaction data sent from the storage device 803, the storage program is executed and the received transaction data is stored in the storage device 803 on a daily / monthly basis in accordance with, for example, the processing capacity and the work progress of the receiving device 801. I have to. Then, the decryption can be performed later using the private key of the user of the receiving apparatus 201 (the private key of the first public key certificate).

When the user of the receiving apparatus 201 loses the secret key, the transaction data can be decrypted between the receiving apparatus 201 and the key recovery organization 851 by implementing the above-described embodiments. Becomes

It is to be noted that the accounting auditing agency 860 operates the storage device 8
It is also possible to carry out an audit procedure using the transaction data encrypted in 03. In this case, the key recovery authority 851 is requested to obtain a key for decrypting the encrypted transaction data.

[0177]

As described above, according to the present invention,
Centralized user management for public key certificates and key recovery, only for users who have been issued public key certificates,
When the public key of the public key certificate and the private key paired with the public key are lost, data recovery using the private key can be permitted.

[Brief description of the drawings]

FIG. 1 is a schematic configuration diagram of a system to which a first embodiment of the present invention is applied.

FIG. 2 illustrates a processing procedure from the issuance of a first public key certificate to the revocation of the second public key certificate after the issuance of the certificate in the first embodiment of the present invention. FIG. 4 is a flowchart for performing the operation.

FIG. 3 is a diagram conceptually showing a data flow in step 130 (public key certificate update procedure) in FIG. 2;

FIG. 4 illustrates a processing procedure from authenticating a user to decapsulating a session key encapsulated with a public key of a revoked first public key certificate in the first embodiment of the present invention. FIG. 4 is a flowchart for performing the operation.

FIG. 5 is a diagram conceptually showing a data flow in steps 144 to 170 (key recovery procedure) of the flow shown in FIG.

FIG. 6 is a flowchart for explaining processing in step 135a corresponding to step 135 in FIG. 2 in the second embodiment of the present invention.

FIG. 7 is a flowchart illustrating a process in step 152a corresponding to step 152 in FIG. 4 in the second embodiment of the present invention.

FIG. 8 is a flowchart for explaining processing in step 150a corresponding to step 150 in FIG. 4 in the third embodiment of the present invention.

FIG. 9 is a flowchart illustrating a process in step 152b corresponding to step 152 in FIG. 4 in the fourth embodiment of the present invention.

FIG. 10 is a schematic configuration diagram of an electronic commerce system to which each embodiment of the present invention is applied.

[Explanation of symbols]

200 USC 201, 221, 231, 232, 241 Computer device 202 Electronic signature program 204 Encryption / decryption program 206, 228 Public key certificate application / update program 208, 243 Encryption data key recovery / re-encryption program 222 Database 226 Use Authentication program 230 KEC 230a secret key registration device 230b key storage device 234 key escrow information table 235 secret key escrow program 236 key escrow information table reference / registration / update program 237 secret key search program 242 recovery person authentication program 800 communication channel 801 transmission Device 802 Receiving device 803 Storage device 851 Key recovery period 861 Accounting auditor

 ──────────────────────────────────────────────────続 き Continuing on the front page (72) Inventor Toru Kawai 504-2 Shinanomachi, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture Inside Hitachi Electronics Service Co., Ltd. (72) Inventor Hidetaka Yanagiuchi 504-2 Shinanocho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture Hitachi Electronics Service Co., Ltd.

Claims (10)

[Claims] 1. An encrypted data recovery method for recovering data encrypted by a private key paired with a public key of a public key certificate issued by a certificate authority, wherein the certificate authority according to a user request, A first step of issuing a first public key certificate; and a second step of abolishing the first public key certificate and issuing a second public key certificate according to the request of the user. A third step of receiving data encrypted by the public key of the first public key certificate and a key recovery request using the second public key certificate from the user; A fourth step of authenticating the user according to the key recovery request received in the third step and using the second public key certificate attached to the key recovery request; When the user is authenticated by A fifth step of searching for a secret key paired with the public key of the first public key certificate from the deposited keys; and using the secret key searched in the fifth step, A sixth step of recovering the encrypted data attached to the key recovery request. 2. The encrypted data recovery method according to claim 1, wherein the fifth step is performed when a plurality of the first public key certificates are issued to the user. By comparing the expiration date of each public key certificate with the encryption time of the encrypted data attached to the key recovery request,
A method for recovering encrypted data, wherein a secret key used for encrypting the encrypted data is searched for from a deposited key. 3. A cryptographic data recovery method for recovering data encrypted with a private key paired with a public key of a public key certificate issued by a certificate authority by a key recovery center entrusted with the private key. A first step of issuing a first public key certificate in accordance with a request from a user at a certificate authority; and abolishing the first public key certificate in accordance with the request of the user. A second public key certificate issuance step, and a deposited key identifier indicating a private key paired with the public key of the first public key certificate abolished in the second step. A third step of transmitting, and at the key recovery center, the data from the user, which is obtained by concatenating the data encrypted with the public key of the first public key certificate and the deposit key identifier, Public key and pair secret of the second public key certificate A fourth step of receiving data signed with a key as a key recovery request; and a step of publishing the signature attached to the key recovery request received in the fourth step with the second public key certificate. A fifth step of authenticating the user by verifying using the key; and, if the user is authenticated by the fifth step, the key recovery request received in the fourth step is A sixth step of searching a secret key indicated by the attached deposit key identifier from the deposited keys, and using the secret key retrieved in the sixth step to attach the private key to the key recovery request. And recovering the encrypted data. 7. A method for recovering encrypted data, comprising: 4. The encryption data recovery method according to claim 3, wherein in the key recovery center, the seventh step includes re-reading the recovered data using a public key of the second public key certificate. A method for recovering encrypted data, which is provided to a user after being encrypted. 5. The encrypted data recovery method according to claim 3, wherein in the certificate authority, the second step uses a secret key paired with the public key of the abolished first public key certificate. The key recovery center sets an expiration date of the recovery. In the key recovery center, when the key recovery request received in the fourth step has passed the expiration date set in the second step, the authentication is performed. A method for recovering encrypted data, wherein no processing is performed. 6. The encrypted data recovery method according to claim 3, wherein in the certificate authority, the third step is performed by pairing with the public key of the first public key certificate abolished in the second step. And sending the escrow key identifier indicating the secret key of the key to the user with the expiration date set in the escrow key identifier. The key recovery center, wherein the fifth step is the key recovery request received in the fourth step. When the encryption time of the encrypted data attached to the key has passed the expiration date of the deposited key identifier attached to the key recovery request, the authentication processing is not performed. Method. 7. An encrypted data recovery system for recovering data encrypted with a private key paired with a public key of a public key certificate issued by a certificate authority, comprising: a key escrow device, a user device, A key storage unit for storing a private key paired with a public key of a first public key certificate abolished by a certificate authority, and in accordance with an instruction of the data recovery device, Notifying means for retrieving the secret key indicated by the deposited key identifier notified from the apparatus from the key storage means, and notifying the data recovery apparatus,
The user device further comprises: data encrypted with the public key of the first public key certificate, and a secret key paired with the public key of the first public key certificate sent from a certificate authority. A consigned key identifier indicating a key is concatenated, and for the concatenated data, an electronic signature is generated using a public key of the second public key certificate issued by a certificate authority and a pair of private keys, and The linked data obtained by
An electronic signature generating unit for notifying the data recovery device, wherein the data recovery device verifies the electronic signature notified from the user device using a public key of the second public key certificate. An authentication unit for authenticating a user, and a key escrow device that configures the linked data notified from the user device when the user is authenticated by the authentication unit. Acquiring means for acquiring the secret key indicated by the deposited key identifier, and using the secret key acquired by the acquiring means, the encrypted data constituting the linked data notified from the user device is encrypted. Recovery means for recovering lost data. 8. A cryptographic data recovery apparatus for recovering data encrypted with a private key paired with a public key of a public key certificate issued by a certificate authority, wherein the first public key certificate abolished by the certificate authority Key storage means for storing a public key paired with a public key of a certificate; public disclosure of the first public key certificate electronically signed with the public key paired with the public key of the second public key certificate Receiving means for receiving, from a user, data in which data encrypted with a key and a public key of the first public key certificate and a escrow key identifier indicating a secret key of a pair are connected; Using a public key of a key certificate, by verifying an electronic signature attached to the concatenated data, an authentication unit that authenticates a user, when the user is authenticated by the authentication unit, Deposit making up the linked data received by the receiving means An acquisition unit that acquires a secret key indicated by a key identifier from the key storage unit; and, using the secret key acquired by the acquisition unit, encrypted data that constitutes the concatenated data received by the reception unit. Recovery means for recovering the encrypted data. 9. A storage medium storing a program for recovering data encrypted with a private key paired with a public key of a public key certificate issued by a certificate authority, the program comprising: A first step of storing, in a storage device, a public key and a pair of a private key of a first public key certificate abolished by a certificate authority, and a secret of the public key and a pair of the second public key certificate; The data encrypted with the public key of the first public key certificate, which has been digitally signed with the key, and a deposited key identifier indicating a private key paired with the public key of the first public key certificate are linked. Receiving the obtained data from a user, and using the public key of the second public key certificate to generate an electronic signature attached to the concatenated data received in the second step. Verifying the third step of authenticating the user And obtaining, from the storage device, a secret key indicated by the deposited key identifier constituting the linked data received in the second step when the user is authenticated in the third step. And a fifth step of recovering the encrypted data constituting the concatenated data received in the second step using the secret key obtained in the fourth step. A storage medium storing a program to be executed. 10. The apparatus of the sender, wherein the transaction data is encrypted using the public key of the first public key certificate issued by the certificate authority, and transmitted to the receiver. Storing the encrypted transaction data transmitted from the sender in a storage medium; and pairing the encrypted transaction data stored in the storage medium with a public key of the first public key certificate. Decrypting using the private key of the first public key certificate in the certificate authority according to the request of the receiver. A first step of issuing a certificate; a second step of receiving a key recovery request from the recipient using the encrypted transaction data and the second public key certificate; In the step A third step of authenticating the recipient using the second public key certificate attached to the key recovery request in accordance with the attached key recovery request; and Is authenticated, a fourth step of searching for a secret key paired with the public key of the first public key certificate from the deposited keys, and a secret key searched in the fourth step. A fifth step of recovering the encrypted transaction data attached to the key recovery request using a key.