WO2008050792A1 - Système, dispositif, procédé et programme pour authentifier un partenaire de communication au moyen d'un certificat électronique incluant des informations personnelles - Google Patents

Système, dispositif, procédé et programme pour authentifier un partenaire de communication au moyen d'un certificat électronique incluant des informations personnelles Download PDF

Info

Publication number
WO2008050792A1
WO2008050792A1 PCT/JP2007/070706 JP2007070706W WO2008050792A1 WO 2008050792 A1 WO2008050792 A1 WO 2008050792A1 JP 2007070706 W JP2007070706 W JP 2007070706W WO 2008050792 A1 WO2008050792 A1 WO 2008050792A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
electronic certificate
client
temporary
server
Prior art date
Application number
PCT/JP2007/070706
Other languages
English (en)
French (fr)
Inventor
Kohsuke Okamoto
Takashi Miyamoto
Original Assignee
International Business Machines Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corporation filed Critical International Business Machines Corporation
Priority to IN2956CHN2009 priority Critical patent/IN2009CN02956A/en
Priority to KR1020097008495A priority patent/KR101054970B1/ko
Priority to EP07830440.9A priority patent/EP2086162B1/en
Priority to CN2007800400182A priority patent/CN101529797B/zh
Priority to CA2663241A priority patent/CA2663241C/en
Priority to JP2008541007A priority patent/JP4870777B2/ja
Publication of WO2008050792A1 publication Critical patent/WO2008050792A1/ja

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden

