JP7811900B2 - Electronic signature system and electronic signature processing method - Google Patents

Description

The present invention relates to an electronic signature system and an electronic signature processing method, and in particular to an electronic signature system and an electronic signature processing method that enable proxy electronic signatures.

In an effort to eliminate the use of seals, progress is being made in introducing electronic signatures that are similar to registered seals. Consideration has begun on services such as remote signatures and witness-type electronic signatures, which eliminate the need for users to manage private keys, rather than the traditional local signatures that utilize IC cards.

Japanese Patent Application Laid-Open Publication No. 2015-215839 discloses a related technology to the present disclosure. JP 2015-215839 A discloses that "the proxy application authorization system according to the present invention comprises a client terminal 100 used by a client who requests an agent to perform an application procedure; an agent terminal 200 used by the agent; an authorization server 300 that generates an agent permission ticket for the application procedure and sends an application procedure request for the application procedure if the agent permission ticket is valid; an agent hub server 600 that converts the ID of the agent listed as the applicant in the application procedure request into the ID of the client; and a processing server 400 that receives the application procedure request from the agent hub server 600 and performs processing related to the application procedure." (For example, an abstract.)

This technology is a system specialized for delegating authority to qualified professionals, etc., and attaches the signature of the agent corresponding to the proxy application to the application form via an authorization server, etc.

Japanese Patent Application Laid-Open No. 2015-215839

Generally, an agent may sign on behalf of a principal. For example, a company employee may sign on behalf of the representative. Therefore, there is a need for technology that allows agents to properly perform electronic proxy signatures on a system.

One aspect of the present invention is an electronic signature system that includes one or more processors and one or more storage devices. The one or more storage devices store key management information that manages the scope of authority of one or more agents for each of the signature keys of different owners. The one or more processors receive from a first terminal the designation of a first agent, the designation of a first signature key, and a request for an agent signature. In response to the request for an agent signature, where the key management information indicates the authority of the first agent to sign on behalf of the first agent using the signature key, the one or more processors execute a signature process using the first signature key for the designated electronic data to generate signed electronic data and transmit the signed electronic data to the first terminal.

According to one aspect of the present invention, electronic signatures by agents can be properly performed on the system.

1 shows an example of the configuration of an electronic signature system. 1A shows an example of a hardware configuration applicable to each of the components shown in FIG. 1A. An example of the logical configuration of an authentication/authorization server is shown below. 1 shows an example of the logical configuration of a remote signing server. 1 shows an example of the logical configuration of a signature application server. 10 shows an example of the configuration of an account management table. 10 shows an example of the configuration of an account management table. 10 shows an example of the configuration of a key information management table. 10 shows an example of the configuration of a key information management table. 10 shows an example of the configuration of a client management table. 10 shows an example of the configuration of a key/certificate management table. FIG. 10 is a sequence diagram illustrating an example of a process for setting delegation authority from a representative to a delegator. An example of service authentication processing for a proxy will be described below, and a sequence diagram of the processing example will be shown. 10 shows a sequence diagram of an example process for an agent to select a delegated signing key. 10 shows a sequence diagram of an example of a key authorization process for an agent to perform a proxy signature using a delegated signature key. An example of the configuration of an access token to a signing key is shown below. 10 shows a sequence diagram of an example of a proxy signing a target document using a delegated signature key by a proxy. An example of the configuration of a proxy token is shown below. 10 shows a sequence diagram of a processing example of signature value generation. 10 shows a sequence diagram of an example process in which a representative views a log of a proxy signing process using his/her own signature key. 10 shows an example of a log screen of the proxy signature process displayed on the representative terminal. 10 illustrates a schematic diagram of the log rotation process of the authentication/authorization server. 10 illustrates a schematic diagram of a log rotation process of a remote signing server. 10 shows an example of the configuration of an event log management table of the authentication and authorization server. 10 shows an example of the configuration of an event log management table of a remote signature server.

In the following, for convenience, when necessary, the description will be divided into multiple sections or embodiments; however, unless otherwise expressly stated, these are not unrelated to one another, and one is a partial or complete modification, detail, supplementary explanation, etc. of the other. Furthermore, in the following, when referring to the number of elements (including numbers, numerical values, amounts, ranges, etc.), unless otherwise expressly stated or when in principle it is clearly limited to a specific number, it is not limited to that specific number, and may be more or less than that specific number.

The electronic signature system in one embodiment of this specification allows a delegated agent to electronically sign on behalf of a principal. In the following, a corporate representative will be used as an example of the principal, and an employee of the corporate representative will be used as an example of the agent. The relationship between the principal and agent is not limited to this. For example, this system can be used by a craftsman to sign electronically on behalf of a specific position.

The system of one embodiment of this specification allows a signing agent (also simply referred to as an agent) to sign an electronic document using the representative's signature key. The system of one embodiment of this specification enables the agent's authority settings and execution.

Furthermore, a system according to an embodiment of this specification activates a signing key and generates a signature according to the authorization status of the agent. For example, the system internally centrally manages activation information for the signing key without disclosing it to the agent. The system activates a signing key in accordance with the agent's authorization. This increases the security of proxy signatures using a signing key.

