JP2020120173A - Electronic signature system, certificate issuing system, certificate issuing method, and program - Google Patents

Abstract

To provide a digital signature system that can reduce the burden on a user and securely issue and register a digital certificate.SOLUTION: A terminal device 10 makes an authentication request to a key management server 30, the key management server 30 sends an authorization code to the terminal device 10 when the authentication is successfully performed, the terminal device 10 sends the authorization code to a certificate issuing server 20, the certificate issuing server 20 sends the authorization code sent from the terminal device 10 to the key management server 30, the key management server 30 issues, to the certificate issuing server 20, an access token in exchange for the authorization code, the certificate issuance server 20 presents the access token to the key management server 30, and then obtains a certificate signing request from the key management server 30, and issues a digital certificate for a public key described in the certificate signing request.SELECTED DRAWING: Figure 5

Description

The present invention relates to a digital signature system and a digital certificate issuing method, and more particularly, to a method for issuing a digital certificate used with a digital signature required in a public key infrastructure.

Electronic governments have begun to operate worldwide, and contracts, which were traditionally done with paper, are now being done electronically. In electronic contracts (electronic contracts), methods using encryption technology and public key infrastructure are the mainstream.
In an electronic contract using a public key infrastructure, based on the public key cryptosystem, the sender of the document adds a digital signature to the contract document (electronic data) using the private key (private key) of the person, and On the receiving side, by verifying the electronic signature given to the contract document by using the public key of the sending side, it is possible to judge whether the transaction is fake or falsified on the communication path. As will be described later, the public key infrastructure can provide various security systems using a public key and a private key (secret key) paired with the public key.
In this method, the public key of the other party (sender) who digitally signed the contract is required at the time of verifying the contract document. Then, in order to prove that the private key paired with this public key is related to possession of the sender (identity of the public key), a public key certificate, so-called "electronic certificate" is used.

An "electronic certificate" is also called an ID card on the Internet and is issued by a trusted third party (TTP). In particular, TTP that issues a digital certificate is called a certificate authority.
Conventionally, it has been general that an electronic signature is made on a user's PC (Personal Computer), but there is also known a mechanism for improving the convenience of the electronic signature by making it on a server.
For example, Patent Document 1 discloses a system including a user terminal, a digital signature server, and a certificate authority.
In Patent Document 1, a certificate authority generates a key pair of a private key and a public key. Then, the digital signature server requests the certificate authority to issue a digital certificate based on the public key. The certificate authority supplies the issued digital certificate and private key to the digital signature server as a file called PKCS#12, and the digital signature server uses the digital certificate and private key in response to a request from the user terminal. Electronic signature.

Furthermore, in recent years, a mechanism called "remote signature" or "cloud signature" has become widespread, and standardization of the protocol has been started by the standardization organizations CSC (Cloud Signature Consortium) such as eIDAS in Europe and Adobe. It is being pushed forward.
More specifically, when a digital signature site requires a digital signature, the user is redirected to the key management system by using the SSO (Single Sign On) mechanism based on OAuth2.0. Implements as a "remote signature" such as issuing a token after user authentication, and the electronic signature site that has obtained the token presents the token to the key management system to sign the key management system. Is being started.

JP, 2010-200142, A

However, in order to perform such a "remote signature", the user creates an account in the key management system in advance, generates a private key (private key) in the key management system, and creates a private key for the private key. It is necessary to prepare to bind the digital certificate issued by the certificate authority.
In this preparatory work, the user acquires (downloads) the public key generated with the private key (private key) in the key management system from the key management system in order to have the certificate authority issue the digital certificate, and then downloads the public key. It was necessary to make a key signing request (certificate signing request) including "" to the certificate authority.

Furthermore, the user must store the issued digital certificate in the key management system.
Such work is complicated for the user and imposes a technical burden. Further, if the user is made to perform such a preparatory work, the selection of the key management system is left to the user, and it is difficult for the certificate authority side to control the security level of the key management system.
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 while reducing a user's burden. The purpose is to provide a possible electronic signature system.

In order to solve the above problems, the present invention has a certificate issuing system for issuing a digital certificate and a function for managing a user's private key, and a key for generating an electronic signature using the private key. A management system, wherein the certificate issuing system obtains a certificate issuance request including the public key of the user from the key management system by presenting a predetermined access token to the key management system, A digital signature system for issuing a digital certificate to the public key is featured.

With the above configuration, according to the present invention, the process of issuing the electronic certificate required for the electronic signature and storing it in the key management system can be executed more safely while reducing the burden on the user. It is possible to realize various digital signature systems.