Definitions

  • the present invention relates to authentication of a communication partner using an electronic certificate, and more particularly to a technique for authenticating a communication partner using an electronic certificate including personal information.
  • SSL Secure Socket Layer
  • RFC 2246 RFC 2246
  • IETF Internet Engineering Task Force Standardized Transport Layer Security
  • SSL / TLS Handshake Protocol Prior to the start of encrypted communication, SSL / TLS Handshake Protocol negotiates various parameters necessary for starting encrypted communication between server and client.
  • Handshake Protocol the other party is authenticated first, and then the optimal algorithm is determined from the compression / encryption algorithm that can be used in common by both the client and server.
  • HandshakeProtocol When negotiation using HandshakeProtocol is completed normally, encrypted communication is started between server clients.
  • partner authentication in Handshake Protocol will be described using an example in which the server device authenticates the client device.
  • the client device's own electronic certificate is included in the body of the ClientCerticicate message and sent to the server device.
  • the server device that has received the electronic certificate checks its validity using the key of the root certificate authority (C (A) that it holds.
  • C (A) root certificate authority
  • the electronic certificate also supports the public key in addition to the public key.
  • the bibliographic information such as the owner of the private key (issuer of the electronic certificate) and the expiry date of the public key, etc. are described.
  • the server device refers to the bibliographic information and the client device is the appropriate communication partner. Make sure that there is.
  • the client device sends a clientshello protocol start message ClientHello
  • ClientHello The digest of the communication content from the message to the Client Key Exchange message is encrypted with the client device's private key to create a signature, which is included in the body of the Certificate Verify message and sent to the server device.
  • the server device verifies that the current communication partner is the owner of the electronic certificate by decrypting the information contained in the body of the CertificateVerify message with the public key described in the electronic certificate of the client device ( Non-patent document 1).
  • Non-Patent Document 2 a public personal authentication service has recently started (see Non-Patent Document 2).
  • the public personal authentication service is a service issued by the prefectural governor to issue an electronic certificate that can be used when using the electronic application 'notification service provided by an administrative agency.
  • Electronic certificates are issued at low cost to people who live anywhere in the country. Therefore, it is desirable to use an electronic certificate issued by a public personal authentication service as an SSL / TLS client certificate.
  • Non-Patent Document 1 T. Dierks, E. Rescorla, fhe TransportLayer security (TLS) Protocol ", [online], April 2004, RFC 4346, [searched September 22, 2006], Internet URL: http: //www.ietf.orgAfcAfc4346.txt>
  • Non-Patent Document 2 "Public Personal Authentication Service Portal Side, [online], January 29, 2004 (Site Open), Public Personal Authentication Service Prefectural Council, [Search September 22, 2006] , Internet URL: http://www.jpki.go.jp/indexl.html>
  • the name, address, date of birth, and gender recorded in the Basic Resident Register are listed as the owner information of the public key in the electronic certificate issued by the public personal authentication service. It has been. For this reason, if this is used as an SSL / TLS client certificate, as described above, SSL / TLS performs peer authentication prior to the start of encrypted communication, so personal information such as name and address is encrypted. It will be sent as it is.
  • the ITU International Telecommunication Unio n
  • X.509 is also adopted in S SL / TLS and becomes a standard specification! /, But this standard does not incorporate a mechanism that can transmit the described information safely.
  • the present invention provides a communication partner authentication method, apparatus, system, and program for preventing unauthorized access to personal information such as eavesdropping in communication partner authentication using an electronic certificate including personal information.
  • the purpose is to do.
  • Another object of the present invention is to maintain compatibility with a conventional communication partner authentication method in secure communication partner authentication using an electronic certificate including personal information.
  • the present invention for achieving the above object is realized by a method for authenticating a communication partner using an electronic certificate including the following personal information.
  • This method starts when a client device receives a request for an electronic certificate from a server device.
  • the client device reads the client certificate including personal information and the server public key of the server device from the storage unit, and encrypts the client certificate including personal information using the server public key. To do.
  • the client device sets judgment information indicating that the electronic certificate is a temporary electronic certificate in the first area of the electronic certificate of the format supported by the server apparatus, and is encrypted in the second area. Create a temporary digital certificate by setting a client certificate. When the temporary digital certificate can be created, the client device sends it to the server device.
  • the server device In response to receiving the electronic certificate, the server device extracts the determination information from the first area of the received electronic certificate. Then, the server device determines whether or not the electronic certificate received by the determination information is a force indicating that the electronic certificate is a temporary electronic certificate. If it is determined that the received electronic certificate is not a temporary electronic certificate, the server device authenticates the client device using the received electronic certificate. On the other hand, if it is determined that the received electronic certificate is a temporary electronic certificate, the server device authenticates the client device using the client certificate described in the second area of the temporary electronic certificate. In the latter case, as a preprocess, the server device extracts the encrypted client certificate from the second area and decrypts it using the server private key corresponding to the server public key.
  • the personal information included in the client certificate is arbitrary information that can specify an individual, such as name, address, date of birth, gender, company name, and mail address.
  • the client certificate containing personal information may be a client's digital certificate issued by a public personal authentication service.
  • the name, address, date of birth, and gender described in the Basic Resident Register will be written on the electronic certificate as owner information of the private key corresponding to the public key described in the electronic certificate. .
  • the format of the electronic certificate supported by the server device may be X.509.
  • the first area is the basic area of the X.509 certificate and the second area is the extension area of the X.509 certificate.
  • the first area of the electronic certificate in the format supported by the server device is an extended area of the X.509 certificate, and the certificate is used as judgment information indicating that the electronic certificate is a temporary electronic certificate. Certificate policy may be used.
  • the electronic certificate request received at the client device may be SSL (Secure Socket Layer) or 3 ⁇ 4 TL3 ⁇ 4 (Transport Layer Security protocol HandShake Protocol Request Certificate Request message!
  • the client device uses, in the second area of the electronic certificate, a predetermined character string and a client private key corresponding to the client public key included in the client certificate for the hash value of the character string.
  • An encrypted signature value may be additionally set.
  • the server device further obtains a hash value of the character string described in the second area of the temporary electronic certificate.
  • the server device also decrypts the signature value described in the second area of the temporary electronic certificate using the client public key described in the client certificate. By determining whether these two values match, the server device confirms that the communication partner is the owner of the client certificate.
  • the client device stores, in the client certificate, a predetermined character string, a signature time indicating the current time, and a hash value of the predetermined character string and the signature time in the second area of the electronic certificate.
  • the signature value encrypted using the client private key corresponding to the included client public key may be additionally set.
  • the current time is obtained on the client device at the time of signing.
  • the server device determines that the received electronic certificate is a temporary electronic certificate. On the condition that it is determined, a hash value of a predetermined character ⁇ IJ and signature time described in the second area of the temporary digital certificate is obtained.
  • the server device also decrypts the signature value described in the second area of the temporary electronic certificate using the client public key described in the client certificate. By determining whether these two values match, the server device confirms that the communication partner is the owner of the client certificate.
  • the server device acquires the current time on the server device on condition that the received electronic certificate is a temporary electronic certificate. Then, the server device obtains the difference between the current time when the reuse of the identity verification information used in the past should be prohibited and the signature time described in the second area of the temporary electronic certificate, and the obtained difference is acceptable. Determine whether it is within range.
  • the present invention has been described above as a method for authenticating a communication partner in a system including a client device and a server device, the present invention is not limited to the system for authenticating a communication partner or the system. It can also be understood as a program for executing the method. The present invention can also be understood as a method for authenticating a communication partner in a client device or a server device, or a program for causing a client device or a server device to execute each method. Furthermore, the present invention can be grasped as a client device or a server device for authenticating a communication partner.
  • unauthorized access to personal information such as eavesdropping can be prevented in authentication of a communication partner using an electronic certificate including personal information.
  • the communication partner authentication technique of the present invention when used, compatibility with a conventional communication partner authentication method can be maintained.
  • FIG. 1 shows a configuration of a system 100 for authenticating a communication partner according to an embodiment of the present invention.
  • An example is shown.
  • the system 100 for authenticating a communication partner according to the present embodiment when the client device 200 transmits an electronic certificate including its own personal information in response to a request for the electronic certificate from the server device 400, The purpose is to maintain compatibility with the conventional authentication method of the communication partner while preventing unauthorized access to personal information due to eavesdropping.
  • the conventional communication partner authentication method follows the Handshake Protocol of SSL / TLS.
  • the system 100 for authenticating a communication partner includes a client device 200 that requests communication with the server device 400 and a server device 400 that requests an electronic certificate for authenticating the communication partner.
  • the client device 200 and the server device 400 are connected via a network 300 such as the Internet. It is assumed that the client device 200 has previously acquired an electronic certificate of the client including personal information as an electronic certificate that certifies itself.
  • the communication partner is authenticated at the beginning of the procedure according to the Handshake Protocol.
  • the server apparatus 400 transmits a Server Certificate message including the server certificate to the client apparatus 200.
  • the server certificate includes the public key of the server that conforms to the public key cryptosystem. Therefore, the client device 200 acquires the server public key at this time.
  • the server apparatus 400 transmits a Clien et Certificate message to the client apparatus 200 and requests the client apparatus 200 for an electronic certificate.
  • the client device 200 reads the client certificate including the personal information from the storage unit of itself and the server public key of the server device 400, and uses the server public key to prevent the unauthorized access to the personal information. Encrypt the certificate.
  • the converted client certificate is not recognized as an electronic certificate in the server apparatus 400 as it is. Therefore, the client device 200 creates a temporary electronic certificate that conforms to the electronic certificate format supported by the server device 400.
  • SSL / TLS adopts X.509 as the format of electronic certificate.
  • X.509. Version 3 which is currently most frequently used, can have its own information in addition to the basic area where basic information such as issuer information and public keys are written. An extended area is newly established. Therefore, the client device 200 can use the basic area or extension of the X.509 certificate. Set the judgment information indicating that the electronic certificate is a temporary electronic certificate in the extension area, and set the encrypted client certificate in the extended area of the X.509 certificate. Create a certificate. Then, the client device 200 includes the temporary electronic certificate in the Client Certificate message and transmits it to the server device 400.
  • Server apparatus 400 receives a Client Certificate message including a temporary electronic certificate from the client apparatus, and extracts determination information from the basic area or the extended area of the temporary electronic certificate. Then, the server device 400 determines whether the determination information power S is a power indicating that the received electronic certificate is a temporary electronic certificate. If it is determined that the received electronic certificate is not a temporary electronic certificate, the server device 400 authenticates the client device using the received electronic certificate. On the other hand, if it is determined that the received electronic certificate is a temporary electronic certificate, the server device 400 extracts the encrypted client certificate from the extended area of the temporary electronic certificate and uses this as the server public key. Decrypt with the corresponding server private key. Then, the server device 400 authenticates the client device using the decrypted client certificate.
  • the client device 200 since the client device 200 sets a true electronic certificate that certifies itself in an electronic certificate in a format supported by the server device 400, the client device 200 encrypts the client certificate including personal information. This makes it possible to prevent unauthorized access to personal information by a third party.
  • the server device 400 since the server device 400 determines whether or not the received electronic certificate is a temporary electronic certificate based on the determination information described in the predetermined area, the server device 400 uses the electronic certificate used for counterpart authentication according to the determination result. It is possible to change the target to be maintained, and compatibility with the authentication method of the conventional communication partner is maintained.
  • FIG. 2 shows an example of a functional configuration of the client device 200 according to an embodiment of the present invention.
  • the client device 200 includes a storage unit 205, a temporary certificate creation unit 235, a policy determination unit 280, a signature creation unit 285, and a communication unit 275.
  • the temporary certificate creation unit 235 has a function of creating a temporary certificate in accordance with the electronic certificate format supported by the server device 400.
  • the temporary key creation unit 240, the basic area setting unit 245, the encryption unit 250, the time An acquisition unit 255, a signature value calculation unit 260, an extension area setting unit 265, and a signature setting unit 270 are included.
  • the storage unit 205 includes a client certificate 230 including personal information acquired in advance and the client certificate.
  • the client private key 225, the server certificate 215 obtained from the server device, the predetermined character string 210, and the temporary certificate creation target policy list 232 Store.
  • An X.509 certificate is roughly divided into two areas: a basic area and an extended area.
  • the basic area includes the X.509 version, the certificate serial number, the hash algorithm used to sign the certificate and the public key algorithm (signature scheme), the issuer information that is the issuer of the certificate,
  • the bibliographic information including the expiration date of the public key set in the basic area and the owner information of the private key corresponding to this is set, and the public key information is set.
  • the extension field contains three sets of certification authority unique identification information and owner unique identification information added from X.509 version 2, and extended type, extension value, and critical bit added from X.509 version 3. Each set can be set arbitrarily. In addition to the standard extension types defined in X.509 version 3, it is possible to incorporate original new! / And extension types.
  • the certificate authority's signature is also attached to the X.509 certificate, which is obtained by encrypting the hash value obtained by hashing the information set in the basic area and extension area with the private key of the certificate authority. .
  • the recipient of the digital certificate can verify the validity of the digital certificate by verifying the certificate authority's signature using the root certificate of the certificate authority.
  • the hash value obtained by hashing the information set in the basic area and the extended area matches the signature of the certificate authority decrypted using the root public key described in the root certificate of the certificate authority. It is possible to confirm that the signature is surely attached by the certificate authority and that the information written in the basic area and the extended area is not damaged or falsified.
  • a root certificate is an electronic certificate that is signed and issued by a certificate authority that issues an electronic certificate to prove its validity.
  • the server certificate 220 stored in the storage unit 205 is transmitted from the server apparatus 400 to the client apparatus 200 in response to the authentication process of communication using SSL / TLS as described above. is there. Therefore, the server certificate 220 according to this embodiment conforms to the X.509 format.
  • the client certificate 230 including personal information stored in the storage unit 205 is In the embodiment, it is assumed that it is issued by a public personal authentication service.
  • Figure 3 (b) shows an example of a client certificate that conforms to the X.509 format issued by the public personal authentication service. In the basic area of the client certificate, information as described with reference to Fig. 3 (a) is described.
  • the name, date of birth, gender, and address listed in the Basic Resident Register are entered in the expanded area of the client certificate 230.
  • the certificate policy described in the extended area specifies the purpose and usage of the certificate.
  • information indicating that the certificate was issued by a public personal authentication service is described in the Object Identifier (OID) format.
  • OID Object Identifier
  • An OID is a specially formatted number that is internationally registered and approved by a standards body, and indicates a specific object or object class registered in an ISO standard.
  • the signature value B attached to the client certificate 230 is a signature given by the prefectural governor.
  • the electronic certificate and the private key corresponding to the public key proved by the electronic certificate are stored in the user's IC card. Therefore, in FIG. 2, it is shown that all the information necessary for creating the temporary certificate is stored in the same storage unit 205.
  • the client certificate 230 and the client private key 225 are actually stored in the IC card. Read by a card reader / writer.
  • the predetermined character string stored in the storage unit 205 is a character string determined in advance with the server apparatus 400, and is an arbitrary character string suitable for use as a signature.
  • the temporary certificate creation target policy list 232 stored in the storage unit 205 is a list of certificate policies that can be set for an electronic certificate including personal information.
  • the temporary certificate creation target policy list 232 according to this embodiment lists a certificate policy indicating that it is issued by a public personal authentication service.
  • the communication unit (reception unit) 275 receives a request for an electronic certificate from the server device 400 and notifies the policy determination unit 280 that the message has been received.
  • the policy determination unit 280 reads the client certificate 230 and the temporary certificate creation target policy list 232 from the storage unit 205. Then, the policy determination unit 280 determines that the certificate policy described in the extension area of the client certificate 230 is the same as the policy for creating a temporary certificate. Determine if the certificate policy is in Listing 232.
  • the policy judgment unit 280 requests the temporary certificate creation unit 235 to create a temporary electronic certificate. To do.
  • the policy determination unit 280 includes the storage unit 205.
  • the client certificate 230 read from the server device 400 is transmitted to the server device 400 as it is via the communication unit (transmission unit) 275. Since the client certificate 230 according to this embodiment includes personal information, the policy determination unit 280 requests the temporary certificate creation unit 235 to create a temporary electronic certificate.
  • the temporary certificate creation unit 235 sends the format of the electronic certificate supported by the server device 400, that is, the temporary electronic certificate according to X.509 in this embodiment.
  • Start creation as follows:
  • Temporary key creation unit 240 generates a pair of keys in accordance with the public key cryptosystem, that is, a temporary public key and a temporary secret key corresponding to the key to be used for creating a temporary electronic certificate.
  • the basic area setting unit 245 sets the basic area of the temporary electronic certificate. As an example, the basic area setting unit 245 reads out the owner information described in the server certificate 215 from the storage unit 205 and copies it to the issuer information field of the temporary electronic certificate. As a result, it is possible to indicate to the server device 400 that has received the temporary electronic certificate that the electronic certificate is a temporary electronic certificate.
  • a certificate policy indicating that the electronic certificate is a temporary electronic certificate may be used.
  • the issuer information field in the basic area of the electronic certificate and the certificate policy field in the extended area of the electronic certificate are fields that are generally used to identify the type of electronic certificate. For this reason, when these fields are used to describe information indicating that an electronic certificate is an electronic certificate, the contents of the electronic certificate are not as in the case of using a field defined by the user. There is no such thing as being unclear to a third party.
  • the basic area setting unit 245 also sets its own information in the owner information field, and further sets the temporary public key generated by the temporary key creation unit 240 in the public key field. For the other fields in the basic area, An appropriate value is set.
  • the encryption unit 250 reads the server public key 220 described in the client certificate 230 and the server certificate 215 from the storage unit 205, and encrypts the client certificate 230 using the server public key 220.
  • the time acquisition unit 255 acquires the current time on the client device 200.
  • the signature value calculation unit 260 reads the character string 210 from the storage unit 205, and calculates the signature value using the current time and the character string acquired by the time acquisition unit 255 as signatures. That is, the signature value calculation unit 260 performs hash processing on the current time and the character ⁇ IJ210 using a hash function, and encrypts the obtained hash value using the client secret key 225 stored in the storage unit 205. .
  • the hash function used for calculating the signature value may be negotiated with the server apparatus 400 in advance, or may be the same as that used for the signature of the client certificate 230. Furthermore, the used hash function information may be notified to the server device 400 using the extended area of the temporary electronic certificate. Also, the signature value calculation unit 260 may set only the character string IJ210 read from the storage unit 205 as a signature target.
  • the extension area setting unit 265 sets the client certificate 230 encrypted by the encryption unit 250 in the extension area of the temporary electronic certificate.
  • the extension area setting unit 265 also stores the character string 210 read from the storage unit 205 and the current time acquired by the time acquisition unit 255 (hereinafter referred to as “signature time”) in the extension area of the temporary digital certificate as identification information.
  • the signature value calculated by the signature value calculation unit 260 may be additionally set.
  • the signature setting unit 270 signs the temporary electronic certificate. In other words, the signature setting unit 270 performs a hash process on the information set in the basic area and the extended area, and temporarily generates a signature value obtained by encrypting the obtained hash value using the server public key 220 described in the server certificate 215. Set to digital certificate.
  • FIG. 3 (c) shows an example of the temporary electronic certificate created by the temporary certificate creating unit 235.
  • determination information server apparatus 400 information in the present embodiment
  • the extended area of the temporary digital certificate includes the encrypted client certificate 230, the character string 210 that is identification information, the signature time, and the signature value. C is listed. Further, a signature value B calculated using the server public key of the server device 400 is attached to the temporary electronic certificate.
  • the communication unit (transmission unit) 275 transmits the temporary electronic certificate created by the temporary certificate creation unit 235 to the server device 400 as a response to the request for the electronic certificate.
  • Temporary storage unit 290 temporarily stores communication contents from a ClientHello message, which is a start message of SSL / TLS Handshake Protocol, to a Client Key Exchange message.
  • the signature creation unit 285 generates a signature that can be used when the server device 400 confirms that the electronic certificate transmitted from the communication unit (transmission unit) 275 is certainly transmitted by the client device 200. Created using the above information stored in temporary storage unit 290. That is, the signature creation unit 285 reads the communication contents from the temporary storage unit 290, obtains a hash value by hashing, and uses a private key corresponding to the public key described in the electronic certificate that transmits the hash value. Create a signature by encrypting it. The signature creation unit 285 transmits the created signature together with or after transmission of the electronic certificate to the server device 400 via the communication unit (transmission unit) 275.
  • the client device 200 As described above, according to the client device 200 according to the embodiment of the present invention, the truth of certifying itself in the electronic certificate in the format supported by the server device 400 using the extended area of the electronic certificate. Since a digital certificate is set, client certificates including personal information can be sent in encrypted form, preventing unauthorized access to personal information by third parties.
  • FIG. 4 shows an exemplary functional configuration of the server apparatus 400 according to an embodiment of the present invention.
  • Server device 400 includes communication unit 405, temporary storage unit 410, determination unit 415, decryption unit 420, storage unit 425, and authentication unit 430.
  • the storage unit 425 stores the server private key 430 and the trusted certificate list 435.
  • the server private key 430 is a private key corresponding to the server public key 220 described in the server certificate 215 transmitted to the client device 200.
  • the trusted certificate list 435 is a list of root certificates of a plurality of certificate authorities, and it is assumed that the validity of the root certificate has already been confirmed in the server device 400.
  • the authentication unit 430 has a function of authenticating a communication partner, and includes a certificate verification unit 435 and an identity verification unit 440.
  • the identity verification unit 440 is a function that confirms that the electronic certificate has been sent by the user.
  • the signature verification unit 445 and the time verification unit 450 are included.
  • the communication unit 405 receives the electronic certificate from the client device 200 as a response to the request for the electronic certificate.
  • the received electronic certificate is stored in the temporary storage unit 410.
  • the determination unit 415 reads the determination information described in the electronic certificate from the temporary storage unit 410, that is, the issuer information described in the basic area of the electronic certificate in the present embodiment, and the received electronic certificate is a temporary electronic certificate. It is determined whether the determination information indicates that it is a certificate.
  • the determination unit 415 sends the determination result to the decryption unit 420 and the authentication unit 430. Notify On the other hand, when the received electronic certificate does not indicate that it is a temporary electronic certificate, the determination unit 415 notifies the determination result only to the authentication unit 430.
  • the decryption unit 420 In response to the notification that the received electronic certificate is a temporary electronic certificate, the decryption unit 420 encrypts the encrypted class described in the extended area of the electronic certificate received from the temporary storage unit 410. Read the client certificate 230. Then, the decryption unit 420 decrypts the read client certificate 230 using the corresponding server private key 430 stored in the storage unit 425. The decrypted client certificate 230 is then passed to the authentication unit 430.
  • the authentication unit 430 is transmitted from the client device 200 together with or after the received electronic certificate.
  • the client device 200 is authenticated using the signature.
  • the determination unit 415 determines that the received electronic certificate is a temporary electronic certificate
  • the authentication unit 430 receives the decrypted client certificate 230 and the signature set in the extension area of the temporary electronic certificate. Is used to authenticate the client device 200. Authentication processing by the authentication unit 430 is started in response to the notification of the determination result from the determination unit 415, and processing by the certificate verification unit 435 and the identity verification unit 440 is performed.
  • the electronic certificate verification method is basically the same regardless of the determination result by the determination unit 415. Therefore, in the following, processing by the certificate verification unit 435 will be described by taking as an example the case of verifying the client certificate 230 including personal information. If the client certificate 230 including personal information is to be verified, it is a condition that the identity verification unit 440 (to be described later) succeeds. Good as.
  • the certificate verification unit 435 receives the decrypted client certificate 230 from the decryption unit 420, verifies the electronic certificate, that is, verifies the signature attached to the client certificate 230, and the client certificate 230. Confirm the bibliographic information described in.
  • the signature is verified as follows. First, referring to the issuer information described in the client certificate 230, the route of the corresponding certificate authority (in this embodiment, the prefectural governor) from the trusted certificate list 435 stored in the storage unit 425 is obtained. Search for a certificate. Next, the signature attached to the client certificate 230 is decrypted using the root public key described in the root certificate.
  • this is compared with the hash value obtained by hashing the information described in the basic area and the extended area of the client certificate 230 to determine whether or not they match. If the two match, the verification is successful.
  • the algorithm used for the signature can be confirmed by the signature method described in the client certificate 230.
  • bibliographic information described in the client certificate 230 includes confirmation of the expiry date and revocation of the client certificate 230 as an example, and the communication partner referring to the owner information and personal information. Confirmation is included.
  • a method for confirming revocation of a client certificate is explained.
  • a certificate authority to notify a user of revocation of an electronic certificate, one is a Certificate Revocation List (CRL) method that periodically publishes a list of revoked certificates, and one Is an online certificate status protocol (OCSP) method that responds to inquiries about certificate revocation information from clients.
  • CTL Certificate Revocation List
  • OCSP online certificate status protocol
  • the certificate verification unit 435 requests the CRL from the certificate authority, and whether or not the received CRL is listed in the client certificate strength S list. Confirm the revocation by judging. Note that the confirmation of the communication partner referring to the personal information described above is limited to the case where the client certificate 230 including the personal information is to be verified.
  • the principal confirmation unit 440 confirms that the electronic certificate to be verified is surely transmitted by the owner of the client certificate 230.
  • the signature verification unit 445 reads the identification information described in the temporary electronic certificate extension area from the temporary storage unit 410, and Verify the signature.
  • Identity The signature verification using the authentication information is performed as follows. First, the hash value is obtained by hashing the character ⁇ IJ210 included in the personal identification information and the signature time using a hash function determined in advance between the client device 200. Next, the signature value C included in the personal identification information is decrypted using the client public key described in the decrypted client certificate 230. The decrypted signature value C is compared with the hash value. If the two match, then the client certificate 230 is indeed sent by the owner of the client certificate 230.
  • the signature verification unit 445 receives the electronic certificate from the client device 200 together with or after receiving the electronic certificate.
  • a verification process is performed on the transmitted signature.
  • the communication details from the Client Hello message to the Client Key Exchange message which is the start message of the Handshake Protocol, are used as identity verification information in SSL / TLS Handshake Protocol authentication. It is done.
  • the certificate verification message sent after the signature value S, ClientCertificate message is calculated by encrypting the hash value of the communication content with the private key corresponding to the public key described in the digital certificate. Sent from the client device 200.
  • the signature verification unit 445 performs signature verification as follows.
  • the signature verification unit 445 reads the signature value included in the CertificateVerify message body via the temporary storage unit 410. Then, the signature verification unit 445 decrypts the signature value with the public key described in the electronic certificate received from the client device 200.
  • the temporary storage unit 410 temporarily stores communication contents from the ClientHello message to the Client Key Ex change message. Therefore, the signature verification unit 445 reads these communication contents from the temporary storage unit 410 to obtain a hash value, and compares it with the decrypted signature value. If the two match, the received electronic certificate is indeed sent by the owner of the electronic certificate.
  • the conventional authentication method of the communication partner that is, Han of SSL / TLS
  • the client apparatus 200 In order to maintain compatibility with the other party authentication in dshakeProtocol, the client apparatus 200 generates a CertificateVerify message and transmits it to the server apparatus 400 even when transmitting a temporary electronic certificate to the server apparatus 400.
  • the client private key used is a temporary private key corresponding to the temporary public key described in the temporary electronic certificate.
  • the server apparatus 400 does not need to verify the signature included in the CertificateVerify message body.
  • the identity verification unit 440 does not re-use the identification information described in the extension area of the temporary electronic certificate. May be confirmed.
  • the time verification unit 450 first acquires the current time on the server device 400. Then, the difference between the current time and the signature time described in the extension area of the temporary electronic certificate is calculated, and it is determined whether or not the obtained difference is within an allowable range. If it is within the allowable range, it can be said that the identification information has not been reused.
  • a third party who eavesdrops on the temporary electronic certificate and steals the identity verification information creates a fake temporary electronic certificate. Can be prevented.
  • the client apparatus 400 As described above, according to the server apparatus 400 according to the embodiment of the present invention, the client apparatus
  • an electronic certificate When an electronic certificate is received from 200, it is first determined whether or not the received electronic certificate is a temporary electronic certificate by using the determination information described in the predetermined area of the electronic certificate. It is possible to change the subject to be used as an electronic certificate for authentication. That is, according to the server device 400 according to the embodiment of the present invention, it is possible to process both an encrypted electronic certificate and a normal unencrypted electronic certificate, and the conventional communication partner Compatibility with authentication methods can be maintained.
  • FIG. 5A shows a processing flow of the client apparatus 200 until the electronic certificate is transmitted in response to the request for the electronic certificate from the server apparatus 400.
  • the client device 200 receives a request for an electronic certificate for authenticating the client device 200 from the server device 400 (step 500), the client device 230 and the temporary certificate to be transmitted from the storage unit 205 to the server device 400.
  • Read out policy creation target policy list 232 (Step 503 ).
  • the client device 200 extracts the certificate policy from the extended area of the client certificate 230 (step 506), and determines whether the extracted certificate policy is listed in the temporary certificate creation target policy list 232. (Step 509).
  • the client device 200 If the extracted certificate policy is listed in the temporary certificate creation target policy list 232 (step 509: YES), preparations for creating a temporary digital certificate are started. That is, the client device 200 first reads the server certificate 215 from the storage unit 205 (step 512), and takes out the owner information and the server public key from the read server certificate 215 (step 515). Further, the client device 200 generates a pair of keys in accordance with the public key method, that is, a temporary public key and a temporary secret key for use in the temporary electronic certificate (step 518).
  • the client device 200 When the preparation is completed, the client device 200 creates a temporary electronic certificate according to the format of the electronic certificate supported by the server device 400 using the prepared information (step 521). A method for creating a temporary electronic certificate will be described later.
  • the client device 200 transmits the created temporary electronic certificate to the server device 400 (step 524), the client device 200 creates a signature using the temporary private key corresponding to the temporary public key described in the temporary electronic certificate, This is transmitted to the server device 400 (step 527).
  • step 509 that is, if the extracted certificate policy is not listed in the temporary certificate creation target policy list 232 and the client certificate 230 does not contain personal information
  • the client The device 200 transmits the client certificate 230 read from the storage unit 205 to the server device 400 as it is (step 530). Then, the client device 200 creates a signature using the client private key corresponding to the client public key described in the client certificate 230, and transmits it to the server device 400 (step 536).
  • the post-processing of step 527 or step 533 ends.
  • step 540 sets the basic area of the temporary electronic certificate using the information prepared in steps 515 and 518 of FIG. 5 (a) (step 540). That is, owner information indicating the server device 400 is set in the issuer information field, and a temporary public key is set in the public key information field. Set any other appropriate values for the other fields.
  • the client device 200 encrypts the client certificate including the personal information by using the server public key acquired in step 515 of FIG. 5A (step 545).
  • the client device 200 also creates identity verification information to indicate that the client certificate was indeed sent by its owner (step 550). How to create identity verification information will be described later.
  • the client device 200 sets the encrypted client certificate and identification information in the extension area of the temporary electronic certificate (step 555).
  • the client device 200 signs the temporary electronic certificate using the server public key 220 (step 560). Then, the process ends.
  • the client apparatus 200 reads the character ⁇ IJ from the storage unit 205 that has been negotiated with the server apparatus 400 in advance (step 570). Next, the client device 200 acquires the current time on the client device 200 (step 575). Then, using the read character string and the current time as signatures, a signature value is calculated using a client private key corresponding to the client public key described in the client certificate 230 (step 580). Then, the process ends.
  • FIG. 6 shows an overview of the flow of processing by the server apparatus 400.
  • the server device 400 transmits a request for an electronic certificate to the client device 200 in order to authenticate the client device 200 that is a communication partner (step 600).
  • the server device 400 verifies this (step 606).
  • the server device 400 receives the signature from the client device 200 (step 609).
  • the server device 400 verifies the signature, and confirms that the received electronic certificate is surely transmitted from the owner of the electronic certificate (step 612). Then, the process ends.
  • the server device 400 extracts issuer information from the basic area of the received electronic certificate (step 615), and determines whether the received electronic certificate is a temporary electronic certificate (step 620). If it is determined that it is a temporary electronic certificate (step 620: YES), the server device 400 verifies the temporary electronic certificate (step 625). The verification of the temporary digital certificate will be described later. If the verification of the temporary digital certificate is successful in step 630 In this case, the server apparatus 400 recognizes the client certificate 230 included in the temporary electronic certificate as a verification target for the client apparatus 200 authentication (step 635). On the other hand, if it is determined that the received electronic certificate is not a temporary electronic certificate (step 620: NO), the server device 400 recognizes the received electronic certificate itself as a verification target for the client device 200 authentication (step 637). ).
  • step 640 the server apparatus 400 verifies the signature applied to the verification target certificate (step 640). If the verification succeeds in step 640, the server apparatus 400 verifies that the certificate is still valid from the expiration date described in the certificate to be verified (step 645). If the verification is successful in step 645, the server apparatus 400 communicates with the issuer of the certificate to be verified and verifies that the certificate has not expired (step 650). If the verification is successful in step 650, the server apparatus 400 refers to the owner information described in the verification target certificate and verifies that the client apparatus 200 is an appropriate communication partner (step 652). Successful verification in step 652 means successful verification of the digital certificate. The order of verification is not limited to the order shown in Fig. 6 (b).
  • step 630 If the verification of the temporary digital certificate fails in step 630, or if the verification fails in any of steps 640, 645, 650, and 652, the process proceeds to step 660, indicating that the verification failed.
  • the client device 200 is notified.
  • AlertProtocol is used in SSL / TLS. For example, when the certificate expires! /, A Certificate—expired message is transmitted to the client device 200. If the certificate has expired, a Certificate-revoked message is transmitted to the client device 200.
  • the server apparatus 400 extracts the encrypted client certificate 230 from the extended area of the temporary electronic certificate (step 665), and decrypts the client certificate 230 using the server secret key 430 read from the storage unit 425. (Step 670).
  • the server device 400 extracts the signature target described as the identity verification information, that is, the character string and the signature time from the extended area of the temporary electronic certificate (step 675), and performs a predetermined hash function. Is used to find the hash value to be signed.
  • the server apparatus 400 also extracts the signature value described as the identity verification information from the extended area of the temporary electronic certificate (step 680).
  • the server device 400 decrypts the signature value extracted using the client public key described in the decrypted client certificate and compares it with the hash value to verify the signature (step 685).
  • step 690 If the verification is successful in step 690, that is, if it can be confirmed that the client certificate 230 is surely transmitted from the owner of the client certificate 230, the server device 400 further determines the current time on the server device 400. Is obtained (step 695). Then, the server device 400 calculates the difference between the acquired current time and the signature time described in the extension area of the temporary electronic certificate (step 700). When the calculated difference is within the allowable range (step 705: Y ES), that is, when it can be confirmed that the identity verification information described in the extended area of the temporary digital certificate is not reused, the server device 400 Save the verification success (step 710). If the signature verification fails in step 740 or if the difference calculated in step 705 is not within the allowable range, the server apparatus 400 stores the verification failure (step 715). Then, the process ends.
  • FIG. 7 shows an example of a hardware configuration of the client device 200 according to the present embodiment.
  • FIG. 7 is also an example of the hardware configuration of the server device 400.
  • FIG. 7 will be described as a hardware configuration of the client device 200.
  • the client device 200 includes a CPU peripheral unit including a CPU 710 and a RAM 730 connected to each other by a host controller 715, a card bus controller 740 connected to the host controller 715 by an input / output controller 735, and an IC connected to the card bus controller 740.
  • Input / output unit including card reader / writer 745, communication interface 770, hard disk drive 750, and CD-ROM drive 760, and super I / O controller 780 and super I / O controller 780 connected to input / output controller 735
  • the host controller 715 connects the CPU 710 that accesses the RAM 730 at a high transfer rate to the RAM 730.
  • CPU710 based on the program stored in the hard disk Operates and controls each part.
  • the program for the client device 200 for authenticating the communication partner according to the embodiment of the present invention is stored in the hard disk and executed by the CPU 710 using the RAM 730.
  • the program for the client device 200 includes the client device 200, a storage unit 205, a policy determination unit 280, a signature creation unit 285, a temporary storage unit 290, a temporary certificate creation unit 235, that is, a temporary key creation unit 240, a basic area setting unit.
  • the program for server device 400 includes server device 400, communication unit 405, temporary storage unit 410, determination unit 415, decryption unit 420, storage unit 425, and authentication unit. 430, that is, the identity verification unit 440 including the certificate verification unit 435 and the signature verification unit 445 and the time verification unit 450. Since the specific functions and operations are the same as those described with reference to FIGS. 4 and 6, description thereof will be omitted.
  • the programs for the client device 200 and the server device 400 according to the embodiment of the present invention can be stored in a computer-readable medium.
  • a computer-readable medium is any device that can contain, store, communicate, propagate, or carry programs used in or related to instruction execution systems, devices, or equipment.
  • the medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium.
  • Examples of computer-readable media include semiconductor or solid 'state storage, magnetic tape, removable computer diskettes, random access' memory (RAM), read-only' memory (ROM), rigid magnetic disks and optical disks Is included.
  • Examples of optical discs at this time include compact 'disc one read only' memory (CD-ROM), compact disc-read / write (CD-R / W) and DVD.
  • the input / output controller 735 includes an IC card reader / writer 745, a communication interface 770, a hard disk drive 750, and a CD connected to the card bus controller 740 and the card bus controller 740, which are relatively high-speed input / output devices.
  • a communication interface 770 Connect ROM drive 760 to host controller 715.
  • the communication interface 770 is connected via a network. Communicates with external devices such as the device 400.
  • the input / output controller 735 is connected to a relatively low-speed input / output device such as the flexible disk drive 790 and the keyboard mouse controller 810, and the flash ROM 800.
  • the flash ROM 800 reads a boot program executed by the CPU 710 when the client device 200 starts up, a program that depends on the hardware of the client device 200, or the like, or provides data to the super I / O controller 735 via the RAM 730.
  • the super I / O controller 735 connects various input / output devices via a flexible disk, for example, a parallel port, a serial port, a keyboard port, a mouse port, and the like.
  • FIG. 1 shows an example of a configuration of a system 100 for authenticating a communication partner according to an embodiment of the present invention.
  • FIG. 2 shows an exemplary functional configuration of a client device 200 according to an embodiment of the present invention.
  • FIG. 3 shows the format of the X.509 certificate.
  • (B) shows an example of a client certificate including personal information according to the embodiment of the present invention.
  • (C) shows an example of a temporary electronic certificate according to an embodiment of the present invention.
  • FIG. 4 shows an exemplary functional configuration of a server apparatus 400 according to an embodiment of the present invention.
  • FIG. 5 (a) illustrates a server device 4 in the client device 200 according to the embodiment of the present invention.
  • FIG. 6 is a flowchart showing an example of a processing flow for communication partner authentication according to 00.
  • FIG. 6 (a) illustrates communication partner authentication in the server apparatus 400 according to the embodiment of the present invention.
  • 5 is a flowchart showing an example of a processing flow for the purpose.
  • B is a flowchart showing an example of a flow of processing for electronic certificate verification according to the embodiment of the present invention.
  • (C) is a flow chart showing an example of a flow of a temporary electronic certificate verification process according to the embodiment of the present invention.

Description

明 細 書
個人情報を含む電子証明書を用いて通信相手を認証するためのシステ ム、装置、方法、及びプログラム
技術分野
[0001] 本発明は電子証明書を用いた通信相手の認証に関し、特に個人情報を含む電子証 明書を用レ、て通信相手を認証する技術に関する。
背景技術
[0002] 従来、電子商取引やオンラインバンキング等のセキュアな通信が求められるサーバ —クライアント型データ通信では、 SSL (Secure Socket Layer)及びその後継技 術であり RFC 2246として IETF (Internet Engineering Task Force)で標準 化された TLS (Transport Layer Security)が広く利用されている。
[0003] SSL/TLSの HandshakeProtocolでは、暗号化通信の開始に先立ち、サーバ クライアント間で暗号化通信を開始するために必要な各種パラメータのネゴシエー シヨンが行われる。 HandshakeProtocolでは、最初に相手の認証が行われ、その後 クライアントとサーバの両者が共通して利用できる圧縮/暗号化アルゴリズムから最 適なアルゴリズムの利用が決定される。 HandshakeProtocolによるネゴシエーショ ンが正常に終了すると、以後サーバークライアント間で暗号化通信が開始される。
[0004] ここで、 HandshakeProtocolにおける相手認証を、サーバ装置がクライアント装置 を認証する場合を例に説明する。公開鍵暗号方式を利用する HandshakeProtocol の相手認証では、サーバ装置からの CertificateRequestメッセージに応答して、ク ライアント装置力 自身の電子証明書を ClientCerticicateメッセージの本体に含め てサーバ装置へ送信する。電子証明書を受け取ったサーバ装置は、その正当性を、 保有するルート認証局（C (A)の鍵を用いて確認する。電子証明書にはまた、公開鍵 の他、当該公開鍵に対応する秘密鍵の所有者 (電子証明書の発行相手)情報、公開 鍵の有効期限等の書誌情報が記載される。そこでサーバ装置は、かかる書誌情報を 参照してクライアント装置が適当な通信相手であることを確認する。
[0005] 次にクライアント装置は、 HandshakeProtocolの開始メッセージである ClientHello メッセージから Client Key Exchangeメッセージまでの通信内容のダイジェストを クライアント装置の秘密鍵で暗号化して署名を作成し、これを Certif icateVerifyメッ セージの本体に含めてサーバ装置へ送信する。サーバ装置は、 CertificateVerify メッセージの本体に含まれる情報をクライアント装置の電子証明書に記載される公開 鍵で復号することにより、現在の通信相手が電子証明書の所有者本人であることを 確認する（非特許文献 1参照）。
[0006] このように、 SSL/TLSが提供する相手認証の機能は非常に厳密なものであり、他 人によるなりすましゃ改竄が重大な問題となる電子政府、電子自治体にぉレ、て最適 な認証方式といえる。ところで、電子政府 ·電子自治体の基盤として、近年公的個人 認証サービスが開始された（非特許文献 2参照）。公的個人認証サービスとは、行政 機関が提供する電子申請'届出サービスを利用する際に使用できる電子証明書を、 都道府県知事が発行するサービスである。電子証明書の発行は、全国どこに住んで いる人に対しても、安い費用で行われる。従って、公的個人認証サービスにより発行 される電子証明書を SSL/TLSのクライアント証明書として使用することが望まれる。
[0007] 非特許文献 1 : T. Dierks, E. Rescorla、 fhe TransportLayer security (TL S) Protocol" , [online]、平成 16年 4月、 RFC 4346、 [平成 18年 9月 22曰検索] 、インターネットく URL : http://www.ietf.orgAfcAfc4346.txt〉
非特許文献 2 : "公的個人認証サービス ポータルサイド、 [online]、平成 16年 1月 29日（サイト開設）、公的個人認証サービス都道府県協議会、 [平成 18年 9月 22日 検索]、インターネットく URL : http://www.jpki.go.jp/indexl.html〉
発明の開示
発明が解決しょうとする課題
[0008] し力、しながら、公的個人認証サービスにより発行される電子証明書には、住民基本台 帳に記録された氏名、住所、生年月日、性別が公開鍵の所有者情報として記載され ている。そのため、これを SSL/TLSのクライアント証明書として使用すると、上述し たように SSL/TLSでは暗号化通信の開始に先立って相手認証が行われるため、 氏名、住所といった個人情報が暗号化されることなくそのまま送信されてしまう。また 、 Ikナ証明 の規格としては、 ITU (International Telecommunication Unio n)が勧告した Χ· 509力 Sある。 X. 509は、 S SL/TLSにおいても採用されており標 準仕様となって!/、るが、この規格には記載情報を安全に送信できる仕組みは組み込 まれていない。
[0009] そこで本発明は、個人情報を含む電子証明書を用いた通信相手の認証において、 盗聴などの個人情報への不正アクセスを防止する通信相手の認証方法、装置、シス テム及びプログラムを提供することを目的とする。本発明のもう一つの目的は、個人 情報を含む電子証明書を用いた安全な通信相手の認証において、従来の通信相手 の認証方法との互換性を維持することである。
課題を解決するための手段
[0010] 上記の目的を達成する本発明は、次のような個人情報を含む電子証明書を用いて 通信相手を認証するための方法によって実現される。この方法は、クライアント装置 がサーバ装置から電子証明書の要求を受信することから開始される。要求の受信に 応答して、クライアント装置は、格納部から個人情報を含むクライアント証明書とサー バ装置のサーバ公開鍵を読み出し、サーバ公開鍵を用いて個人情報を含むクライァ ント証明書を暗号化する。そしてクライアント装置はサーバ装置がサポートするフォー マットの電子証明書の第 1領域に当該電子証明書が一時電子証明書であることを示 す判定情報を設定し、かつ第 2領域に暗号化されたクライアント証明書を設定するこ とにより、一時電子証明書を作成する。一時電子証明書が作成できると、クライアント 装置はこれをサーバ装置に送信する。
[0011] 電子証明書の受信に応答して、サーバ装置は受信した電子証明書の第 1領域から 判定情報を取り出す。そしてサーバ装置は、判定情報が受信した電子証明書が一時 電子証明書であることを示す力、どうか判定する。受信した電子証明書は一時電子証 明書でないと判定した場合、サーバ装置は受信した電子証明書を用いてクライアント 装置を認証する。一方、受信した電子証明書は一時電子証明書であると判定した場 合、サーバ装置は一時電子証明書の第 2領域に記載されるクライアント証明書を用 いてクライアント装置を認証する。後者の場合、サーバ装置は前処理として、第 2領 域から暗号化されたクライアント証明書を取り出し、これをサーバ公開鍵に対応する サーバ秘密鍵を用いて復号する。 [0012] クライアント証明書に含まれる個人情報は、氏名、住所、生年月日、性別、会社名、メ ールアドレス等、個人を特定可能な任意の情報である。個人情報を含むクライアント 証明書は、公的個人認証サービスにより発行されたクライアントの電子証明書であつ てよい。この場合電子証明書には、当該電子証明書に記載された公開鍵に対応する 秘密鍵の所有者情報として、住民基本台帳に記載された氏名、住所、生年月日、性 別が記載される。
[0013] サーバ装置がサポートする電子証明書のフォーマットは、 X. 509であってよい。好ま しくは、第 1領域は X. 509証明書の基本領域であり、第 2領域は X. 509証明書の拡 張領域である。これに代えて、サーバ装置がサポートするフォーマットの電子証明書 の第 1領域は、 X. 509証明書の拡張領域であり、電子証明書が一時電子証明書で あることを示す判定情報として、証明書ポリシーを利用してもよい。また、クライアント 装置において受信される電子証明書の要求は、 SSL (Secure Socket Layer)又 ¾TL¾ (Transport Layer Securityノの HandShakeプロトコノレの Certificate R equestメッセージであってよ!/ヽ。
[0014] また、クライアント装置は、電子証明書の第 2領域に、所定の文字列と、当該文字列 のハッシュ値をクライアント証明書に含まれるクライアント公開鍵に対応するクライアン ト秘密鍵を用いて暗号化した署名値とを更に追加で設定してもよい。この場合、サー バ装置は受信した電子証明書が一時電子証明書であると判定することを条件として 、更に一時電子証明書の第 2領域に記載される文字列のハッシュ値を求める。また、 サーバ装置は一時電子証明書の第 2領域に記載される署名値をクライアント証明書 に記載されるクライアント公開鍵を用いて復号する。そしてこれら 2つの値が一致する 力、どうか判定することにより、サーバ装置は通信相手がクライアント証明書の所有者 本人であることを確認する。
[0015] これに代えてクライアント装置は、電子証明書の第 2領域に、所定の文字列と、現在 時刻を示す署名時刻と、所定の文字列と署名時刻とのハッシュ値をクライアント証明 書に含まれるクライアント公開鍵に対応するクライアント秘密鍵を用いて暗号化した署 名値とを更に追加で設定してもよい。現在時刻は署名時にクライアント装置上で取得 される。この場合、サーバ装置は受信した電子証明書が一時電子証明書であると判 定することを条件として、更に一時電子証明書の第 2領域に記載される所定の文字 歹 IJと署名時刻とのハッシュ値を求める。また、サーバ装置は一時電子証明書の第 2領 域に記載される署名値をクライアント証明書に記載されるクライアント公開鍵を用いて 復号する。そしてこれら 2つの値が一致するかどうか判定することにより、サーバ装置 は通信相手がクライアント証明書の所有者本人であることを確認する。
[0016] 好ましくは、サーバ装置は、受信した電子証明書が一時電子証明書であることを条 件として、サーバ装置上で現在時刻を取得する。そしてサーバ装置は、過去に使用 された本人確認情報の再利用を禁止するべぐ現在時刻と一時電子証明書の第 2領 域に記載される署名時刻との差を求め、求めた差が許容範囲内であるかどうか判断 する。
[0017] 以上、クライアント装置及びサーバ装置を含むシステムにおける、通信相手を認証す るための方法として本発明を説明したが、本発明は、通信相手を認証するためのシス テム又は当該システムに上記方法を実行させるためのプログラムとして把握すること もできる。また本発明は、クライアント装置又はサーバ装置における、通信相手を認 証するための方法又は当該各方法をクライアント装置又はサーバ装置に実行させる ためのプログラムとして把握することもできる。更に本発明は、通信相手を認証するた めのクライアント装置又はサーバ装置として把握することもできる。
発明の効果
[0018] 本発明によれば、個人情報を含む電子証明書を用いた通信相手の認証において、 盗聴などの個人情報への不正アクセスを防止することができる。更に本発明の通信 相手の認証技術を用いると、従来の通信相手の認証方法との互換性も維持できる。 発明を実施するための最良の形態
[0019] 以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明するが、 以下の実施形態は特許請求の範囲に力、かる発明を限定するものではなぐまた実施 形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であ るとは限らない。なお、実施の形態の説明の全体を通じて同じ要素には同じ番号を 付している。
[0020] 図 1は、本発明の一実施形態に係る通信相手を認証するためのシステム 100の構成 の一例を示す。本実施形態に係る通信相手を認証するためのシステム 100は、サー バ装置 400からの電子証明書の要求に応答してクライアント装置 200が自身の個人 情報を含む電子証明書を送信する場合に、盗聴等による個人情報への不正ァクセ スを防止しつつ、従来の通信相手の認証方法との互換性を維持することを目的とす る。なお、本実施形態では、従来の通信相手の認証方法は SSL/TLSの Handsha keProtocolに従つ。
[0021] 通信相手を認証するためのシステム 100は、サーバ装置 400との通信を要求するク ライアント装置 200と、通信相手を認証するために電子証明書を要求するサーバ装 置 400とを備える。クライアント装置 200とサーバ装置 400とは、インターネット等のネ ットワーク 300を介して接続される。 なお、クライアント装置 200は、自身を証明する 電子証明書として個人情報を含むクライアントの電子証明書を予め取得しているもの とする。
[0022] SSL/TLSを利用した通信では、通信相手の認証は HandshakeProtocolに従う 手続きの初期に行われる。サーバ装置 400はまず、サーバ証明書を含む Server C ertificateメッセージをクライアント装置 200へ送信する。サーバ証明書には公開鍵 暗号方式に従うサーバの公開鍵が含まれる。そのためクライアント装置 200はこの時 点でサーバ公開鍵を取得する。次にサーバ装置 400はクライアント装置 200へ Clien et Certificateメッセージを送信し、クライアント装置 200に電子証明書を要求する 。要求を受信したクライアント装置 200は、自身の格納部から個人情報を含むクライ アント証明書とサーバ装置 400のサーバ公開鍵を読み出し、個人情報への不正ァク セスを防ぐためサーバ公開鍵でクライアント証明書を暗号化する。
[0023] 喑号化されたクライアント証明書はそのままではサーバ装置 400において電子証明 書として認識されない。そのためクライアント装置 200は、サーバ装置 400がサポート する電子証明書のフォーマットに従う一時電子証明書を作成する。 SSL/TLSは、 電子証明書のフォーマットとして X. 509を採用する。 X. 509には複数のバージョン があり、現在最もよく利用されているバージョン 3には、発行者情報や公開鍵等の基 本事項が記載される基本領域の他に、独自の情報を記載できる拡張領域が新たに 設けられている。そこでクライアント装置 200は、 X. 509証明書の基本領域または拡 張領域に当該電子証明書が一時電子証明書であることを示す判定情報を設定し、ま た X. 509証明書の拡張領域に暗号化されたクライアント証明書を設定することで、 一時電子証明書を作成する。そしてクライアント装置 200は Client Certificateメッ セージに一時電子証明書を含めてサーバ装置 400へ送信する。
[0024] サーバ装置 400は、クライアント装置から一時電子証明書が含まれた Client Certif icateメッセージを受信し、一時電子証明書の基本領域または拡張領域から判定情 報を取り出す。そしてサーバ装置 400は判定情報力 S、受信した電子証明書が一時電 子証明書であることを示す力、どうか判定する。受信した電子証明書が一時電子証明 書でないと判定した場合、サーバ装置 400は、受信した電子証明書を用いてクライア ント装置を認証する。一方、受信した電子証明書が一時電子証明書であると判定し た場合、サーバ装置 400は、一時電子証明書の拡張領域から暗号化されたクライア ント証明書を取り出し、これをサーバ公開鍵に対応するサーバ秘密鍵で復号する。そ してサーバ装置 400は、復号したクライアント証明書を用いてクライアント装置を認証 する。
[0025] 以上のようにクライアント装置 200は、サーバ装置 400がサポートするフォーマットの 電子証明書内に自身を証明する真の電子証明書を設定するので、個人情報を含む クライアント証明書を暗号化して送信することが可能となり、第三者による個人情報へ の不正アクセスが防止される。また、サーバ装置 400は、所定の領域に記載される判 定情報により受信した電子証明書が一時電子証明書力、どうか判定するので、判定結 果に応じて相手認証に用いる電子証明書とすべき対象を変えることが可能となり、従 来の通信相手の認証方法との互換性が維持される。
[0026] 図 2は、本発明の一実施形態に係るクライアント装置 200の機能構成の一例を示す。
クライアント装置 200は、格納部 205、一時証明書作成部 235、ポリシー判定部 280 、署名作成部 285及び通信部 275を備える。一時証明書作成部 235は、サーバ装 置 400がサポートする電子証明書のフォーマットに従う一時証明書を作成する機能 を有し、一時鍵作成部 240、基本領域設定部 245、暗号化部 250、時刻取得部 255 、署名値計算部 260、拡張領域設定部 265、及び署名設定部 270を含む。格納部 2 05は、予め取得した個人情報を含むクライアント証明書 230、当該クライアント証明 書 230に記載される公開鍵暗号方式に従うクライアント公開鍵に対応するクライアント 秘密鍵 225、サーバ装置から取得したサーバ証明書 215、所定の文字列 210、及び 一時証明書作成対象ポリシ一一覧 232を格納する。
[0027] ここで図3 (&)を参照して、33し/丁し3で採用される . 509バージョン 3の電子証明 書のフォーマットを説明する。 X. 509証明書は大きく分けて基本領域と拡張領域の 2 つの領域から構成される。基本領域には、 X. 509のバージョン、証明書のシリアル 番号、証明書の署名に使用されているハッシュ 'アルゴリズム及び公開鍵ァルゴリズ ム（署名方式）、証明書の発行者である発行者情報、当該基本領域に設定される公 開鍵の有効期限及びこれに対応する秘密鍵の所有者情報を含む書誌情報と、公開 鍵情報とが設定される。また拡張領域には、 X. 509バージョン 2から追加された認証 局固有識別情報及び所有者固有識別情報、また X. 509バージョン 3から追加され た拡張型、拡張値及びクリティカルビットの 3つの組の集合が、それぞれ任意で設定 可能である。なお拡張型には X. 509バージョン 3で定められた標準の拡張型のほか 、独自の新し!/、拡張型を組み込むことが可能である。
[0028] X. 509証明書にはまた、基本領域及び拡張領域に設定される情報をハッシュ処理 して得られるハッシュ値を認証局の秘密鍵で暗号化した、認証局の署名が付される。 電子証明書の受信者は、認証局のルート証明書を用いて認証局の署名を検証する ことにより電子証明書の有効性を確認できる。すなわち、基本領域及び拡張領域に 設定される情報をハッシュ処理して得られるハッシュ値と、認証局のルート証明書に 記載されるルート公開鍵を用いて復号した認証局の署名とがー致するかどうか判定 することにより、署名が確かに認証局により付されたこと、及び基本領域及び拡張領 域に記載される情報が損傷や改竄を受けていないことを確認できる。なお、ルート証 明書とは、電子証明書を発行する認証局が、その正当性を証明するために自ら署名 して発行する電子証明書である。
[0029] 格納部 205に格納されるサーバ証明書 220は、上述したように SSL/TLSを利用し た通信の認証処理にぉレ、て、サーバ装置 400からクライアント装置 200へ送信され たものである。従って本実施形態に係るサーバ証明書 220は X. 509のフォーマット に従う。また、格納部 205に格納される個人情報を含むクライアント証明書 230は、本 実施形態では公的個人認証サービスにより発行されたものとする。図 3 (b)に、公的 個人認証サービスにより発行された X. 509のフォーマットに従うクライアント証明書の 一例を示す。クライアント証明書の基本領域には、図 3 (a)を参照して説明した通りの 情報が記載される。一方クライアント証明書 230の拡張領域には、独自に、住民基本 台帳に記載される氏名、生年月日、性別、住所が記載される。同じく拡張領域に記 載される証明書ポリシーは、証明書の目的や利用用途を規定するものである。ここで は、当該証明書が公的個人認証サービスにより発行されたものであることを示す情報 が Object Identifier (OID)形式で記載される。 OIDとは、国際的に登録し標準化 機関によって承認された特別に形式化された番号であり、 ISO標準に登録された特 定のオブジェクトやオブジェクトクラスを示すものである。
またクライアント証明書 230に付される署名値 Bは都道府県知事により施される署名 である。
[0030] なお、公的個人認証サービスでは、他人による不正使用を防ぐため、電子証明書と 当該電子証明書が証明する公開鍵に対応する秘密鍵は利用者の ICカードに格納さ れる。従って、図 2では一時証明書作成に必要な情報はすべて同一の格納部 205に 格納されるよう示している力 クライアント証明書 230及びクライアント秘密鍵 225は実 際には ICカードに格納され、 ICカードリーダライタによって読み出される。格納部 20 5に格納される所定の文字列は、予めサーバ装置 400との間で取り決められた文字 列であり、署名として利用するのに適切な任意の文字列である。また格納部 205に格 納される一時証明書作成対象ポリシ一一覧 232は、個人情報を含む電子証明書に 設定されうる証明書ポリシーの一覧である。本実施形態にかかる一時証明書作成対 象ポリシ一一覧 232は、公的個人認証サービスにより発行されたものであることを示 す証明書ポリシーがリストされる。
[0031] 通信部（受信部） 275は、サーバ装置 400から電子証明書の要求を受信し、ポリシ 一判定部 280にメッセージの受信を通知する。ポリシー判定部 280は、電子証明書 の要求の通知に応答して、格納部 205からクライアント証明書 230と一時証明書作成 対象ポリシ一一覧 232を読み出す。そして、ポリシー判定部 280は、クライアント証明 書 230の拡張領域に記載される証明書ポリシーが、一時証明書作成対象ポリシ一一 覧 232にリストされている証明書ポリシーであるかどうか判定する。
[0032] クライアント証明書 230の証明書ポリシーが一時証明書作成対象ポリシ一一覧 232 にリストされている場合、ポリシー判定部 280は、一時証明書作成部 235に一時電子 証明書の作成を依頼する。クライアント証明書 230の証明書ポリシーが一時証明書 作成対象ポリシ一一覧 232にリストされていない場合、すなわちクライアント証明書 2 30が個人情報を含まない場合は、ポリシー判定部 280は、格納部 205から読み出し たクライアント証明書 230を、通信部（送信部） 275を介してそのままサーバ装置 400 へ送信する。なお、本実施形態に係るクライアント証明書 230は個人情報を含むため 、ポリシー判定部 280は、一時証明書作成部 235に一時電子証明書の作成を依頼 する。
[0033] 一時証明書作成部 235は、ポリシー判定部 280からの依頼に応答して、サーバ装置 400がサポートする電子証明書のフォーマット、すなわち本実施形態では X. 509に 従う一時電子証明書の作成を次のように開始する。一時鍵作成部 240は、一時電子 証明書作成に使用するため、公開鍵暗号方式に従う一組の鍵、すなわち一時公開 鍵とこれに対応する一時秘密鍵とを生成する。基本領域設定部 245は、一時電子証 明書の基本領域を設定する。一例として基本領域設定部 245は、格納部 205からサ ーバ証明書 215に記載される所有者情報を読み出し、これを一時電子証明書の発 行者情報のフィールドにコピーする。これにより一時電子証明書を受信したサーバ装 置 400に対し、当該電子証明書が一時電子証明書であることを示すことができる。
[0034] これに代えて、電子証明書が一時電子証明書であることを示す証明書ポリシーを 利用してもよい。電子証明書の基本領域の発行者情報のフィールドや、電子証明書 の拡張領域の証明書ポリシーのフィールドは、一般的に電子証明書の種別を識別す る目的で使用されているフィールドである。このためこれらのフィールドを電子証明書 がー時電子証明書であることを示す情報を記載するために利用した場合は、独自定 義のフィールドを利用する場合のように、電子証明書の内容が第三者に対し意味不 明なるというようなことがない。基本領域設定部 245はまた、所有者情報のフィールド に自身の情報を設定し、更に公開鍵のフィールドに一時鍵作成部 240が生成した一 時公開鍵を設定する。基本領域のその他のフィールドについては、それぞれ任意の 適切な値が設定される。
[0035] 暗号化部 250は、格納部 205からクライアント証明書 230及びサーバ証明書 215に 記載されるサーバ公開鍵 220を読み出し、サーバ公開鍵 220を用いてクライアント証 明書 230を暗号化する。時刻取得部 255は、クライアント装置 200上の現在時刻を 取得する。署名値計算部 260は、格納部 205から文字列 210を読み出し、時刻取得 部 255により取得された現在時刻と文字列とを署名対象として署名値を計算する。す なわち署名値計算部 260は、現在時刻と文字歹 IJ210とをハッシュ関数を用いてハツ シュ処理し、得られるハッシュ値を格納部 205に格納されるクライアント秘密鍵 225を 用いて暗号化する。
[0036] 署名値計算に用いるハッシュ関数は、予めサーバ装置 400との間で取り決めておい てもよく、又はクライアント証明書 230の署名に利用されているものと同じものとしても ょレ、。更には利用したハッシュ関数情報を一時電子証明書の拡張領域を利用してサ ーバ装置 400に通知してもよい。また、署名値計算部 260は、格納部 205から読み 出した文字歹 IJ210のみを署名対象としてもよい。
[0037] 拡張領域設定部 265は、一時電子証明書の拡張領域に暗号化部 250により暗号化 されたクライアント証明書 230を設定する。拡張領域設定部 265はまた、本人確認情 報として一時電子証明書の拡張領域に、格納部 205から読み出された文字列 210、 時刻取得部 255により取得された現在時刻（以下、「署名時刻」という）、及び署名値 計算部 260により計算された署名値を追加設定してもよい。また、署名設定部 270は 、一時電子証明書に署名を施す。すなわち署名設定部 270は、基本領域及び拡張 領域に設定された情報をハッシュ処理し、得られるハッシュ値をサーバ証明書 21 5に 記載されるサーバ公開鍵 220を用いて暗号化した署名値を一時電子証明書に設定 する。
[0038] 図 3 (c)に、一時証明書作成部 235により作成された一時電子証明書の一例を示す 。上述したように、本実施形態に係る一時電子証明書の発行者情報フィールドには、 当該電子証明書が一時デジタル証明であることを示す判定情報 (本実施形態ではサ ーバ装置 400情報）が記載される。また、一時電子証明書の拡張領域には、暗号化 済みのクライアント証明書 230と本人確認情報である文字列 210、署名時刻、署名値 Cが記載される。更に、一時電子証明書には、サーバ装置 400のサーバ公開鍵を用 いて計算された署名値 Bが付される。通信部（送信部） 275は、一時証明書作成部 2 35により作成された一時電子証明書を電子証明書の要求に対する応答としてサー バ装置 400へ送信する。
[0039] 一時格納部 290は、 SSL/TLSの HandshakeProtocolの開始メッセージである ClientHelloメッセージから Client Key Exchangeメッセージまでの通信内容を 一時的に格納する。署名作成部 285は、通信部（送信部） 275より送信される電子証 明書が確かにクライアント装置 200により送信されたものであることをサーバ装置 400 が確認する際に使用可能な署名を、一時格納部 290が格納する上記情報を使用し て作成する。すなわち、署名作成部 285は、一時格納部 290から上記通信内容を読 み出してハッシュ処理することによりハッシュ値を求め、これを送信する電子証明書に 記載される公開鍵に対応する秘密鍵で暗号化することにより署名を作成する。そして 署名作成部 285は、作成した署名を、電子証明書と一緒に又はその送信の後、通信 部（送信部） 275を介してサーバ装置 400へ送信する。
[0040] 以上のように、本発明の実施形態に係るクライアント装置 200によれば、電子証明書 の拡張領域を利用してサーバ装置 400がサポートするフォーマットの電子証明書内 に自身を証明する真の電子証明書を設定するので、個人情報を含むクライアント証 明書を暗号化した状態で送信することができ、第三者による個人情報への不正ァク セスを防止できる。
[0041] 図 4は、本発明の一実施形態に係るサーバ装置 400の機能構成の一例を示す。サ ーバ装置 400は、通信部 405、一時格納部 410、判定部 415、復号部 420、格納部 425、及び認証部 430を備える。格納部 425は、サーバ秘密鍵 430と信頼済み証明 書一覧 435を格納する。ここでサーバ秘密鍵 430は、クライアント装置 200へ送信し たサーバ証明書 215に記載されるサーバ公開鍵 220に対応する秘密鍵である。また 、信頼済み証明書一覧 435は、複数の認証局のルート証明書の一覧であり、ルート 証明書の正当性はサーバ装置 400において既に確認されているものとする。認証部 430は、通信相手を認証する機能を有し、証明書検証部 435と本人確認部 440とを 含む。本人確認部 440は電子証明書が確かに本人から送信されたことを確認する機 能を有し、署名検証部 445と時刻検証部 450とを含む。
[0042] 通信部 405は、電子証明書の要求に対する応答としてクライアント装置 200から電子 証明書を受信する。受信した電子証明書は、一時格納部 410に格納される。判定部 415は、一時格納部 410から電子証明書に記載される判定情報、すなわち本実施 形態では電子証明書の基本領域に記載される発行者情報を読み出し、受信した電 子証明書が一時電子証明書であることを判定情報が示しているかどうか判定する。 受信した電子証明書が一時電子証明書であることを示す場合、すなわち本実施形 態では発行者情報がサーバ装置 400自身を示す場合、判定部 415は判定結果を復 号部 420と認証部 430に通知する。一方、受信した電子証明書が一時電子証明書 であることを示さない場合、判定部 415は判定結果を認証部 430にのみ通知する。
[0043] 復号部 420は、受信した電子証明書が一時電子証明書であるとの通知に応答して、 一時格納部 410から受信した電子証明書の拡張領域に記載される暗号化されたクラ イアント証明書 230を読み出す。そして復号部 420は、読み出したクライアント証明書 230を格納部 425に格納される対応するサーバ秘密鍵 430を用いて復号する。復号 されたクライアント証明書 230はその後認証部 430へ渡される。
[0044] 認証部 430は、受信した電子証明書は一時電子証明書でないと判定部 415が判定 した場合、受信した電子証明書と当該電子証明書と一緒に又はその後にクライアント 装置 200から送信される署名とを用いてクライアント装置 200を認証する。一方、受 信した電子証明書は一時電子証明書であると判定部 415が判定した場合、認証部 4 30は復号されたクライアント証明書 230と一時電子証明書の拡張領域に設定される 署名とを用いてクライアント装置 200を認証する。認証部 430による認証処理は、判 定部 415からの判定結果の通知に応答して開始され、証明書検証部 435と本人確 認部 440による処理が行われる。
[0045] 電子証明書の検証方法は判定部 415による判定結果にかかわらず基本的に同じで ある。そこで以下では、個人情報を含むクライアント証明書 230を検証する場合を例 に、証明書検証部 435による処理を説明する。なお、個人情報を含むクライアント証 明書 230を検証対象とする場合、後述する本人確認部 440による処理の成功を条件 としてあよい。
[0046] 証明書検証部 435は、復号部 420から復号されたクライアント証明書 230を受け取り 、電子証明書の検証、すなわち、クライアント証明書 230に付された署名の検証と、ク ライアント証明書 230に記載される書誌情報の確認を行う。署名の検証は次のように して行う。まず、クライアント証明書 230に記載される発行者情報を参照して、格納部 425に格納される信頼済み証明書一覧 435の中から該当する認証局（本実施形態 では、都道府県知事）のルート証明書を検索する。次に、ルート証明書に記載される ルート公開鍵を用いてクライアント証明書 230に付された署名を復号する。そして、こ れをクライアント証明書 230の基本領域及び拡張領域に記載される情報をハッシュ 処理して得られたハッシュ値と比較して一致するかどうか判定する。 2つが一致すれ ば検証は成功である。なお、署名に使用されるアルゴリズムは、クライアント証明書 23 0に記載される署名方式により確認できる。
[0047] 次に、クライアント証明書 230に記載される書誌情報の確認には、一例としてクライァ ント証明書 230の有効期限及び失効の確認、また所有者情報や個人情報を参照し た通信相手の確認が含まれる。ここで、クライアント証明書の失効を確認する方法を 説明する。認証局が電子証明書の失効を利用者に通知するには 2つの方法があり、 1つは失効された証明書のリストを定期的に公開する Certificate Revocation List (CRL)方法であり、 1つは証明書の失効情報を保持したサーバー力 S、クライアン トからの証明書の失効情報の問い合わせに答える Online Certificate Status P rotocol (OCSP)方法である。公的個人認証サービスでは前者の方法が採用されて おり、従って本実施形態では、証明書検証部 435は認証局に CRLを要求し、受信し た CRLにクライアント証明書力 Sリストされているかどうか判定することにより失効を確認 する。なお、上述した個人情報を参照した通信相手の確認は、個人情報を含むクラ イアント証明書 230を検証対象とする場合に限られる。
[0048] 本人確認部 440は、検証対象の電子証明書が確かにクライアント証明書 230の所有 者により送信されたことを確認する。受信した電子証明書は一時電子証明書であると 判定部 415が判定した場合、署名検証部 445は、一時格納部 410から一時電子証 明書の拡張領域に記載される本人確認情報を読み出し、署名の検証を行う。本人確 認情報を用いた署名の検証は次のようにして行われる。まず本人確認情報に含まれ る文字歹 IJ210と署名時刻を予めクライアント装置 200との間で取り決められたハッシュ 関数を用いてハッシュ処理しハッシュ値を得る。次に本人確認情報に含まれる署名 値 Cを、復号されたクライアント証明書 230に記載されるクライアント公開鍵を用いて 復号する。最後に復号された署名値 Cと上記ハッシュ値を比較する。 2つが一致すれ ば、クライアント証明書 230は確かにクライアント証明書 230の所有者により送信され たものであるといえる。
[0049] 一方、受信した電子証明書は一時電子証明書でないと判定部 415が判定した場合 、署名検証部 445は、電子証明書と一緒に又は電子証明書の受信の後にクライアン ト装置 200から送信される署名に対して検証処理を行う。クライアント装置 200の機能 構成の説明で上述したように、 SSL/TLSの HandshakeProtocolにおける相手認 証では、本人確認情報として、 HandshakeProtocolの開始メッセージである Client Helloメッセージから Client Key Exchangeメッセージまでの通信内容が利用さ れる。そして、力、かる通信内容のハッシュ値を電子証明書に記載される公開鍵に対 応する秘密鍵で暗号化することにより計算された署名値力 S、 ClientCertificateメッ セージの後に送信される CertificateVerifyメッセージの本体に入れられてクライア ント装置 200から送信される。
[0050] そこで、受信した電子証明書がそのまま検証対象となる場合、署名検証部 445は次 のようにして署名検証を行う。通信部 405においてクライアント装置 200から Certific ateVerifyメッセージが受信されると、署名検証部 445は一時格納部 410を介して C ertificateVerifyメッセージ本体に含まれる署名値を読み出す。そして、署名検証部 445は署名値をクライアント装置 200から受信した電子証明書に記載される公開鍵 で復号する。また一時格納部 410は、 ClientHelloメッセージから Client Key Ex changeメッセージまでの通信内容を一時的に格納する。そこで署名検証部 445は 一時格納部 410からこれら通信内容を読み出してハッシュ値を求め、復号した署名 値と比較する。 2つが一致すれば、受信した電子証明書は確かに当該電子証明書の 所有者により送信されたものであるとレ、える。
[0051] なお、本実施形態では従来の通信相手の認証方法、すなわち SSL/TLSの Han dshakeProtocolにおける相手認証との互換性を維持するため、一時電子証明書を サーバ装置 400へ送信する場合でも、クライアント装置 200は CertificateVerifyメッ セージを作成しサーバ装置 400へ送信するものとする。この場合使用されるクライア ントの秘密鍵は一時電子証明書に記載される一時公開鍵に対応する一時秘密鍵で ある。但し、サーバ装置 400は、 CertificateVerifyメッセージ本体に含まれる署名を 検証する必要はない。
[0052] 本人確認部 440はまた、一時電子証明書の拡張領域に署名時刻が記載される場合 、一時電子証明書の拡張領域に記載される本人確認情報が再利用されたものでな いことを確認してもよい。この場合、時刻検証部 450はまずサーバ装置 400上の現在 時刻を取得する。そして、現在時刻と一時電子証明書の拡張領域に記載される署名 時刻との差を計算し、求めた差が許容範囲内であるかどうか判定する。許容範囲内 であれば、本人確認情報は再利用されたものでないといえる。このように署名に署名 時刻を含めることによって本人確認情報の再利用を禁止することで、一時電子証明 書を盗聴して本人確認情報を盗んだ第三者が偽の一時電子証明書を作成すること を防止できる。
[0053] 以上のように、本発明の実施形態に係るサーバ装置 400によれば、クライアント装置
200から電子証明書を受信した場合に、まず電子証明書の所定の領域に記載される 判定情報を用いて、受信した電子証明書が一時電子証明書かどうか判定するので、 判定結果に応じて相手認証に用いる電子証明書とすべき対象を変えることが可能と なる。すなわち、本発明の実施形態に係るサーバ装置 400によれば、暗号化された 電子証明書と通常の暗号化されていない電子証明書の両方を処理することが可能と なり、従来の通信相手の認証方法との互換性を維持できる。
[0054] 次に、図 5のフローチャートを参照して、本実施形態に係るクライアント装置 200の動 作を説明する。図 5 (a)はサーバ装置 400からの電子証明書の要求に応答して電子 証明書を送信するまでのクライアント装置 200の処理の流れを示す。クライアント装置 200は、サーバ装置 400からクライアント装置 200を認証するための電子証明書の要 求を受信すると (ステップ 500)、格納部 205からサーバ装置 400へ送信すべきクライ アント証明書 230と一時証明書作成対象ポリシ一一覧 232を読み出す (ステップ 503 )。そしてクライアント装置 200は、クライアント証明書 230の拡張領域から証明書ポリ シーを取り出し（ステップ 506)、取り出した証明書ポリシーが一時証明書作成対象ポ リシ——覧 232にリストされているかどうか判断する（ステップ 509)。
[0055] 取り出した証明書ポリシーが一時証明書作成対象ポリシ一一覧 232にリストされてい る場合 (ステップ 509 : YES)、一時電子証明書を作成するための前準備が開始され る。すなわちクライアント装置 200はまず、格納部 205からサーバ証明書 215を読み 出し (ステップ 512)、読み出したサーバ証明書 215から所有者情報とサーバ公開鍵 を取り出す (ステップ 515)。また、クライアント装置 200は、一時電子証明書に使用す るため、公開鍵方式に従う一組の鍵、すなわち一時公開鍵と一時秘密鍵とを生成す る（ステップ 518)。
[0056] 前準備が終わると、クライアント装置 200は用意した情報を用いてサーバ装置 400が サポートする電子証明書のフォーマットに従う一時電子証明書を作成する (ステップ 5 21)。一時電子証明書の作成方法については後述する。クライアント装置 200は、作 成した一時電子証明書をサーバ装置 400へ送信すると（ステップ 524)、一時電子証 明書に記載される一時公開鍵に対応する一時秘密鍵を用いて署名を作成し、これを サーバ装置 400へ送信する（ステップ 527)。
[0057] 一方、ステップ 509で NOの場合、すなわち取り出した証明書ポリシーが一時証明書 作成対象ポリシ一一覧 232にリストされておらずクライアント証明書 230に個人情報 が含まれていない場合、クライアント装置 200は、格納部 205から読み出したクライア ント証明書 230をそのままサーバ装置 400へ送信する（ステップ 530)。そして、クライ アント装置 200は、クライアント証明書 230に記載されるクライアント公開鍵に対応す るクライアント秘密鍵を用いて署名を作成し、これをサーバ装置 400へ送信する（ステ ップ 536)。ステップ 527又はステップ 533の後処理は終了する。
[0058] 図 5 (b)を参照して一時電子証明書作成の処理の流れを説明する。クライアント装置
200はまず、図 5 (a)のステップ 515及び 518で用意した情報を用いて、一時電子証 明書の基本領域の設定を行う（ステップ 540)。すなわち、発行者情報のフィールドに サーバ装置 400を示す所有者情報を設定し、また公開鍵情報のフィールドに一時公 開鍵を設定する。その他のフィールドについては、それぞれ任意の適切な値を設定 する。次にクライアント装置 200は、図 5 (a)のステップ 515で取得したサーバ公開鍵 を用いて、個人情報を含むクライアント証明書を暗号化する（ステップ 545)。またクラ イアント装置 200は、クライアント証明書が確かにその所有者により送信されたことを 示すため本人確認情報を作成する（ステップ 550)。本人確認情報の作成方法につ いては後述する。そしてクライアント装置 200は、暗号化済みのクライアント証明書と 本人確認情報とを一時電子証明書の拡張領域に設定する（ステップ 555)。最後にク ライアント装置 200は、サーバ公開鍵 220を用いて一時電子証明書に署名を施す（ ステップ 560)。そして処理は終了する。
[0059] 図 5 (c)を参照して、本人確認情報の作成方法の処理の流れを説明する。クライアン ト装置 200は、格納部 205から予めサーバ装置 400との間で取り決めてお!/、た文字 歹 IJを読み出す (ステップ 570)。次にクライアント装置 200はクライアント装置 200上の 現在時刻を取得する（ステップ 575)。そして読み出した文字列と現在時刻とを署名 対象として、クライアント証明書 230に記載されるクライアント公開鍵に対応するクライ アント秘密鍵を用いて署名値を計算する (ステップ 580)。そして処理は終了する。
[0060] 次に、図 6のフローチャートを参照して、本実施形態に係るサーバ装置 400の動作を 説明する。図 6 (a)はサーバ装置 400による処理の流れの概要を示す。サーバ装置 4 00は、通信相手であるクライアント装置 200を認証するために、クライアント装置 200 へ電子証明書の要求を送信する (ステップ 600)。クライアント装置 200から電子証明 書を受信すると（ステップ 603)、サーバ装置 400はこれを検証する（ステップ 606)。 続レ、てサーバ装置 400はクライアント装置 200から署名を受信する（ステップ 609)。 サーバ装置 400は署名を検証し、受信した電子証明書が確かに当該電子証明書の 所有者から送信されたことを確認する (ステップ 612)。そして処理は終了する。
[0061] 図 6 (b)を参照して、サーバ装置 400による電子証明書の検証処理の流れを説明 する。まずサーバ装置 400は、受信した電子証明書の基本領域から発行者情報を取 り出し (ステップ 615)、受信した電子証明書が一時電子証明書であるかどうか判定す る（ステップ 620)。一時電子証明書であると判定した場合 (ステップ 620 : YES)、サ ーバ装置 400は一時電子証明書を検証する（ステップ 625)。一時電子証明書の検 証については後述する。ステップ 630において一時電子証明書の検証が成功した場 合、サーバ装置 400は一時電子証明書内に含まれるクライアント証明書 230をクライ アント装置 200認証のための検証対象と認識する（ステップ 635)。一方、受信した電 子証明書は一時電子証明書でないと判定した場合 (ステップ 620： NO)サーバ装置 400は受信した電子証明書そのものをクライアント装置 200認証のための検証対象と 認識する（ステップ 637)。
[0062] そして処理はステップ 635又はステップ 637からステップ 640へ進み、サーバ装置 40 0は、検証対象の証明書に施された署名を検証する（ステップ 640)。ステップ 640に おいて検証が成功すると、サーバ装置 400は検証対象の証明書に記載された有効 期限から証明書がまだ有効であることを検証する（ステップ 645)。ステップ 645にお いて検証が成功すると、サーバ装置 400は検証対象の証明書の発行者と通信し、証 明書が失効していないことを検証する（ステップ 650)。ステップ 650において検証に 成功すると、サーバ装置 400は、検証対象の証明書に記載された所有者情報を参 照し、クライアント装置 200が適当な通信相手であることを検証する（ステップ 652)。 ステップ 652における検証の成功は、電子証明書の検証の成功を意味する。なお、 検証の順番は図 6 (b)に示す順番に制限されない。
[0063] ステップ 630において一時電子証明書の検証に失敗した場合、又はステップ 640、 6 45、 650及び 652のいずれかにおいて検証に失敗した場合、処理はステップ 660へ 進み、検証が失敗したことをクライアント装置 200へ通知する。検証の失敗を知らせる ために、 SSL/TLSでは AlertProtocolを利用する。例えば証明書の有効期限が 切れて!/、る場合、 Certificate— expiredメッセージをクライアント装置 200へ送信す る。また、証明書が失効している場合は、 Certificate— revokedメッセージをクライ アント装置 200へ送信する。
[0064] 図 6 (c)を参照して、サーバ装置 400による一時電子証明書の検証処理の流れを説 明する。まずサーバ装置 400は、一時電子証明書の拡張領域から暗号化されたクラ イアント証明書 230を取り出し（ステップ 665)、格納部 425から読み出したサーバ秘 密鍵 430を用いてクライアント証明書 230を復号する（ステップ 670)。次にサーバ装 置 400は一時電子証明書の拡張領域から、本人確認情報として記載されている署名 対象、すなわち文字列と署名時刻とを取り出し (ステップ 675)、所定のハッシュ関数 を用いて署名対象のハッシュ値を求める。サーバ装置 400はまた、一時電子証明書 の拡張領域から本人確認情報として記載されている署名値を取り出す (ステップ 680 )。サーバ装置 400は、復号したクライアント証明書に記載されているクライアント公開 鍵を用いて取り出した署名値を復号し、これをハッシュ値と比較して署名を検証する（ ステップ 685)。
[0065] ステップ 690で検証が成功した場合、すなわちクライアント証明書 230が確かにクライ アント証明書 230の所有者から送信されたと確認できる場合、サーバ装置 400は更 に、サーバ装置 400上の現在時刻を取得する（ステップ 695)。そしてサーバ装置 40 0は、取得した現在時刻と、一時電子証明書の拡張領域に記載された署名時刻との 差を計算する (ステップ 700)。計算した差が許容範囲内である場合 (ステップ 705 : Y ES)、すなわち、一時電子証明書の拡張領域に記載された本人確認情報が再利用 されたものでないと確認できる場合、サーバ装置 400は検証成功を保存する（ステツ プ 710)。ステップ 740において署名検証が失敗した場合又はステップ 705で計算し た差が許容範囲内でない場合、サーバ装置 400は検証失敗を保存する（ステップ 71 5)。そして処理は終了する。
[0066] 図 7は、本実施形態に係るクライアント装置 200のハードウェア構成の一例を示す。
図 7はまたサーバ装置 400のハードウェア構成の一例でもある。以下では、クライアン ト装置 200のハードウェア構成として図 7を説明する。クライアント装置 200は、ホスト コントローラ 715により相互に接続される CPU710及び RAM730を含む CPU周辺 部と、入出力コントローラ 735によりホストコントローラ 715に接続されるカードバスコン トローラ 740及びカードバスコントローラ 740に接続される ICカードリードライタ 745、 通信インターフェース 770、ハードディスクドライブ 750、及び CD— ROMドライブ 76 0を含む入出力部と、入出力コントローラ 735に接続されるスーパー I/Oコントローラ 780及びスーパー I/Oコントローラ 780に接続されるフレキシブルディスクドライブ 7 90、フラッシュ ROM800、ならびにキーボードマウスコントローラ 810を有するレガシ 一入出力部とを備える。
[0067] ホストコントローラ 715は、高い転送レートで RAM730にアクセスする CPU710を RA M730と接続する。 CPU710は、ハードディスクに格納されたプログラムに基づいて 動作し、各部の制御を行う。本発明の実施形態に係る通信相手を認証するためのク ライアント装置 200用のプログラムは、ハードディスクに格納され、 RAM730を用いて CPU710により実行される。クライアント装置 200用のプログラムは、クライアント装置 200を、格納部 205、ポリシー判定部 280、署名作成部 285、一時格納部 290、一時 証明作成部 235、すなわち、一時鍵作成部 240、基本領域設定部 245、暗号化部 2 50、時刻取得部 255、署名値計算部 260、拡張領域設定部 265、及び署名設定部 270、並びに通信部 275として機能させる。その具体的な機能及び動作は、図 2及び 図 5を用いて説明したのと同一であるから説明を省略する。
[0068] 一方、本発明の実施形態に係るサーバ装置 400用のプログラムは、サーバ装置 400 を、通信部 405、一時格納部 410、判定部 415、復号部 420、格納部 425、及び認 証部 430、すなわち、証明書検証部 435、並びに署名検証部 445及び時刻検証部 4 50を含む本人確認部 440として機能させる。その具体的な機能及び動作は、図 4及 び図 6を用いて説明したのと同一であるから説明を省略する。なお、本発明の実施形 態に係るクライアント装置 200用及びサーバ装置 400用のプログラムは、コンピュータ により読み取り可能な媒体に格納できる。コンピュータで読み取り可能な媒体とは、命 令実行システム、装置または機器に使用されあるいはこれらに関連するプログラムを 含み、記憶し、通信し、伝搬し、あるいは搬送することができる任意の装置であること ができる。媒体は、電子的、磁気的、光学的、電磁的、赤外線または半導体システム (または、装置または機器)あるいは伝搬媒体であることができる。コンピュータ可読の 媒体の例には、半導体またはソリッド '·ステート記憶装置、磁気テープ、取り外し可能 なコンピュータ.ディスケット、ランダム.アクセス 'メモリ（RAM)、リードオンリー 'メモリ（ ROM)、リジッド磁気ディスクおよび光ディスクが含まれる。現時点における光ディスク の例には、コンパクト 'ディスク一リードオンリー 'メモリ（CD-ROM)、コンパクト'デイス ク―リード/ライト（CD- R/W)および DVDが含まれる。
[0069] 入出力コントローラ 735は、比較的高速な入出力装置であるカードバスコントローラ 7 40及びカードバスコントローラ 740に接続される ICカードリードライタ 745、通信イン ターフェース 770、ハードディスクドライブ 750、及び CD— ROMドライブ 760をホスト コントローラ 715と接続する。通信インターフェース 770は、ネットワークを介してサー バ装置 400等の外部装置と通信する。
[0070] また、入出力コントローラ 735には、フレキシブルディスクドライブ 790やキーボードマ ウスコントローラ 810等の比較的低速な入出力装置と、フラッシュ ROM800とが接続 される。フラッシュ ROM800は、クライアント装置 200の起動時に CPU710が実行す るブートプログラムや、クライアント装置 200のハードウェアに依存するプログラム等を またはデータを読み取り、 RAM730を介してスーパー I/Oコントローラ 735に提供 する。スーパー I/Oコントローラ 735は、フレキシブルディスクや、例えばパラレルポ ート、シリアルポート、キーボードポート、マウスポート等を介して各種の入出力装置を 接続する。
[0071] 以上、実施形態を用いて本発明の説明をしたが、本発明の技術範囲は上記実施形 態に記載の範囲には限定されない。上記の実施形態に、種々の変更または改良を 加えることが可能であることが当業者に明らかである。従って、そのような変更または 改良を加えた形態も当然に本発明の技術的範囲に含まれる。
図面の簡単な説明
[0072] [図 1]本発明の一実施形態に係る通信相手を認証するためのシステム 100の構成の 一例を示す。
[図 2]本発明の一実施形態に係るクライアント装置 200の機能構成の一例を示す。
[図 3] (a)は、 X. 509証明書のフォーマットを示す。 （b)は、本発明の実施形態に係る 個人情報を含むクライアント証明書の一例を示す。 （c)は本発明の実施形態に係る 一時電子証明書の一例を示す。
[図 4]本発明の一実施形態に係るサーバ装置 400の機能構成の一例を示す。
[図 5] (a)は、本発明の実施形態に係るクライアント装置 200における、サーバ装置 4
00による通信相手認証のための処理の流れの一例を示すフローチャートを示す。 （b
)は、本発明の実施形態に係る一時電子証明書作成の処理の流れの一例を示すフ ローチャートである。 （c)は、本発明の実施形態に係る本人確認情報作成の処理の 流れの一例を示すフローチャートである。
[図 6] (a)は、本発明の実施形態に係るサーバ装置 400における、通信相手認証の ための処理の流れの一例を示すフローチャートを示す。 （b)は、本発明の実施形態 に係る電子証明書検証の処理の流れの一例を示すフローチャートである。 （c)は、本 発明の実施形態に係る一時電子証明書検証の処理の流れの一例を示すフローチヤ ートである。
園 7]本発明の実施形態に係るクライアント装置 200及びサーバ装置 400のハードウ エア構成の一例を示す。