The system of one embodiment of this specification also enables post-facto verification of electronic proxy signatures by the proxy, enabling internal audits of signature operation events and ensuring the authenticity of signature processing in remote signature services.

Figure 1A shows an example of a computer system configuration including an electronic signature system. The computer system includes a representative terminal 11, an agent terminal 13, and an electronic signature system. The electronic signature system includes a key management device 15, an authentication/authorization server 20, a remote signature server 30, and a signature application server 40. In the example of Figure 1A, multiple agent terminals 13 and multiple signature application servers 40 are included, and the number of other components is one. However, the number of these components can be determined depending on the system design.

The key management device 15 communicates with the remote signature server 30 and performs the necessary processing. The representative terminal 11, agent terminal 13, authentication/authorization server 20, remote signature server 30, and signature application server 40 communicate via a network 17. The type of network 17 can be selected depending on the system. Note that functions distributed across multiple devices in FIG. 1A may be implemented in a single device, or functions implemented in a single device may be distributed across multiple devices. For example, the functions of the authentication/authorization server 20 or the signature application server 40 may be included in the remote signature server 30.

Figure 1B shows an example hardware configuration applicable to each component shown in Figure 1A. Figure 1B shows an information processing device having a computer configuration. Each component shown in Figure 1A can be configured, for example, by one or more computers. In addition to the configuration described below, the key management device 15 can also have tamper resistance. Tamper resistance is the ability to prevent internal confidential information data and operations from being analyzed or altered from the outside, and allows for strict management of private keys.

The information processing device 101 includes a processor 102, a main memory device 103, an auxiliary memory device 104, an input device 105, and an output device 106. The various components of the information processing device 101 are communicatively connected to one another via communication means such as a bus (not shown). Note that all or part of the configuration of the information processing device 101 may be realized by virtual resources such as a cloud server.

The processor 102 is composed of a CPU (Central Processing Unit), MPU (Micro Processing Unit), GPU (Graphics Processing Unit), etc. The processor 102 reads and executes programs stored in the main memory device 103, thereby realizing the functions of each device in the electronic signature system.

The main memory device 103 is a device that stores programs and data, and may be ROM (Read Only Memory), RAM (Random Access Memory), NVRAM (Non Volatile RAM), etc.

The auxiliary storage device 104 may be, for example, an SSD (Solid State Drive), an NVRAM such as an SD memory card, an optical storage device such as a CD (Compact Disc) or a DVD (Digital Versatile Disc), an HDD (Hard Disc Drive), or a storage area on a cloud server. The auxiliary storage device 104 includes a non-transitory storage medium that stores programs and data. The programs and data stored in the auxiliary storage device 104 are loaded into the main storage device 103 as needed.

The input device 105 is an interface that accepts information input, and may be, for example, a keyboard, mouse, touch panel, card reader, microphone, etc. Alternatively, the information processing device 101 may be configured to accept information input between itself and another device via some kind of communication means.

The output device 106 is an interface that outputs various types of information, and may be, for example, a screen display device such as a liquid crystal monitor, LCD (Liquid Crystal Display), or graphics card, a printer, or an audio output device such as a speaker. Alternatively, the information processing device 101 may be configured to output information to and from other devices via some form of communication means. Some of the components shown in FIG. 1B may be omitted, and other components may be added.

In this way, the electronic signature system and each component of the electronic signature system may include one or more processors and one or more arithmetic units. The one or more processors operate as specified functional units by executing programs stored in one or more storage devices.

Figure 2 shows an example of the logical configuration of the authentication/authorization server 20. The authentication/authorization server 20 includes an account setting unit 21, an authority setting unit 22, a service authentication unit 23, a key information providing unit 24, a key authorization unit 25, and an evidence management unit 26. These may be implemented by a program or one or more processors that operate in accordance with a program.

The authentication and authorization server 20 includes a setting information management store 27 and a trail information management store 28. The setting information management store 27 stores an account management table 271, a key information management table 272, and a client management table 273. The trail information management store 28 stores an event log management table 281 and an audit log management table 282. The setting information management store 27 and the trail information management store 28 may be implemented in, for example, an auxiliary storage device.

Figure 3 shows an example of the logical configuration of the remote signing server 30. The remote signing server 30 includes a signing key management unit 31, a signing request acceptance unit 32, a proxy authority verification unit 33, a key management device collaboration unit 34, a log provider unit 35, and a trail management unit 36. These may be implemented by a program or one or more processors that operate in accordance with a program.

The remote signing server 30 includes a signing key information management store 37 and a trail information management store 38. The signing key information management store 37 stores a key/certificate management table 371. The trail information management store 38 stores an event log management table 381 and an audit log management table 382. The signing key information management store 37 and the trail information management store 38 may be implemented in, for example, an auxiliary storage device. Note that the real PIN column 252 included in the key/certificate management table 371 may be implemented in a device with specifications similar to those of the key management device 15 as a more advanced leak prevention measure.