It is a reference diagram explaining the processing of OAuth2.0. It is a figure explaining the system configuration of this embodiment. It is a figure which shows the structure of the certificate issuing server of this embodiment. It is a figure which shows the structure of the key management server of this embodiment. It is a figure explaining the flow of the electronic certificate storage process in the remote signature system of this embodiment. FIG. 6 is a diagram illustrating a flow of remote signature processing after the electronic certificate storage processing shown in FIG. 5. It is a figure which shows the structure of the certificate management server 40 of this embodiment. It is a figure explaining the flow of the electronic certificate update process after the electronic certificate storage process shown in FIG.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
First, prior to the description of the present embodiment, a technology as a premise will be described.
[Public key infrastructure]
A public key infrastructure (PKI) is an information security infrastructure that provides security functions such as encryption, digital signature (electronic signature), and authentication by using an encryption method called public key encryption method.
The public key infrastructure utilizes the features of public key cryptography, and provides the functions such as encryption, digital signature, and authentication described above. In the public key cryptosystem, one-way property of the private key and the public key (a feature that the public key can be calculated from the private key, but it is difficult to calculate the private key from the public key) is used. Provides various functions. The user keeps his/her private key secretly and discloses the public key to others. The private key is also referred to as a private key because it has the meaning of being kept secret.
For example, when the user B sends a document to the user A, the user B obtains the public key made public by the user A, and sends the document encrypted by the public key to the user A. The user A decrypts the received encrypted document using his/her own private key (secret key).
Anyone who has the public key of user A can send an encrypted document to user A, while the one encrypted with user A's public key is privately owned by user A. Since it can be decrypted only with the key (private 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.

[Digital certificate]
To communicate using public key cryptography, you need to send the public key to the other party, but since you cannot see the other party when communicating via the network, a third party impersonates the other party and sends the public key. there's a possibility that. Therefore, it is necessary to confirm whether the public key is really sent from the correct party.
In PKI, for example, a trusted third party (TTP) guarantees the owner of the private key. That is, the TTP confirms the identity of the owner of the private key (secret key), and associates the public key paired with the private key (secret key) with the owner of the private key (secret key). Issue a (public key certificate). A digital certificate is an "identity certificate" that correctly guarantees the owner's information.
The TTP that issues an electronic certificate is particularly called a certification authority or 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, and the email address. An electronic signature of TTP is added to prevent falsification of the certificate itself. By attaching a digital certificate to a document, the risk of spoofing or falsification can be prevented. The owner of a private key (secret key) trusted by TTP is called a subscriber.

[Electronic signature]
Digital certificates are also used for verifying digital signatures. Usually, an electronic certificate is attached to the electronic signature. The user who receives the digital signature verifies the signature by using the public key written in the digital certificate, detects data tampering, and identifies the signer by using the content written in the digital certificate. You can
A digital signature includes a value obtained by encrypting the hash value of a document with a private key (private key). (Actually, the encryption process and the signature process are different, but the signature process is called broadly-defined encryption. There are many). When the user A sends a document file with an electronic signature to the user B, the user A uses the hash value obtained by multiplying the document file to be transmitted by a hash function as the private key of the user A (secret. Encrypt with a key), create a digital signature, and attach it to the document file.
The user B receiving the document file with the digital signature uses the hash value obtained by decrypting the encrypted value included in the digital signature using the public key of the user A and the hash function of the document file. The hash value obtained by multiplying by is compared. As a result of the comparison, if both 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 (server). Along with this, a digital signature of a method called “remote signature (cloud signature)” in which a document is digitally signed not on a signer's PC (Personal Computer) but on a server (cloud) is becoming popular.
More specifically, the remote signature is an electronic certificate of a signer or a private key (private key) managed by a key management system. When a digital signature is required, the digital certificate and private key (secret key) are managed on the key management system. This is a mechanism for executing an electronic signature using a key.

Remote signature has the advantage that the signer does not have to manage the private key (private key) himself. Furthermore, not only a PC but also a mobile device such as a web browser or a smart phone can electronically sign a document. Therefore, as compared with the generation of an electronic signature at an endpoint using a smart card storing a private key (secret key) or a USB token, the convenience is significantly improved. Further, since the private key (private key) is robustly protected by the key management system, it can be said that it is a more desirable signature method from the viewpoint of security.

As described above, in the signature system that provides the remote signature service, the signer's private key (private key) and the electronic certificate associated with the private key are required to perform the signature.
As explained below, the key pair of the private key (private key) and public key is generated by the key management system, but the digital certificate is an authentication that guarantees the identity of the owner of the private key (private key). It is issued by the station, and for the reasons described above, it is necessary to appropriately import the issued digital certificate into the key management system.
Importing a digital certificate is a preparatory work for performing a remote signature in the signature system.

Currently, as such a preparatory action, the user (signer) himself must import (store) the digital certificate generated by the CA based on the public key generated by the key management system into the key management system. The following procedure was required.
That is,
(1) A 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 terminal device, and the key management system generates a key pair.
(3) The user logs in to the key management system using his/her own terminal device, causes the key management system to generate a certificate signing request (CSR), and downloads it. The certificate signing request is also called a certificate issuing request.
(4) The user uses his or her own terminal device to send the certificate signature request (CSR) acquired in (3) to the certificate authority.
(5) The certificate authority issues an electronic certificate based on the certificate signing request (CSR) and sends it to the user.
(6) The user logs in to the key management system and imports the electronic certificate sent in (5) into the key management system.

