WO2020017643A1 - 電子署名システム、証明書発行システム、鍵管理システム、証明書発行方法及びプログラム - Google Patents

電子署名システム、証明書発行システム、鍵管理システム、証明書発行方法及びプログラム Download PDF

Info

Publication number
WO2020017643A1
WO2020017643A1 PCT/JP2019/028492 JP2019028492W WO2020017643A1 WO 2020017643 A1 WO2020017643 A1 WO 2020017643A1 JP 2019028492 W JP2019028492 W JP 2019028492W WO 2020017643 A1 WO2020017643 A1 WO 2020017643A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
key
key management
server
user
Prior art date
Application number
PCT/JP2019/028492
Other languages
English (en)
French (fr)
Inventor
杉本　浩一
良尚 桑江
Original Assignee
Ｇｍｏグローバルサイン株式会社
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
Priority claimed from JP2018136657A external-priority patent/JP6465426B1/ja
Priority claimed from JP2019007592A external-priority patent/JP6571890B1/ja
Application filed by Ｇｍｏグローバルサイン株式会社 filed Critical Ｇｍｏグローバルサイン株式会社
Publication of WO2020017643A1 publication Critical patent/WO2020017643A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • 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

Definitions

  • the present invention relates to a digital signature system and a method for issuing a digital certificate, and more particularly, to a method for issuing a digital certificate used with a digital signature required in a public key infrastructure.
  • Electronic contracts mainly use a method using encryption technology or a public key infrastructure.
  • the sender of the document attaches an electronic signature to the contract document (electronic data) using its own private key (private key) based on public key cryptography, and
  • the receiving side verifies the electronic signature given to the contract document using the sending side's public key, thereby making it possible to determine whether there is any impersonation or falsification in the communication path.
  • the public key infrastructure can provide various security systems using a public key and a private key (private key) that is paired with the public key.
  • the public key of the other party (sender side) who signed the contract electronically when verifying the contract document is required.
  • a public key certificate that is, a so-called “electronic certificate” is used.
  • An “electronic certificate” is also called an identification card on the Internet and is issued by a trusted third party (TTP: Trusted Third Party).
  • TTP Trusted Third Party
  • a TTP that issues an electronic certificate is called a certificate authority.
  • an electronic signature is generally performed on a user's PC (Personal Computer).
  • PC Personal Computer
  • Patent Literature 1 discloses a system including a user terminal, an electronic signature server, and a certificate authority.
  • a certificate authority generates a key pair of a secret key and a public key.
  • the electronic signature server requests the certificate authority to issue an electronic certificate based on the public key.
  • the certificate authority supplies the issued electronic certificate and private key to the electronic signature server as a file called PKCS # 12, and the electronic signature server uses the electronic certificate and private key in response to a request from the user terminal.
  • Electronic signature is also called an identification card on the Internet and is issued by a trusted third party (TTP: Trusted Third Party).
  • a certificate authority that issues an
  • the user creates an account in the key management system in advance, further generates a private key (private key) in the key management system, and It is necessary to prepare to bind the digital certificate issued by the certificate authority.
  • the key management system issues a key including the public key to the public key generated together with the private key (private key) in the key management system.
  • a signature request (certificate signature request) had to be generated, obtained (downloaded), and sent to a certificate authority.
  • the present invention has been made in view of the above problems, and executes a process of issuing an electronic certificate necessary for an electronic signature and storing it in a key management system more safely and with a reduced burden on the user. It is an object to provide a possible electronic signature system.
  • a certificate issuing system that issues an electronic certificate, and a key management system that has a function of managing a user's private key and generates an electronic signature using the private key.
  • the certificate issuing system includes: presenting a predetermined access token to the key management system to acquire a certificate issuance request including the user's public key from the key management system; And a digital signature system for issuing a digital certificate.
  • an electronic signature system that can execute a process of issuing an electronic certificate necessary for an electronic signature and storing the electronic certificate in a key management system more safely and with a reduced burden on a user.
  • FIG. 9 is a reference diagram for describing OAuth2.0 processing.
  • FIG. 1 is a diagram illustrating a system configuration according to an embodiment. It is a figure showing composition of a certificate issuing server of this embodiment. It is a figure showing the composition of the key management server of this embodiment.
  • FIG. 9 is a diagram illustrating a flow of a digital certificate storage process in the remote signature system of the embodiment.
  • FIG. 6 is a diagram illustrating a flow of a remote signature process after the electronic certificate storage process illustrated in FIG. 5.
  • FIG. 3 is a diagram illustrating a configuration of a certificate management server 40 according to the embodiment.
  • FIG. 6 is a diagram illustrating a flow of an electronic certificate update process after the electronic certificate storage process illustrated in FIG. 5.
  • FIG. 7 is a diagram illustrating a flow of a pre-authorization process in the remote signature system of the present embodiment.
  • FIG. 10 is a diagram illustrating a flow of an electronic certificate issuance and update process after the pre-authorization process illustrated in FIG
  • the public key infrastructure is an information security infrastructure that provides security functions such as encryption, digital signature (electronic signature), and authentication using an encryption method called a public key encryption method.
  • the public key infrastructure uses the features of the public key cryptosystem to provide the above-described functions such as encryption, digital signature, and authentication.
  • the public key cryptosystem uses one-way property of a private key and a public key (a feature that a public key can be calculated from a private key, but it is difficult to calculate a private key from a public key). Provides various functions. Users keep their private keys secret and keep their public keys open to others.
  • the private key is also referred to as a secret key because it has the meaning of being kept secret.
  • the user B when transmitting a document to the user A, the user B obtains a public key published by the user A, and transmits a document encrypted using the public key to the user A.
  • the user A decrypts the received encrypted document using his / her own private key (secret key).
  • Secret key An Encrypts the received encrypted document using his / her own private key (secret key).
  • Secret key secret key
  • anyone who has the public key of User A can send the encrypted document to User A, while the one encrypted with User A's public key is the private property of User A. Since it can be decrypted only with the key (secret key), even if a malicious third party obtains the public key of the user A, the contents of the encrypted document will not be leaked.
  • TTP trusted third party
  • An electronic certificate is an "identity certificate" that correctly guarantees the information of the owner of a private key (private key).
  • TTP that issues an electronic certificate is particularly called a certification authority or a certification authority (CA).
  • the electronic certificate contains information such as the public key and the name of the owner who certifies the owner of the private key (private key) corresponding to the public key, the name of the organization to which the private key belongs, and the e-mail address.
  • An electronic signature of TTP is given to prevent the falsification of the certificate itself. By attaching an electronic certificate to a document together with an electronic signature, risks such as spoofing and falsification can be prevented.
  • the owner of a private key (private key) trusted by TTP is called a subscriber.
  • the electronic certificate is further used for verifying the electronic signature.
  • an electronic certificate is attached to the electronic signature.
  • the user who receives the digital signature verifies the signature using the public key described in the digital certificate, detects data falsification, and identifies the signer using the content described in the digital certificate. I can do it.
  • An electronic signature includes a value obtained by encrypting the hash value of a document with a private key (private key). (Actually, encryption processing and signature processing are different, but signature processing is called encryption in a broad sense. Often).
  • user A sends a document file with an electronic signature to user B user A uses the hash value obtained by applying the hash function to the document file to be transmitted to user A's private key (secret key).
  • the user B decrypts the encrypted value included in the electronic signature using the public key of the user A and obtains the hash value obtained by decrypting the document file with the hash function. Is compared with the hash value obtained by applying As a result of the comparison, if the two hash values are the same, it is proved that the document has not been tampered with.
  • Remote signature Various cloud services and online services are provided, and documents are often handled on the cloud (on a server).
  • remote signing means managing the signer's digital certificate and private key (private key) with a key management system.
  • the digital certificate and private key private key
  • Remote signature has the advantage that the signer does not need to manage the private key (private key) himself. Furthermore, a document can be digitally signed not only by a PC but also by a mobile device such as a web browser or a smartphone. Therefore, the convenience is greatly improved as compared with the case where an electronic signature is generated at an endpoint using a smart card or a USB token storing a private key (secret key). Further, since the private key (private key) is securely protected by the key management system, it can be said that this is a more desirable signature method from the viewpoint of security.
  • a signature system that provides a remote signature service requires a private key (private key) of a signer and a digital certificate associated with the signer in order to perform the signature.
  • a key pair of a private key (private key) and a public key is generated by a key management system, but a digital certificate is an authentication that guarantees the identity of the owner of a private key (private key). It is issued by an authority, and for the above-mentioned reason, it is necessary to appropriately import the issued digital certificate into the key management system. Importing a digital certificate is a preparation work for performing a remote signature in a signature system.
  • a user himself imports (stores) an electronic certificate generated by a certificate authority based on a public key generated by a key management system into a key management system.
  • the following procedure was required. That is, (1) The user creates an account in the key management system using his / her own terminal device. (2) The user logs in to the key management system using his / her own terminal device, and generates a key pair using the key management system. (3) The user logs in to the key management system using his / her own terminal device, and causes the key management system to generate and download a certificate signing request (CSR).
  • CSR certificate signing request
  • the certificate signing request is also called a certificate issuance request.
  • the user sends the certificate signature request (CSR) obtained in (3) to the certificate authority using his / her own terminal device.
  • the certificate authority issues an electronic certificate based on the certificate signing request (CSR) and sends it to the user.
  • the user logs in to the key management system and imports the electronic certificate sent in (5) into the key management system.
  • the certificate authority itself is a trusted third party, but some key management systems are not always reliable.
  • the reliability of a key management system is whether or not a private key (private key) is managed by an appropriate method.
  • the remote signature requires that a private key (private key) and an electronic certificate be securely managed by a device called HSM (Hardware Security Module) described later. Selecting and using a key management system that does not satisfy such requirements involves security risks.
  • the certificate authority registers a key management system that can ensure reliability. Then, by using a mechanism of SSO (Single Sign On) by OAuth 2.0 described later, the public key and the digital certificate are exchanged between the certificate authority and the trusted key management system, thereby enabling the user The user can use a highly reliable key management system while reducing the burden on the user.
  • SSO Single Sign On
  • OAuth 2.0 defined in RFC6749 is a mechanism that allows clients to use protected resources (important information, keys, etc.) held by a resource server with the permission of the resource owner. is there. Then, the authorization server controls whether the client can access the protected resources held by the resource server. To access a protected resource, information called an access token is required, and the authorization server issues an access token to a client that permits access.
  • a user agent for example, a web browser
  • the user agent mediates the authentication of the resource owner in the authorization server and the transmission of the authorization code (Authorization @ code) from the authorization server to the client.
  • the authorization code is also called an authorization token.
  • FIG. 1 is a reference diagram for explaining OAuth 2.0 processing in which a user agent intervenes.
  • the reference diagram of FIG. 1 is a diagram disclosed in RFC6749.
  • a certificate issuing server as a certificate authority, a key management system, and a terminal device, which constitute the present embodiment, are associated with each entity defined by OAuth 2.0, and each entity defines OAuth2.0 processing is explained.
  • the certificate issuing system according to the present embodiment corresponds to the “client”, and a web browser (described later) executed on the terminal device according to the present embodiment corresponds to the “user agent”.
  • the key management system according to the present embodiment corresponds to the “authorization server”, and the user of the terminal device corresponds to the “resource owner”.
  • the client (certificate issuing server) sends the client ID information to the authorization server (key management system) via the user agent (web browser of the terminal device) (RFC6749 # 4.1).
  • the authorization server (key management system) authenticates and authorizes the resource owner (user) via the user agent (web browser).
  • the authorization server (key management system) authorizes the client (certificate issuing server) via the user agent (web browser). Issue the code (RFC6749 # 4.1.2. Authorization response).
  • the client (certificate issuing server) requests an access token from the authorization server (key management system) by presenting the authorization code (RFC6749 # 4.1.3. Access token request).
  • the authorization server (key management system) issues an access token to the client (certificate issuing server) (RFC6749 # 4.1.4. response).
  • the user is made to access a digital certificate issuing page of a certificate authority (certificate issuing system). Then, the certificate authority transfers the user to a key management system determined to be reliable in advance, and logs in the key management system (authorization request in FIG. 1A).
  • the authorization code of the key management system is sent to the user (the web browser of the terminal device), and the authorization code is transmitted to the certificate authority (certificate issuing system). ) (Authorization response in FIG. 1 (C)).
  • the certificate authority (certificate issuing system) uses this authorization code to make a request for an access token to the key management system (the access token request in FIG. 1D).
  • the certificate authority (certificate issuing system) is given an access token from the key management system (the access token response in FIG. 1E).
  • the certificate authority (certificate issuing system) requests the key management system for a certificate signing request (CSR) using the access token, and the key management system issues a certificate signing request.
  • An electronic certificate is issued by receiving a request (CSR).
  • the certificate authority (certificate issuing system) requests the certificate management request (CSR) to the key management system while satisfying the requirement of user authentication.
  • a certificate signing request (CSR) can be directly received from the key management system, an electronic certificate can be issued, sent to the key management system, and imported.
  • FIG. 2 is a diagram illustrating a system configuration according to the present embodiment.
  • a remote signature system 1 includes a terminal device 10 related to use by a user, a certificate issuing system 2 including a certificate issuing server 20 that issues a user's electronic certificate, A key management system 3 including a key management server 30 for managing a user's private key (private key) and public key pair and a digital certificate issued by the certificate issuing server 20 to provide a remote signature service; A certificate management system 4 that manages the expiration date of an electronic certificate issued by the certificate issuing server 20 and managed by the key management server 30, and a certificate management terminal 15.
  • the certificate management terminal 15 is for logging in to the certificate management system 4 and inputting certificate management information. For example, when distributing a certificate to employees of a company, an administrator uses the information to input subject identification information (distinguish name), a validity period, whether or not a certificate is updated, and the like.
  • the terminal device 10 is, for example, a terminal used by a certificate distribution target employee.
  • the terminal device 10, the certificate issuing system 2, the key management system 3, the certificate management system 4, and the certificate management terminal 15 are all connected to the Internet and can communicate with each other.
  • the terminal device 10 and the certificate management terminal 15 may be connected to the Internet via the same local network.
  • the types of data exchanged between these devices and systems are mainly transmitted and received (using the HTTP protocol) as parameters of HTTP requests and HTTP responses. However, for security, the communication itself is protected. It is customary (eg, utilizing HTTPS).
  • the certificate issuing system 2 corresponds to the OAuth client
  • a web browser executed on the terminal device 10 corresponds to a user agent.
  • the key management system 3 corresponds to the authorization server
  • the user of the terminal device 10 corresponds to the resource owner. Therefore, the certificate issuing device 20 that constitutes the certificate issuing system 2, the key management server 30 that constitutes the key management system 3, and the web browser of the terminal device 10 can execute the processes based on the OAuth described above. It is configured.
  • the terminal device 10 is a general PC or smartphone that can execute a web browser (user agent).
  • the web browser executed by the CPU of the terminal device 10 is a page requesting unit for requesting an electronic certificate issuing page provided from the certificate issuing system 20, a page displaying unit for displaying a transfer page received from the certificate issuing server 20, and the like.
  • OAuth executing means for transmitting an authorization request to the key management server 30 and receiving an authorization response including the authorization code, and transmitting the authorization code received from the key management server 30 to the certificate issuing server 20. It functions as an authorization code transmission unit that performs processing such as transfer.
  • the authentication means for receiving the input of the authentication information (for example, KeyAlias and PIN) necessary for accessing the private key and transmitting it to the key management server 30 may be implemented in a web browser, or may be separately performed by another means. Is also good.
  • the certificate issuing server 20 belongs to a certificate authority that issues an electronic certificate.
  • a certificate authority is an organization that issues an electronic certificate used to confirm the owner of a private key used in a public key infrastructure (PKI).
  • the certificate issuing system 2 may further include, in addition to the certificate issuing server 20, a web server that receives a request from a user's web browser and supplies data of an electronic certificate issuing page to the terminal device 10.
  • the function of the web server may be provided in the certificate issuing server 20 itself.
  • the key management system 3 is a system that manages a user's private key (private key) and an electronic certificate to provide a remote signature service, generates an electronic signature in response to a request, and supplies the electronic signature to a request source.
  • the key management system 3 of the present embodiment includes, for example, a key management server 30 and a hardware security module (HSM) 100.
  • the HSM 100 is a device that generates a pair of a user's private key (private key) and a public key, and generates an electronic signature using the private key (private key).
  • the HSM 100 may have a function of importing and managing a user's electronic certificate issued by a certificate authority, or the electronic certificate may be managed on the key management server 30 side.
  • the HSM 100 is built in the key management server 30, for example, by being connected to an internal bus of the key management server 30. Further, the HSM 100 may be connected to an external bus (such as a USB bus) of the key management server. Further, the HSM 100 may be provided with a network interface so that the HSM 100 alone can be connected to a network.
  • the HSM 100 is communicably connected to the key management server 30 on the same local network as the key management server 30 or on a remote network.
  • the key management server 30 instructs the HSM 100 to generate a key pair in response to a request from the terminal device 10 via the network, and transmits the electronic certificate transmitted from the certificate issuing server 20 (certificate authority) to the HSM 100.
  • the key is imported into the key management server 30 itself.
  • a user for example, a web browser executed on the terminal device 10
  • the key management server 30 sends an authorization code to the terminal device 10 (web browser).
  • the user can select whether or not to perform the authentication request.
  • the user can select whether to establish authentication on a dialog screen for confirming whether to establish authorization.
  • the terminal device 10 (web browser) that has received the authorization code sends (transfers) the authorization code to the certificate issuing server 20.
  • the certificate issuing server 20 sends the authorization code sent from the terminal device 10 (web browser) to the key management server 30, and the key management server 30 sends the access token to the certificate issuing server 20 in exchange for the authorization code. Send it.
  • the certificate issuing server 20 presents the access token to the key management server 30, the certificate issuing server 20 can obtain a certificate signature request (CSR) from the key management server 30. Then, the certificate issuing server 20 issues an electronic certificate for the public key described in the certificate signature request (CSR).
  • CSR certificate signature request
  • the key management server 30 If the user's account does not exist in the key management server 30 when the user requests authentication to the key management server 30, the key management server 30 prompts the user to create a new account. After the user creates a new account in the key management server 30, the key management server 30 can send the authorization code to the user (web browser).
  • the certificate management system 4 includes, for example, a certificate management server 40.
  • the electronic certificate issued by the certificate issuing server 20 has an expiration date such as one year or several years, and the electronic certificate needs to be renewed after the expiration date, preferably before the expiration date.
  • the certificate management server 40 manages the expiration date of the digital certificate issued by the certificate issuing server 20, and issues an instruction to renew an electronic certificate with a near expiration date or an arbitrary digital certificate. This can be performed for the issuing server 20. Further, the certificate management server 40 can instruct the certificate issuing server 20 to update the electronic certificate in response to a request from the certificate management terminal 15.
  • certificate management server 40 The process of updating the electronic certificate related to the certificate management system 4 (certificate management server 40) will be described later in detail. Note that the certificate management server 40 may be included in the certificate management system 4 independent of the certificate issuing system 2 as described above, or may be included in the certificate issuing system 2.
  • FIG. 3A and 3B are diagrams illustrating a configuration of the certificate issuing server according to the present embodiment, in which FIG. 3A illustrates a functional configuration using hardware, and FIG. 3B illustrates a functional configuration using software.
  • the certificate issuing server 20 executes a general-purpose operating system for controlling the entire apparatus and a CPU (Central Processing) for executing a program for realizing the functions of the certificate issuing server 20.
  • Unit 21 a RAM (Random Access Memory) 22 in which various programs, temporary data, and variables are developed for processing by the CPU 21, an HDD (Hard Disk Drive) 23 in which programs and data are stored, and a RAM (not shown).
  • HDD Hard Disk Drive
  • a ROM (Read Only Memory) and a network I / F 24 for connecting the certificate issuing server 20 to a network are provided.
  • the CPU 21 is an example of a control circuit provided in the certificate issuing server 20 to implement a control unit.
  • Other examples of the control circuit include a multi-core CPU, a processor such as an FPGA (Field Programmable Gate Array), and a PLD (Programmable Logic Device). Can be applied.
  • An HDD (Hard Disk Drive) 23 is a drive device for driving a built-in hard disk (Hard Disk).
  • the HDD 23 reads out programs and data stored in a hard disk as a storage medium, and writes data to the hard disk.
  • the certificate issuance server 20 is used to attach and detach optical disks such as FD (Floppy Disk Drive), CD (Compact Disc), DVD (Digital Versatile Disc), BD (Blu-ray (registered trademark) Disk), and flash memory.
  • a reading device 25 that reads and writes programs and data from and to the possible storage medium 200 may be provided.
  • the reading device 25 is an FDD (Floppy Disk Drive), a CDD (Compact Disc Drive), a DVDD (Digital Versatile Disc Drive), a BDD (Blu-ray (registered trademark) Disk Drive), a USB (Universal Serial Bus), or the like.
  • the CPU 21, the RAM 22, the HDD 23, the network I / F 24, and the reading device 25 are connected, for example, via a bus 1000.
  • the RAM 22 and the HDD 23 constitute a storage unit 20B of the certificate issuing server 20.
  • the CPU 21 controls the web page processing unit 51, the OAuth execution processing unit 52, the signature request request processing unit 53, and the electronic certificate issuance processing unit 54 as the control unit 20A. , Run.
  • These processing units are programs for realizing the function of the control unit 20A of the certificate issuing server 20, and the programs may be stored in a hard disk included in the HDD 23 or the storage medium 200.
  • the program is read from the hard disk or the storage medium 200 to the RAM 22 by the HDD 23 or the reading device 25 and executed by the CPU 21.
  • the web page processing unit 51 functions as a so-called web server, and transmits data of an electronic certificate issue page from data of a web page (HTML page) stored in the HDD 23 in response to an HTTP request from the terminal device 10.
  • the web page processing unit 51 may be configured as an independent server device (web server) different from the certificate issuing server 20. That is, the certificate issuing server 20 has a web server function for supplying a web page (electronic certificate issuing page) for accepting the issuance of an electronic certificate and displaying the web page on a web browser of the terminal device.
  • the certificate issuing system 2 includes a back-end certificate issuing server 20 and a web server as a front end accessed by a user.
  • the OAuth execution processing unit 52 is a processing unit for controlling the OAuth 2.0 authorization process defined in the so-called RFC6749, and is transmitted from the terminal device 10 (web browser). A process of requesting an access token from the key management server 30 is performed using the authorization code thus obtained.
  • the OAuth execution processing unit 52 receives the access token from the key management server 30, and stores the received access token in the access token storage unit 55 of the storage unit 20B.
  • the signature request request processing unit 53 performs a process of requesting the key management server 30 for a certificate signature request (CSR) using the access token acquired by the OAuth execution processing unit 52 and stored in the storage unit 20B. It is.
  • the electronic certificate issuance processing unit 54 is a processing unit that performs processing for issuing an electronic certificate based on the public key included in the certificate signature request (CSR) transmitted from the key management server 30.
  • the certificate issuing system 2 issues a certificate signing request including a public key to a trusted signature service (key management system 3) when issuing a digital certificate required by a remote signature. Requests and issuance of electronic certificates can be performed automatically under user authentication and management. This makes it possible to securely issue the electronic certificate while reducing the burden on the user.
  • a trusted signature service key management system 3
  • FIG. 4A and 4B are diagrams illustrating a configuration of the key management server according to the present embodiment, in which FIG. 4A illustrates a functional configuration using hardware, and FIG. 4B illustrates a functional configuration using software.
  • the key management server 30 executes a general-purpose operating system for controlling the entire apparatus and a CPU (Central Processing Unit) for executing a program for realizing the functions of the key management server 30. 31, a random access memory (RAM) 32 in which various programs, temporary data, and variables are developed for processing by the CPU 31, a hard disk drive (HDD) 33 in which programs and data are stored, and a ROM (not shown) Read Only Memory) and a network I / F 34 for connecting the key management server 30 to a network.
  • a CPU Central Processing Unit
  • RAM random access memory
  • HDD hard disk drive
  • ROM Read Only Memory
  • the CPU 31 is an example of a control circuit included in the certificate issuing server 20 to realize a control unit.
  • a processor such as a multi-core CPU, an FPGA (Field Programmable Gate Array), or a PLD (Programmable Logic Device) may be used. Can be applied.
  • the key management server 30 includes a hardware security module (HSM: Hardware Security Module) 100 connected to the internal bus.
  • HSM Hardware Security Module
  • the key management server 30 is synonymous with the key management system 3.
  • the HSM 100 may be connected to an external bus of the key management server 30, or may be connected to the key management server 30 via a network having a network I / F.
  • the key management server 3 and the network connection type HSM 100 constitute the key management system 3.
  • An HDD (Hard Disk Drive) 33 is a drive device for driving a built-in hard disk (Hard Disk). The HDD 33 reads out programs and data stored in a hard disk as a storage medium and writes data into the hard disk.
  • the key management server 30 is detachable from optical disks such as FD (Floppy Disk), CD (Compact Disc), DVD (Digital Versatile Disc), BD (Blu-ray (registered trademark) Disk), and USB flash memory.
  • a reading device 35 that reads and writes programs and data from and to the storage medium 200 may be provided.
  • the reading device 35 is an FDD (Floppy Disk Drive), a CDD (Compact Disc Drive), a DVDD (Digital Versatile Disc Drive), a BDD (Blu-ray (registered trademark) Disk Drive), a USB (Universal Serial Bus), or the like.
  • the CPU 31, the RAM 32, the HDD 33, the network I / F 34, the reading device 35, and the HSM 100 are connected via, for example, a bus 1001. As described above, the HSM 100 may be connected to the network I / F 34 or the USB bus.
  • the RAM 32 and the HDD 33 constitute a storage unit 30B of the key management server 30.
  • the CPU 31 serves as a control unit 30A, an OAuth execution processing unit 61, a user authentication processing unit 62, a key generation processing unit 63, a signature request processing unit 64, a certificate And the storage processing unit 65.
  • These processing units are programs that realize the functions of the control unit 30A of the key management server 30, and the programs can be stored in a hard disk included in the HDD 33 or the storage medium 200.
  • the program is read from the hard disk or the storage medium 200 to the RAM 32 by the HDD 33 or the reading device 35 and executed by the CPU 31.
  • the OAuth execution processing unit 61 is a processing unit for controlling the OAuth 2.0 authorization process defined in RFC6749, together with the OAuth execution processing unit 52 of the certificate issuing server 20.
  • the OAuth execution processing unit 61 When the OAuth execution processing unit 61 receives the authorization request from the terminal device 10 (web browser), the OAuth execution processing unit 61 displays an authentication screen on the terminal device 10, and when the authentication by the user authentication processing unit 62 succeeds, the authorization code Is transmitted to the terminal device 10. Further, when the certificate issuing server 20 requests the access token together with the authorization code from the certificate issuing server 20, the OAuth execution processing unit 61 performs a process of transmitting the access token to the certificate issuing server 20.
  • the user authentication processing unit 62 authenticates authentication information (for example, a combination of a user ID and a password) input on the authentication screen displayed on the terminal device 10, and notifies the OAuth execution processing unit 61 if the authentication information is authenticated.
  • the key generation processing unit 63 is a processing unit that controls the HSM 100 and performs a key generation process for generating a pair of a private key (private key) and a public key.
  • the private key (secret key) is generated based on, for example, KeyAlias and PIN received from the terminal device 10.
  • the signature request processing unit 64 Upon receiving a certificate signature request (CSR) from the certificate issuing server 20, the signature request processing unit 64 sends the certificate signature request (CSR) including the public key generated by the key generation processing unit 63 to the certificate issuing server.
  • 20 is a processing unit that performs a process of transmitting data to the server 20
  • the certificate storage processing unit 65 is a processing unit that stores (imports) the electronic certificate transmitted from the certificate issuing server 20 in the key management server 30 or in the HSM 100.
  • the CPU 31 of the key management server 30 executes an electronic signature generation processing unit that performs processing for causing the HSM 100 to generate an electronic signature in response to an electronic certificate issuance request.
  • the key management system 3 when issuing a digital certificate required by a remote signature, sends a certificate to the certificate issuing system 2 based on user authentication and management. It is possible to automatically issue a certificate signature request including a public key and issue an electronic certificate. This makes it possible to securely issue the electronic certificate while reducing the burden on the user.
  • FIG. 5 is a diagram illustrating the flow of a digital certificate storage process in the remote signature system of the present embodiment.
  • the key management system 3 (key management server 30) is an Identity Provider (IdP) that controls authentication and authorization, and the certificate issuing system 2 (certificate issuing server 20), which is a certificate authority, The Service Provider (SP) that uses the protected resources.
  • IdP Identity Provider
  • SSP Service Provider
  • step S1 the terminal device 10 (web browser) used by the user accesses the certificate issuing server 20 of the certificate authority (CA).
  • the certificate issuing server 20 that has received the request for the electronic certificate issuing page supplies the terminal device 10 with a page for redirecting the user to the key management server 30 in step S2.
  • the terminal device 10 transmits an authorization request to the key management server 30 in step S3 (RFC6749 # 4.1.1.). This is a procedure for requesting user authentication in the single sign-on mechanism.
  • the key management server 30 requests the user to input authentication information (for example, a user ID and a password). If the account of the user has not been created, the key management server 30 performs a process of newly creating an account for the user. In the user authentication process in step S4, the input of the authentication information is performed in a session separately established between the key management server 30 and the terminal device 10, unlike the process defined by RFC6749 (OAuth2.0). .
  • the authentication method is not limited to a form for authenticating a combination of a user ID and a password, and may be performed by sending a token stored in an IC card from the terminal device or 10 to the key management server 30.
  • the key management server 30 establishes the authorization after confirming the user, and transmits an authorization code to the terminal device 10 as an authorization response in step S5. (RFC6749 # 4.1.2.)
  • step S6 the terminal device 10 (web browser) transmits the KeyAlias (identification name given to the key) and the PIN input by the user to the key management server 30.
  • step S7 the key management server 30 causes the HSM (Hardware Security Module) 100 to generate a pair of a private key (private key) and a public key based on the KeyAlias and PIN entered by the user. To be stored.
  • the key pair may be generated by the time a certificate signature request (CSR) including a public key described later is transmitted.
  • CSR certificate signature request
  • the terminal device 10 (web browser) that has received the authorization code transmitted from the key management server 30 transfers (redirects) the authorization code to the certificate issuing server 20 in step S8.
  • the certificate issuing server 20 that has obtained the authorization code transferred from the terminal device 10 makes an access token request (Access token request) to the key management server 30 using this authorization code in step S9 (RFC6749 # 4.1.3.).
  • the key management server 30 that has received the access token request returns an access token response (Access token response) to the certificate issuing server 20 in step S10. That is, the key management server 30 transmits the access token to the certificate issuing server 20 (RFC6749 # 4.1.4.).
  • the certificate issuing server 20 which has obtained the access token from the key management server 30, makes a request for a certificate signature request (CSR) to the key management server 30 using this access token in step S11.
  • the key management server 30 that has received the request for the certificate signing request (CSR) makes a certificate signing request (CSR) to the certificate issuing server 20 in step S12.
  • the certificate signature request includes the public key generated by the key management server 30.
  • the certificate issuing server 20 that has received the certificate signing request issues an electronic certificate in step S13, posts it to, for example, the key management server 30 in step S14, and in step S15, the key management server 30 Accept it (store it in HSM 100).
  • the key management server 30 manages the posted electronic certificate together with a private key (private key) and a public key.
  • FIG. 6 is a diagram for explaining the flow of the remote signature process after the electronic certificate storage process shown in FIG.
  • the certificate issuing server 20 transmits a remote signature request to the key management server 30 using the access token acquired in the process of FIG.
  • This remote signature request is a process for remotely requesting generation of an electronic signature, and is different from the above-described certificate signature request for requesting issuance (signing) of an electronic certificate in the electronic certificate storage process.
  • the key management server 30 that has received the remote signature request transmission generates an electronic signature (HSM 100 generates an electronic signature) in step S22, and transmits the generated electronic signature to the certificate issuing server 20 in step S23. .
  • the certificate issuing server 20 of the present embodiment uses the OAuth 2.0 mechanism from the key management server 30 to access the certificate issuing request (CSR) to the key management server 30 for requesting the certificate. Get a token. Then, the certificate issuing server 20 can use this access token not only for a request for a certificate signature request (CSR) but also for a request for a remote signature to the key management server 30. The certificate issuing server 20 can confirm that the key management server 30 holds a private key corresponding to the issued certificate by verifying the electronic signature sent from the key management server 30 ( Proof of Possession).
  • a public key is included between a certificate authority (certificate issuing system) and a trusted signature service (key management server).
  • the request for the certificate signature and the exchange of the electronic certificate are automatically performed under the authentication and management of the user.
  • the certificate issuing server can automatically issue an electronic certificate.
  • an electronic certificate has an expiration date and must be reissued (updated) periodically.
  • the user of the terminal device 10 performs an operation of accessing the certificate issuing server 20 of the certification authority (CA), the steps S1 to S15 (for generating the key pair) shown in FIG.
  • the steps S6 and S7 By performing the processing of steps S6 and S7 again), a new digital certificate is stored in the key management server 30 (HSM 100), and the digital certificate can be updated.
  • HSM 100 key management server 30
  • the certificate issuance server 20 updates the electronic certificate using the access token issued under the authentication and management of the user of the terminal device 10 at the time of the first storage.
  • the registration of the certificate management information can be performed on the certificate management server 40 from the certificate management terminal 15.
  • the update processing of the electronic certificate is performed by the access token held by the certificate issuing server 20 based on the certificate management information performed from the certificate management terminal 15 to the certificate management server 40. The user does not need to be aware of the digital certificate update process itself, and can minimize the load.
  • the remote signature system 1 of the present embodiment manages a digital certificate issued by the certificate issuing system 2 and stored in the key management system 3 (key management server 30).
  • the system 4 is provided.
  • the certificate management server 40 included in the certificate management system 4 instructs the certificate issuing server 20 to update (reissue) the electronic certificate based on the information registered by the certificate management terminal 15.
  • FIGS. 7A and 7B are diagrams illustrating a configuration of the certificate management server 40 according to the present embodiment.
  • FIG. 7A illustrates a functional configuration using hardware
  • FIG. 7B illustrates a functional configuration using software.
  • the certificate management server 40 executes a general-purpose operating system that controls the entire apparatus and also executes a CPU (Central Processing) that executes a program that implements the function of the certificate issuing server 20. Unit) 41, a RAM (Random Access Memory) 42 in which various programs, temporary data, and variables are developed for processing by the CPU 41, a HDD (Hard Disk Drive) 43 in which programs and data are stored, and a RAM (not shown).
  • CPU Central Processing
  • RAM Random Access Memory
  • the CPU 41 is an example of a control circuit included in the certificate management server 40 and implementing a control unit.
  • Other control circuits include a multi-core CPU, an FPGA (Field Programmable Gate Array), and a PLD (Programmable).
  • Logic Device An HDD (Hard Disk Drive) 43 is a drive device for driving a built-in hard disk (Hard Disk). The HDD 43 reads out programs and data stored in a hard disk as a storage medium and writes data into the hard disk.
  • the certificate management server 40 is detachable from an optical disk such as an FD (Floppy Disk), a CD (Compact Disc), a DVD (Digital Versatile Disc), a BD (Blu-ray (registered trademark) Disk), and a flash memory.
  • a reading device 45 that reads and writes programs and data from and to the storage medium 200 may be provided.
  • the reading device 45 is an FDD (Floppy Disk Drive), a CDD (Compact Disc Drive), a DVDD (Digital Versatile Disc Drive), a BDD (Blu-ray (registered trademark) Disk Drive), a USB (Universal Serial Bus), or the like.
  • the CPU 41, the RAM 42, the HDD 43, the network I / F 44, and the reading device 45 are connected via, for example, a bus 1002.
  • the RAM 42, the HDD 43, and the storage unit 40B of the certificate management server 40 are configured.
  • the CPU 41 executes an update request processing unit 71 and a certificate management processing unit 72 as the control unit 40A.
  • These processing units are programs that realize the functions of the control unit 40A of the certificate management server 40, and the programs may be stored in a hard disk included in the HDD 43 or the storage medium 200.
  • the program is read from the hard disk or the storage medium 200 to the RAM 42 by the HDD 43 or the reading device 45 and is executed by the CPU 41.
  • a certificate management database (DB) 81 that manages the state (valid or expired) and the expiration date of the digital certificate issued by the certificate issuing server 20 is stored in the storage unit 40B including the HDD 43 and the like. Is stored.
  • the certificate management DB 81 is open to a specific external device (such as the certificate management terminal 15) so that the expiration date of the electronic certificate can be confirmed.
  • the certificate management server 40 includes a web page processing unit (a so-called web server) as a front end for exposing information to an external device.
  • the update request processing unit 71 is a processing unit that mainly receives a request from the certificate management terminal 15 and issues a request for updating a specific electronic certificate to the certificate issuing server 20.
  • the certificate management processing unit 72 writes the state (validity, expiration date) and expiration date of the digital certificate issued by the certificate issuing server 20 in the certificate management DB 81 or refers to database information. Department.
  • FIG. 8 is a diagram for explaining the flow of the electronic certificate update process after the electronic certificate storage process shown in FIG.
  • the certificate management server 40 requests the certificate issuing server 20 to update a specific electronic certificate in step S31.
  • the renewal request may be made for one digital certificate, or may be made for a plurality of digital certificates that are about to expire.
  • step S32 the certificate issuing server 20 makes a request for a certificate signature request (CSR) to the key management server 30 using the access token.
  • the key management server 30 that has received the request for the certificate signing request (CSR) makes a certificate signing request (CSR) to the certificate issuing server 20 in step S33.
  • the certificate issuing server 20 that has received the certificate signing request issues an electronic certificate in step S34, and posts it to, for example, the key management server 30 in step S35, and in step S36, the key management server 30 Accept it (store it in HSM 100).
  • the key management server 30 manages the posted electronic certificate together with a private key (private key) and a public key.
  • the access token used in step S32 has been acquired from the key management server 30 in step S10 of the first electronic certificate storage process described with reference to FIG.
  • the access token acquired from the key management server 30 is not necessary to repeat the authorization operation (steps S1 to S5 in FIG. 5) by the terminal device 10 when updating the electronic certificate, and the work load on the user is remarkably increased. Reduced.
  • the access token acquired from the key management server 30 is issued under the authentication and management of the user of the terminal device 10 and is guaranteed to be an appropriate process. You.
  • the access token acquired from the key management server 30 in step S10 of the certificate storage process is used when transmitting a remote signature request to the key management server 30. This means that it can be used when renewing an electronic certificate.
  • the normal access token has an expiration date, which is shorter than the expiration date of the electronic certificate. At the time of renewal of the electronic certificate, there is a high possibility that the expiration date of the access token has passed. On the other hand, under specific conditions, for example, by setting a long validity period of the access token only for the purpose of updating the electronic certificate, the electronic certificate can be reliably updated.
  • the user performs an authorization operation (access to the electronic certificate issuance page in step S1, access to the key management server in step S4) in the first storage process. After performing the login authentication, the storage of the electronic certificate in the key management server 30 and the update of the stored electronic certificate can be performed almost completely automatically.
  • the process of updating the electronic certificate using the access token at the time of initial storage by the certificate issuing server 20 does not necessarily require the request for updating the electronic certificate by the certificate management server 40 in accordance with the request of the certificate management terminal 15. It does not have to be performed at the opportunity. For example, if a mechanism for registering the access token or authentication token acquired by the service provider in the remote signature processing into the key management server 30 is introduced, the key management server 30 uses the access token or the authorization code acquired from the service provider to electronically The certificate can be updated.
  • issuance and update of an electronic certificate and storage in the key management server 30 are completely automated by a process managed by the certificate management server 40 that has received a request from the certificate management terminal 15. It is assumed that the certificate issuing server 20, the key management server 30, and the certificate management server 40 can all have the same configuration as those shown in FIGS. 3, 4, and 7.
  • CSR certificate signing request
  • the certificate issuing server 20 requests the key management server 30 to issue a certificate signing request (CSR) to issue and update a digital certificate, or when the issued digital certificate is stored in the key management server 30, An access token is required.
  • the certificate issuing server 20 performs a pre-authorization process of issuing an available access token in a procedure different from the issuance and renewal of an electronic certificate.
  • the information may be stored in the storage unit 20B (the access token storage unit 55).
  • the certificate issuing server 20 issues and updates an electronic certificate using the access token stored in the access token storage unit 55 under the control of the certificate management server 40 that has received the request from the certificate management terminal 15. be able to.
  • By performing the pre-authorization it is possible to realize the automation from the time of new issuance of the electronic certificate without requiring the authorization operation performed by the user in the processing of FIG.
  • FIG. 9 is a diagram illustrating the flow of the pre-authorization process in the remote signature system of the present embodiment.
  • the user of the terminal device 10 performs the same authorization operation as in FIG.
  • the terminal device 10 web browser
  • the certificate issuing server 20 that has received the request for the electronic certificate issuing page supplies the terminal device 10 with a page for redirecting the user to the key management server 30 in step S42.
  • the terminal device 10 transmits an authorization request to the key management server 30 in step S43 (RFC6749 # 4.1.1.). This is a procedure for requesting user authentication in the single sign-on mechanism.
  • the key management server 30 requests the user to input authentication information (for example, a user ID and a password). If the account of the user has not been created, the key management server 30 performs a process of newly creating an account for the user. In the user authentication process of step S44, the input of the authentication information is performed in a session separately established between the key management server 30 and the terminal device 10, unlike the process defined by RFC6749 (OAuth2.0). .
  • the authentication method is not limited to a form for authenticating a combination of a user ID and a password, and may be performed by sending a token stored in an IC card from the terminal device or 10 to the key management server 30.
  • the key management server 30 establishes the authorization after confirming the user, and transmits an authorization code to the terminal device 10 as an authorization response in step S45. (RFC6749 # 4.1.2.)
  • step S46 the terminal device 10 (web browser) transmits the KeyAlias (identification name given to the key) and the PIN input by the user to the key management server 30.
  • step S47 the key management server 30 causes the HSM (Hardware Security Module) 100 to generate a pair of a private key (private key) and a public key based on the KeyAlias and PIN entered by the user. To be stored.
  • the key pair may be generated by the time a certificate signature request (CSR) including a public key described later is transmitted.
  • CSR certificate signature request
  • the terminal device 10 (web browser) that has received the authorization code transmitted from the key management server 30 transfers (redirects) the authorization code to the certificate issuing server 20 in step S48.
  • the certificate issuing server 20 that has obtained the authorization code transferred from the terminal device 10 makes an access token request to the key management server 30 using this authorization code (RFC6749 # 4.1.3). .).
  • the key management server 30 that has received the access token request returns an access token response to the certificate issuing server 20 in step S50. That is, the key management server 30 transmits the access token to the certificate issuing server 20 (RFC6749 # 4.1.4.).
  • the certificate issuing server 20 stores the received access token in the access token storage unit 55 of the storage unit 20B, and prepares for a certificate issuing request from the certificate management server 40 and a certificate issuing process for the request. .
  • FIG. 10 is a diagram illustrating the flow of an electronic certificate issuance and update process after the pre-authorization process shown in FIG. Since the issuance of the access token has been completed by the pre-authorization process of FIG. 9, the process of issuing an electronic certificate can be executed starting from the certificate management server 40. On the basis of the registration information from the certificate management terminal 15 or the like, the certificate management server 40 issues an electronic certificate issuance request to the certificate issuance server 20 in step S61.
  • step S62 the certificate issuing server 20 makes a request for a certificate signature request (CSR) to the key management server 30 using the access token stored in the storage unit 20B in the process of FIG.
  • the key management server 30 that has received the certificate signing request (CSR) sends the certificate signing request (CSR) to the certificate issuing server 20 in step S63.
  • the certificate issuing server 20, which has received the certificate signing request issues an electronic certificate in step S64, posts it to, for example, the key management server 30 in step S65, and in step S66, the key management server 30 Accept it (store it in HSM 100).
  • the key management server 30 manages the posted electronic certificate together with a private key (private key) and a public key.
  • the certificate issuing server 20 can transmit the signature request shown in FIG. 6 using the access token stored in the storage unit 20B.
  • the certificate management server 40 sends a specific electronic certificate to the certificate issuing server 20 in step S71.
  • the renewal request may be made for one digital certificate, or may be made for a plurality of digital certificates that are about to expire.
  • step S72 the certificate issuing server 20 makes a request for a certificate signature request (CSR) to the key management server 30 using the access token stored in the storage unit 20B.
  • the key management server 30 that has received the request for the certificate signing request (CSR) sends the certificate signing request (CSR) to the certificate issuing server 20 in step S73.
  • the certificate issuing server 20 that has received the certificate signing request issues an electronic certificate in step S74, posts it to, for example, the key management server 30 in step S75, and in step S76, the key management server 30 Accept it (store it in HSM 100).
  • the key management server 30 manages the posted electronic certificate together with a private key (private key) and a public key.
  • the access token used in steps S62 and S72 has been obtained from the key management server 30 in the pre-authorization processing of FIG. 9 and stored in the storage unit 20B.
  • the electronic certificate can be automatically issued and updated under the control of the certificate management terminal 15 and the certificate management server 40.
  • the burden is significantly reduced.
  • the access token acquired from the key management server 30 has been issued under the authentication and management of the user of the terminal device 10 and is guaranteed to be an appropriate process.
  • an access token has an expiration date. After the pre-authorization process of FIG. 9, it is highly likely that the expiration date has passed when issuing or updating the digital certificate in FIG.
  • the issuance and renewal of the electronic certificate can be reliably performed. It is preferable that the user of the terminal device 10 does not need to perform the pre-authorization operation of FIG. 9 again.
  • a refresh token is issued together with an access token. If the expiration date of the access token has passed, the certificate issuing server 20 sends a refresh token to the key management server 30, and the key management server 30 issues a new access token and a refresh token, and issues a certificate. It is sent to the server 20.
  • the certificate issuing server 20 can issue and update an electronic certificate and transmit the signature request shown in FIG. 6 using the newly issued access token. Thereafter, when the expiration date of the new access token has expired, the certificate issuing server 20 can acquire a new access token by presenting the refresh token to the key management server 30.
  • the expiration date of the access token can be maintained at a safe length. Therefore, the user of the terminal device 10 executes the remote signature using the electronic certificate stored in the key management server 30 without being conscious of issuing and updating the electronic certificate at all after the pre-authorization operation of FIG. I can do it.
  • the access token used by the certificate management server 40 for issuing and updating the electronic certificate shown in FIG. 10 does not necessarily have to be issued by the pre-authorization process shown in FIG.
  • the access token used for issuing and updating the electronic certificate may be independently issued by the key management server 30 and transmitted to the certificate issuing server 20 without performing the authorization process as shown in FIG.
  • the present invention is not limited thereto, and the remote signature system 1 of the present embodiment can be configured by a plurality of terminal devices 10, a plurality of certificate issuing systems 20, and a plurality of key management systems 30.
  • the user of one or more terminal devices 10 selects an arbitrary certificate issuing system 20 from a plurality of certificate issuing systems (certificate authorities) having the functions described above, and displays the certificate issuing page on the certificate issuing page. You can access it.
  • one certificate issuing system 20 trusts a plurality of key management systems 30 having the functions described above, and issues an electronic certificate for a public key issued by each key management system according to the above procedure. Perform the registration process.
  • each certificate issuing system displays a list of available key management systems on a certificate issuance page, for example, and selects a key management system to be used from the list. Can be selected by the user.
  • Patent Document 1 Japanese Patent Laid-Open No. 2010-200142 discloses a system including a user terminal, an electronic signature server, and a certificate authority.
  • a certificate authority generates a key pair of a secret key and a public key.
  • the electronic signature server requests the certificate authority to issue an electronic certificate based on the public key.
  • the certificate authority stores the issued electronic certificate and private key in a file in a format called PKCS # 12, and supplies the file to the electronic signature server.
  • the electronic signature server performs an electronic signature using the electronic certificate and the private key in response to a request from the user terminal.
  • the certificate authority generates a key pair
  • the electronic signature server makes a certificate signature request by directly communicating with the certificate authority, and the generated certificate and private key This is done by a direct exchange between the server and the certificate authority. There is no room for the user to intervene during the communication.
  • a user terminal device is interposed between the certificate authority (certificate issuing system) and the key management server, and the user manages the key using the mechanism of OAuth 2.0 (RFC6749).
  • Authentication is performed on the server, and an electronic certificate is exchanged between the certificate authority (certificate issuing system) and the key management server using the access token issued as a result.
  • the private key secret key
  • the private key is generated by the key management server in the first place, and is not exchanged between the certificate authority and the key management server.
  • a certificate signature request and an exchange of an electronic certificate are performed when a user authenticates to the key management server, so that an electronic certificate can be issued more securely than in the conventional method.
  • private keys private keys
  • private keys are not transmitted to other servers or terminals after they are generated by the key management system, the risk of leaking to the outside is low, and a more secure digital signature system can be operated.
  • a first mode is a certificate issuing system 2 that issues an electronic certificate, and a key management system that has a function of managing a secret key of a user and generates an electronic signature using the secret key.
  • the key management system 3 transmits the access token to the electronic certificate issuing system 2, and the certificate issuing system 2 presents the access token to the key management system 3.
  • the electronic signature system 1 acquires a certificate issuance request including a user's public key from the key management system 3 and issues an electronic certificate to the public key.
  • a certificate signing request including a public key and issuance of an electronic certificate are transmitted to a certificate authority (certificate issuance) via an access token. Automatically between the system 2) and the trusted signature service (key management system 3). This makes it possible to realize an electronic signature system that can securely issue an electronic certificate while reducing the burden on the user.
  • a second aspect according to the present embodiment is a certificate issuing system that issues a digital certificate, and requests a certificate issuing request including a public key of a user from a key management system using a predetermined access token.
  • Requesting means (signing request processing unit 53), and issuing means (electronic certificate issuing processing unit 54) for issuing an electronic certificate for the public key included in the certificate issuance request obtained in response to the request by the requesting means. )
  • the certificate issuing system issues a request for a certificate signing request including a public key to a trusted signature service (key management system 3) and issues an electronic certificate when issuing an electronic certificate required by a remote signature. Issuance can be performed automatically via an access token. This makes it possible to securely issue the electronic certificate while reducing the burden on the user.
  • a third mode according to the present embodiment is a key management system that has a function of managing a user's secret key and generates an electronic signature using the secret key, and generates at least a user's public key.
  • Key generation means key generation processing unit 63
  • signature request means for transmitting a certificate issuance request including a public key to the certificate issuance system which has transmitted the access token, and causing the certificate issuance system to issue an electronic certificate.
  • Signature request processing unit 64 The key management system according to the third aspect automatically issues a certificate signing request including a public key to the certificate issuing system via the access token when issuing the digital certificate required by the remote signature. Can be issued. This makes it possible to securely issue the electronic certificate while reducing the burden on the user.
  • 1 remote signing system 10 terminal device, 20 certificate issuing server, 21 CPU, 22 RAM, 23 HDD, 24 network I / F, 30 key management server, 31 CPU, 32 RAM, 33 HDD, 34 network I / F, 51 Web page processing unit, 52 OAuth execution processing unit, 53 Signature request request processing unit, 54 Digital certificate issuance processing unit, 61 User authentication processing unit, 62 OAuth execution processing unit, 63 Key generation processing unit, 64 Signature request processing unit , 65 Certificate storage unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

利用者の負担を低減できるとともに安全に電子証明書の発行、登録が可能な電子署名システムを提供することを目的とする。端末装置１０は、鍵管理サーバ３０に対して認証要求を行い、認証が成功した場合、鍵管理サーバ３０は、端末装置１０に対して認可コードを送信し、端末装置１０は、認可コードを証明書発行サーバ２０に送付し、証明書発行サーバ２０は、端末装置１０から送付された認可コードを鍵管理サーバ３０に送付し、鍵管理サーバ３０は、認可コードと引き換えにアクセストークンを証明書発行サーバ２０に送付し、証明書発行サーバ２０は、アクセストークンを鍵管理サーバ３０に提示することによって、鍵管理サーバ３０より証明書署名要求を入手し、証明書署名要求に記載されている公開鍵に対して電子証明書を発行する。

Description

電子署名システム、証明書発行システム、鍵管理システム、証明書発行方法及びプログラム
　本発明は、電子署名システム及び電子証明書発行方法に関し、特に、公開鍵基盤で必要とされる電子署名と共に用いられる電子証明書を発行するための方法に関する。
　全世界的に電子政府が稼働し始め、従来、紙で行われてきた契約行為も電子的に行われるようになってきた。電子的に行われる契約（電子契約）では、暗号技術や公開鍵基盤を用いた方式が主流である。
　公開鍵基盤を用いた電子契約では、公開鍵暗号方式をベースとして、文書の送り側では、本人の私有鍵（秘密鍵）を用いて契約文書（電子データ）に電子署名を付与し、文書の受け取り側では、送り側の公開鍵を用いて契約文書に付与される電子署名を検証することで、なり済ましや、通信経路での改竄の有無を判断することが出来る。後述するが、公開鍵基盤は、公開鍵と、それと対になる私有鍵（秘密鍵）と、を用いて様々なセキュリティシステムを提供することができる。
　この方式では、契約文書の検証時に契約書に電子署名を施した相手方（送り側）の公開鍵が必要となる。そして、この公開鍵と対になる私有鍵が送り側の所有に係ること（公開鍵の本人性）を証明するため、公開鍵証明書、いわゆる「電子証明書」が用いられる。
　「電子証明書」はインターネット上の身分証とも呼ばれ、信頼できる第三者機関（ＴＴＰ：Trusted Third Party）によって発行される。特に、電子証明書を発行するＴＴＰを認証局と呼ぶ。
　従来、電子署名は利用者のＰＣ（Personal Computer）上で行われることが一般的であったが、サーバ上で行うことにより電子署名の利便性を高めた仕組みも知られている。
　例えば、特許文献１には、ユーザ端末、電子署名サーバ、認証局と、を備えたシステムが開示されている。
　特許文献１においては、認証局が秘密鍵、公開鍵の鍵ペアを生成する。そして、電子署名サーバは、認証局に対して公開鍵に基づく電子証明書の発行を要求する。認証局は、発行した電子証明書と秘密鍵とをＰＫＣＳ＃１２と呼ばれるファイルとして電子署名サーバに供給し、電子署名サーバは、ユーザ端末からの求めに応じて、電子証明書、秘密鍵を用いて電子署名を行う。
　さらに近年では、「リモート署名」あるいは「クラウド署名」と呼ばれるという仕組みが普及をはじめ、そして、ヨーロッパ諸国のｅＩＤＡＳやＡｄｏｂｅ社をはじめとした標準化団体ＣＳＣ(Cloud Signature Consortium)などで、プロトコルの標準化が推し進められている。
　より具体的には、電子署名サイトなどで電子署名が必要な状況になると、OAuth2.0によるＳＳＯ(Single Sign On)の仕組みなどを用いて、利用者が鍵管理システムへリダイレクトされ、鍵管理システムは、ユーザ認証後にトークンを払い出し、そのトークンを取得した電子署名サイトは、トークンを鍵管理システムに対して提示することで、鍵管理システムに署名を行わせる、といった仕組みが「リモート署名」として実装され始めている。
日本特開２０１０－２００１４２公報
　しかしながら、このような「リモート署名」を行うために、利用者は、鍵管理システムに予めアカウントを作成し、さらに鍵管理システムにて私有鍵（秘密鍵）を生成し、その私有鍵に対して認証局から発行された電子証明書をバインドする、という準備が必要となる。
　この準備作業において、利用者は、認証局に電子証明書の発行させるために、鍵管理システムで私有鍵（秘密鍵）とともに生成された公開鍵に対し、鍵管理システムにて公開鍵を含む鍵署名要求（証明書署名要求）を生成、取得（ダウンロード）し、認証局に対して送付する必要があった。
　さらに利用者は、発行された電子証明書を鍵管理システムに対して格納しなければならない。
　このような作業は利用者にとって煩雑なものであるとともに、技術的な負担を強いるものである。さらにこのような準備作業を利用者に行わせると、鍵管理システムの選択を利用者に委ねることになり、認証局側で鍵管理システムのセキュリティーレベルをコントロールすることが難しいという問題もある。
　本発明は上記の問題点を鑑みてなされたものであり、電子署名に必要な電子証明書を発行して鍵管理システムに格納させる処理を、より安全に且つ利用者の負担を軽減しながら実行可能な電子署名システムを提供することを目的とする。
　本発明は、一側面として、電子証明書を発行する証明書発行システムと、利用者の秘密鍵を管理する機能を有し、前記秘密鍵を用いて電子署名を生成する鍵管理システムと、を備え、前記証明書発行システムは、所定のアクセストークンを前記鍵管理システムに提示することによって、前記鍵管理システムから前記利用者の公開鍵を含む証明書発行要求を取得し、前記公開鍵に対して電子証明書を発行する電子署名システムを特徴とする。
　一側面として、電子署名に必要な電子証明書を発行して鍵管理システムに格納させる処理を、より安全に且つ利用者の負担を軽減しながら実行可能な電子署名システムを実現することが出来る。
OAuth2.0の処理を説明する参考図である。 本実施形態のシステム構成を説明する図である。 本実施形態の証明書発行サーバの構成を示す図である。 本実施形態の鍵管理サーバの構成を示す図である。 本実施形態のリモート署名システムにおける電子証明書格納処理の流れを説明する図である。 図５に示した電子証明書格納処理の後の、リモート署名処理の流れを説明する図である。 本実施形態の証明書管理サーバ４０の構成を示す図である。 図５に示した電子証明書格納処理の後の、電子証明書更新処理の流れを説明する図である。 本実施形態のリモート署名システムにおける事前認可処理の流れを説明する図である。 図９に示した事前認可処理のあとにおける電子証明書発行、更新処理の流れを説明する図である。
　以下に、図面を参照して本発明の実施の形態を詳細に説明する。
　まず、本実施形態の説明に先立って前提となる技術を説明する。
［公開鍵基盤］
　公開鍵基盤（ＰＫＩ：Public Key Infrastructure）は、公開鍵暗号方式と呼ばれる暗号方式を用い、暗号化、デジタル署名（電子署名）、認証といったセキュリティ機能を提供する情報セキュリティ基盤である。
　公開鍵基盤では、公開鍵暗号方式の特徴を利用し、上述の暗号化、デジタル署名、認証といった機能を提供する。公開鍵暗号方式では、私有鍵と公開鍵の一方向性（私有鍵から公開鍵を計算できるが、公開鍵から私有鍵を計算するのは計算量的に困難であるという特徴）を利用して様々な機能を提供する。利用者は自らの私有鍵を秘密裏に保持し、公開鍵を他者に公開しておく。私有鍵は、秘密に保持するという意味を持たせて秘密鍵とも呼ぶ。
　例えば利用者Ｂは、利用者Ａに文書を送信するとき、利用者Ａが公開している公開鍵を入手し、その公開鍵を使って暗号化した文書を利用者Ａに送信する。利用者Ａは受信した暗号化文書を、自身の私有鍵（秘密鍵）を用いて復号化する。
　利用者Ａの公開鍵を持っていれば誰もが利用者Ａに対して暗号化文書を送信することが出来る一方で、利用者Ａの公開鍵で暗号化したものは、利用者Ａの私有鍵（秘密鍵）でしか復号できないため、仮に悪意の第三者が利用者Ａの公開鍵を入手したとしても、暗号化文書の内容が漏えいすることはない。
[電子証明書]
　公開鍵暗号方式で通信を行うには、通信相手に公開鍵を送信することになるが、ネットワーク経由での通信では通信相手が見えないため、第三者が通信相手に成りすまして公開鍵を送信する可能性がある。従って、公開鍵が本当に正しい相手から送られてきたものであるかを確認する必要がある。
　ＰＫＩでは、例えば、信頼できる第三者機関(ＴＴＰ： Trusted Third Party)が、私有鍵の所有者を保証する。すなわち、ＴＴＰは私有鍵（秘密鍵）の所有者の本人性を確認し、私有鍵（秘密鍵）と対になる公開鍵とその私有鍵（秘密鍵）の所有者とを紐づける電子証明書（公開鍵証明書）を発行する。電子証明書は私有鍵（秘密鍵）の所有者の情報を正しく保障する「身分証明書」である。
　電子証明書を発行するＴＴＰは、特に認証局あるいは認証機関（ＣＡ：Certification Authority）と呼ばれる。
　電子証明書には、公開鍵と、その公開鍵に対応する私有鍵（秘密鍵）の所有者を証明する所有者の名前、所属組織名、メールアドレス等の情報が記載されており、さらに電子証明書自体の改ざんを防ぐためにＴＴＰの電子署名が付与されている。電子証明書を電子署名と共に文書に付すことで、なりすましや、改ざんなどのリスクを未然に防ぐことが出来る。また、ＴＴＰに信頼される私有鍵（秘密鍵）の所有者を加入者(Subscriber、サブスクライバー)という。
[電子署名]
　電子証明書はさらに、電子署名を検証する用途に用いられる。通常、電子署名には、電子証明書を添付する。電子署名を受け取った利用者は、電子証明書に記載された公開鍵を使って署名を検証し、データの改ざん検知を行い、電子証明書に記載された内容を使って署名者の特定を行うことが出来る。
　電子署名には、文書のハッシュ値を私有鍵（秘密鍵）で暗号化した値が含まれる（実際には、暗号処理と署名処理は異なるが、署名処理のことを広義の暗号化と呼ぶことが多い）。利用者Ａが利用者Ｂに対して電子署名を付した文書ファイルを送る場合、利用者Ａは、送信する文書ファイルをハッシュ関数にかけることによって得たハッシュ値を利用者Ａの私有鍵（秘密鍵）を用いて暗号化し、電子署名を作成して、文書ファイルに添付する。
　電子署名付きの文書ファイルを受け取った利用者Ｂは、電子署名に含まれる暗号化された値を利用者Ａの公開鍵を使って復号化することによって得たハッシュ値と、文書ファイルをハッシュ関数にかけることによって得たハッシュ値と、を比較する。比較の結果、双方のハッシュ値が同一であれば、文書が改ざんされていないことが証明される。
［リモート署名］
　様々なクラウドサービス、オンラインサービスが提供され、クラウド上（サーバ上）で文書を扱うことが多くなっている。それに伴い、文書に対する電子署名を署名者のＰＣ（Personal Computer）上ではなく、サーバ上（クラウド上）で行う「リモート署名（クラウド署名）」と呼ばれる方式の電子署名が普及しつつある。
　より詳しくは、リモート署名とは、署名者の電子証明書、私有鍵（秘密鍵）を鍵管理システムで管理し、電子署名が必要なときには、鍵管理システム上で電子証明書、私有鍵（秘密鍵）を用いた電子署名を実行する仕組みである。
　リモート署名には、署名者が私有鍵（秘密鍵）を自ら管理する必要が無いという利点がある。さらに、ＰＣのみならず、ウェブブラウザやスマートフォンなどのモバイルデバイスによっても文書に電子署名が可能である。従って、私有鍵（秘密鍵）を格納したスマートカードやＵＳＢトークン等を用いたエンドポイントでの電子署名の生成に比べ、格段に利便性が向上する。さらに、鍵管理システムで私有鍵（秘密鍵）が堅牢に保護されるため、セキュリティの観点からも、より望ましい署名方法であると言える。
　上記のように、リモート署名のサービスを提供する署名システムでは、署名を行うために署名者の私有鍵（秘密鍵）と、それに紐づけた電子証明書と、が必要である。
　下記に説明するが、私有鍵（秘密鍵）と公開鍵の鍵ペアは鍵管理システムで生成するものであるが、電子証明書は、私有鍵（秘密鍵）の所有者の身分を保障する認証局によって発行されるものであり、前述した理由により、鍵管理システムには、発行された電子証明書を適宜インポートする必要がある。
　電子証明書のインポートは、署名システムにおいてリモート署名をおこなうための準備作業である。
　現状、そのような準備作用として、鍵管理システムが生成した公開鍵に基づいて認証局で生成された電子証明書を鍵管理システムにインポート（格納）するには、利用者（署名者）自身による以下のような手順が必要であった。
　すなわち、
（１）利用者が自身の端末装置を用いて鍵管理システムにアカウントを作成する。
（２）利用者が自身の端末装置を用いて鍵管理システムにログインし、鍵管理システムで鍵ペアを生成する。
（３）利用者が自身の端末装置を用いて鍵管理システムにログインし、鍵管理システムに証明書署名要求（ＣＳＲ：Certificate Signing Request）を生成させ、ダウンロードする。証明書署名要求は、証明書発行要求ともいう。
（４）利用者が自身の端末装置を用いて、（３）で取得した証明書署名要求（ＣＳＲ）を認証局に送付する。
（５）認証局が上記証明書署名要求（ＣＳＲ）に基づいて電子証明書を発行して利用者に送付する。
（６）利用者が鍵管理システムにログインし、（５）で送付された電子証明書を鍵管理システムにインポートする。
　このような準備作業では、利用者が自分で行う作業や手順が多く、また、技術的な知識も必要となるため、利用者に負担を強いるという問題があった。
　また、認証局側の観点では、準備作業を利用者に行わせた結果、鍵管理システムの選択を利用者に委ねることになり、認証局側が鍵管理システムのセキュリティーレベルをコントロールすることが難しい、という問題があった。
　認証局自体は信頼できる第三者機関であるが、鍵管理システムの中には、必ずしも信頼がおけないものがある。鍵管理システムの信頼性とは、私有鍵（秘密鍵）を適切な方法で管理しているか否かである。リモート署名では、私有鍵（秘密鍵）や電子証明書を後述するＨＳＭ（Hardware Security Module）と呼ばれる装置で安全に管理することが要求される。そのような要求を満たしていない鍵管理システムを利用者が選択し、利用することにはセキュリティリスクが伴う。
　そこで本実施形態において、認証局は、信頼性を担保出来る鍵管理システムを登録する。そして、後述するOAuth2.0によるＳＳＯ（Single Sign On）の仕組みを用いて、認証局と、信頼された鍵管理システムと、の間で公開鍵と電子証明書のやりとりを行うことで、利用者の負担を軽減しながら、信頼性の高い鍵管理システムを利用者に利用させることが出来る。
　ＲＦＣ６７４９で定義されるOAuth2.0は、概略としては、リソースサーバが保有している保護リソース（重要情報や鍵等）をリソースオーナーの許可を得てクライアントが使用することができるようにする仕組みである。
　そして、リソースサーバが保有する保護リソースに対するクライアントのアクセス可否を認可サーバがコントロールする。
　保護リソースにアクセスするにはアクセストークン（Access token）と呼ばれる情報が必要であり、認可サーバは、アクセスを許可するクライアントに対してアクセストークンを発行する。
　また、上記に加えてユーザーエージェント（例えばウェブブラウザ）がアクセスの介在をする場合がある。その場合、認可サーバにおけるリソースオーナーの認証、及び、認可サーバからクライアントへの認可コード（Authorization code）の送付を、ユーザーエージェントが仲介して行う。なお、認可コードは、認可トークンとも呼ぶ。
　図１は、ユーザーエージェントが介在するOAuth2.0の処理を説明する参考図である。
　なお、図１の参考図は、ＲＦＣ６７４９に開示されている図である。
　図１を用いて、本実施形態を構成する、認証局としての証明書発行サーバ、鍵管理システム、端末装置と、OAuth2.0で定義される各エンティティとの対応付けを行うとともに、各エンティティによるOAuth2.0の処理を説明する。
　なお、本実施形態の証明書発行システムが上記「クライアント」に対応し、本実施形態の端末装置で実行されるウェブブラウザ（後述）が上記「ユーザーエージェント」に対応する。また、本実施形態の鍵管理システムが上記「認可サーバ」に対応し、端末装置の利用者が上記「リソースオーナー」に対応する。
　図１の（Ａ）において、クライアント（証明書発行サーバ）は、ユーザーエージェント（端末装置のウェブブラウザ）を経由してクライアントのＩＤ情報を認可サーバ（鍵管理システム）に送り（ＲＦＣ６７４９＃４．１．１．　認可要求）、（Ｂ）において、認可サーバ（鍵管理システム）は、ユーザーエージェント（ウェブブラウザ）を経由してリソースオーナー（利用者）に認証・認可を実施する。
　（Ｃ）において、認可サーバ（鍵管理システム）がリソースへのアクセスを許可する場合、認可サーバ（鍵管理システム）は、ユーザーエージェント（ウェブブラウザ）を経由してクライアント（証明書発行サーバ）に認可コードを発行する（ＲＦＣ６７４９＃４．１．２．　認可応答）。
　（Ｄ）において、クライアント（証明書発行サーバ）は、認可コードを提示することによって、認可サーバ（鍵管理システム）に対してアクセストークンを要求する（ＲＦＣ６７４９＃４．１．３．　アクセストークン要求）。
　（Ｅ）において、認可サーバ（鍵管理システム）は、提示された認可コードの検証に成功した場合、アクセストークンをクライアント（証明書発行サーバ）に発行する（ＲＦＣ６７４９＃４．１．４．　アクセストークン応答）。
　本実施形態においては、利用者を認証局（証明書発行システム）の電子証明書発行ページにアクセスさせる。そして、認証局は、予め信頼できると決められている鍵管理システムに利用者を転送して当該の鍵管理システムにログインさせる（図１（Ａ）の認可要求）。
　利用者が鍵管理システムに対して行ったログイン認証が成功すると、鍵管理システムの認可コードが、利用者（端末装置のウェブブラウザ）に送付され、この認可コードは、認証局（証明書発行システム）に転送される（図１（Ｃ）の認可応答）。
　認証局（証明書発行システム）は、この認可コードを用いて、アクセストークンの要求を鍵管理システムに対して行う（図１（Ｄ）のアクセストークン要求）。
　認証局（証明書発行システム）は、鍵管理システムからアクセストークンを付与される（図１（Ｅ）のアクセストークン応答）。
　さらに、本実施形態の特徴として、認証局（証明書発行システム）は、そのアクセストークンを使って鍵管理システムに対して証明書署名要求（ＣＳＲ）の要求を行い、鍵管理システムから証明書署名要求（ＣＳＲ）を受け取ることで電子証明書の発行を行う。
　このような本実施形態のシステムによれば、利用者による認証という要件を満たしながら、認証局（証明書発行システム）側で鍵管理システムに対する証明書署名要求（ＣＳＲ）の要求を行うことで、鍵管理システムから証明書署名要求（ＣＳＲ）を直接受け取って、電子証明書を発行して鍵管理システムに送信し、インポートさせることが出来る。
　以下に、本実施形態のシステム及びその処理をより詳しく説明する。
　図２は、本実施形態のシステム構成を説明する図である。
　図２に示すように、本実施形態のリモート署名システム１は、利用者の利用に係る端末装置１０と、ユーザの電子証明書を発行する証明書発行サーバ２０を含む証明書発行システム２と、ユーザの私有鍵（秘密鍵）及び公開鍵のペア、及び証明書発行サーバ２０が発行した電子証明書を管理してリモート署名のサービスを提供するための鍵管理サーバ３０を含む鍵管理システム３と、証明書発行サーバ２０で発行されて鍵管理サーバ３０で管理されている電子証明書の期限管理等を行う証明書管理システム４と、証明書管理端末１５と、を備える。
　証明書管理端末１５は、証明書管理システム４へログインし、証明書の管理情報を入力するためのものである。
　例えば、企業の社員に証明書を配布する際に、管理者が、主体者識別情報（ディスティンギッシュネーム）や、有効期間、証明書の更新の有無などを入力する用途に用いる。
　端末装置１０は、例えば、証明書配布対象社員の使用する端末である。
　端末装置１０、証明書発行システム２、鍵管理システム３、証明書管理システム４、証明書管理端末１５は、いずれもインターネットに接続され、互いに通信可能に構成されている。
　端末装置１０と証明書管理端末１５は同一のローカルネットワークを経由してインターネットに接続されてもよい。
　これらの装置、システム間でやり取りされるデータの類は、おもにＨＴＴＰリクエストやＨＴＴＰレスポンスのパラメータとして（ＨＴＴＰプロトコルを利用して）送受信されるが、セキュリティ確保のため、通信自体は保護されるのが慣例である（例えば、ＨＴＴＰＳを利用する）。
　上記したように、証明書発行システム２が上記OAuthにおけるクライアントに対応し、
端末装置１０で実行されるウェブブラウザがユーザーエージェントに対応する。また、鍵管理システム３が認可サーバに対応し、端末装置１０の利用者が上記リソースオーナーに対応する。
　従って、証明書発行システム２を構成する証明書発行装置２０、鍵管理システム３を構成する鍵管理サーバ３０、端末装置１０のウェブブラウザは、夫々上記に説明したOAuthに準拠した処理を実行可能に構成されている。
　端末装置１０は、ウェブブラウザ（ユーザーエージェント）を実行可能な一般的なＰＣやスマートフォンである。
　端末装置１０のＣＰＵによって実行されるウェブブラウザは、証明書発行システム２０から提供する電子証明書発行ページを要求するページ要求手段、証明書発行サーバ２０から受信した転送ページ等を表示するページ表示手段、認可要求（Authorization request）を鍵管理サーバ３０に送信し、認可コードを含む認可応答（Authorization response）を受信するＯＡｕｔｈ実行手段、鍵管理サーバ３０から受信した認可コードの証明書発行サーバ２０への転送等の処理を行う認可コード送信手段等として機能する。プライベートキーにアクセスするために必要な認証情報（例えばKeyAliasとPIN）の入力を受け付けて鍵管理サーバ３０に送信する認証手段についてはウェブブラウザに実装してもよいし、別途別の手段で行ってもよい。
　証明書発行サーバ２０は、電子証明書を発行する認証局に属する。上記したように、認証局は、公開鍵基盤（ＰＫＩ：Public Key Infrastructure）で用いられる私有鍵の所有者を確認するために用いられる電子証明書を発行する機関である。
　証明書発行システム２は、上記証明書発行サーバ２０に加え、利用者のウェブブラウザによるリクエストを受け付けて電子証明書発行ページのデータを端末装置１０に供給するウェブサーバをさらに備えてもよい。また、ウェブサーバの機能は、証明書発行サーバ２０自体が備えていてもよい。
　鍵管理システム３は、利用者の私有鍵（秘密鍵）、電子証明書を管理してリモート署名サービスを提供するシステムであり、要求に応じて電子署名を生成し、要求元に供給する。
　本実施形態の鍵管理システム３は、例えば、鍵管理サーバ３０と、ハードウェアセキュリティモジュール（ＨＳＭ：Hardware Security Module）１００と、を備えている。
　ＨＳＭ１００は、利用者の私有鍵（秘密鍵）と公開鍵のペアを生成し、私有鍵（秘密鍵）を用いて電子署名を生成する装置である。ＨＳＭ１００が認証局で発行された利用者の電子証明書をインポートして管理する機能を有してもよいし、電子証明書は鍵管理サーバ３０側で管理してもよい。
　本実施形態のシステムにおいて、ＨＳＭ１００は、例えば、鍵管理サーバ３０の内部バスに接続されるかたちで鍵管理サーバ３０に内蔵される。また、ＨＳＭ１００は、鍵管理サーバの外部バス（ＵＳＢバスなど）に接続されてもよい。
　さらに、ＨＳＭ１００はネットワークインターフェイスを備え、ＨＳＭ１００単独でネットワークに接続可能とされてもよい。ＨＳＭ１００は、鍵管理サーバ３０と同一のローカルネットワーク、遠隔のネットワークにおいて、鍵管理サーバ３０と通信可能に接続される。
　その場合、鍵管理サーバ３０は、ネットワーク経由で、端末装置１０からの要求に応じてＨＳＭ１００に鍵ペアの生成を命令し、証明書発行サーバ２０（認証局）から送信された電子証明書をＨＳＭ１００あるいは鍵管理サーバ３０自身にインポートする。
　上記のOAuthの説明においても述べたが、図２に示すシステム１において、証明書発行サーバ２０によってリダイレクトされた利用者（例えば、端末装置１０で実行されるウェブブラウザ）が鍵管理サーバ３０に対して認証を要求し、認証が成功した際には、鍵管理サーバ３０は、端末装置１０（ウェブブラウザ）に対して認可コードを送付する。
　なお、鍵管理サーバ３０に対して認証の要求を行うか否か、認証が成功しても認可を確立させるか否かは、利用者自身の裁量で決定出来る。リダイレクト画面に示される認証要求の可否を確認するダイアログ画面において、利用者は、認証要求の可否を選択することが出来る。あるいは認証成功後に、認可確立の是非を確認するダイアログ画面において、利用者は、認証確立の是非を選択することが出来る。
　認可コードを受け取った端末装置１０（ウェブブラウザ）は、その認可コードを証明書発行サーバ２０に送付（転送）する。
　証明書発行サーバ２０は、端末装置１０（ウェブブラウザ）より送付された認可コードを鍵管理サーバ３０に送付し、鍵管理サーバ３０は、その認可コードと引き換えにアクセストークンを証明書発行サーバ２０に送付する。
　証明書発行サーバ２０がアクセストークンを鍵管理サーバ３０に提示することで、証明書発行サーバ２０は、鍵管理サーバ３０より証明書署名要求（ＣＳＲ）を入手することが出来る。そして、証明書発行サーバ２０は、証明書署名要求（ＣＳＲ）に記載されている公開鍵に対して電子証明書を発行する。
　なお、利用者が鍵管理サーバ３０に対して認証を要求した際に利用者のアカウントが鍵管理サーバ３０に存在しない場合、鍵管理サーバ３０は、利用者に新規アカウントの作成を促す。利用者が鍵管理サーバ３０に新規アカウントを作成した後、鍵管理サーバ３０は、その利用者（ウェブブラウザ）に対して認可コードを送付することができる。
　証明書管理システム４は、例えば、証明書管理サーバ４０を備えている。
　証明書発行サーバ２０で発行された電子証明書には、１年間や数年間などの有効期限があり、電子証明書はその有効期限満了後、望ましくは有効期限満了前に更新される必要がある。
　証明書管理サーバ４０は、証明書発行サーバ２０で発行された電子証明書の有効期限の管理を行い、有効期限が近い電子証明書、あるいは任意の電子証明書を更新するための指示を証明書発行サーバ２０に対して行うことが出来る。
　また証明書管理サーバ４０は、証明書管理端末１５からの要求に応じて、電子証明書を更新する指示を証明書発行サーバ２０に対して行うことが出来る。
　証明書管理システム４（証明書管理サーバ４０）が関連する電子証明書の更新処理については後に詳述する。
　なお証明書管理サーバ４０は、上記のように証明書発行システム２とは独立した証明書管理システム４に含まれてもよく、証明書発行システム２に含まれていてもよい。
　図３は、本実施形態の証明書発行サーバの構成を示す図であり、（ａ）は、ハードウェアによる機能構成を示す図、（ｂ）は、ソフトウェアによる機能構成を示す図である。
　図３（ａ）に示すように、証明書発行サーバ２０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、証明書発行サーバ２０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）２１と、ＣＰＵ２１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）２２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）２３や不図示のＲＯＭ（Read Only Memory）と、証明書発行サーバ２０をネットワークに接続するためのネットワークＩ／Ｆ２４と、を備えている。
　ＣＰＵ２１は、証明書発行サーバ２０が備えて制御部を実現する制御回路の一例であり、制御回路としては、その他にマルチコアＣＰＵ、ＦＰＧＡ（Field Programmable Gate Array）、ＰＬＤ（Programmable Logic Device）などのプロセッサを適用することが出来る。
　ＨＤＤ（Hard Disk Drive）２３は、内蔵するハードディスク（Hard Disk）を駆動するドライブ装置であり、ＨＤＤ２３は記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
　また、証明書発行サーバ２０は、ＦＤ（Floppy Disk Drive）、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu-ray（登録商標） Disk）などの光学ディスク、フラッシュメモリなどの着脱可能な記憶媒体２００に対してプログラムやデータを読み書きする読書装置２５を備えてもよい。
　読書装置２５は、ＦＤＤ（Floppy Disk Drive）、ＣＤＤ（Compact Disc Drive）、ＤＶＤＤ（Digital Versatile Disc Drive）、ＢＤＤ（Blu-ray（登録商標） Disk Drive）、ＵＳＢ（Universal Serial Bus）などである。
　ＣＰＵ２１、ＲＡＭ２２、ＨＤＤ２３、ネットワークＩ／Ｆ２４、読書装置２５は、例えばバス１０００を介して接続されている。
　ＲＡＭ２２、ＨＤＤ２３は、証明書発行サーバ２０の記憶部２０Ｂを構成する。
　また、図３（ｂ）に示すように、ＣＰＵ２１は、制御部２０Ａとして、ウェブページ処理部５１と、ＯＡｕｔｈ実行処理部５２と、署名リクエスト要求処理部５３と、電子証明書発行処理部５４と、を実行する。
　これらの処理部は、証明書発行サーバ２０の制御部２０Ａの機能を実現するプログラムであり、当該プログラムは、ＨＤＤ２３に含まれるハードディスクや記憶媒体２００に格納され得る。プログラムは、ＨＤＤ２３や読書装置２５によってハードディスクや記憶媒体２００からＲＡＭ２２に読み出されてＣＰＵ２１によって実行される。
　ウェブページ処理部５１は、所謂ウェブサーバとして機能し、端末装置１０からのＨＴＴＰリクエストに応じて、ＨＤＤ２３に格納されるウェブページ（ＨＴＭＬページ）のデータから電子証明書発行ページのデータを送信する。上記したように、ウェブページ処理部５１は、証明書発行サーバ２０とは異なる独立したサーバ装置（ウェブサーバ）として構成されてもよい。
　すなわち、証明書発行サーバ２０は、電子証明書の発行を受け付けるためのウェブページ（電子証明書発行ページ）を供給して端末装置のウェブブラウザで表示させるためのウェブサーバの機能を有する。あるいは、証明書発行システム２は、バックエンドの証明書発行サーバ２０と、ユーザがアクセスするフロントエンドとしてのウェブサーバと、から構成されている。
　ＯＡｕｔｈ実行処理部５２は、鍵管理サーバ３０のＯＡｕｔｈ実行処理部６１とともに、所謂ＲＦＣ６７４９に規定されるOAuth2.0の認可処理を制御するための処理部であり、端末装置１０（ウェブブラウザ）から送信された認可コードを用いて、鍵管理サーバ３０にアクセストークンを要求する処理を行う。
　ＯＡｕｔｈ実行処理部５２は、鍵管理サーバ３０からアクセストークンを受信し、受信したアクセストークンを記憶部２０Ｂのアクセストークン記憶部５５に格納する。
　署名リクエスト要求処理部５３は、ＯＡｕｔｈ実行処理部５２によって取得されて記憶部２０Ｂに格納されたアクセストークンを用いて、証明書署名要求（ＣＳＲ）を鍵管理サーバ３０に要求する処理を行う処理部である。
　電子証明書発行処理部５４は、鍵管理サーバ３０から送信された証明書署名要求（ＣＳＲ）に含まれる公開鍵に基づいて電子証明書を発行する処理を行う処理部である。
　以上のような構成を備えることにより、証明書発行システム２は、リモート署名で求められる電子証明書の発行に際し、信頼された署名サービス（鍵管理システム３）に対する公開鍵を含む証明書署名要求の要求及び電子証明書の発行を、利用者の認証と管理のもと自動的に行うことが出来る。これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。
　図４は、本実施形態の鍵管理サーバの構成を示す図であり、（ａ）は、ハードウェアによる機能構成を示す図、（ｂ）は、ソフトウェアによる機能構成を示す図である。
　図４（ａ）に示すように、鍵管理サーバ３０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、鍵管理サーバ３０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）３１と、ＣＰＵ３１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）３２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）３３や不図示のＲＯＭ（Read Only Memory）と、鍵管理サーバ３０をネットワークに接続するためのネットワークＩ／Ｆ３４と、を備えている。
　ＣＰＵ３１は、証明書発行サーバ２０が備えて制御部を実現する制御回路の一例であり、制御回路としては、その他にマルチコアＣＰＵ、ＦＰＧＡ（Field Programmable Gate Array）、ＰＬＤ（Programmable Logic Device）などのプロセッサを適用することが出来る。
　さらに、鍵管理サーバ３０は、内部バスに接続されたハードウェアセキュリティモジュール（ＨＳＭ：Hardware Security Module）１００を備えている。この場合、鍵管理サーバ３０は、鍵管理システム３と同義である。
　なお、上記したように、ＨＳＭ１００は、鍵管理サーバ３０の外部バスに接続されていてもよいし、ネットワークＩ／Ｆを有してネットワーク経由で鍵管理サーバ３０と接続可能されてもよい。この場合、鍵管理サーバ３０と、ネットワーク接続型ＨＳＭ１００と、によって鍵管理システム３が構成される。
　ＨＤＤ（Hard Disk Drive）３３は、内蔵するハードディスク（Hard Disk）を駆動するドライブ装置であり、ＨＤＤ３３は記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
　また、鍵管理サーバ３０は、ＦＤ（Floppy Disk）、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu-ray（登録商標） Disk）などの光学ディスク、ＵＳＢフラッシュメモリなどの着脱可能な記憶媒体２００に対してプログラムやデータを読み書きする読書装置３５を備えてもよい。
　読書装置３５は、ＦＤＤ（Floppy Disk Drive）、ＣＤＤ（Compact Disc Drive）、ＤＶＤＤ（Digital Versatile Disc Drive）、ＢＤＤ（Blu-ray（登録商標） Disk Drive）、ＵＳＢ（Universal Serial Bus）などである。
　ＣＰＵ３１、ＲＡＭ３２、ＨＤＤ３３、ネットワークＩ／Ｆ３４、読書装置３５、ＨＳＭ１００は、例えばバス１００１を介して接続されている。上記のように、ＨＳＭ１００はネットワークＩ／Ｆ３４やＵＳＢバスに接続されてもよい。
　ＲＡＭ３２、ＨＤＤ３３は、鍵管理サーバ３０の記憶部３０Ｂを構成する。
　また、図４（ｂ）に示すように、ＣＰＵ３１は、制御部３０Ａとして、ＯＡｕｔｈ実行処理部６１と、ユーザ認証処理部６２と、鍵生成処理部６３と、署名要求処理部６４と、証明書格納処理部６５と、を実行する。
　これらの処理部は、鍵管理サーバ３０の制御部３０Ａの機能を実現するプログラムであり、当該プログラムは、ＨＤＤ３３に含まれるハードディスクや記憶媒体２００に格納され得る。プログラムは、ＨＤＤ３３や読書装置３５によってハードディスクや記憶媒体２００からＲＡＭ３２に読み出されてＣＰＵ３１によって実行される。
　ＯＡｕｔｈ実行処理部６１は、証明書発行サーバ２０のＯＡｕｔｈ実行処理部５２とともに、ＲＦＣ６７４９に規定されるOAuth2.0の認可処理を制御するための処理部である。
　ＯＡｕｔｈ実行処理部６１は、端末装置１０（ウェブブラウザ）から認可要求を受信すると、認証画面を端末装置１０に表示させ、ユーザ認証処理部６２による認証が成功した場合に、認可応答として、認可コードを端末装置１０に送信する。
　さらに、ＯＡｕｔｈ実行処理部６１は、証明書発行サーバ２０から認可コードとともにアクセストークンを要求されると、証明書発行サーバ２０に対してアクセストークンを送信する処理を行う。
　ユーザ認証処理部６２は、端末装置１０に表示された認証画面に入力された認証情報（例えば、ユーザＩＤ及びパスワードの組み合わせ）を認証し、認証されれば上記ＯＡｕｔｈ実行処理部６１に通知する処理を行う処理部である。
　鍵生成処理部６３は、ＨＳＭ１００を制御し、私有鍵（秘密鍵）と公開鍵のペアを生成させる鍵生成処理を行う処理部である。私有鍵（秘密鍵）は、例えば、端末装置１０から受信したKeyAlias、PINに基づいて生成される。
　署名要求処理部６４は、証明書発行サーバ２０から証明書署名要求（ＣＳＲ）を要求されると、鍵生成処理部６３で生成した公開鍵を含む証明書署名要求（ＣＳＲ）を証明書発行サーバ２０に送信する処理を行う処理部である。
　証明書格納処理部６５は、証明書発行サーバ２０から送信された電子証明書を、鍵管理サーバ３０内、あるいは、ＨＳＭ１００に格納（インポート）する処理を行う処理部である。
　また、鍵管理サーバ３０のＣＰＵ３１は、電子証明発行要求に応じて、ＨＳＭ１００に電子署名を生成させる処理を行う電子署名生成処理部を実行する。
　以上のような構成を備えることにより、本実施形態の鍵管理システム３は、リモート署名で求められる電子証明書の発行に際し、利用者の認証と管理のもと、証明書発行システム２に対して公開鍵を含む証明書署名要求を自動で行い、電子証明書の発行を行わせることが出来る。これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。
　図５は、本実施形態のリモート署名システムにおける電子証明書格納処理の流れを説明する図である。
　シングルサインオンの技術において、鍵管理システム３（鍵管理サーバ３０）は、認証・認可を司るIdentity Provider（ＩｄＰ）であり、認証局である証明書発行システム２（証明書発行サーバ２０）は、保護リソースを利用する側であるService Provider（ＳＰ）である。
　ステップＳ１において、利用者が使用する端末装置１０（ウェブブラウザ）は、認証局（ＣＡ）の証明書発行サーバ２０にアクセスする。
　電子証明書発行ページのリクエストを受けた証明書発行サーバ２０は、ステップＳ２において、利用者を鍵管理サーバ３０にリダイレクトするページを端末装置１０に供給する。
　利用者の操作によって、端末装置１０は、ステップＳ３において、鍵管理サーバ３０に対して、認可要求の送信を行う（ＲＦＣ６７４９＃４．１．１．）。これは、シングルサインオンの仕組みにおいてユーザの認証を要求するための手続である。
　ステップＳ４のユーザ認証処理において、鍵管理サーバ３０は、認証情報（例えば、ユーザＩＤとパスワード）の入力を利用者に要求する。また、当該の利用者のアカウントが未作成の場合には、鍵管理サーバ３０は、当該利用者のためのアカウントを新規に作成する処理を行う。
　なお、ステップＳ４のユーザ認証処理において、認証情報の入力はＲＦＣ６７４９（ＯＡｕｔｈ２．０）で規定される処理とは異なり、鍵管理サーバ３０と端末装置１０との間で別途確立されるセッションにおいて行われる。
　認証の方法は、ユーザＩＤ及びパスワードの組み合わせを認証する形式のみならず、ＩＣカードに格納されたトークンが端末装置か１０から鍵管理サーバ３０に送付されることにより認証が行われる場合もある。
　ユーザの認証又はアカウントの作成が正常に行われると、鍵管理サーバ３０は、利用者の確認を得たうえで認可を確立し、ステップＳ５において、認可応答として、認可コードを端末装置１０に送信する（ＲＦＣ６７４９＃４．１．２．）。
　なお、例えばこの段階で、ステップＳ６において、端末装置１０（ウェブブラウザ）は、利用者が入力したKeyAlias（鍵に付す識別用の名前）とＰＩＮを鍵管理サーバ３０に送信する。
　それに対して、鍵管理サーバ３０は、ステップＳ７において、利用者が入力したKeyAliasとＰＩＮに基づいて、ＨＳＭ（Hardware Security Module）１００に私有鍵（秘密鍵）と公開鍵のペアを生成させ、ＨＳＭ１００に格納させる。
　なお実際には、鍵ペアの生成は、後述する公開鍵を含む証明書署名要求（ＣＳＲ）の送信時までに行われていればよい。
　鍵管理サーバ３０から送信された認可コードを受信した端末装置１０（ウェブブラウザ）は、ステップＳ８において、認可コードを証明書発行サーバ２０に転送（Redirect）する。
　端末装置１０から転送された認可コードを取得した証明書発行サーバ２０は、ステップＳ９において、この認可コードを用いて、アクセストークン要求（Access token request）を鍵管理サーバ３０に対して行う（ＲＦＣ６７４９＃４．１．３．）。
　アクセストークン要求を受けつけた鍵管理サーバ３０は、ステップＳ１０において、アクセストークン応答（Access token response）を証明書発行サーバ２０に返す。
　すなわち、鍵管理サーバ３０は、アクセストークンを証明書発行サーバ２０に送信する（ＲＦＣ６７４９＃４．１．４．）。
　鍵管理サーバ３０からアクセストークンを取得した証明書発行サーバ２０は、ステップＳ１１において、このアクセストークンを用いて、鍵管理サーバ３０に対して証明書署名要求（ＣＳＲ）の要求を行う。
　証明書署名要求（ＣＳＲ）の要求を受けた鍵管理サーバ３０は、ステップＳ１２において、証明書署名要求（ＣＳＲ）を証明書発行サーバ２０に対して行う。証明書署名要求は、鍵管理サーバ３０が生成した公開鍵を含む。
　証明書署名要求を受けた証明書発行サーバ２０は、ステップＳ１３において、電子証明書の発行を行い、ステップＳ１４で、例えば鍵管理サーバ３０に対してポストし、ステップＳ１５で、鍵管理サーバ３０はそれを受け入れる（ＨＳＭ１００に格納する）。
　鍵管理サーバ３０は、ポストされた電子証明書を私有鍵（秘密鍵）、公開鍵とともに管理する。
　図６は、図５に示した電子証明書格納処理の後の、リモート署名処理の流れを説明する図である。
　端末装置１０からの要求に応じて、証明書発行サーバ２０は、ステップＳ２１において、図５の処理で取得したアクセストークンを用いて、リモート署名要求を鍵管理サーバ３０に送信する。
　なお、このリモート署名要求は、遠隔で電子署名の生成を要求する処理であり、上記した電子証明書格納処理における電子証明書の発行（署名）を要求する証明書署名要求とは異なる処理である。
　リモート署名要求送信を受信した鍵管理サーバ３０は、ステップＳ２２において、電子署名を生成し（ＨＳＭ１００に電子署名を生成させ）、ステップＳ２３において、生成された電子署名を証明書発行サーバ２０に送信する。
　上記したように、本実施形態の証明書発行サーバ２０は、鍵管理サーバ３０からOAuth2.0の仕組みを用いて、証明書署名要求（ＣＳＲ）を鍵管理サーバ３０に対して要求する為のアクセストークンを取得する。
　そして、証明書発行サーバ２０は、このアクセストークンを、証明書署名要求（ＣＳＲ）の要求のみならず、鍵管理サーバ３０に対するリモート署名の要求にも利用することが出来る。
　証明書発行サーバ２０は、鍵管理サーバ３０から送付された電子署名を検証することにより、発行した証明書に対応した私有鍵を鍵管理サーバ３０が保有していることを確認することができる（Proof of Possession）。
　以上説明したように、本実施形態のリモート署名システムでは、電子証明書の発行に際して、認証局（証明書発行システム）と信頼された署名サービス（鍵管理サーバ）との間で、公開鍵を含む証明書署名要求及び電子証明書のやりとりが、利用者の認証と管理のもと自動的に行われる。特に、証明書発行サーバは、電子証明書の発行を自動的に行うことが出来る。
　これにより、利用者の負担を軽減しながら、電子証明書の発行、鍵管理サーバへの電子証明書の登録が安全に実施可能な電子署名システムを実現し、信頼性の高い署名サービスを利用者に利用させることが出来る。
　ところで、上記したように電子証明書には有効期限があり、定期的に再発行（更新）する必要がある。
　基本的には、端末装置１０の利用者が認証局（ＣＡ）の証明書発行サーバ２０にアクセスする操作を行うことを契機として、図５に示したステップＳ１～ステップＳ１５（鍵ペアの生成に係るステップＳ６、ステップＳ７は除いてもよい）の処理が再び行われることで、新たな電子証明書が鍵管理サーバ３０（ＨＳＭ１００）に格納され、電子証明書の更新を行うことが出来る。
　しかしながら、端末装置１０の利用者自身が、電子証明書の有効期限を管理し、定期的に電子証明書の更新に係る操作を行うことは非常に煩雑であり、且つ不便である。
　鍵管理サーバ３０に格納された電子証明書の有効期限を端末装置１０の利用者が意識する必要がなく、電子証明書が自動的に更新されていく仕組みが望ましい。
　本発明では、証明書発行サーバ２０は、初回格納時に端末装置１０の利用者自身の認証と管理のもと発行されたアクセストークンを用いて電子証明書の更新処理を行う。
　証明書管理情報の登録は証明書管理端末１５より証明書管理サーバ４０に対して行うことができる。電子証明書の更新処理は、証明書管理端末１５から証明書管理サーバ４０に対して行われた証明書管理情報に基づき、証明書発行サーバ２０の保有するアクセストークンによって行われるので、端末装置１０の利用者は電子証明書の更新処理自体を意識することがなく、その負荷を最大限に抑制することが出来る。
　図２で説明したように、本実施形態のリモート署名システム１は、証明書発行システム２で発行されて鍵管理システム３（鍵管理サーバ３０）に格納された電子証明書を管理する証明書管理システム４を備えている。
　証明書管理システム４が含む証明書管理サーバ４０は、証明書管理端末１５によって登録された情報に基づき、証明書発行サーバ２０に対して電子証明書の更新（再発行）を指示する。
　図７は、本実施形態の証明書管理サーバ４０の構成を示す図であり、（ａ）は、ハードウェアによる機能構成を示す図、（ｂ）は、ソフトウェアによる機能構成を示す図である。
　図７（ａ）に示すように、証明書管理サーバ４０は、装置全体の制御を行う汎用のオペレーティングシステムを実行するとともに、証明書発行サーバ２０の機能を実現するプログラムを実行するＣＰＵ（Central Processing Unit）４１と、ＣＰＵ４１による処理のために各種のプログラムや一時データ、変数が展開されるＲＡＭ（Random Access Memory）４２と、プログラムやデータが格納されるＨＤＤ（Hard Disk Drive）４３や不図示のＲＯＭ（Read Only Memory）と、証明書管理サーバ４０をネットワークに接続するためのネットワークＩ／Ｆ４４と、を備えている。
　ＣＰＵ（Central Processing Unit）４１は、証明書管理サーバ４０が備えて制御部を実現する制御回路の一例であり、制御回路としては、その他にマルチコアＣＰＵ、ＦＰＧＡ（Field Programmable Gate Array）、ＰＬＤ（Programmable Logic Device）などのプロセッサを適用することが出来る。
　ＨＤＤ（Hard Disk Drive）４３は、内蔵するハードディスク（Hard Disk）を駆動するドライブ装置であり、ＨＤＤ４３は記憶媒体としてのハードディスクに格納されたプログラムやデータを読み出し、またハードディスクにデータを書き込む。
　また、証明書管理サーバ４０は、ＦＤ（Floppy Disk）、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu-ray（登録商標） Disk）などの光学ディスク、フラッシュメモリなどの着脱可能な記憶媒体２００に対してプログラムやデータを読み書きする読書装置４５を備えてもよい。
　読書装置４５は、ＦＤＤ（Floppy Disk Drive）、ＣＤＤ（Compact Disc Drive）、ＤＶＤＤ（Digital Versatile Disc Drive）、ＢＤＤ（Blu-ray（登録商標） Disk Drive）、ＵＳＢ（Universal Serial Bus）などである。
　ＣＰＵ４１、ＲＡＭ４２、ＨＤＤ４３、ネットワークＩ／Ｆ４４、読書装置４５は例えばバス１００２を介して接続されている。
　ＲＡＭ４２、ＨＤＤ４３、証明書管理サーバ４０の記憶部４０Ｂを構成する。
　また、図７（ｂ）に示すように、ＣＰＵ４１は、制御部４０Ａとして、更新要求処理部７１と、証明書管理処理部７２と、を実行する。
　これらの処理部は、証明書管理サーバ４０の制御部４０Ａの機能を実現するプログラムであり、当該プログラムは、ＨＤＤ４３に含まれるハードディスクや記憶媒体２００に格納され得る。プログラムは、ＨＤＤ４３や読書装置４５によってハードディスクや記憶媒体２００からＲＡＭ４２に読み出されてＣＰＵ４１によって実行される。
　また、ＨＤＤ４３等から構成される記憶部４０Ｂには、証明書発行サーバ２０によって発行された電子証明書の状態（有効または有効期限切れ）と有効期限とを管理する証明書管理データベース（ＤＢ）８１が格納されている。
　証明書管理ＤＢ８１は特定の外部装置（証明書管理端末１５等）に対して公開されて、電子証明書の有効期限を確認可能であることが望ましい。その場合、証明書管理サーバ４０は、外部装置に対して情報を公開するためのフロントエンドとしてのウェブページ処理部（所謂ウェブサーバ）を備えることが望ましい。
　更新要求処理部７１は、主に上記の証明書管理端末１５からの要求を受けて、特定の電子証明書の更新要求を証明書発行サーバ２０に対して行う処理部である。
　証明書管理処理部７２は、証明書発行サーバ２０によって発行された電子証明書の状態（有効、有効期限切れ）と有効期限を証明書管理ＤＢ８１に書き込み、またはデータベースの情報の参照を行うデータベース管理処理部である。
　図８は、図５に示した電子証明書格納処理の後の、電子証明書更新処理の流れを説明する図である。
　証明書管理端末１５等から登録された証明書管理情報に基づき、証明書管理サーバ４０は、ステップＳ３１において、証明書発行サーバ２０に対して、特定の電子証明書の更新を要求する。更新要求は、一つの電子証明書に対して行われてもよいし、有効期限切れが近い複数の電子証明書について一括して行われてもよい。
　ステップＳ３２において、証明書発行サーバ２０は、アクセストークンを用いて、鍵管理サーバ３０に対して証明書署名要求（ＣＳＲ）の要求を行う。
　証明書署名要求（ＣＳＲ）の要求を受けた鍵管理サーバ３０は、ステップＳ３３において、証明書署名要求（ＣＳＲ）を証明書発行サーバ２０に対して行う。
　証明書署名要求を受けた証明書発行サーバ２０は、ステップＳ３４において、電子証明書の発行を行い、ステップＳ３５で、例えば鍵管理サーバ３０に対してポストし、ステップＳ３６で、鍵管理サーバ３０はそれを受け入れる（ＨＳＭ１００に格納する）。
　鍵管理サーバ３０は、ポストされた電子証明書を私有鍵（秘密鍵）、公開鍵とともに管理する。
　ステップＳ３２で用いられるアクセストークンは、図５で説明した初回の電子証明書格納処理のステップＳ１０において、鍵管理サーバ３０から取得されたものである。
　鍵管理サーバ３０から取得されたアクセストークンを利用することで、電子証明書の更新にあたり端末装置１０による認可操作（図５のステップＳ１～Ｓ５）を繰り返す必要がなくなり、利用者の作業負担は著しく低減される。
　また、上記のように、鍵管理サーバ３０から取得されたアクセストークンは、端末装置１０の利用者自身の認証と管理のもとで発行されたものであり、適正な処理であることを保証される。
　図６について説明したように、証明書格納処理のステップＳ１０において鍵管理サーバ３０から取得されたアクセストークンは、リモート署名要求を鍵管理サーバ３０に送信する際に用いられるものであるが、これは電子証明書の更新時にも用いることが出来るということである。
　なお、通常アクセストークンには有効期限があり、それは電子証明書の有効期限よりも短いものである。電子証明書の更新時には、アクセストークンの有効期限が過ぎている可能性が高い。
　それに対し、特定の条件下で、例えば電子証明書の更新用途に限ってアクセストークンの有効期限を長く設定するなどすることで電子証明書の更新を確実に行うことが出来る。
　以上のように構成したことで、本実施形態のリモート署名システム１では、利用者は、初回の格納処理で認可操作（ステップＳ１における電子証明書発行ページへのアクセス、ステップＳ４における鍵管理サーバに対するログイン認証）を行った後は、電子証明書の鍵管理サーバ３０への格納と、格納された電子証明書の更新を、ほぼ完全に自動で行うことが出来る。
　なお、証明書発行サーバ２０による、初回格納時のアクセストークンを使った電子証明書の更新処理は、必ずしも証明書管理端末１５の要求に従った証明書管理サーバ４０による電子証明書の更新要求を契機に行われずともよい。
　例えばリモート署名処理時にサービスプロバイダが取得したアクセストークンや認証トークンを鍵管理サーバ３０へ登録するような仕組みを導入すれば、鍵管理サーバ３０はサービスプロバイダから取得したアクセストークンや認可コードを使って電子証明書の更新処理を行うことが可能となる。
　下記に説明する処理では、証明書管理端末１５の要求を受けた証明書管理サーバ４０が管理するプロセスによって、電子証明書の発行及び更新、鍵管理サーバ３０への格納を完全に自動化する。
　証明書発行サーバ２０、鍵管理サーバ３０、証明書管理サーバ４０は、いずれも図３、図４、図７と同じ構成を備え得るものとする。
　証明書発行サーバ２０が電子証明書の発行及び更新を行うために証明書署名要求（ＣＳＲ）を鍵管理サーバ３０に要求するにあたり、あるいは発行した電子証明書を鍵管理サーバ３０に格納するにあたり、アクセストークンが必要である。
　本発明では、電子証明書の発行、更新とは別手順で、証明書発行サーバ２０が利用可能なアクセストークンを発行する事前認可処理を行い、証明書発行サーバ２０が、発行されたアクセストークンを記憶部２０Ｂ（アクセストークン記憶部５５）に保持してもよい。
　証明書発行サーバ２０は、証明書管理端末１５の要求を受けた証明書管理サーバ４０の制御のもとアクセストークン記憶部５５に記憶されたアクセストークンを用いて電子証明書の発行及び更新を行うことができる。
　事前認可を行うことで、図５の処理で利用者が行っていた認可操作を必要とせず、電子証明書の新規発行時点から自動化を実現することが出来る。
　図９は、本実施形態のリモート署名システムにおける事前認可処理の流れを説明する図である。
　事前認可処理の一例として、端末装置１０の利用者が図５と同様の認可操作を行う。
　ステップＳ４１において、利用者が使用する端末装置１０（ウェブブラウザ）は、認証局（ＣＡ）の証明書発行サーバ２０にアクセスする。
　電子証明書発行ページのリクエストを受けた証明書発行サーバ２０は、ステップＳ４２において、利用者を鍵管理サーバ３０にリダイレクトするページを端末装置１０に供給する。
　利用者の操作によって、端末装置１０は、ステップＳ４３において、鍵管理サーバ３０に対して、認可要求の送信を行う（ＲＦＣ６７４９＃４．１．１．）。これは、シングルサインオンの仕組みにおいてユーザの認証を要求するための手続である。
　ステップＳ４４のユーザ認証処理において、鍵管理サーバ３０は、認証情報（例えば、ユーザＩＤとパスワード）の入力を利用者に要求する。また、当該の利用者のアカウントが未作成の場合には、鍵管理サーバ３０は、当該利用者のためのアカウントを新規に作成する処理を行う。
　なお、ステップＳ４４のユーザ認証処理において、認証情報の入力はＲＦＣ６７４９（ＯＡｕｔｈ２．０）で規定される処理とは異なり、鍵管理サーバ３０と端末装置１０との間で別途確立されるセッションにおいて行われる。
　認証の方法は、ユーザＩＤ及びパスワードの組み合わせを認証する形式のみならず、ＩＣカードに格納されたトークンが端末装置か１０から鍵管理サーバ３０に送付されることにより認証が行われる場合もある。
　ユーザの認証又はアカウントの作成が正常に行われると、鍵管理サーバ３０は、利用者の確認を得たうえで認可を確立し、ステップＳ４５において、認可応答として、認可コードを端末装置１０に送信する（ＲＦＣ６７４９＃４．１．２．）。
　なお、例えばこの段階で、ステップＳ４６において、端末装置１０（ウェブブラウザ）は、利用者が入力したKeyAlias（鍵に付す識別用の名前）とＰＩＮを鍵管理サーバ３０に送信する。
　それに対して、鍵管理サーバ３０は、ステップＳ４７において、利用者が入力したKeyAliasとＰＩＮに基づいて、ＨＳＭ（Hardware Security Module）１００に私有鍵（秘密鍵）と公開鍵のペアを生成させ、ＨＳＭ１００に格納させる。
　なお実際には、鍵ペアの生成は、後述する公開鍵を含む証明書署名要求（ＣＳＲ）の送信時までに行われていればよい。
　鍵管理サーバ３０から送信された認可コードを受信した端末装置１０（ウェブブラウザ）は、ステップＳ４８において、認可コードを証明書発行サーバ２０に転送（Redirect）する。
　端末装置１０から転送された認可コードを取得した証明書発行サーバ２０は、ステップＳ４９において、この認可コードを用いて、アクセストークン要求を鍵管理サーバ３０に対して行う（ＲＦＣ６７４９＃４．１．３．）。
　アクセストークン要求を受けつけた鍵管理サーバ３０は、ステップＳ５０において、アクセストークン応答を証明書発行サーバ２０に返す。
　すなわち、鍵管理サーバ３０は、アクセストークンを証明書発行サーバ２０に送信する（ＲＦＣ６７４９＃４．１．４．）。
　証明書発行サーバ２０は、ステップＳ５１において、受信したアクセストークンを記憶部２０Ｂのアクセストークン記憶部５５に格納し、証明書管理サーバ４０からの証明書発行要求と、それに対する証明書発行処理に備える。
　図１０は、図９に示した事前認可処理のあとにおける電子証明書発行、更新処理の流れを説明する図である。
　図９の事前認可処理によってアクセストークンの発行が済んでいるため、証明書管理サーバ４０を起点として電子証明書の発行処理を実行することができる。
　証明書管理端末１５等からの登録情報に基づき、証明書管理サーバ４０は、ステップＳ６１において、証明書発行サーバ２０に対して電子証明書の発行要求を行う。
　証明書発行サーバ２０は、ステップＳ６２において、図９の処理で記憶部２０Ｂに格納しておいたアクセストークンを用いて、鍵管理サーバ３０に対して証明書署名要求（ＣＳＲ）の要求を行う。
　証明書署名要求（ＣＳＲ）の要求を受けた鍵管理サーバ３０は、ステップＳ６３において、証明書署名要求（ＣＳＲ）を証明書発行サーバ２０に対して送付する。
　証明書署名要求を受けた証明書発行サーバ２０は、ステップＳ６４において、電子証明書の発行を行い、ステップＳ６５で、例えば鍵管理サーバ３０に対してポストし、ステップＳ６６で、鍵管理サーバ３０はそれを受け入れる（ＨＳＭ１００に格納する）。
　鍵管理サーバ３０は、ポストされた電子証明書を私有鍵（秘密鍵）、公開鍵とともに管理する。
　証明書発行サーバ２０は、記憶部２０Ｂに格納しておいたアクセストークンを用いて、図６に示す署名要求送信を行うことが出来る。
　次に、発行済み電子証明書の更新タイミングにおいて証明書管理端末１５等からの登録情報に基づき、証明書管理サーバ４０は、ステップＳ７１において、証明書発行サーバ２０に対して、特定の電子証明書の更新要求を行う。更新要求は、一つの電子証明書に対して行われてもよいし、有効期限切れが近い複数の電子証明書について一括して行われてもよい。
　ステップＳ７２において、証明書発行サーバ２０は、記憶部２０Ｂに格納しているアクセストークンを用いて、鍵管理サーバ３０に対して証明書署名要求（ＣＳＲ）の要求を行う。
　証明書署名要求（ＣＳＲ）の要求を受けた鍵管理サーバ３０は、ステップＳ７３において、証明書署名要求（ＣＳＲ）を証明書発行サーバ２０に対して送付する。
　証明書署名要求を受けた証明書発行サーバ２０は、ステップＳ７４において、電子証明書の発行を行い、ステップＳ７５で、例えば鍵管理サーバ３０に対してポストし、ステップＳ７６で、鍵管理サーバ３０はそれを受け入れる（ＨＳＭ１００に格納する）。
　鍵管理サーバ３０は、ポストされた電子証明書を私有鍵（秘密鍵）、公開鍵とともに管理する。
　上記のように、ステップＳ６２、ステップＳ７２で用いられるアクセストークンは、図９の事前認可処理において鍵管理サーバ３０から取得して記憶部２０Ｂに格納しておいたものである。
　一度、事前認可処理によってアクセストークンを発行しておけば、証明書管理端末１５と証明書管理サーバ４０の制御によって電子証明書の発行、更新を自動的に行うことができるため、利用者の作業負担は著しく低減される。
　鍵管理サーバ３０から取得されたアクセストークンは、端末装置１０の利用者自身の認証と管理のもとで発行されたものであり、適正な処理であることが保証される。
　なお通常、アクセストークンには有効期限がある。図９の事前認可処理後、図１０における電子証明書の発行または更新時には有効期限が過ぎている可能性が高い。
　それに対し、特定の条件下で、例えば電子証明書の発行、更新用途に限ってアクセストークンの有効期限を長く設定するなどすることで、電子証明書の発行、更新を確実に行うことが出来る。端末装置１０の利用者に対して再び図９の事前認可操作を行わせる必要もなく好適である。
　アクセストークンの有効期限を長く設定することでセキュリティ上の懸念が生じる場合には、有効期限を長く設定することに替えてリフレッシュトークン（Refresh token）を用いる方法がある。
　OAuth2.0において、リフレッシュトークンはアクセストークンとともに発行されるものである。
　アクセストークンの有効期限が過ぎてしまった場合は、証明書発行サーバ２０がリフレッシュトークンを鍵管理サーバ３０に送信すると、鍵管理サーバ３０は、新たなアクセストークンとリフレッシュトークンを発行し、証明書発行サーバ２０に送付する。
　証明書発行サーバ２０は、新たに発行されたアクセストークンを用いて、電子証明書の発行及び更新や、図６に示す署名要求送信を行うことが出来る。
　その後、新たなアクセストークンについても有効期限が過ぎてしまった場合には、リフレッシュトークンを鍵管理サーバ３０に提示することで、証明書発行サーバ２０新たなアクセストークンを取得することが出来る。
　リフレッシュトークンを用いることで、アクセストークンの有効期限を安全な長さに保つことができる。
　従って端末装置１０の利用者は、図９の事前認可操作以降電子証明書の発行及び更新に関して全く意識することがなく、鍵管理サーバ３０に格納された電子証明書を用いてリモート署名を実行することが出来る。
　なお、図１０に示す、証明書管理サーバ４０が電子証明書の発行、更新処理に用いるアクセストークンは、必ずしも図９に示した事前認可処理によって発行されずともよい。
　電子証明書の発行、更新処理に用いるアクセストークンは、図９のような認可処理を伴わず、鍵管理サーバ３０によって独自に発行されて、証明書発行サーバ２０に対して送信されてもよい。
　なお、上記では、端末装置１０と、証明書発行システム（証明書発行サーバ２０）と、鍵管理システム３（鍵管理サーバ３０）と、がそれぞれ一つずつ含まれるシステムを説明した。
　それに限らず、本実施形態のリモート署名システム１は、複数の端末装置１０、複数の証明書発行システム２０、複数の鍵管理システム３０によって構成されることが出来る。
　１または複数の端末装置１０の利用者は、上記に説明した機能を有する複数の証明書発行システム（認証局）の中から、任意の証明書発行システム２０を選択し、その証明書発行ページにアクセスすることが出来る。
　また、一の証明書発行システム２０は、上記に説明した機能を有する複数の鍵管理システム３０を信頼し、上記の手順に従って、各鍵管理システムで発行された公開鍵について電子証明書を発行して登録する処理を行う。
　各証明書発行システムは、利用者をリダイレクト可能な鍵管理システムが複数ある場合、例えば、証明書発行ページに、利用可能な鍵管理システムのリストを表示し、その中から、利用する鍵管理システムを利用者に選択させることが出来る。
　なお、上記の特許文献１（特開２０１０－２００１４２公報）には、ユーザ端末、電子署名サーバ、認証局と、を備えたシステムが開示されている。
　この特許文献１においては、認証局が秘密鍵、公開鍵の鍵ペアを生成する。そして、電子署名サーバは、認証局に対して公開鍵に基づく電子証明書の発行を要求する。認証局は、発行した電子証明書と秘密鍵をＰＫＣＳ＃１２と呼ばれる形式のファイルに格納し、電子署名サーバに供給する。
　そして、電子署名サーバは、ユーザ端末からの求めに応じて、電子証明書、秘密鍵を用いて電子署名を行う。
　このように、特許文献１では認証局が鍵ペアを生成し、電子署名サーバは、認証局と直接的なやりとりによって証明書署名要求を行い、かつ生成された証明書と秘密鍵も、電子署名サーバと認証局の直接的なやりとりによって行われる。その間の通信において、利用者が介在する余地はない。
　それに対し本実施形態では、認証局（証明書発行システム）と、鍵管理サーバとの間に、利用者の端末装置が介在し、OAuth2.0（ＲＦＣ６７４９）の仕組みを用いて利用者が鍵管理サーバに対する認証を行い、その結果払い出されるアクセストークンを用いて、認証局（証明書発行システム）と鍵管理サーバとの間で電子証明書の授受が行われる。
　本実施形態において、私有鍵（秘密鍵）は、そもそも鍵管理サーバで生成されるものであり、認証局と鍵管理サーバとの間で授受されるものではない。
　本実施形態では、利用者による鍵管理サーバに対する認証を契機に証明書署名要求、電子証明書のやり取りが行われるため、従来の方法に比べ、より安全に電子証明書の発行が可能である。また、私有鍵（秘密鍵）は、鍵管理システムで生成された後、他のサーバや端末に送信されることがないため、外部に漏れるリスクが低く、より安全な電子署名システムの運用が可能となる。
［第１の態様］
　本実施形態に係る第１の態様は、電子証明書を発行する証明書発行システム２と、利用者の秘密鍵を管理する機能を有し、秘密鍵を用いて電子署名を生成する鍵管理システム３と、を備える電子署名システムであって、鍵管理システム３は、アクセストークンを電子証明書発行システム２に送信し、証明書発行システム２は、アクセストークンを鍵管理システム３に提示することによって、鍵管理システム３から利用者の公開鍵を含む証明書発行要求を取得し、公開鍵に対して電子証明書を発行する電子署名システム１を特徴とする。
　第１の態様の電子署名システムでは、リモート署名で求められる電子証明書の発行に際し、公開鍵を含む証明書署名要求及び電子証明書の発行が、アクセストークンを介して、認証局（証明書発行システム２）と信頼された署名サービス（鍵管理システム３）との間で自動的に行われる。
　これにより、利用者の負担を軽減しながら電子証明書の安全な発行が可能な電子署名システムを実現することが出来る。
［第２の態様］
　本実施形態に係る第２の態様は、電子証明書を発行する証明書発行システムであって、所定のアクセストークンを用いて、利用者の公開鍵を含む証明書発行要求を鍵管理システムに要求する要求手段（署名リクエスト要求処理部５３）と、要求手段による要求に応じて取得した証明書発行要求に含まれる公開鍵に対して電子証明書を発行する発行手段（電子証明書発行処理部５４）と、を備える証明書発行システムを特徴とする。
　第２の態様の証明書発行システムは、リモート署名で求められる電子証明書の発行に際し、信頼された署名サービス（鍵管理システム３）に対する公開鍵を含む証明書署名要求の要求及び電子証明書の発行を、アクセストークンを介して自動的に行うことが出来る。これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。
［第３の態様］
　本実施形態に係る第３の態様は、利用者の秘密鍵を管理する機能を有し、秘密鍵を用いて電子署名を生成する鍵管理システムであって、利用者の公開鍵を少なくとも生成する鍵生成手段（鍵生成処理部６３）と、アクセストークンを送信した証明書発行システムに対し、公開鍵を含む証明書発行要求を送信し、証明書発行システムに電子証明書を発行させる署名要求手段（署名要求処理部６４）と、を備える鍵管理システムを特徴とする。
　第３の態様の鍵管理システムは、リモート署名で求められる電子証明書の発行に際し、証明書発行システムに対して公開鍵を含む証明書署名要求を、アクセストークンを介して自動で行い、電子証明書の発行を行わせることが出来る。
　これにより、利用者の負担を軽減しながら電子証明書の発行を安全に行うことが出来る。
１　リモート署名システム、１０　端末装置、２０　証明書発行サーバ、２１　ＣＰＵ、２２　ＲＡＭ、２３　ＨＤＤ、２４　ネットワークＩ／Ｆ、３０　鍵管理サーバ、３１　ＣＰＵ、３２　ＲＡＭ、３３　ＨＤＤ、３４　ネットワークＩ／Ｆ、５１　ウェブページ処理部、５２　ＯＡｕｔｈ実行処理部、５３　署名リクエスト要求処理部、５４　電子証明書発行処理部、６１　ユーザ認証処理部、６２　ＯＡｕｔｈ実行処理部、６３　鍵生成処理部、６４　署名要求処理部、６５　証明書格納処理部

Claims (5)

  1. 　電子証明書を発行する証明書発行システムと、
    　利用者の秘密鍵を管理する機能を有し、前記秘密鍵を用いて電子署名を生成する鍵管理システムと、を備え、
    　前記証明書発行システムは、所定のアクセストークンを前記鍵管理システムに提示することによって、前記鍵管理システムから前記利用者の公開鍵を含む証明書発行要求を取得し、前記公開鍵に対して電子証明書を発行することを特徴とする電子署名システム。
  2. 　電子証明書を発行する証明書発行システムであって、
    　所定のアクセストークンを用いて、利用者の公開鍵を含む証明書発行要求を鍵管理システムに要求する要求手段と、
    　前記要求手段による要求に応じて取得した前記証明書発行要求に含まれる前記公開鍵に対して電子証明書を発行する発行手段と、
    を備えることを特徴とする証明書発行システム。
  3. 　利用者の秘密鍵を管理する機能を有し、前記秘密鍵を用いて電子署名を生成する鍵管理システムであって、
    　利用者の公開鍵を少なくとも生成する鍵生成手段と、
    　所定のアクセストークンを送信した証明書発行システムに対し、前記公開鍵を含む証明書発行要求を送信し、前記証明書発行システムに電子証明書を発行させる署名要求手段と、を備えることを特徴とする鍵管理システム。
  4. 　要求手段と、発行手段と、を備え、電子証明書を発行する証明書発行システムの証明書発行方法であって、
    　前記要求手段が、所定のアクセストークンを用いて、利用者の公開鍵を含む証明書発行要求を鍵管理システムに要求するステップと、
    　前記要求手段による要求に応じて取得した前記証明書発行要求に含まれる前記公開鍵に対して電子証明書を発行するステップと、
    を備えることを特徴とする証明書発行方法。
  5. 　請求項４に記載の証明書発行方法をコンピュータに実行させるプログラム。
PCT/JP2019/028492 2018-07-20 2019-07-19 電子署名システム、証明書発行システム、鍵管理システム、証明書発行方法及びプログラム WO2020017643A1 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2018136657A JP6465426B1 (ja) 2018-07-20 2018-07-20 電子署名システム、証明書発行システム、鍵管理システム及び電子証明書発行方法
JP2018-136657 2018-07-20
JP2019007592A JP6571890B1 (ja) 2019-01-21 2019-01-21 電子署名システム、証明書発行システム、証明書発行方法及びプログラム
JP2019-007592 2019-01-21

Publications (1)

Publication Number Publication Date
WO2020017643A1 true WO2020017643A1 (ja) 2020-01-23

Family

ID=69164925

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/028492 WO2020017643A1 (ja) 2018-07-20 2019-07-19 電子署名システム、証明書発行システム、鍵管理システム、証明書発行方法及びプログラム

Country Status (1)

Country Link
WO (1) WO2020017643A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017175226A (ja) * 2016-03-18 2017-09-28 株式会社インテック 公開鍵証明書を発行するためのプログラム、方法およびシステム
US20180048638A1 (en) * 2016-08-11 2018-02-15 Motorola Solutions, Inc Method for obtaining vetted certificates by microservices in elastic cloud environments

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017175226A (ja) * 2016-03-18 2017-09-28 株式会社インテック 公開鍵証明書を発行するためのプログラム、方法およびシステム
US20180048638A1 (en) * 2016-08-11 2018-02-15 Motorola Solutions, Inc Method for obtaining vetted certificates by microservices in elastic cloud environments

Similar Documents

Publication Publication Date Title
US10567370B2 (en) Certificate authority
US10630489B2 (en) Apparatus and method for managing digital certificates
WO2020143470A1 (zh) 发放数字证书的方法、数字证书颁发中心和介质
US8788811B2 (en) Server-side key generation for non-token clients
JP4863777B2 (ja) 通信処理方法及びコンピュータ・システム
US9137017B2 (en) Key recovery mechanism
JP6571890B1 (ja) 電子署名システム、証明書発行システム、証明書発行方法及びプログラム
US20120295587A1 (en) Trusted mobile device based security
US20030177351A1 (en) System and method for single session sign-on with cryptography
US20110296171A1 (en) Key recovery mechanism
TW200833060A (en) Authentication delegation based on re-verification of cryptographic evidence
JP2006060779A (ja) 証明書送信装置、通信システム、証明書送信方法、プログラム及び記録媒体
JP6609788B1 (ja) 情報通信機器、情報通信機器用認証プログラム及び認証方法
US10263789B1 (en) Auto-generation of security certificate
US11777743B2 (en) Method for securely providing a personalized electronic identity on a terminal
JP5992535B2 (ja) 無線ｉｄプロビジョニングを実行するための装置及び方法
JP6465426B1 (ja) 電子署名システム、証明書発行システム、鍵管理システム及び電子証明書発行方法
JP4332071B2 (ja) クライアント端末、ゲートウエイ装置、及びこれらを備えたネットワークシステム
CN114760070A (zh) 数字证书颁发方法、数字证书颁发中心和可读存储介质
JP2012181662A (ja) アカウント情報連携システム
CN112235276B (zh) 主从设备交互方法、装置、系统、电子设备和计算机介质
JP2009212689A (ja) 共通鍵自動配布システム、クライアント、第三者認証機関側サーバ、及び共通鍵自動共有方法
JP2008129673A (ja) ユーザ認証システム、ユーザ認証方法、それに用いるゲートウェイ及びプログラムとその記録媒体
WO2020017643A1 (ja) 電子署名システム、証明書発行システム、鍵管理システム、証明書発行方法及びプログラム
TWI698113B (zh) 電子裝置之認證方法及系統

Legal Events

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

Ref document number: 19838342

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19838342

Country of ref document: EP

Kind code of ref document: A1