Figure 4 shows an example of the logical configuration of the signature application server 40. The signature application server 40 includes a signature target document creation unit 41, a service authentication request unit 42, a signature key list request unit 43, a key authorization request unit 44, a signature request unit 45, a signed document management unit 46, and a log viewing unit 47. These may be implemented by a program or one or more processors operating in accordance with a program.

The signature application server 40 includes a signature document management store 48. The signature document management store 48 stores a signature target document management table 481 and a signed document management table 482. The signature document management store 48 can be implemented, for example, in an auxiliary storage device.

Figures 5A and 5B show example configurations of the account management table 271. The account management table 271 manages account information for representatives and signing agents who use the electronic signature service. Figure 5A shows an example configuration of the account management table 271 before agent information is registered, and Figure 5B shows an example configuration of the account management table 271 after specific agent information has been registered.

The account management table 271 associates service authentication information 201 with key authorization information 202. The service authentication information 201 includes a user ID field and a password field. The key authorization information 202 includes a public key certificate identification information (e.g., serial number) field and a public key certificate file field. The account management table 271 manages combinations of user IDs, passwords, public key certificate identification information, and public key certificate files.

In the examples of Figures 5A and 5B, the user with user ID "A-1" is the representative who owns the signature key, and the users with user IDs "A-2" and "A-3" are respectively agents authorized to sign on behalf of the representative using the representative's signature key. As described below, signatures by specific users are authorized and registered by the representative.

Figures 6A and 6B show example configurations of the key information management table 272. The key information management table 272 manages signature key information. Figure 6A shows an example configuration of the key information management table 272 before proxy information is registered, and Figure 6B shows an example configuration of the key information management table 272 after specific proxy information has been registered.

The key information management table 272 includes a signature key ID column 211, an owner column 212, a key scope column 213, an agent column 214, and a key scope column 215. The signature key ID column 211 indicates the ID of the signature key. The owner column 212 indicates the owner of the signature key. The key scope column 213 indicates the scope of authority of the signature key owner for the signature key. In this example, the key owner has the authority to sign using the signature key, view signature key information, and edit signature key information. The agent column 214 indicates a signing agent who has been delegated (accepted) to sign on behalf of someone using the signature key. The key scope column 215 indicates the scope of authority of the signing agent (agent) for the signature key. In this example, the agent is permitted to sign using the signature key and view signature key information.

In the examples of Figures 6A and 6B, the user with user ID "A-1" is the representative who owns the signature key, and the users with user IDs "A-2" and "A-3" are agents (agents) who have been delegated to sign on behalf of the representative using the signature key.

Figure 7 shows an example of the configuration of the client management table 273. The client management table 273 manages the permissions of the components within the electronic signature system. The client management table 273 includes a client ID column 221, a client name column 222, a client scope column 223, and a key scope column 224. The client ID column 221 indicates the client ID, and the client name column 222 indicates the client name. In the example of Figure 7, a signature application server and a remote signature server are registered. The client scope column 223 indicates the scope of permissions for services or resources that the client can access on behalf of the user, and the key scope column 224 indicates the scope of permissions, particularly for the signature key, among the resources that the client can access on behalf of the user.

Figure 8 shows an example of the configuration of the key/certificate management table 371. The key/certificate management table 371 manages information related to signature keys. The key/certificate management table 371 includes a signature key ID column 251, a real PIN column 252, a public key certificate identification information column 253, and a public key certificate file column 254.

The signature key ID field 251 indicates the ID of the signature key. The real PIN field 252 indicates the real PIN of the signature key, i.e., information for activating the signature key. The public key certificate identification information field 253 indicates the identification information of the public key certificate required when signing with the signature key. The public key certificate file field 254 stores the public key certificate file indicated in the public key certificate identification information field 253.

<Delegation authority setting phase>
An example of processing in an electronic signature system according to an embodiment of this specification will be described below. First, the phase of granting proxy signing authority from the representative, who is the owner of the signature key, to a signing agent will be described. FIG. 9 shows a sequence diagram of an example of processing for granting proxy authority from the representative to the agent. The representative uses the representative terminal 11 to grant proxy authority to the agent.

In response to input from the representative, the representative terminal 11 requests the remote signature server 30 to display a screen for selecting proxy authority (S11).

When the signature key management unit 31 of the remote signature server 30 receives the permission setting request, it generates an authorization request for permission setting and returns it to the representative terminal 11 along with the redirect URL (S12).

The representative terminal 11 accesses the redirect URL and forwards an authorization request for permission setting to the authentication/authorization server 20 (S13).

The service authentication unit 23 of the authentication/authorization server 20 sends a login screen to the representative terminal 11 and requests a login (S14).

The representative terminal 11 displays a login screen (S15), receives login authentication information from the representative, and transmits it to the authentication/authorization server 20 (S16). Specifically, the representative's user ID and password are transmitted.

The service authentication unit 23 of the authentication/authorization server 20 compares the received authentication information with the service authentication information 201 in the account management table 271 to verify the authentication information (S17). Once the identity of the representative who made the login request has been confirmed, the service authentication unit 23 sends an access token and redirect URL to the representative terminal 11. The access token may be a random character string that allows the agent to set key usage authority.

