JP2008252440A - Linkage electronic certificate issuing, utilization and verification system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To allow a client being a portable terminal user to use a previously used client certificate as it is even when the client changes certificate authorities because the client certificate used in a carrier A can not be used and a new client certificate sometimes has to be reissued at a carrier B when the client changes the certificate authorities (carrier) for issuing an electronic certificate, for example, the carrier A is changed to the carrier B. <P>SOLUTION: A self signature certificate issued by the client himself/herself is made to be a client certificate, the certificate authority issues a linkage electronic certificate that links the client certificate with a root certificate, and when an electronic signature is performed, the client has a secret key corresponding to the client certificate to generate an electronic signature. Even when certificate authorities are changed, only the root certificate and the linkage certificate are changed, and the client certificate is used as it is. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to an electronic certificate issuance method, usage method, and verification method.

  With the spread of the Internet in recent years, the demand for electronic commerce and electronic applications has increased. As a security infrastructure for safely using these services, there is a public key infrastructure (PKI: Public Key Infrastructure) that proves the existence of an individual. With the implementation of PKI, falsification and spoofing of electronic documents are prevented, and electronic commerce and the like can be realized safely. These PKI technologies are used not only in the Internet world but also in the mobile network world.

  In some cases, public key certificates are used to implement PKI. In the conventional PKI technology, a specific certificate authority issues public key certificates for each user (for example, non-patent literature). 1).