Claims

請求の範囲
[1] 個人情報を含む電子証明書を用いて通信相手を認証する方法であって、
クライアント装置において、
サーバ装置から電子証明書の要求を受信するステップと、
前記要求の受信に応答して、格納部から個人情報を含むクライアント証明書及び前 記サーバ装置のサーバ公開鍵を読み出すステップと、
前記サーバ公開鍵を用いて前記クライアント証明書を暗号化するステップと、 前記サーバ装置がサポートするフォーマットの電子証明書の第 1領域に当該電子証 明書が一時電子証明書であることを示す判定情報を設定し、かつ第 2領域に暗号化 された前記クライアント証明書を設定することにより、前記一時電子証明書を作成す 前記一時電子証明書をサーバ装置に送信するステップとを含み、
前記サーバ装置において、
電子証明書を受信するステップと、
受信した前記電子証明書の前記第 1領域から前記判定情報を取り出すステップと 前記判定情報が、受信した前記電子証明書が前記一時電子証明書であることを 示すかどうか判定するステップと、
受信した前記電子証明書が前記一時電子証明書であると判定した場合、 前記一時電子証明書の前記第 2領域から暗号化された前記クライアント証明書を取 取り出した前記クライアント証明書を前記サーバ公開鍵に対応するサーバ秘密鍵を 用いて復号するステップと、
復号した前記クライアント証明書を用いて前記クライアント装置を認証するステツ プとを含む、
認証方法。
[2] 前記サーバ装置において、受信した前記電子証明書が前記一時電子証明書でない と判定した場合、受信した前記電子証明書を用いて前記クライアント装置を認証する ステップを含む、請求項 1に記載の認証方法。
[3] 前記個人情報を含むクライアント証明書は、公的個人認証サービスにより発行された 前記クライアント装置の電子証明書である、請求項 1に記載の認証方法。
[4] 前記サーバ装置がサポートする電子証明書のフォーマットは、 X. 509である、請求 項 1に記載の方法。
[5] 前記第 1領域は、 X. 509証明書の基本領域であり、前記第 2領域は、前記 X. 509 証明書の拡張領域である、請求項 1に記載の方法。
[6] 前記サーバ装置がサポートするフォーマットの電子証明書の第 1領域は、 X. 509 証明書の拡張領域であり、電子証明書が一時電子証明書であることを示す前記判定 情報として、証明書ポリシーが利用される、請求項 1に記載の方法。
[7] 前記クライアント装置において受信される前記電子証明書の要求は、 SSL (Secure
Socket Layer)又 (ュ ELS、丄' ransport Layer security)の Handshakeフロト コルの Certificate Requestメッセージである、請求項 1に記載の方法。
[8] 前記クライアント装置において、前記第 2領域に更に、所定の文字列と、当該所定の 文字列のハッシュ値を前記クライアント証明書に記載されるクライアント公開鍵に対応 するクライアント秘密鍵を用いて暗号化した署名値とを設定するステップを含み、 前記サーバ装置において、受信した前記電子証明書が前記一時電子証明書である と判定した場合に、前記一時電子証明書の前記第 2領域に記載された前記所定の 文字列から求めたハッシュ値と、前記一時電子証明書の前記第 2領域に記載された 前記署名値を前記クライアント証明書から取り出した前記クライアント公開鍵を用いて 復号したものとを比較することにより通信相手が前記クライアント証明書の所有者本 人であることを確認するステップを更に含む、請求項 1に記載の認証方法。
[9] 前記クライアント装置において、前記クライアント装置上の現在時刻を取得するステツ プと、前記第 2領域に更に、所定の文字列、前記現在時刻を示す署名時刻、並びに 前記所定の文字列及び前記署名時刻のハッシュ値を前記クライアント証明書に含ま れるクライアント公開鍵に対応するクライアント秘密鍵を用いて暗号化した署名値とを
ΒΧ L·するス尸ッゾを 3 、
前記サーバ装置において、受信した前記電子証明書が前記一時電子証明書である と判定した場合に、前記一時電子証明書の前記第 2領域に記載された前記所定の 文字列及び前記署名時刻と、前記一時電子証明書の前記第 2領域に記載された前 記署名値を前記クライアント証明書から取り出した前記クライアント公開鍵を用いて復 号したものとを比較することにより、通信相手が前記クライアント証明書の所有者本人 であることを確認するステップを更に含む、請求項 1記載の認証方法。
[10] 前記サーバ装置において、受信した前記電子証明書が前記一時電子証明書であ ると判定した場合に、前記サーバ装置上の現在時刻を取得するステップと、当該現 在時刻と前記一時電子証明書の前記第 2領域から取り出した前記署名時刻との差が 許容範囲内であるかどうか判断するステップを更に含む、請求項 9に記載の方法。
[11] クライアント装置において実行される、個人情報を含む電子証明書を用いて通信相 手を認証するための方法であって、
サーバ装置から電子証明書の要求を受信するステップと、
前記要求の受信に応答して、格納部から個人情報を含むクライアント証明書及び前 記サーバ装置のサーバ公開鍵を読み出すステップと、
前記サーバ公開鍵を用いて前記クライアント証明書を暗号化するステップと、 前記サーバ装置がサポートするフォーマットの電子証明書の第 1領域に当該電子証 明書が一時電子証明書であることを示す判定情報を設定し、かつ第 2領域に暗号化 された前記クライアント証明書を設定することにより、前記一時電子証明書を作成す 前記一時電子証明書を前記サーバ装置に送信するステップと
を含む通信相手認証のための方法。
[12] サーバ装置において実行される、個人情報を含む電子証明書を用いて通信相手を 認証するための方法であって、
クライアント装置に対しクライアント証明書を要求するステップと、
前記クライアント装置から当該クライアント装置の電子証明書を受信するステップと、 受信した前記電子証明書の第 1領域力、ら判定情報を取り出すステップと、 前記判定情報が、受信した前記電子証明書が個人情報を含む一時電子証明書 であることを示す力、どうか判定するステップと、 受信した前記電子証明書が前記一時電子証明書でな!/、と判定した場合、受信した 前記電子証明書を用いて前記クライアント装置を認証するステップと、
受信した前記電子証明書が前記一時電子証明書であると判定した場合、 受信した前記電子証明書の第 2領域から前記サーバ装置のサーバ公開鍵を用いて 暗号化されたクライアント証明書を取り出すステップと、
暗号化された前記クライアント証明書を前記サーバ公開鍵に対応するサーバ秘密鍵 を用いて復号するステップと、
復号した前記クライアント証明書を用いて前記クライアント装置を認証するステツ プとを含む、
通信相手認証のための方法。
[13] 個人情報を含む電子証明書を用いて通信相手を認証するためのシステムであって、 サーバ装置から電子証明書の要求を受信する受信部と、
個人情報を含むクライアント証明書及び前記サーバ装置のサーバ公開鍵を格納する 格納部と、
前記要求の受信に応答して、前記格納部から読み出した前記サーバ公開鍵を用い て前記クライアント証明書を暗号化する暗号化部と、
前記サーバ装置がサポートするフォーマットの電子証明書の第 1領域に当該電子証 明書が一時電子証明書であることを示す判定情報を設定し、かつ第 2領域に暗号化 された前記クライアント証明書を設定することにより、前記一時電子証明書を作成す る作成部と、
前記一時電子証明書をサーバ装置に送信する送信部と
を備えるクライアント装置と、
前記サーバ公開鍵に対応するサーバ秘密鍵を格納する格納部と、
電子証明書を受信する受信部と、
受信した前記電子証明書の前記第 1領域から取り出した前記判定情報が、受信 した前記電子証明書が一時電子証明書であることを示すかどうか判定する判定部と 前記判定部が一時電子証明書であると判定することに応答して、受信した前記電子 証明書の前記第 2領域から暗号化された前記クライアント証明書を取り出し、当該ク ライアント証明書を前記格納部から読み出したサーバ秘密鍵を用いて復号する復号 部と、
受信した前記電子証明書が一時電子証明書であると前記判定部が判定した場合、 前記復号部により復号された前記クライアント証明書を用いてクライアント装置を認証 する認証部と
を備えるサーバ装置と
を含む、システム。
[14] 個人情報を含む電子証明書を用いて通信相手を認証するためのクライアント装置で あって、
サーバ装置から電子証明書の要求を受信する受信部と、
個人情報を含むクライアント証明書及び前記サーバ装置のサーバ公開鍵を格納する 格納部と、
前記要求の受信に応答して、前記格納部から読み出した前記サーバ公開鍵を用い て前記クライアント証明書を暗号化する暗号化部と、
前記サーバ装置がサポートするフォーマットの電子証明書の第 1領域に当該電子証 明書が一時電子証明書であることを示す判定情報を設定し、かつ第 2領域に暗号化 された前記クライアント証明書を設定することにより、一時電子証明書を作成する作 成部と、
前記一時電子証明書をサーバ装置に送信する送信部と
を備えるクライアント装置。
[15] 個人情報を含む電子証明書を用いて通信相手を認証するためのサーバ装置であつ て、
サーバ公開鍵に対応するサーバ秘密鍵を格納する格納部と、
クライアント装置から電子証明書を受信する受信部と、
受信した前記電子証明書の第 1領域から取り出した判定情報力 S、受信した前記電 子証明書が一時電子証明書であることを示すかどうか判定する判定部と、 前記判定部が一時電子証明書であると判定することに応答して、受信した前記電子 証明書の第 2領域から暗号化されたクライアント証明書を取り出し、前記格納部から 読み出したサーバ秘密鍵で復号する復号部と、
受信した前記電子証明書が前記一時電子証明書でないと前記判定部が判定する場 合、受信した前記電子証明書を用いて前記クライアントを認証し、一時電子証明書で あると前記判定部が判定する場合、前記復号部により復号された前記クライアント証 明書を用いて前記クライアントを認証する認証部と
を備えるサーバ装置。
[16] 個人情報を含む電子証明書を用いて通信相手を認証するためのプログラムであって 前記プログラムは、クライアント装置に、
サーバ装置から電子証明書の要求を受信するステップと、
前記要求の受信に応答して、格納部から個人情報を含むクライアント証明書及び前 記サーバ装置のサーバ公開鍵を読み出すステップと、
前記サーバ公開鍵を用いて前記クライアント証明書を暗号化するステップと、 前記サーバ装置がサポートするフォーマットの電子証明書の第 1領域に当該電子証 明書が一時電子証明書であることを示す判定情報を設定し、かつ第 2領域に暗号化 された前記クライアント証明書を設定することにより、一時電子証明書を作成するステ 前記一時電子証明書をサーバ装置に送信するステップとを実行させ、
前記プログラムは、更に、前記サーバ装置に
電子証明書を受信するステップと、
受信した前記電子証明書の前記第 1領域から前記判定情報を取り出すステップと 前記判定情報が、受信した前記電子証明書が前記一時電子証明書であることを 示すかどうか判定するステップと、
受信した前記電子証明書が前記一時電子証明書であると判定した場合、 前記一時電子証明書の前記第 2領域から暗号化された前記クライアント証明書を取 取り出した前記クライアント証明書を前記サーバ公開鍵に対応するサーバ秘密鍵を
Figure imgf000032_0001
復号した前記クライアント証明書を用いて前記クライアント装置を認証するステツ プとを実行させる、
通信相手を認証するためのプログラム。
[17] 個人情報を含む電子証明書を用いて通信相手を認証するためのプログラムであって 、前記プログラムは、クライアント装置に、
サーバ装置から電子証明書の要求を受信するステップと、
前記要求の受信に応答して、格納部から個人情報を含むクライアント証明書及び前 記サーバ装置のサーバ公開鍵を読み出すステップと、
前記サーバ公開鍵を用いて前記クライアント証明書を暗号化するステップと、 前記サーバ装置がサポートするフォーマットの電子証明書の第 1領域に当該電子証 明書が一時電子証明書であることを示す判定情報を設定し、かつ第 2領域に暗号化 された前記クライアント証明書を設定することにより、一時電子証明書を作成するステ 前記一時電子証明書を前記サーバ装置に送信するステップとを実行させる、 通信相手認証のためのプログラム。
[18] 個人情報を含む電子証明書を用いて通信相手を認証するためのプログラムであって 、前記プログラムは、サーバ装置に、
クライアント装置に対しクライアント証明書を要求するステップと、
前記クライアント装置から当該クライアント装置の電子証明書を受信するステップと、 受信した前記電子証明書の第 1領域力、ら判定情報を取り出すステップと、 前記判定情報が、受信した前記電子証明書が前記個人情報を含む一時電子証 明書であることを示す力、どうか判定するステップと、
受信した前記電子証明書が前記一時電子証明書でな!/、と判定した場合、受信した 前記電子証明書を用いて前記クライアント装置を認証するステップと、
受信した前記電子証明書が前記一時電子証明書であると判定した場合、 受信した前記電子証明書の第 2領域から前記サーバ装置のサーバ公開鍵を用いて 暗号化されたクライアント証明書を取り出すステップと、
暗号化された前記クライアント証明書を前記サーバ公開鍵に対応するサーバ秘密鍵 を用いて復号するステップと、
復号した前記クライアント証明書を用いて前記クライアント装置を認証するステツ プとを実行させる、
通信相手認証のためのプログラム。
PCT/JP2007/070706 2006-10-27 2007-10-24 Système, dispositif, procédé et programme pour authentifier un partenaire de communication au moyen d'un certificat électronique incluant des informations personnelles WO2008050792A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
IN2956CHN2009 IN2009CN02956A (ja) 2006-10-27 2007-10-24
KR1020097008495A KR101054970B1 (ko) 2006-10-27 2007-10-24 개인 정보를 포함하는 전자 증명서를 이용하여 통신 상대를 인증하기 위한 시스템, 장치, 방법, 및 컴퓨터 판독 가능한 기록 매체
EP07830440.9A EP2086162B1 (en) 2006-10-27 2007-10-24 System, device, method and program for authenticating communication partner by means of electronic certificate including personal information
CN2007800400182A CN101529797B (zh) 2006-10-27 2007-10-24 用于使用包含个人信息的电子证明书来认证通信对方的系统、装置、方法
CA2663241A CA2663241C (en) 2006-10-27 2007-10-24 System, apparatus, method, and program product for authenticating communication partner using electonic certificate containing personal information
JP2008541007A JP4870777B2 (ja) 2006-10-27 2007-10-24 個人情報を含む電子証明書を用いて通信相手を認証するためのシステム、装置、方法、及びプログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2006293253 2006-10-27
JP2006-293253 2006-10-27

Publications (1)

Publication Number Publication Date
WO2008050792A1 true WO2008050792A1 (fr) 2008-05-02

Family

ID=39324586

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2007/070706 WO2008050792A1 (fr) 2006-10-27 2007-10-24 Système, dispositif, procédé et programme pour authentifier un partenaire de communication au moyen d'un certificat électronique incluant des informations personnelles

Country Status (8)

Country Link
US (2) US8225096B2 (ja)
EP (1) EP2086162B1 (ja)
JP (1) JP4870777B2 (ja)
KR (1) KR101054970B1 (ja)
CN (1) CN101529797B (ja)
CA (1) CA2663241C (ja)
IN (1) IN2009CN02956A (ja)
WO (1) WO2008050792A1 (ja)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009533945A (ja) * 2006-04-10 2009-09-17 トラスト インテグレーション サービシィズ ベスローテン フェンノートシャップ データを安全に伝送するための装置および方法
US8539239B2 (en) 2010-07-22 2013-09-17 Brother Kogyo Kabushiki Kaisha Information processing apparatus
JP2014510967A (ja) * 2011-02-20 2014-05-01 カーン，ロバート，エス． 関連付けられた組織証明書を利用するオンラインメンバシップ検証
JP2017073610A (ja) * 2015-10-05 2017-04-13 任天堂株式会社 情報処理システム、周辺機器、無線通信チップ、アプリケーションプログラム、および情報処理方法
US9773127B2 (en) 2010-07-22 2017-09-26 Brother Kogyo Kabushiki Kaisha Information processing apparatus
JP2019509652A (ja) * 2016-08-08 2019-04-04 イサラ コーポレイション 複数の暗号システムとのデジタル証明書の使用
JP2019057083A (ja) * 2017-09-20 2019-04-11 株式会社三井住友銀行 非対面取引によるリモート口座開設方法、コンピュータ、およびプログラム
US10425401B1 (en) 2018-10-31 2019-09-24 ISARA Corporation Extensions for using a digital certificate with multiple cryptosystems

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6990581B1 (en) 2000-04-07 2006-01-24 At&T Corp. Broadband certified mail
US8225096B2 (en) 2006-10-27 2012-07-17 International Business Machines Corporation System, apparatus, method, and program product for authenticating communication partner using electronic certificate containing personal information
FR2958821A1 (fr) * 2007-12-11 2011-10-14 Mediscs Procede d'authentification d'un utilisateur
CN102105883A (zh) * 2008-06-23 2011-06-22 Nxp股份有限公司 电子装置以及电子装置的软件或固件更新的方法
JP5329184B2 (ja) * 2008-11-12 2013-10-30 株式会社日立製作所 公開鍵証明書の検証方法及び検証サーバ
US8510810B2 (en) * 2008-12-23 2013-08-13 Bladelogic, Inc. Secure credential store
US8499154B2 (en) * 2009-01-27 2013-07-30 GM Global Technology Operations LLC System and method for establishing a secure connection with a mobile device
US20110150266A1 (en) * 2009-12-22 2011-06-23 Dirk Hohndel Automated security control using encoded security information
US8776205B2 (en) * 2010-10-29 2014-07-08 GM Global Technology Operations LLC Secure connection systems and methods for vehicles
JP5682237B2 (ja) * 2010-11-05 2015-03-11 富士ゼロックス株式会社 情報処理装置及びプログラム
US8843740B2 (en) * 2011-12-02 2014-09-23 Blackberry Limited Derived certificate based on changing identity
US9026789B2 (en) 2011-12-23 2015-05-05 Blackberry Limited Trusted certificate authority to create certificates based on capabilities of processes
US9444629B2 (en) 2013-05-24 2016-09-13 Sap Se Dual layer transport security configuration
EP3036680B1 (en) * 2013-08-21 2018-07-18 Intel Corporation Processing data privately in the cloud
DE102013222503A1 (de) * 2013-11-06 2015-05-07 Siemens Aktiengesellschaft Client-Einrichtung und Verfahren zum Prägen einer Client-Einrichtung auf mindestens eine Server-Einrichtung
CN104320264B (zh) * 2014-02-24 2018-07-31 杨淼彬 一种有效信息的电子认证方法
US20160182289A1 (en) * 2014-12-18 2016-06-23 Interactive Intelligence Group, Inc. System and method for device pairing transaction
US10523435B2 (en) * 2015-07-20 2019-12-31 Digicert, Inc. Mutable fields in digital certificates
US10454689B1 (en) * 2015-08-27 2019-10-22 Amazon Technologies, Inc. Digital certificate management
US20170063557A1 (en) * 2015-08-28 2017-03-02 Fortinet, Inc. Detection of fraudulent certificate authority certificates
US11552968B2 (en) * 2015-10-28 2023-01-10 Qomplx, Inc. System and methods for detecting and mitigating golden SAML attacks against federated services
KR102444239B1 (ko) * 2016-01-21 2022-09-16 삼성전자주식회사 보안 칩, 어플리케이션 프로세서, 보안 칩을 포함하는 디바이스 및 그 동작방법
US10243955B2 (en) * 2016-07-14 2019-03-26 GM Global Technology Operations LLC Securely establishing time values at connected devices
WO2018045590A1 (en) * 2016-09-12 2018-03-15 Telefonaktiebolaget Lm Ericsson (Publ) A method for secure link layer connection over wireless local area networks
US9667619B1 (en) * 2016-10-14 2017-05-30 Akamai Technologies, Inc. Systems and methods for utilizing client side authentication to select services available at a given port number
JP6784198B2 (ja) * 2017-03-09 2020-11-11 トヨタ自動車株式会社 施解錠システム、キーユニット
US10581829B1 (en) 2017-05-31 2020-03-03 Cisco Technology, Inc. Certificate-based call identification and routing
US11316666B2 (en) * 2017-07-12 2022-04-26 Amazon Technologies, Inc. Generating ephemeral key pools for sending and receiving secure communications
US11082412B2 (en) 2017-07-12 2021-08-03 Wickr Inc. Sending secure communications using a local ephemeral key pool
US11546310B2 (en) * 2018-01-26 2023-01-03 Sensus Spectrum, Llc Apparatus, methods and articles of manufacture for messaging using message level security
TWI723494B (zh) * 2019-08-15 2021-04-01 威進國際資訊股份有限公司 客戶端驗證系統及其驗證方法
KR20210076402A (ko) * 2019-12-16 2021-06-24 현대자동차주식회사 차량용 제어기 및 그 인증서 주입 방법
JP2022020143A (ja) * 2020-07-20 2022-02-01 富士通株式会社 通信プログラム、通信装置、及び通信方法
US11514165B2 (en) * 2020-09-18 2022-11-29 Dell Products L.P. Systems and methods for secure certificate use policies
CN112311766B (zh) * 2020-09-29 2022-04-01 新华三大数据技术有限公司 一种用户证书的获取方法及装置、终端设备
KR102474894B1 (ko) * 2022-09-01 2022-12-06 (주)노르마 양자 내성 암호화 알고리즘에 기초한 서명과 인증을 수행함으로써 가상 사설 네트워크를 제공하는 가상 사설 네트워크 형성 방법 및 이를 수행하는 가상 사설 네트워크 운용 시스템

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003124926A (ja) * 2001-10-15 2003-04-25 Hitachi Ltd 暗号化通信システムにおける認証処理方法及びそのシステム
JP2005051734A (ja) * 2003-07-15 2005-02-24 Hitachi Ltd 電子文書の真正性保証方法および電子文書の公開システム
JP2005328408A (ja) * 2004-05-17 2005-11-24 Hitachi Ltd 属性証明書の属性情報暗号化方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3905961B2 (ja) 1997-11-11 2007-04-18 インターナショナル・ビジネス・マシーンズ・コーポレーション 臨時署名認証の方法及びそのシステム
US6189096B1 (en) * 1998-05-06 2001-02-13 Kyberpass Corporation User authentification using a virtual private key
US7039805B1 (en) * 1998-05-20 2006-05-02 Messing John H Electronic signature method
US6367009B1 (en) * 1998-12-17 2002-04-02 International Business Machines Corporation Extending SSL to a multi-tier environment using delegation of authentication and authority
US8812850B2 (en) * 2000-03-02 2014-08-19 Tivo Inc. Secure multimedia transfer system
JP4586250B2 (ja) * 2000-08-31 2010-11-24 ソニー株式会社 個人識別証明書リンクシステム、情報処理装置、および情報処理方法、並びにプログラム提供媒体
US6807577B1 (en) * 2000-09-14 2004-10-19 International Business Machines Corporation System and method for network log-on by associating legacy profiles with user certificates
FR2822002B1 (fr) 2001-03-12 2003-06-06 France Telecom Authentification cryptographique par modules ephemeres
US7197168B2 (en) * 2001-07-12 2007-03-27 Atrua Technologies, Inc. Method and system for biometric image assembly from multiple partial biometric frame scans
US20090055642A1 (en) * 2004-06-21 2009-02-26 Steven Myers Method, system and computer program for protecting user credentials against security attacks
EP1766848A1 (en) 2004-06-21 2007-03-28 Echoworx Corporation Method, system and computer program for protecting user credentials against security attacks
US7900247B2 (en) * 2005-03-14 2011-03-01 Microsoft Corporation Trusted third party authentication for web services
US8225096B2 (en) 2006-10-27 2012-07-17 International Business Machines Corporation System, apparatus, method, and program product for authenticating communication partner using electronic certificate containing personal information

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003124926A (ja) * 2001-10-15 2003-04-25 Hitachi Ltd 暗号化通信システムにおける認証処理方法及びそのシステム
JP2005051734A (ja) * 2003-07-15 2005-02-24 Hitachi Ltd 電子文書の真正性保証方法および電子文書の公開システム
JP2005328408A (ja) * 2004-05-17 2005-11-24 Hitachi Ltd 属性証明書の属性情報暗号化方法

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009533945A (ja) * 2006-04-10 2009-09-17 トラスト インテグレーション サービシィズ ベスローテン フェンノートシャップ データを安全に伝送するための装置および方法
US8539239B2 (en) 2010-07-22 2013-09-17 Brother Kogyo Kabushiki Kaisha Information processing apparatus
US9773127B2 (en) 2010-07-22 2017-09-26 Brother Kogyo Kabushiki Kaisha Information processing apparatus
JP2014510967A (ja) * 2011-02-20 2014-05-01 カーン，ロバート，エス． 関連付けられた組織証明書を利用するオンラインメンバシップ検証
JP2017073610A (ja) * 2015-10-05 2017-04-13 任天堂株式会社 情報処理システム、周辺機器、無線通信チップ、アプリケーションプログラム、および情報処理方法
US10412084B2 (en) 2015-10-05 2019-09-10 Nintendo Co., Ltd. Information processing system, peripheral device, wireless communication chip, computer-readable non-transitory storage medium having application program stored therein, and information processing method
JP2019509652A (ja) * 2016-08-08 2019-04-04 イサラ コーポレイション 複数の暗号システムとのデジタル証明書の使用
JP2019057083A (ja) * 2017-09-20 2019-04-11 株式会社三井住友銀行 非対面取引によるリモート口座開設方法、コンピュータ、およびプログラム
US10425401B1 (en) 2018-10-31 2019-09-24 ISARA Corporation Extensions for using a digital certificate with multiple cryptosystems
US10841295B1 (en) 2018-10-31 2020-11-17 ISARA Corporation Extensions for using a digital certificate with multiple cryptosystems

Also Published As

Publication number Publication date
CA2663241C (en) 2014-12-09
US20120272066A1 (en) 2012-10-25
EP2086162A1 (en) 2009-08-05
KR20090075705A (ko) 2009-07-08
US20080104401A1 (en) 2008-05-01
EP2086162A4 (en) 2017-05-17
CA2663241A1 (en) 2008-05-02
IN2009CN02956A (ja) 2015-08-07
KR101054970B1 (ko) 2011-08-05
JPWO2008050792A1 (ja) 2010-02-25
JP4870777B2 (ja) 2012-02-08
CN101529797A (zh) 2009-09-09
EP2086162B1 (en) 2020-01-29
US8578167B2 (en) 2013-11-05
US8225096B2 (en) 2012-07-17
CN101529797B (zh) 2011-12-14

Similar Documents

Publication Publication Date Title
JP4870777B2 (ja) 個人情報を含む電子証明書を用いて通信相手を認証するためのシステム、装置、方法、及びプログラム
US8185938B2 (en) Method and system for network single-sign-on using a public key certificate and an associated attribute certificate
US7797544B2 (en) Attesting to establish trust between computer entities
US8340283B2 (en) Method and system for a PKI-based delegation process
JP5132222B2 (ja) クライアント装置、サーバ装置及びプログラム
JP4600851B2 (ja) コンピュータシステム間でメッセージを通信するための安全なコンテキストの確立
US7496755B2 (en) Method and system for a single-sign-on operation providing grid access and network access
US9888037B1 (en) Cipher suite negotiation
US9137017B2 (en) Key recovery mechanism
EP3149887B1 (en) Method and system for creating a certificate to authenticate a user identity
US20020144108A1 (en) Method and system for public-key-based secure authentication to distributed legacy applications
US20070136599A1 (en) Information processing apparatus and control method thereof
US8806206B2 (en) Cooperation method and system of hardware secure units, and application device
US20030208681A1 (en) Enforcing file authorization access
TW200833060A (en) Authentication delegation based on re-verification of cryptographic evidence
JP2008236248A (ja) 電子情報認証方法、電子情報認証装置及び電子情報認証システム
JP4071474B2 (ja) 失効確認装置及び方法
JP2008109569A (ja) 中継装置及び通信システム及び中継方法及びプログラム
JP2005109641A (ja) サーバ、公開鍵の情報の提供方法、およびコンピュータプログラム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200780040018.2

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07830440

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2663241

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2008541007

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 1020097008495

Country of ref document: KR

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2007830440

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2956/CHENP/2009

Country of ref document: IN