The representative terminal 11 sends the authentication result to the remote signature server 30 indicated by the redirect URL (S18). The signature key management unit 31 of the remote signature server 30 verifies the authentication result (S19). Specifically, it analyzes the authentication result to confirm that it is normal and extracts the user ID. The signature key management unit 31 then queries the authentication/authorization server for the key owned by the corresponding user ID (S20). The key information provider 24 of the authentication/authorization server retrieves information about the signature key owned by the representative, which is registered in the key information management table 272. (S21) Based on the acquired information, the remote signature server 30 sends a screen for setting proxy authority to the representative terminal 11.

The representative terminal 11 receives proxy authority setting information from the representative (S22). For example, information including the key ID of the signature key to which proxy authority is to be granted, the user ID of the delegated proxy, and the authority to be granted is input. The representative terminal 11 sends the input setting information to the remote signature server 30 (S23).

The signature key management unit 31 of the remote signature server 30 receives the setting information from the representative terminal 11 (S24) and requests the authentication/authorization server 20 to set up proxy authority along with that information (S25). The authority setting unit 22 of the authentication/authorization server 20 registers the information for the specified proxy authority in the account management table 271 and key information management table 272, and returns the result to the remote signature server 30 (S26). The signature key management unit 31 sends information on the proxy authority registration result to the representative terminal 11. The representative terminal 11 displays the information (S27).

Following the above sequence, for example, the information in account management table 271 shown in Figure 5A changes to the information in account management table 271 shown in Figure 5B. User information added to account management table 271 may be pre-registered in a user management table (not shown). Furthermore, following the above sequence, the information in key information management table 272 shown in Figure 6A changes to the information in key information management table 272 shown in Figure 6B. Through the above process, the owner of a signing key can safely set and register the proxy and scope of authority for that signing key.

<Proxy signing phase>
The proxy signature phase will be described below. First, an example of the process of service authentication (first stage authentication and authorization) for the proxy will be described. Fig. 10 shows a sequence diagram of this process example.

In response to a specific URL specified by the agent via the input device, the agent terminal 13 accesses the signature application server 40 and requests and obtains a menu screen (S31).

The agent terminal 13 accepts the selection of the signature service from the agent and requests the remote signature service from the signature application server 40 (S32).

The service authentication request unit 42 of the signature application server 40 generates an authorization request for the remote signature service and returns it to the agent terminal 13 along with the redirect URL (S33).

The agent terminal 13 forwards the authorization request for the remote signature service to the authentication/authorization server 20 indicated by the redirect URL (S34).

The service authentication unit 23 of the authentication/authorization server 20 sends a login screen to the agent terminal 13 and makes a login request (S35).

The agent terminal 13 displays a login screen (S36), receives login authentication information from the agent, and transmits it to the authentication/authorization server 20 (S36). Specifically, the agent's user ID and password are transmitted.

The service authentication unit 23 of the authentication/authorization server 20 compares the received authentication information with the service authentication information 201 in the account management table 271 to verify the authentication information (S37). Once the identity of the representative who made the login request has been confirmed and the verification has been successfully completed, the service authentication unit 23 sends an authorization code and redirect URL to the agent terminal 13 (S38). The authorization code may be a short-lived random character string to be exchanged for an access code.

The agent terminal 13 transfers the received authorization code to the redirect destination signature application server 40 (S39).

The service authentication request unit 42 of the signature application server 40 sends a request for an access token along with the authorization code to the authentication and authorization server 20 (S40).

The service authentication unit 23 of the authentication/authorization server 20 verifies the received authorization code (S41). If the authorization code is valid, the service authentication unit 23 generates an access token and sends it to the signature application server 40 (S42). The signature application server 40 stores the access token in a storage device (S43). The access token may be a random character string that authorizes use of the remote signature service.

The service authentication request unit 42 of the signature application server 40 sends the signature service screen to the agent terminal 13, and the agent terminal 13 displays it (S44).

The agent terminal 13 uploads the document to be signed as instructed by the agent to the signature application server 40 (S45), and the signature application server 40 returns the result.

The signature target document creation unit 41 of the signature application server 40 stores the received signature target document in the signature target document management table 481 (S46) and further generates a hash value (S47).

Next, we will explain the next process in the proxy signing phase, which is the process by which the proxy selects a delegated signing key. Figure 11 shows a sequence diagram of an example process by which the proxy selects a delegated signing key.

In response to instructions from the agent, the agent terminal 13 sends a request for the delegated signature key to the signature application server 40 (S51).

In response to the request from the agent terminal 13, the signature key list request unit 43 of the signature application server 40 generates a delegated signature key request and sends it to the remote signature server 30 together with the access token saved in step S43 of FIG. 10 (S52).

The signature key management unit 31 of the remote signature server 30 verifies the access token (S53). Specifically, the signature key management unit 31 queries the authentication/authorization server 20 about the access token and obtains information linked to the access token. In this case, it obtains the user ID of the agent registered in the account management table 271 (S54).