International Telecommunication Union al., "Information technology - Open systems interconnection - The Directory: Public-key and attribute certificate frameworks (ITU-T Recommendation X.509)", (Switzerland), International Telecommunication Union, 3 May 31, 2000, p . 1-129

  In the conventional PKI system, public key certificates are roughly divided into a root certificate of the certificate authority itself and a client certificate of the client. As shown in FIG. 4, the public key certificate is composed of information such as version number, certificate authority name, serial number, validity period, public key certificate owner name, public key, and certificate authority digital signature. . Here, not only public key certificates but also electronic certificates are collectively referred to as electronic certificates or simply certificates.

  As shown in FIG. 4, when a client applies an electronic signature (hereinafter also simply referred to as a signature) to an electronic contract or the like (hereinafter also simply referred to as electronic data), the client uses the public key in the client certificate 70. An electronic signature is applied to an electronic contract or the like with a private key corresponding to (client private key). The client certificate 70 is digitally signed with a private key (certificate authority private key) corresponding to the public key in the root certificate 60. As a result, the electronic contract 80 or the like with the electronic signature is guaranteed to have been electronically signed by the client, and the validity of the client certificate 70 itself is guaranteed by the certificate authority. Further, the root certificate 60 is obtained by applying an electronic signature (hereinafter referred to as a self-signed certificate, and a self-signed certificate is referred to as a self-signed certificate) with its own private key. , It is guaranteed that the root certificate 60 itself has not been tampered with.

  These mechanisms are used not only in the Internet world but also in the mobile network world. In the world of mobile networks, certificate authorities are operated by mobile telecommunications carriers (hereinafter also referred to as carriers and mobile companies), and client certificates issued by each carrier are stored and operated on mobile terminals of each carrier. Many.

  However, when the client changes the contracted mobile company, for example, from carrier A to carrier B, storing and using the client certificate issued by carrier A in the mobile terminal of carrier B is carrier B However, the client certificate itself is guaranteed by the carrier A, and may not be suitable for operation. For this reason, it is necessary to revoke the client certificate issued by carrier A that was used before the contract change, and to have carrier B reissue a client certificate. Therefore, if you change the contracted mobile company, you can not reuse the digital certificate that you used before, and it is inconvenient for the client, even if you change the mobile company, There is a request to use a certificate.

  In order to verify the validity of an electronic contract with an electronic signature, it is necessary to verify the following two broad categories. The first is “signature verification” to confirm whether the electronic signature itself applied to an electronic contract is valid, and the second is that each certificate is valid. It is “certificate verification” to check if it exists. Certificate verification means verification of an electronic signature applied to a certificate, confirmation of validity period, revocation confirmation, and the like.

  However, here, if the client changes the mobile company, for example, the carrier A is changed to the carrier B, the client certificate issued by the carrier A is revoked, and the carrier B is issued a new client certificate again. In the case of a signed electronic contract signed with a business partner using a client certificate issued by Carrier A before the change, the verifier ( (E.g., suppliers) may fail to verify signed electronic contracts, etc., and contracts may become invalid. Therefore, when the client changes the mobile phone company, it is inconvenient because it requires re-contracting with the business partner using a new certificate. In other words, not only on the client side (signature assigning side) but also on the side that received the signed electronic contract (signature verification side), the signed electronic contract etc. are invalidated to the extent that the client changes the mobile company. Since this is inconvenient, there is a request for the client side to use the digital certificate that has been used before.

  The present invention has been made in view of the above circumstances, and it is an object of the present invention to be able to use a client certificate that has been used before, even when the client changes the trust certificate authority. It is to provide an electronic certificate issuance / use / verification system.

  Specifically, the present invention includes a certificate authority certificate issuing device that issues a public electronic certificate, a client device that applies an electronic signature to an electronic contract, and a verification device that verifies signed electronic data. When issuing a certificate, the client device creates a self-signed certificate by itself and uses it as its own client certificate. The certificate authority certificate issuing device issues a concatenated electronic certificate that concatenates the root certificate and the self-signed client certificate from the client device, and the client device is self-signed when applying the electronic signature to the electronic data. Create signed electronic data by applying the electronic signature to the electronic data to be signed with the private key corresponding to the client certificate (client private key). When verifying such data, the verification device, in addition to verifying the electronic signature, the client certificate, the connection certificate, and the root certificate It is characterized by verifying.

  Also, when changing the CA issuing device that issued the concatenated certificate, the target CA certificate issuing device issues a concatenated certificate that concatenates its root certificate and the existing client certificate of the client device. However, when a client device applies an electronic signature to electronic data, a signature with an electronic signature applied to the electronic data to be signed with a private key corresponding to an existing client certificate (an existing private key of the client) is attached. Electronic data is created, and a new root certificate, new connection certificate, existing client certificate, and signed electronic data are combined, and the verification device verifies the electronic signature when verifying the data. In addition to this, it is characterized by verifying the client certificate, the link certificate, and the root certificate.

  The data sent from the client device to the verification device does not necessarily need to be a bundle of a root certificate, a connection certificate, a client certificate, and signed electronic data, so that each piece of information can be acquired from the signed electronic data. May be. Also, each certificate is not necessarily stored inside the client device, but is stored in another device so that the required device can be obtained when the information of each certificate is required. Good.

  According to the above aspect, the client device applies the electronic signature to the electronic data with the private key corresponding to the self-signed certificate (client certificate) created by itself, and the authentication is performed even when the mobile company is changed. It is only necessary to change the root certificate and the concatenation certificate issued by the station certificate issuing device. The self-signed certificate (client certificate) with the electronic signature on the electronic data can be generated and changed without changing it. , Signature verification, etc. becomes possible.

  Also, even if the mobile company is changed, the client certificate has not been revoked, so the electronic contract signed before the change of the mobile company etc. can be verified even after the change. It becomes possible, and procedures such as re-contract are unnecessary.

  According to the present invention, the client certificate that has been used before can be used even when the client changes the certificate authority as the trust point, and convenience is improved.

  Hereinafter, an embodiment of the present invention will be described with reference to the drawings. However, this does not limit the present invention.

  FIG. 1 is a network configuration diagram to which an embodiment of the present invention is applied. In the system of this embodiment, as shown in FIG. 1, a certificate authority certificate issuing device 10, a client device 20, and a verification device 30 are connected to each other via a communication network (hereinafter referred to as a network) 40 such as the Internet. Configured. In FIG. 1, in order to clarify that there are a plurality of certificate authority certificate issuing devices, they are denoted as A certificate authority certificate issuing device 10 (1) and B certificate authority certificate issuing device 10 (2).

  The certificate authority certificate issuing device 10 issues a concatenated certificate that links the root certificate, which is its own self-signed certificate, and the client certificate issued by the client device. Also, if necessary, the linked certificate is revoked and revocation information is created / updated. In response to the validity check request from the verification device 30, the validity of the linked certificate is returned. As shown in FIG. 2, the certificate authority certificate issuance apparatus 10 includes a certificate creation unit 102 that creates a root certificate and a linked certificate, a revocation list creation unit 103 that creates and updates certificate revocation information, A secret key 105, which is secret information for applying a digital signature to the certificate and the revocation information, a revocation list 106, which is the revocation information created / updated, and a data transmission / reception unit 104 that transmits / receives each certificate, revocation list, etc. , A control unit 101 for controlling them.

  The client device 20 issues a client certificate, which is its own self-signed certificate, transmits the client certificate to the certificate authority certificate issuing device 10, and issues a connection certificate issue request. Further, the client device 20 creates signature target data and applies an electronic signature to the signature target data. As shown in FIG. 2, the client device 20 includes a certificate creating unit 202 that issues a client certificate that is a self-signed certificate, a cryptographic operation unit 203 that applies a digital signature to data to be signed, a self-signed certificate, and a signature. A secret key 205, which is secret information for applying an electronic signature to the target data, a data transmission / reception unit 204 that transmits / receives each certificate, electronic data with a signature, and the like, and a control unit 201 that controls them are included.

  The verification device 30 receives the electronic data with signature and verifies the electronic signature. Each certificate is also verified (certificate signature verification, validity period confirmation, revocation confirmation, etc.). As shown in FIG. 2, the verification device 30 includes a cryptographic operation unit 303 that verifies an electronic signature of signed electronic data, a certificate verification unit 302 that verifies a certificate, signed electronic data, a revocation list, and the like. Includes a data transmission / reception unit 304 for transmitting and receiving and a control unit 301 for controlling them.

  Further, each of the certificate authority certificate issuing device 10, the client device 20, and the verification device 30 includes a storage medium 57, a reading device 51 of the storage medium 57, and a primary storage device using a semiconductor (see FIG. 3). (Hereinafter referred to as a memory) 52, an input / output device 53, a CPU 54, a secondary storage device (hereinafter referred to as a storage device) 55 such as a hard disk, and a communication device 56 are connected to an internal communication line (hereinafter referred to as a bus). It can be configured on the information processing apparatus 50 connected at 58.

  The above-described cryptographic operation units 203 and 303, certificate creation units 102 and 202, revocation list creation unit 103, certificate verification unit 302, data transmission / reception units 104, 204, and 304, control units 101, 201, 301 is embodied on the device by the CPU 54 executing a program stored in the memory 52 or the storage device 55 of each device. These programs, secret keys 105 and 205, and revocation list 106 may be stored in the storage device 55, and when necessary, a removable storage medium 57 or a communication medium (network 40 or network 40). It may be introduced into the information processing apparatus 50 via the upper carrier).

  Hereinafter, an outline of the system according to the present embodiment will be described with reference to the drawings.

  As shown in FIG. 7, the certificate authority certificate issuance apparatus 10 creates a root certificate that is a self-signed certificate in advance (denoted as step 001 and S001, and so on).

  As shown in FIG. 5, the client device 20 includes a version number, a certificate authority name (client device 20 or owner name of the client device 20), a serial number, a validity period, and an owner name of the public key certificate (client device 20). Alternatively, a self-signed certificate (client certificate) 71 self-signed with the private key 205 of the client device 20 is created in information such as the owner name of the client device 20) and the public key (S002), and a certificate authority certificate is issued A self-signed certificate (client certificate) 71 is sent to the apparatus 10 and a connection certificate issuance request is made to the certificate authority certificate issuing apparatus 10 (S003).

  The certificate authority certificate issuance apparatus 10 confirms and examines the request contents of the connection certificate issuance request from the client apparatus 20 (S004). If there is no problem, the self-signed certificate (client certificate) sent from the client apparatus 20 is obtained. The hash value of 71 is calculated (S005). As shown in FIG. 5, the certificate authority certificate issuing device 10 further includes a version number, a certificate authority name (name of the certificate authority certificate issuing device 10), a serial number, a validity period, and an owner name of the linked certificate (client). Device 20 or the owner name of the client device 20), and a link certificate 90 signed with the private key 105 of the certificate authority certificate issuing device 10 based on information such as the hash value calculated in S005 (S006) The certificate 60 and the connection certificate 90 are sent to the client device 20.

  On the other hand, when the private key 205 managed by the client device 20 is compromised due to leakage or the like and the linked certificate is to be revoked, the client device 20 requests the certificate authority certificate issuing device 10 to revoke the linked certificate. (S007), the certificate authority certificate issuance apparatus 10 confirms and examines the contents of the request (S008), and is necessary for revocation confirmation, such as the version number, certificate authority name, serial number, and revocation date, etc. of the concatenated certificate to be revoked. Information is collected and a revocation list is created / updated (S008). It is assumed that the revocation list is digitally signed with the private key 105 of the certificate authority certificate issuing device 10 in order to ensure validity.

  Further, when the client device 20 changes the certificate authority certificate issuing device 10 (here, the certificate authority certificate issuing device 10 before the change is the A certificate authority certificate issuing device 10 (1), and the authentication after the change is performed. The station certificate issuing device 10 is assumed to be a B certificate authority certificate issuing device 10 (2)), and the client device 20 sends an existing self-signed certificate (client certificate) to the B certificate authority certificate issuing device 10 (2). 71 is sent, and a concatenated certificate issuance request is made to the B certificate authority certificate issuing apparatus 10 (2) (S003). It is assumed that the B certificate authority certificate issuing device 10 (2) has also created its own root certificate (S001).

  The B certificate authority certificate issuing device 10 (2) confirms and examines the request contents of the connection certificate issuance request from the client device 20 (S004), and if there is no problem, the self-signed certificate sent from the client device 20 The hash value of the certificate (client certificate) 71 is calculated (S005). As shown in FIG. 6, the B certificate authority certificate issuing device 10 (2) further includes a version number, a certificate authority name (name of the B certificate authority certificate issuing device 10 (2)), a serial number, a validity period, and a connection. The certificate owner name (client device 20 or the owner name of the client device 20), the hash value calculated in S005, and the like signed with the private key 105 of the certificate authority certificate issuing device 10 (2) The certificate 91 is created (S006), and the root certificate 61 and the connection certificate 91 are sent to the client device 20.

  When an electronic signature is applied to an electronic contract or the like, as shown in FIG. 7, the client device 20 creates signature target data (S011), and uses the private key 205 of the client device 20 to sign the signature target data. An electronic signature is given (S012). In addition, the client device 20 sends the signed electronic data 81 including the self-signed certificate (client certificate) 71, the connection certificate 90, and the root certificate 60 to the verification device 30 (S013).

  When the verification device 30 that has received the signed electronic data verifies the validity of the signed electronic data, the verification device 30 checks the validity period of each certificate 71, 90, 60 as shown in FIG. (S020), if S020 is passed, the public key of the client device 20 is extracted from the self-signed certificate (client certificate) 71 (S021), and the self-signed certificate (client certificate) 71 itself is valid. The electronic signature of the self-signed certificate (client certificate) 71 is verified with the public key acquired in S021 (S022). If the verification in S022 is passed, the digital signature of the signed electronic data 81 is verified with the public key acquired in S021 (S023). If the verification of S023 is passed, the public key of the CA certificate issuing device 10 is taken out from the root certificate 60 (S024), and whether the root certificate 60 itself is valid or not is obtained with the public key acquired in S024. The electronic signature of the root certificate 60 is verified (S025).

  If the verification of S025 is passed, the verification device 30 calculates the hash value of the self-signed certificate (client certificate) 71, and further compares it with the hash value described in the concatenated certificate 90 to determine whether both are the same value. Confirm (S026). If S026 is passed, the electronic signature of the concatenated certificate 90 is verified with the public key of the certificate authority certificate issuing device 10 acquired in S024 (S027). If the verification of S027 is passed, the concatenated certificate 90 is revoked. In order to determine whether or not it has been made, a validity check request is sent to the certificate authority certificate issuing device 10 (S028).

  The certificate authority certificate issuing device 10 that has received the validity check request for the linked certificate 90 from the verification device 30 transmits the revocation list 106 to the verification device 30 (S029).

  The verification device 30 that has received the revocation list verifies the signature of the revocation list with the public key of the CA certificate issuance device 10 acquired in S024 in order to confirm the validity of the revocation list, and further includes the revocation list in the revocation list. It is confirmed whether or not the concatenation certificate 90 is not applicable (S030). If S030 is passed, the electronic data with signature is regarded as valid (S031), otherwise it is regarded as invalid (S032), and the process is terminated.

  As described above, according to the present embodiment, the client device 20 applies the electronic signature to the electronic data with the private key 205 corresponding to the self-signed certificate (client certificate) 71 created by itself. Even if the A certificate authority certificate issuing device 10 (1) is changed to the B certificate authority certificate issuing device 10 (2), the root certificate issued by the A certificate authority certificate issuing device 10 (1) The certificate 60 and the concatenated certificate 90 need only be changed to the root certificate 61 and concatenated certificate 91 issued by the B certificate authority certificate issuing device 10 (2), respectively, and the self-signed electronic signature is applied to the electronic data. Even if the signature certificate (client certificate) 71 is not changed, the signature can be generated and the signature can be verified.

  Further, even when the A certificate authority certificate issuing device 10 (1) is changed to the B certificate authority certificate issuing device 10 (2), the self-signed certificate (client certificate) 71 is not revoked. , Electronic contracts signed before the change can be verified even after the change, and procedures such as a re-contract are not required.

  In addition, this invention is not limited to said one Embodiment, A various deformation | transformation is possible within the range of the summary.

  For example, the certificate authority certificate issuing device 10 sends the root certificate 60 and the connection certificate 90 to the client device 20 in S006 of FIG. 7, and the client device 20 sends the self-signed certificate (client) to the verification device 30 in S013. Certificate) 71, a concatenated certificate 90, and a signed electronic data 81 including a root certificate 60 are sent, and each certificate 71, 90, 60 is sent to the certificate authority certificate issuing device 10, the client device 20, It may be stored in a separate device that can be accessed by the verification device 30, and the necessary certificates 71, 90, 60 may be acquired by the devices 10, 20, 30 as necessary.