In such a preparatory work, there are many tasks and procedures to be performed by the user, and technical knowledge is also required, so that there is a problem that the user is burdened.
Also, from the viewpoint of the certificate authority, as a result of having the user perform the preparatory work, it is left to the user to select the key management system, and it is difficult for the certificate authority to control the security level of the key management system. There was a problem.

Of course, the certificate authority itself is a trusted third party, but some key management systems are not always reliable. The reliability of the key management system is whether or not the private key (secret key) is managed by an appropriate method. In remote signature, it is required to securely manage a private key (private key) and an electronic certificate by a device called HSM (Hardware Security Module) described later. There is a security risk in that the user selects and uses a key management system that does not meet such requirements.

Therefore, in this embodiment, the certificate authority registers a key management system capable of ensuring reliability. Then, by using the SSO (Single Sign On) mechanism 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, so that the user It is possible to allow users to use a highly reliable key management system while reducing the burden on users.

OAuth 2.0 defined in RFC6749 is a mechanism that allows a client 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 or not the client can access the protected resource held by the resource server.
Information called an access token is required to access the protected resource, and the authorization server issues an access token to the client to which the access is permitted.

In addition to the above, a user agent (eg, web browser) may intervene in access. In that case, the user agent mediates the authentication of the resource owner in the authorization server and the sending of the authorization code from the authorization server to the client. The authorization code is also called an authorization token.

FIG. 1 is a reference diagram illustrating a process of OAuth 2.0 in which a user agent intervenes.
The reference diagram of FIG. 1 is a diagram disclosed in RFC6749.
With reference to FIG. 1, the certificate issuing server, the key management system, and the terminal device as the certificate authority, which constitute the present embodiment, are associated with each entity defined in OAuth2.0, and The process of OAuth2.0 is explained.
The certificate issuing system of the present embodiment corresponds to the “client”, and the web browser (described later) executed by the terminal device of the present embodiment corresponds to the “user agent”. Further, the key management system of the present embodiment corresponds to the “authorization server”, and the user of the terminal device corresponds to the “resource owner”.