The signature key management unit 31 further requests information about the signature key for which the specified user ID is a delegate (signing agent) from the authentication/authorization server 20 (S55).

The key information providing unit 24 of the authentication/authorization server 20 references the key information management table 272 and responds with signature key information, including the key ID of the signature key for which the user name is the agent (S56).

The signature key management unit 31 then requests signature key ownership information from the authentication/authorization server 20, specifying the received key ID (S57). The key information provision unit 24 references the key information management table 272 and responds with information about the owner of the specified key ID (S58).

The signature key management unit 31 of the remote signature server 30 generates a delegated signature key list indicating information about each signature key delegated to the agent and sends it to the signature application server 40 (S59). The signature key list request unit 43 of the signature application server 40 generates a signature key list screen and sends it to the agent terminal 13 (S60).

The agent terminal 13 displays the delegated signature key list on the display device (S61) and accepts the agent's selection of the owner and signature key via the input device (S62).

Next, we will explain the process following the proxy signing phase, which is the authorization of the proxy signing key (second-stage authentication and authorization). Figure 12 shows a sequence diagram of an example key authorization process in which an agent uses a delegated signing key to perform a proxy signing.

The agent terminal 13 receives an instruction from the agent regarding the signature key to be used for the proxy signature and sends a key authorization request indicating that signature key to the signature application server 40 (S71).

The key authorization request unit 44 of the signature application server 40 generates an authorization request for the specified signature key and returns it to the agent terminal 13 along with the redirect URL (S72). The authorization request indicates the proxy signature authority (signature key_proxy), which is the process for which authorization is requested, and includes the ID of the target signature key and the hash value of the document to be signed.

The agent terminal 13 forwards the authorization request for the delegated signature key to the redirect destination authentication/authorization server 20 (S73).

The key authorization unit 25 of the authentication/authorization server 20 sends a login screen showing a challenge (random number) to the agent terminal 13 and makes a login request (S74).

The agent terminal 13 displays a login screen (S75). Here, the agent terminal 13 accepts the challenge signature (signature value) submitted by the agent using the private key and generates a response (S76).

The agent terminal 13 sends the authentication information, including the response (signature value) and the public key certificate entered by the agent, to the authentication/authorization server 20 (S77). Here, it is assumed that the private key in S76 and the public key certificate in S77 have been acquired in advance by the agent and stored on the agent terminal or a recording medium.

The key authorization unit 25 of the authentication/authorization server 20 verifies the received authentication information (S78). Specifically, the key authorization unit 25 extracts identification information from the received public key certificate and compares it with the identification information of the public key certificate stored in the account management table 271. This confirms that the public key certificate registered in the account management table 271 is correct.

Next, the key authorization unit 25 uses the public key of the public key certificate that has been confirmed to match to decrypt the response (signature value) and derive the challenge. The key authorization unit 25 confirms that it matches the challenge previously sent from the authentication/authorization server 20. If the authentication information is correct and the authentication process has been successfully completed, the key authorization unit 25 generates an authorization code and sends it to the agent terminal 13 together with the redirect URL (S79).

The agent terminal 13 transfers the authorization code to the redirect destination signature application server 40 (S80).

Upon receiving the authorization code, the key authorization request unit 44 of the signature application server 40 sends a request for an access token along with the authorization code to the authentication and authorization server 20 (S81).

The key authorization unit 25 of the authentication/authorization server 20 verifies the received authorization code (S82). If the received authorization code is valid, the key authorization unit 25 generates an access token for the specified signature key and returns it to the signature application server 40 (S83). The key authorization request unit 44 of the signature application server 40 stores the received access token in a storage device (S84).

As described above, the security of proxy signatures by agents can be improved by performing the service authentication described with reference to FIG. 10 and the authentication for key authorization described with reference to FIG. 12. Furthermore, performing key authentication using a private key and a public key enables more secure remote proxy signatures. Performing service authentication using a password and ID enables efficient processing.

Figure 13 shows an example configuration of an access token (authorization token) for the above-mentioned signature key. In the example configuration of Figure 13, the access token indicates the scope indicating the processing permitted by the access token, the agent's user ID, the signature key ID, the scope (scope of authority) of the user's signature key indicated by the user ID, the hash value of the object to be signed, the expiration date and issuance time of the access token, the access token ID, and a signature value created by the private key held by the authentication/authorization server 20. The access token allows the authentication result of the authentication/authorization server 20 to be appropriately presented to the remote signature server 30.

Next, we will explain the proxy signature process, which is the next process after the proxy signature phase. Figure 14 shows a sequence diagram of an example of a proxy signature on a target document using a delegated signature key by a proxy.

The signature request unit 45 of the signature application server 40 generates a proxy signature request and sends it to the remote signature server 30 together with the access token to the delegated signature key stored in step S84 (S91).