It is a figure explaining the network structure in one Embodiment. It is a figure which shows the structural example of the certification authority certificate issuing apparatus, client apparatus, and verification apparatus which are shown in FIG. It is a figure which shows the hardware structural example of the certification authority certificate issuing apparatus, client apparatus, and verification apparatus which are shown in FIG. It is a figure which shows the content and relationship of the client certificate in a conventional system, a root certificate, and electronic data with a signature. FIG. 6 is a diagram (part 1) illustrating the contents and relationships of a client certificate, a connection certificate, a root certificate, and signed data in an embodiment. FIG. 7 is a diagram (part 2) illustrating the contents and relationship of a client certificate, a connection certificate, a root certificate, and signed data in an embodiment. FIG. 6 is a workflow diagram illustrating certificate issuance, revocation, and signature generation processing according to an embodiment. It is a workflow figure explaining the process of signature verification in one Embodiment.

Explanation of symbols

10: CA certificate issuing device, 20: client device, 30: verification device, 40 network, 50: information processing device, 51: reading device, 52: memory, 53: input / output device, 54: CPU, 55: storage Device, 56: communication device, 57: storage medium, 58: bus, 60: root certificate, 70, 71: client certificate, 80, 81: electronic data with signature, 90, 91: connection certificate, 101, 201 , 301: Control unit, 102, 202: Certificate creation unit, 103: Revocation list creation unit, 104, 204, 304: Data transmission / reception unit, 105, 205: Private key, 106: Revocation list, 203, 303: Cryptographic operation Section 302: Certificate verification section