In FIG. 1A, the client (certificate issuing server) sends the ID information of the client to the authorization server (key management system) via the user agent (web browser of the terminal device) (RFC6749#4.1). (1. Authorization request), (B), the authorization server (key management system) authenticates and authorizes the resource owner (user) via the user agent (web browser).
In (C), when the authorization server (key management system) permits access to the resource, the authorization server (key management system) authorizes the client (certificate issuing server) via the user agent (web browser). Issue a code (Authorization code) (RFC6749#4.1.2. Authorization response).
In (D), the client (certificate issuing server) requests an access token (Access token) from the authorization server (key management system) by presenting an authorization code (RFC6749#4. 1.3. Access token request).
In (E), the authorization server (key management system) issues an access token (Access token) to the client (certificate issuing server) if the presented authorization code is successfully verified (RFC6749#). 4.1.4.Access token response).

In this embodiment, the user is made to access the electronic certificate issuing page of the certificate authority (certificate issuing system). Then, the certificate authority transfers the user to a key management system that is determined to be reliable in advance and logs in to the key management system (authorization request in FIG. 1A).

If the user successfully authenticates the login to the key management system, the authorization code (Authorization code) of the key management system is sent to the user (web browser of the terminal device), and this authorization code (Authorization code) , And is transferred to the certificate authority (certificate issuing system) (authorization response in FIG. 1C).
The certificate authority (certificate issuing system) uses this authorization code to make an access token request to the key management system (access token request in FIG. 1D).
The certificate authority (certificate issuing system) is given an access token by the key management system (access token response in FIG. 1E).

Further, as a feature of this embodiment, the certificate authority (certificate issuing system) uses the access token to make a certificate signing request (CSR) request to the key management system, The electronic certificate is issued by receiving the certificate signing request (CSR) from the.
According to such a system of the present embodiment, the certificate authority (certificate issuing system) makes a certificate signing request (CSR) request 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, transmitted to the key management system, and imported.

The system of this embodiment and its processing will be described in more detail below.
FIG. 2 is a diagram for explaining the system configuration of this embodiment.
As shown in FIG. 2, the remote signature system 1 according to the present embodiment includes a terminal device 10 used 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 signature issued by the certificate issuing server 20 to provide a remote signature service. And a certificate management system 4 for managing the expiration date of the electronic certificate issued by the certificate issuing server 20 and managed by the key management server 30.

The terminal device 10, the certificate issuing system 2, the key management system 3, and the certificate management system 4 are all connected to the Internet so that they can communicate with each other.
The types of data exchanged between these devices and systems are mainly transmitted and received as parameters of HTTP requests and HTTP responses (using the HTTP protocol), but the communication itself is protected to ensure security. By convention (eg, utilizing HTTPS).

As described above, the certificate issuing system 2 corresponds to the client in the above OAuth,
A web browser executed by the terminal device 10 corresponds to a user agent. The key management system 3 corresponds to the authorization server, and 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 above-described OAuth-compliant processing. It is configured.

The terminal device 10 is a general PC or smartphone capable of executing a web browser (user agent).
The web browser executed by the CPU of the terminal device 10 is a page requesting unit that requests an electronic certificate issuing page provided by the certificate issuing system 20, a page displaying unit that displays a transfer page received from the certificate issuing server 20, and the like. , An OAuth execution means for transmitting an authorization request to the key management server 30 and receiving an authorization response including an authorization code, and receiving the input of KeyAlias and PIN to the key management server 30. It functions as key information transmitting means for transmitting, authorization code transmitting means for performing processing such as transfer of the authorization code (Authorization code) received from the key management server 30 to the certificate issuing server 20, and the like.

The certificate issuing server 20 belongs to a certificate authority that issues electronic certificates. As described above, 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).
In addition to the certificate issuing server 20, the certificate issuing system 2 may further include a web server that receives a request from a user's web browser and supplies the data of the electronic certificate issuing page to the terminal device 10. Further, the function of the web server may be included 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 it to a request source.
The key management system 3 of this embodiment includes, for example, a key management server 30 and a hardware security module (HSM: Hardware Security Module) 100.
The HSM100 generates a pair of the user's private key (private key) and public key, imports and manages the user's digital certificate issued by the certificate authority, and uses the private key (private key). This is a device for generating a digital signature.

In the system of the present embodiment, the HSM 100 is incorporated in the key management server 30 in a manner connected to the internal bus of the key management server 30, for example. Further, the HSM 100 may be connected to an external bus (USB bus or the like) of the key management server.
Further, the HSM 100 may include a network interface so that the HSM 100 alone can be connected to the network. The HSM 100 is communicably connected to the key management server 30 in the same local network or remote network as the key management server 30.
In that case, the key management server 30 commands the HSM 100 to generate a key pair in response to a request from the terminal device 10 via the network, and sends the electronic certificate transmitted from the certificate issuing server 20 (certificate authority) to the HSM 100. To import.

As described in the above description of OAuth, in the system 1 shown in FIG. 2, the user (the web browser executed by the terminal device 10) redirected by the certificate issuing server 20 authenticates to the key management server 30. When the authentication is successful and the authentication is successful, the key management server 30 sends an authorization code to the terminal device 10 (web browser).
It should be noted that whether or not to request the key management server 30 for authentication and whether or not to establish authorization even if the authentication is successful can be determined at the discretion of the user himself. On the dialog screen for confirming the approval/disapproval of the authentication request displayed on the redirect screen, the user can select whether the authentication request is acceptable or not. Alternatively, after successful authentication, the user can select whether to establish authentication on the 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 (Authorization code) sent from the terminal device 10 (web browser) to the key management server 30, and the key management server 30 accesses in exchange for the authorization code (Authorization code). The token (Access token) is sent to the certificate issuing server 20.
The certificate issuing server 20 presents the access token to the key management server 30, so that the certificate issuing server 20 can obtain the certificate signature request (CSR) from the key management server 30. Then, the certificate issuing server 20 issues an electronic certificate to the public key described in the certificate signing request (CSR).

If the user's account does not exist in the key management server 30 when the user requests the key management server 30 for authentication, 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 an 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, preferably before the expiration.
The certificate management server 40 manages the expiration date of the electronic certificate issued by the certificate issuing server 20, and issues an instruction for updating an electronic certificate that is about to expire or an arbitrary electronic certificate. This can be done for the 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 management device that manages the terminal device 10.

The update processing of the electronic certificate related to the certificate management system 4 (certificate management server 40) will be described in detail later.
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.

3A and 3B are diagrams showing a configuration of the certificate issuing server of the present embodiment, FIG. 3A is a diagram showing a functional configuration by hardware, and FIG. 3B is a diagram showing a functional configuration by software.
As shown in FIG. 3A, the certificate issuing server 20 executes a general-purpose operating system that controls the entire apparatus, and a CPU (Central Processing) that executes a program that realizes 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 expanded for processing by the CPU 21, an HDD (Hard Disk Drive) 23 in which programs and data are stored, and a not-shown A ROM (Read Only Memory) and a network I/F 24 for connecting the certificate issuing server 20 to the network are provided.

Further, as shown in FIG. 3B, the CPU 21 executes a web page processing unit 51, an OAuth execution processing unit 52, a signature request request processing unit 53, and a digital certificate issuance processing unit 54.
The web page processing unit 51 functions as a so-called web server, and transmits the data of the electronic certificate issuance page from the data of the web page (HTML page) stored in the HDD 23 in response to the HTTP request from the terminal device 10. As described above, 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 function of a web server for supplying a web page for receiving the issuance of the electronic certificate (electronic certificate issuing page) and displaying it on the web browser of the terminal device. Alternatively, the certificate issuing system 3 includes a back-end certificate issuing server 30 and a web server as a front end accessed by the user.

The OAuth execution processing unit 52, together with the OAuth execution processing unit 61 of the key management server 20, is a processing unit for controlling the authorization process of OAuth2.0 defined in so-called RFC6749, and is transmitted from the terminal device 10 (web browser). Using the obtained authorization code, a process of requesting an access token from the key management server 30 is performed.
The signature request request processing unit 53 is a processing unit that uses the access token acquired by the OAuth execution processing unit 52 to perform a process of requesting a certificate signature request (CSR) from the key management server 20.
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 20.

With the above-described configuration, the certificate issuing system 2 issues a certificate signature request including a public key to a trusted signature service (key management system 3) when issuing a digital certificate required for remote signature. Requests and issuance of digital certificates can be performed automatically under user authentication and management. This makes it possible to issue the electronic certificate safely while reducing the burden on the user.

4A and 4B are diagrams showing a configuration of the key management server of the present embodiment, FIG. 4A is a diagram showing a functional configuration by hardware, and FIG. 4B is a diagram showing a functional configuration by software.
As shown in FIG. 4A, the key management server 30 executes a general-purpose operating system that controls the entire device, and a CPU (Central Processing Unit) that executes a program that realizes the functions of the key management server 30. 31, a RAM (Random Access Memory) 32 in which various programs, temporary data, and variables are expanded for processing by the CPU 31, an HDD (Hard Disk Drive) 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 the network.

Further, the key management server 30 includes a hardware security module (HSM: Hardware Security Module) 100 connected to the internal bus. In this case, the key management server 30 is synonymous with the key management system 3.
As described above, the HSM 100 may be connected to the external bus of the key management server 30 or may have a network I/F and be connectable to the key management server 30 via the network. In this case, the key management server 30 and the network connection type HSM 100 constitute the key management system 3.

Further, as shown in FIG. 4B, the CPU 31 includes an OAuth execution processing unit 61, a user authentication processing unit 62, a key generation processing unit 63, a signature request processing unit 64, and a certificate storage processing unit 65. , Run.
The OAuth execution processing unit 61, together with the OAuth execution processing unit 52 of the certificate issuing server 30, is a processing unit for controlling the OAuth2.0 authorization process defined in RFC6749.
When receiving the authorization request (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 is successful, the authorization response As the (Authorization response), the authorization code is transmitted to the terminal device 10.
Further, when the OAuth execution processing unit 61 is requested by the certificate issuing server 20 for an access token (Access token) together with the authorization code, it transmits the access token to the certificate issuing server 20. Perform processing to

The user authentication processing unit 62 authenticates the authentication information (for example, the combination of the user ID and the password) input on the authentication screen displayed on the terminal device 10 and, if authenticated, notifies the OAuth execution processing unit 61. Is a processing unit for performing.
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 (secret key) and a public key. The private key (secret key) is generated, for example, based on the KeyAlias and PIN received from the terminal device 10.
When the certificate requesting server 20 requests the certificate signing request (CSR), the signature request processing unit 64 sends the certificate signing request (CSR) including the public key generated by the key generation processing unit 63 to the certificate issuing server. It is a processing unit that performs a process of transmitting to 20.
The certificate storage processing unit 65 is a processing unit that performs processing of storing (importing) the electronic certificate transmitted from the certificate issuing server 20 in the HSM 100.
Further, the CPU 31 of the key management server 30 executes an electronic signature generation processing unit that causes the HSM 100 to generate an electronic signature in response to the electronic certificate issuance request.

With the above-described configuration, the key management system 3 of the present exemplary embodiment provides the certificate issuing system 2 with the authentication and management of the user when issuing the electronic certificate required for the remote signature. It is possible to automatically issue a certificate signing request including a public key and issue a digital certificate. This makes it possible to issue the electronic certificate safely while reducing the burden on the user.

FIG. 5 is a diagram illustrating a flow of electronic certificate storage processing in the remote signature system of the present embodiment.
In the single sign-on technique, the key management system 3 (key management server 30) is an Identity Provider (IdP) that is a side that provides authentication information, and is a certificate issuing system 2 (certificate issuing server 20) that is a certificate authority. ) Is a Service Provider (SP) that is a side that uses the authentication information.

In 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 page for redirecting the user to the key management server 30 to the terminal device 10 in step S2.
The terminal device 10 transmits an authorization request to the key management server 30 (RFC6749#4.1.1.) in step S3 by the operation of the user. This is a procedure for requesting user authentication in the single sign-on mechanism.

In the user authentication process of step S4, the key management server 30 requests the user to input authentication information (for example, user ID and password). In addition, when the account of the user is not created, the key management server 30 performs a process of newly creating an account for the user.
In the user authentication process of 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 the method of authenticating the combination of the user ID and the password, and the authentication may be performed by sending the token stored in the IC card from the terminal device 10 to the key management server 30.
When the user is authenticated or the account is created normally, the key management server 30 establishes the authorization after obtaining the confirmation of the user, and in step S5, the authorization code (Authorization response) is given as the authorization response (Authorization response). code) to the terminal device 10 (RFC6749#4.1.2.).

Note that, for example, at this stage, in step S6, the terminal device 10 (web browser) transmits the KeyAlias (identifying name attached to the key) and the PIN input by the user to the key management server 30.
On the other hand, in step S7, the key management server 30 causes the HSM (Hardware Security Module) 100 to generate a private key (private key) and public key pair based on the KeyAlias and PIN input by the user, and the HSM100 To be stored in.
Actually, the generation of the key pair may be performed by the time of transmitting the certificate signature request (CSR) including the public key described later.

Upon receiving the authorization code (Authorization code) transmitted from the key management server 30, the terminal device 10 (web browser) transfers (Redirect) the authorization code (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 uses the authorization code to send an Access token request to the key management server in step S9. 30 (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 S10.
That is, the key management server 30 transmits an access token to the certificate issuing server 20 (RFC6749#4.1.4.).

In step S11, the certificate issuing server 20, which has obtained the access token from the key management server 30, uses the access token to access the key management server 30 and issue a certificate signature request (CSR). Make the request.
The key management server 30 that has received the request for the certificate signature request (CSR) makes a certificate signature request (CSR) to the certificate issuing server 20 in step S12. The certificate signing request includes the public key generated by the key management server 30.
Upon receiving the certificate signing request, the certificate issuing server 20 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 in HSM100).
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 remote signature processing after the electronic certificate storage processing shown in FIG.
In response to the request from the terminal device 10, 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. 5 in step S21.
Note that this remote signature request is a process for remotely requesting generation of an electronic signature, and is a process different from the certificate signature request for requesting issuance (signature) of an electronic certificate in the above-described electronic certificate storage process. ..
Upon receiving the remote signature request transmission, the key management server 30 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. ..

As described above, the certificate issuing server 20 of this embodiment uses the mechanism of OAuth2.0 from the key management server 30 to access the key management server 30 for a certificate signature request (CSR). Get a token (Access token).
Then, the certificate issuing server 20 can use this access token not only for requesting a certificate signature request (CSR) but also for requesting a remote signature to the key management server 30.

As described above, in the remote signature system of this embodiment, when issuing a digital certificate, the public key is included between the certificate authority (certificate issuing system) and the trusted signature service (key management server). Requests for certificate signing and exchange of digital certificates are automatically performed under the user's authentication and management. In particular, the certificate issuing server can automatically issue the electronic certificate.
As a result, while reducing the burden on the user, we have realized a digital signature system that can securely issue digital certificates and register digital certificates in the key management server, and provide highly reliable signature services to users. Can be used by

By the way, as described above, the electronic certificate has an expiration date and needs to be reissued (updated) periodically.
Basically, when the user of the terminal device 10 performs an operation to access the certificate issuing server 20 of the certificate authority (CA), steps S1 to S15 shown in FIG. By performing the processing in steps S6 and S7) again, a new digital certificate is stored in the key management server 30 (HSM100), and the digital certificate can be updated.
However, it is very complicated and inconvenient for the user of the terminal device 10 to manage the expiration date of the electronic certificate and to perform the operation related to the update of the electronic certificate on a regular basis.
It is preferable that the user of the terminal device 10 does not need to be aware of the expiration date of the electronic certificate stored in the key management server 30 and that the electronic certificate is automatically updated.

Moreover, it is desirable that the operation is not performed by the user (administrator) of the management device that manages the terminal device 10, but is performed under the authentication and management of the user of the terminal device 10. This principle is the same as when the electronic certificate is first stored in the key management server 30 described with reference to FIG.
In view of this point, the certificate issuing server 20 performs the update processing of the electronic certificate by using the access token issued under the authentication and management of the user of the terminal device 10 at the time of first storing. ..
Since the management device or the like can issue the command itself for causing the certificate issuing server 20 to perform the electronic certificate update process, the user of the terminal device 10 does not have to be aware of the electronic certificate update process itself. , The load can be suppressed to the maximum.

Details are given below. As described with reference to FIG. 2, the remote signature system 1 of the present embodiment manages the electronic 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 receives a request from the management device that manages the terminal device 10, and requests the certificate issuing server 20 to update (reissue) the electronic certificate.

7A and 7B are diagrams showing a configuration of the certificate management server 40 of the present embodiment, FIG. 7A is a diagram showing a functional configuration by hardware, and FIG. 7B is a diagram showing a functional configuration by software.
As shown in FIG. 7A, the certificate management server 40 executes a general-purpose operating system that controls the entire apparatus and also executes a program (CPU) that realizes the functions of the certificate issuing server 20 (Central Processing). Unit) 41, a RAM (Random Access Memory) 42 in which various programs, temporary data, and variables are expanded for processing by the CPU 41, an HDD (Hard Disk Drive) 43 in which programs and data are stored, and a not-shown A ROM (Read Only Memory) and a network I/F 44 for connecting the certificate management server 40 to the network are provided.

Further, as shown in FIG. 7B, the CPU 41 executes an update request processing unit 71 and a certificate management processing unit 72.
Further, a storage unit configured from the HDD 43 or the like stores a certificate management database (DB) 81 that manages the state (valid or revoked) and the expiration date of the electronic certificate issued by the certificate issuing server 20. Has been done.
It is desirable that the certificate management DB 81 is open to a specific external device (management device or the like) so that the expiration date of the electronic certificate can be confirmed. In that case, the certificate management server 40 preferably includes a web page processing unit (a so-called web server) as a front end for disclosing information to an external device.

The update request processing unit 71 is a processing unit that mainly receives a request from the management device and issues an update request for a specific electronic certificate to the certificate issuing server 20.
The certificate management processing unit 72 writes the state (valid or revoked) and the expiration date of the electronic certificate issued by the certificate issuing server 20 into the certificate management DB 81 or refers to the information in the database. It is a department.

FIG. 8 is a diagram for explaining the flow of the electronic certificate update processing after the electronic certificate storage processing shown in FIG.
Upon receiving the request from the management device or the like, the certificate management server 40 requests the certificate issuing server 20 to update a specific electronic certificate in step S31. The update request may be issued for one electronic certificate or may be issued collectively for a plurality of electronic certificates that are about to expire.

In step S32, the certificate issuing server 20 uses the access token to make a request for a certificate signature request (CSR) to the key management server 30.
The key management server 30 that has received the request for the certificate signature request (CSR) makes a certificate signature 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, posts to the key management server 30 in step S35, and in step S36, the key management server 30 Accept it (store in HSM100).
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 is obtained from the key management server 30 in step S10 of the first electronic certificate storage processing described in FIG.
By using the access token obtained from the key management server 30, it is not necessary to repeat the authorization operation by the terminal device 10 (steps S1 to S5 in FIG. 5) when updating the electronic certificate, and the user's The work load is significantly reduced.
In addition, as described above, the access token (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 an appropriate process. Be assured.
As described with reference to FIG. 6, the access token obtained from the key management server 30 in step S10 of the certificate storage process is used when transmitting the remote signature request to the key management server 30. However, this means that it can also be used when updating the digital certificate.

It should be noted that the normal access token has an expiration date, which is shorter than the expiration date of the digital certificate. When updating the digital certificate, it is likely that the access token has expired.
On the other hand, under a specific condition, for example, by setting the expiration date of the access token to be long only for updating the electronic certificate, the electronic certificate can be surely updated.
With the above configuration, in the remote signature system 1 of the present embodiment, the user performs the authorization operation (access to the electronic certificate issuance page in step S1 and the key management server in step SS4 in the first storing process. After the login authentication), the electronic certificate can be stored in the key management server 30 and the stored electronic certificate can be updated almost completely automatically.

It should be noted that the update processing of the electronic certificate using the access token at the time of initial storage by the certificate issuing server 20 is not necessarily the update request of the electronic certificate by the certificate management server 40 according to the request of the management apparatus. It does not have to be triggered by.
For example, in the remote signature process shown in FIG. 6, in response to a request from the terminal device 10, the certificate issuing server 20 uses the access token acquired in the process of FIG. The signature request is transmitted to the key management server 30.
Upon receiving the remote signature request transmission, the key management server 30 generates an electronic signature in step S22, and transmits the generated electronic signature to the certificate issuing server 20 in step S23.
At this time, the key management server 30 may transmit the CSR together with the electronic signature to the certificate issuing server 20 when the electronic certificate corresponding to the remote signature request stored in the HSM 100 is about to expire. Also by this method, the electronic certificate can be updated without burdening the user of the terminal device 10.

In the above description, the system including the terminal device 10, the certificate issuing system (certificate issuing server 20), and the key management system 3 (key management server 30) is described.
Not limited to that, 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.

A user of one or a plurality of 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 selected certificate issuing system 20. You can access it.
Further, the one certificate issuing system 20 trusts the plurality of key management systems 30 having the functions described above, and issues a digital certificate for the public key issued by each key management system according to the above procedure. And register it.
When there are multiple key management systems that can redirect users, for example, each certificate issuing system displays a list of available key management systems on the certificate issuance page, and the key management system to be used from among them is displayed. Can be selected by the user.

Note that the above-mentioned Patent Document 1 (Japanese Patent Laid-Open No. 2010-200142) discloses a system including a user terminal, a digital signature server, and a certificate authority.
In Patent Document 1, a certificate authority generates a key pair of a private key and a public key. Then, the digital signature server requests the certificate authority to issue a digital certificate based on the public key. The certificate authority stores the issued electronic certificate and private key in a file of a format called PKCS#12 and supplies it to the electronic signature server.
Then, 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.

As described above, in Patent Document 1, the certificate authority generates a key pair, the digital signature server makes a certificate signing request by directly communicating with the certificate authority, and the generated certificate and private key are also digitally signed. Direct interaction between the server and the certificate authority. There is no room for the user to intervene during the communication.

On the other hand, in the present embodiment, the user's 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 OAuth2.0 (RFC6749). Authentication to the server is performed, and using the access token issued as a result, an electronic certificate is exchanged between the certificate authority (certificate issuing system) and the key management server.
In the present embodiment, the private key (secret key) is originally generated by the key management server, and is not exchanged between the certificate authority and the key management server.
In this embodiment, since the certificate signature request and the electronic certificate are exchanged when the user authenticates the key management server, the electronic certificate can be issued more safely than the conventional method. In addition, since the private key (private key) is not transmitted to other servers or terminals after it is generated by the key management system, the risk of leaking to the outside is low and a safer digital signature system can be operated. Becomes

[First invention]
A first invention according to the present embodiment has a certificate issuing system 2 for issuing a digital certificate, and a key management system having a function of managing a user's private key and generating a digital signature using the private key. The key management system 3 sends 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 digital signature system 1 is characterized by obtaining a certificate issuance request including a user's public key from the key management system 3 and issuing an electronic certificate to the public key.
In the digital signature system of the first invention, when issuing a digital certificate required for a remote signature, a certificate signing request including a public key and a digital certificate are issued by a certificate authority (certificate issue) via an access token. It is done automatically between the system 2) and the trusted signature service (key management system 3).
As a result, it is possible to realize an electronic signature system capable of securely issuing an electronic certificate while reducing the burden on the user.

[Second invention]
A second invention according to the present embodiment is a certificate issuing system for issuing a digital certificate, which requests a key management system to issue a certificate including a user's public key using a predetermined access token. Requesting means (signature request processing part 53) and issuing means (electronic certificate issuing processing part 54) for issuing a digital certificate to the public key included in the certificate issuing request acquired in response to the request from the requesting means. ), and a certificate issuing system comprising.
A certificate issuing system according to a second aspect of the present invention issues a request for a certificate signature request including a public key to a trusted signature service (key management system 3) and an electronic certificate of an electronic certificate when issuing an electronic certificate required for a remote signature. Issuing can be done automatically via an access token. This makes it possible to issue the electronic certificate safely while reducing the burden on the user.

[Third invention]
A third invention according to the present embodiment is a key management system which has a function of managing a user's private key and generates a digital signature using the private key, and at least generates a user's public key. Signature request means for transmitting a certificate issuance request including a public key to the key generation means (key generation processing unit 63) and the certificate issuance system that has transmitted the access token, and causing the certificate issuance system to issue an electronic certificate. (Signature request processing unit 64) and a key management system.
A key management system according to a third aspect of the present invention automatically issues a certificate signing request including a public key to a certificate issuing system via an access token when issuing a digital certificate required for a remote signature, and obtains a digital certificate. It is possible to issue a book.
This makes it possible to issue the electronic certificate safely while reducing the burden on the user.

1 remote signature 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 electronic 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 processing unit

In order to solve the above problems, the present invention provides a certificate issuing system for issuing a digital certificate, a certificate management system for managing the life cycle of the issued digital certificate, and a digital signature using a private key. And a terminal device used by a user, and when a new electronic certificate is issued, the terminal device requests the key management system to authenticate the user, If the authentication is successful, the key management system transmits an authorization code to the terminal device, and the terminal device that has acquired the authorization code transfers the authorization code to the certificate issuing system, The certificate issuing system that has obtained the authorization code requests an access token by sending the authorization code to the key management system, and the key management system sends the access token to the certificate issuing system, the certificate issuing system, by presenting the access token to the key management system, to obtain a certificate issuance request containing the public key of the user from the key management system, the electronic certificate to the public key The certificate management system , the certificate management system issues a certificate update request to the certificate issuing system when the electronic certificate is updated based on the establishment of a predetermined condition, and the certificate issuing system sends the certificate. A certificate issuance request including the user's public key is obtained from the key management system by presenting the access token acquired from the key management system at the time of new issue to the key management system based on a certificate update request. The digital signature system issues an electronic certificate for the public key .

Claims (5)

A certificate issuing system that issues electronic certificates,
A key management system having a function of managing a user's private key, and generating a digital signature using the private key;
The certificate issuing system obtains a certificate issuance request including the user's public key from the key management system by presenting a predetermined access token to the key management system, and electronically responds to the public key. An electronic signature system that issues a certificate. A certificate issuing system for issuing a digital certificate,
Request means for requesting a key management system for a certificate issuance request including a user's public key using a predetermined access token,
Issuing means for issuing an electronic certificate to the public key included in the certificate issuance request acquired in response to the request by the requesting means,
A certificate issuing system comprising: A key management system that has a function of managing a user's private key, and that generates a digital signature using the private key,
A key generation means for generating at least the public key of the user,
Signature request means for transmitting a certificate issuance request including the public key to the certificate issuance system that has transmitted a predetermined access token, and for causing the certificate issuance system to issue an electronic certificate. Key management system. A certificate issuing method for a certificate issuing system, comprising a requesting means and an issuing means, for issuing an electronic certificate,
A step of requesting a key management system for a certificate issuance request including a user's public key using the predetermined access token;
Issuing a digital certificate to the public key included in the certificate issuance request acquired in response to the request by the requesting unit,
A method of issuing a certificate, comprising: A program that causes a computer to execute the certificate issuing method according to claim 4.

Images