The signature request acceptance unit 32 of the remote signature server 30 verifies the received access token (S92). Specifically, the signature request acceptance unit 32 verifies the signature value of the access token using the public key of the pre-registered verification agent. Furthermore, the signature request acceptance unit 32 analyzes the access token and obtains the user ID, signature key ID, and key scope (S93). Next, the signature request acceptance unit 32 specifies the signature key ID and requests signature key owner information from the authentication/authorization server 20 (S94).

The key information providing unit 24 of the authentication/authorization server 20 reads the signature key owner information from the key information management table 272 and returns it to the remote signature server 30 (S95).

The signature request acceptance unit 32 of the remote signature server 30 confirms that the user ID in the access token does not match the owner of the signature key ID received from the authentication/authorization server 20 (S96). This confirms that the person requesting the signature using the signature key is not the owner, but an owner proxy. At this point, the signature request acceptance unit 32 stores the access token from step S92 in a storage device.

Next, the proxy authority verification unit 33 of the remote signature server 30 specifies the signature key ID, key scope, and hash value and requests a proxy ticket from the authentication/authorization server 20 (S97).

The key authorization unit 25 of the authentication/authorization server 20 generates a proxy ticket and returns it to the remote signing server 30 (S98). The proxy ticket may be a random character string.

The proxy authority verification unit 33 of the remote signature server 30 sends the received proxy ticket to the signature application server 40 (S99). Here, the proxy authority verification unit 33 associates the access token ID of step S92 with the proxy ticket ID of step S99 and stores the proxy ticket in a storage device. The signature application server 40 stores the received proxy ticket in a storage device (S100).

The signature request unit 45 of the signature application server 40 sends a proxy token request to the authentication and authorization server 20 along with the proxy ticket and access token (S101).

The key authorization unit 25 of the authentication/authorization server 20 references the key information management table 272 to confirm whether the user indicated by the access token can use the signature key indicated by the access token within the key scope (S102).

Once it is confirmed that the designated user has authorization to use the signature key on their behalf, the key authorization unit 25 generates a proxy token and sends it to the signature application server 40 (S103). The signature application server 40 stores the received proxy token in a storage device (S104).

The signature request unit 45 of the signature application server 40 sends a proxy signature request including the signature key ID, key scope, and hash value along with the proxy token to the remote signature server 30 (S105).

The proxy authority verification unit 33 of the remote signing server 30 verifies the proxy token (S106). Specifically, the proxy authority verification unit 33 verifies that the proxy ticket ID and access token ID included in the proxy token match the access token ID of step S92 and the proxy ticket ID of step S99 associated in step S100. The proxy authority verification unit 33 also verifies that the signature subject hash value and signature key ID (information on the signature subject and signature key) included in the access token of step S92 match the signature subject hash value and signature key ID included in the proxy token. The proxy authority verification unit 33 works with the key management device 15 to generate a signature value using the signature key (S107). This will be described later.

The proxy authority verification unit 33 sends the generated signature value along with the signature processing ID to the signature application server 40 (S108). The signature application server 40 stores the received signature value in the signed document management table 482 (S109).

The signed document management unit 46 of the signature application server 40 combines the document to be signed and the signature value to generate a signed document in a specific format and stores it in the signed document management table 482 (S110). The signed document management unit 46 then transmits the signed document to the agent terminal 13. The agent terminal 13 displays the received signed document on a display device (S111).

Figure 15 shows an example configuration of the above-mentioned proxy token. In the example configuration of Figure 15, the proxy token includes the user ID authorized for proxy signing, the permission details, the proxy ticket ID and access token ID at the time of the proxy token request, the expiration date, the issuance time, and the signature value. The permission details include the signature key ID that can be used for proxy signing, the "signature" process authorized for the signature key, and the hash value of the signature target. The user ID, permission details, and signature value are the same as those of the access token. The proxy token allows the authentication result of the authentication/authorization server 20 to be properly presented to the remote signature server 30.

The following describes in detail the process S107 for generating a signature value for a target document in the sequence diagram of Figure 14. Figure 16 shows a sequence diagram of an example of the signature value generation process.

The key management device linkage unit 34 of the remote signature server 30 obtains the signature key information for the signature key ID indicated by the proxy token from the key/certificate management table 371 (S121).

The key management device cooperation unit 34 searches for key objects stored in the key management device 15 (S122). Specifically, the key management device cooperation unit 34 sends the signature key ID to the key management device 15 and receives a key object handle (key object identifier) from the key management device 15.

The key management device cooperation unit 34 obtains the actual PIN information of the signing key from the key/certificate management table 371 (S123). The key management device cooperation unit 34 further obtains the public key certificate of the signing key from the key/certificate management table 371 (S124). The key management device cooperation unit 34 sends a key activation request along with the key object handle and the actual PIN encrypted with the private key to the key management device 15 (S125).

The key management device 15 compares the received real PIN with information previously registered in the key management device (S126), and if they match, activates the specified key and returns a result indicating activation to the remote signature server 30 (S127).

The key management device linkage unit 34 of the remote signature server 30 sends a signature value request along with the key object handle and hash value to the key management device 15 (S128).

The key management device 15 uses the specified signature key to generate a signature value from the received hash value and returns it to the remote signature server 30 (S129). The remote signature server 30 stores the received signature value in a storage device (S130).