Claims (6)

A method for issuing / using / verifying an electronic certificate in a system comprising: a certificate authority certificate issuing device that issues an electronic certificate; a client device that applies an electronic signature to electronic data; and a verification device that verifies signed electronic data. Because
The certificate authority certificate issuing device issues a root certificate that proves the existence of the certificate authority certificate issuing device, and further connects the root certificate and a client certificate that proves the existence of the client device. Issue a certificate,
The certificate authority certificate issuing device revokes the connection certificate as necessary, and creates information for revocation confirmation,
The certificate authority certificate issuing device provides information for checking the revocation in response to a validity check request for the connection certificate from the verification device;
The client device issues the client certificate, requests the certificate authority certificate issuance device to issue the linked certificate that links the client certificate and the root certificate;
The client device creates electronic data, creates electronic data with a signature obtained by applying an electronic signature to the electronic data with a private key corresponding to the client certificate,
The verification device verifies the electronic signature of the signed electronic data using the client certificate;
The verification device requests the certificate authority certificate issuing device to check the validity of the connection certificate, and checks the validity of the electronic data with signature. Usage and verification methods. A method for issuing / using / verifying an electronic certificate according to claim 1,
The certificate authority certificate issuing device adds an electronic signature to the data describing the hash value of the client certificate and the relationship between the certificate authority certificate issuing device and the client device with the private key of the certificate authority certificate issuing device. A method for issuing / using / verifying an electronic certificate, characterized by creating the linked certificate. A method for issuing / using / verifying an electronic certificate according to claim 1,
The client device has a self-signed certificate in which an electronic signature is applied to the information indicating the presence of the client device and the information obtained by associating the public key of the client device in the public key cryptosystem with a private key that is a pair of the public key An electronic certificate issuing method for requesting the CA certificate issuing device to issue the connection certificate, and a secret paired with the public key described in the self-certificate for electronic data An issuance / use / verification method for an electronic certificate, characterized by creating electronic data with a signature with an electronic signature using a key. A method for issuing / using / verifying an electronic certificate according to claim 1,
The verification device obtains the client certificate, the connection certificate, and the root certificate used to apply an electronic signature to the signed electronic data, and the electronic signature of the signed electronic data is obtained from the client certificate. The public key described in the certificate is verified, the digital signature of the client certificate is verified with the public key described in the client certificate, and the digital signature of the connection certificate and the root certificate is disclosed as described in the root certificate. And verifying with a key, comparing the hash value described in the concatenated certificate with the hash value of the client certificate, and confirming the validity of the concatenated certificate to the previous certificate authority certificate issuing device. How to issue / use / verify certificates.   The root certificate for data including information for identifying the root certificate issued by the certificate authority certificate issuing device, information for identifying the client certificate issued by the client device, and information for uniquely determining the client certificate Data format of the electronic certificate of the concatenation certificate that has been digitally signed with the private key for the public key described in the certificate.   The electronic data is a signed electronic data obtained by applying an electronic signature to the electronic data with a private key that is a public key pair described in the client certificate, and includes information on the client certificate, the connection certificate, and the root certificate. Includes electronic signature data format.

Images