<Log viewing phase>
The log viewing process phase will be described below. Fig. 17 is a sequence diagram showing an example of a process in which a representative views a log of a proxy signing process using his/her own signature key.

The representative terminal 11 displays the proxy signature event notification received from the signature application server 40 (S141). Information such as the address of the signature key owner's terminal is registered in advance with the signature application server 40.

Next, processing similar to the service authentication of the proxy signature phase sequence shown in Figure 10 (S32 to S44) is executed. Here, instead of the agent terminal 13 in Figure 10, the representative terminal 11 executes processing in response to the representative's input. Step S32 is changed to "log viewing request," and step S44 is changed to "log display."

Next, the representative terminal 11 accepts the selection of a signature process ID from the representative (S143). The representative terminal 11 may display, for example, the signature process ID, date, and the user ID of the agent. The representative terminal 11 sends a proxy signature log request along with the signature process ID to the signature application server 40 (S144).

Upon receiving the log request, the log viewing unit 47 of the signature application server 40 generates a proxy signature log request and sends it to the remote signature server 30 together with the access token saved in step S142 (S145).

The log provider 35 of the remote signature server 30 verifies the access token (S146). This verification method is the same as step S53 in FIG. 11. The log provider 35 obtains the viewing log of the signature process and proxy authority setting (S147). The log provider 35 obtains the audit log of the signature process and proxy authority setting from the audit log management table 382 and sends it to the signature application server 40 (S148).

The log viewing unit 47 of the signature application server 40 generates a log screen related to the proxy signature process and transmits it to the representative terminal 11 (S149). The representative terminal 11 displays the log screen on a display device.

Figure 18 shows an example of a proxy signature processing log screen displayed on the representative terminal 11. The proxy signature log screen shows the signature processing log 310 and the proxy authority setting log 330 associated with the signature key ID and proxy ID. In this way, by displaying the proxy authority setting log along with the signature processing, it is possible to simultaneously obtain information to determine the legitimacy of the proxy authority, such as which administrator set the authority for the relevant proxy signature and when it was set. Note that only either the signature processing log 310 or the proxy authority setting log 330 may be displayed.

In the example of Figure 18, the signature processing log 310 includes information such as the user ID of the person requesting the signature key (the signer), the user IDs of the delegate and delegatee of the proxy authority, the user ID of the owner of the signature key, and the hash value of the signature target. Furthermore, the proxy authority setting log 330 includes information such as the ID of the user who set the proxy authority, the user IDs of the delegate and delegatee of the proxy authority, and the user ID of the owner of the signature key.

<Log rotation process>
The log rotation process is described below. Fig. 19A schematically illustrates the log rotation process of the authentication/authorization server 20. The trail management unit 26 generates an audit log from the event log stored in the event log management table 281 and stores it in the audit log management table 282. Fig. 19B schematically illustrates the log rotation process of the remote signature server 30. The trail management unit 36 generates an audit log from the event log stored in the event log management table 381 and stores it in the audit log management table 382.

The remote signing server 30 receives and stores audit log information from the authentication/authorization server 20. Specifically, when the signing key management unit 31 executes the authority setting request shown in step S23 of FIG. 9, it requests a proxy authority setting log from the authentication/authorization server 20 and stores it in the audit log management table 382. In other words, the audit log management table 382 also includes the data in the audit log management table 282.

In addition, when the proxy authority confirmation unit 33 executes the proxy signature shown in step S107 of FIG. 14, it searches the event log management table 381 for a proxy authority setting log related to the signature key ID and the proxy's user ID, links it to the signature processing log, and stores it in the audit log management table 382. As described with reference to FIG. 18, the audit log management table 382 includes a log of the signature key authority setting process in addition to the log of each signature process using the signature key. As described above, the log provider 35 of the remote signature server 30 selects and returns from the audit log management table 382 the log of the specified signature process and the process of setting authority for the proxy for that signature process in response to a request from the signature application server 40.

Figure 20A shows an example of the configuration of the event log management table 281 of the authentication/authorization server 20. The event log management table 281 includes a process ID column 401, a date/time column 402, an operation item column 403, a user ID column 404, and a message column 405. The process ID column 401 indicates the ID of each process, and the date/time column 402 indicates the date and time the process was executed. The operation item column 403 indicates the process content, and the user ID column 404 indicates the ID of the user who requested the process. The message column 405 stores an explanation created by the authentication/authorization server 20 for each process.

Figure 20B shows an example configuration of the event log management table 381 of the remote signature server 30. The event log management table 381 includes a process ID column 421, a date and time column 422, an operation item column 423, a user ID column 424, and a message column 425. The process ID column 421 indicates the ID of each process, and the date and time column 422 indicates the date and time the process was executed. The operation item column 423 indicates the process content, and the user ID column 424 indicates the ID of the user who requested the process. The message column 425 stores an explanation created by the remote signature server 30 for each process.

The present invention is not limited to the above-described embodiments and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and are not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

Furthermore, some or all of the above-mentioned configurations, functions, processing units, etc. may be implemented in hardware, for example by designing them as integrated circuits. Furthermore, the above-mentioned configurations, functions, etc. may be implemented in software by a processor interpreting and executing programs that implement each function. Information such as programs, tables, and files that implement each function can be stored in memory, a recording device such as a hard disk or SSD, or a recording medium such as an IC card or SD card.

Furthermore, the control and information lines shown are those deemed necessary for explanation, and do not necessarily represent all control and information lines on the product. In reality, it is safe to assume that almost all components are interconnected.

11 Representative terminal 13 Agent terminal 15 Key management device 20 Authentication and authorization server 30 Remote signature server 40 Signature application server 271 Account management table 272 Key information management tables 281, 381 Event log management tables 282, 382 Audit log management table 371 Key and certificate management table 481 Signature target document management table 482 Signed document management table

Claims (12)

1. An electronic signature system, comprising:
one or more processors;
one or more storage devices;
The one or more storage devices include:
storing key management information for managing the scope of authority of each of one or more delegates for each of the signature keys of different owners;
The one or more processors:
receiving, from a first terminal, a designation of a first agent, a designation of a first signing key, and a request for a proxy signature;
In response to the request for a proxy signature, where the key management information indicates the authority of the first proxy to perform a proxy signature using the first signature key, a signature process is executed using the first signature key for designated electronic data to generate signed electronic data;
and transmitting the signed electronic data to the first terminal. 2. The electronic signature system according to claim 1,
the one or more storage devices pre-store activation information for activating each of the signature keys of the different owners;
The one or more processors activate the first signature key with the corresponding activation information and perform the signature process. 2. The electronic signature system according to claim 1,
The one or more storage devices include:
a log of authorization settings for each of the one or more agents for each of the different owners' signing keys;
a log of signing transactions using each of the different owners' signing keys;
An electronic signature system, wherein the one or more processors transmit to a second terminal a log of the signature process using the first signature key and a log of the first agent's authority setting for the first signature key. 4. The electronic signature system according to claim 3,
the one or more processors sending an event notification of the signing process to the second terminal;
An electronic signature system that, in response to a viewing request from the second terminal, transmits to the second terminal a log of the signature processing using the first signature key and a log of the first agent's authority setting for the first signature key. 2. The electronic signature system according to claim 1,
The one or more processors:
receiving authentication information of the owner of the first signing key from a second terminal;
comparing the authentication information with pre-registered information on the owner of the first signature key to perform authentication processing on the owner of the first signature key;
After the authentication process has been successfully completed, the electronic signature system receives information about the first agent and scope of authority for the first signature key from the second terminal and registers the information in the key management information. 2. The electronic signature system according to claim 1,
The one or more processors:
performing a first-stage authentication process using the authentication information of the first agent received from the first terminal;
receiving a designation of the first signing key from the first terminal after the first stage authentication process has been successfully completed;
receiving authentication information of the first agent from the first terminal after receiving the designation of the first signing key;
an electronic signature system that executes a signature process using the first signature key after second-stage authentication using the authentication information of the first agent has been successfully completed; 7. The electronic signature system according to claim 6,
An electronic signature system in which the one or more processors, when determining that the authorization token indicates a proxy signature by referring to the authority scope, proxy ID, and signature key information contained in the authorization token provided after the second stage authentication process has been successfully completed, generate a proxy token indicating proxy signature authority. 8. The electronic signature system according to claim 7,
An electronic signature system in which the one or more processors verify that the signature subject and signature key information contained in the authorization token and the proxy token match before the signing process, and that the identifier of the authorization token is included in the proxy token. 2. The electronic signature system according to claim 1,
a first system;
a second system;
The first system comprises:
storing the key management information;
generating a token indicating that the first agent has authority to sign on behalf of the first signature key;
The second system acquires and verifies the token, and then generates a signature value using the first signature key. An electronic signature processing method by an electronic signature system, comprising:
The electronic signature system stores key management information that manages the scope of authority of each of one or more agents for each of different owners' signature keys;
The digital signature processing method includes the steps of: the digital signature system receiving, from a first terminal, a designation of a first agent, a designation of a first signature key, and a request for a proxy signature;
In response to the request for a proxy signature, where the key management information indicates the authority of the first proxy to perform a proxy signature using the first signature key, a signature process is executed using the first signature key for designated electronic data to generate signed electronic data;
The digital signature processing method further comprises transmitting the signed digital data to the first terminal. 11. The digital signature processing method according to claim 10,
The electronic signature system pre-stores activation information for activating each of the signature keys of the different owners;
The electronic signature processing method includes the electronic signature system activating the first signature key with the corresponding activation information and executing the signature processing. 11. The digital signature processing method according to claim 10,
The electronic signature system includes:
a log of authorization settings for each of the one or more agents for each of the different owners' signing keys;
a log of signing transactions using each of the different owners' signing keys;
The electronic signature processing method includes the electronic signature system transmitting a log of the signature processing using the first signature key and a log of the first agent's authority setting for the first signature key to a second terminal.