Electronic signature system and electronic signature processing method

The electronic signature system facilitates secure and efficient proxy signing by managing agent authority and implementing secure authentication protocols, addressing the need for remote signature services.

JP7811900B2Active Publication Date: 2026-02-06HITACHI LTD
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
JP2022195879
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Filing Date
2022-12-07
Publication Date
2026-02-06
Estimated Expiration
2042-12-07

AI Technical Summary

Technical Problem

Existing systems lack the capability for agents to perform electronic proxy signing securely and efficiently, particularly in remote signature services, without managing private keys.

Method used

An electronic signature system that includes key management information to track agent authority, allowing processors to perform signing processes using designated signature keys and transmit signed data, with secure authentication and authorization protocols.

Benefits of technology

Enables secure and efficient electronic proxy signing, ensuring appropriate authorization, internal auditing, and authenticity of signature processing in remote signature services.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007811900000001
    Figure 0007811900000001
  • Figure 0007811900000002
    Figure 0007811900000002
  • Figure 0007811900000003
    Figure 0007811900000003
Patent Text Reader

Abstract

To allow a representative to give a proper electronic signature on a system.SOLUTION: A digital signature system includes one or more processors and one or more storage devices. The one or more storage devices store key management information that manages the range of authorization of each of one or more representatives for each of signing keys of different owners. The one or more processors receive, from a first terminal, designation of a first representative, designation of a first signing key, and a request for vicarious signing. The one or more processors execute a signing process with the first signing key for designated electronic data in response to the request for vicarious signing in which the key management information indicates the authority for the vicarious signing with the signing key by the first representative to generate signed electronic data and transmit it to the first terminal.SELECTED DRAWING: Figure 1A
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to an electronic signature system and an electronic signature processing method, and more particularly to an electronic signature system and an electronic signature processing method that enable proxy electronic signatures. [Background technology]

[0002] In an effort to move away from seals, the introduction of electronic signatures that are similar to registered seals is progressing. Consideration has begun on services such as remote signatures and witness-type electronic signatures, which do not require users to manage private keys, rather than the traditional local signatures that use IC cards.

[0003] Japanese Patent Laid-Open Publication No. 2015-215839 discloses a related technique to the present disclosure, which states (for example, in an abstract) 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, if the agent permission ticket is valid, transmits an application procedure request for the application procedure, 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."

[0004] 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. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Laid-Open No. 2015-215839 Summary of the Invention [Problem to be solved by the invention]

[0006] Generally, an agent may sign on behalf of a principal. For example, a company employee may sign on behalf of the representative. Therefore, a technology that enables an agent to perform electronic proxy signing appropriately on a system is desired. [Means for solving the problem]

[0007] One aspect of the present invention is an electronic signature system that includes one or more processors and one or more storage devices, wherein the one or more storage devices store key management information that manages the scope of authority of each of one or more agents for each of different owners' signature keys, and the one or more processors receive from a first terminal a designation of a first agent, a designation of a first signature key, and a request for an agent signature, and 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 perform a signing 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. [Effects of the Invention]

[0008] According to one aspect of the present invention, an electronic signature by a proxy can be appropriately performed on the system. [Brief explanation of the drawings]

[0009] [Figure 1A] 1 shows an example of the configuration of an electronic signature system. [Figure 1B] An example of a hardware configuration applicable to each component shown in FIG. 1A is shown. [Figure 2] An example of the logical configuration of an authentication / authorization server is shown below. [Figure 3] 1 shows an example of the logical configuration of a remote signing server. [Figure 4] 1 shows an example of the logical configuration of a signature application server. [Figure 5A] 10 shows an example of the configuration of an account management table. [Figure 5B] 10 shows an example of the configuration of an account management table. [Figure 6A] 10 shows an example of the configuration of a key information management table. [Figure 6B] 10 shows an example of the configuration of a key information management table. [Figure 7] 10 shows an example of the configuration of a client management table. [Figure 8] 10 shows an example of the configuration of a key / certificate management table. [Figure 9] FIG. 10 is a sequence diagram illustrating an example of a process for setting delegation authority from a representative to a delegator. [Figure 10] An example of service authentication processing for a proxy will be described below, and a sequence diagram of the processing example will be shown. [Figure 11] 10 shows a sequence diagram of an example process for an agent to select a delegated signing key. [Figure 12] 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. [Figure 13] An example of the configuration of an access token to a signing key is shown below. [Figure 14] 10 shows a sequence diagram of an example of a proxy signing a target document using a delegated signature key by a proxy. [Figure 15] An example of the configuration of a proxy token is shown below. [Figure 16] 10 shows a sequence diagram of a processing example of signature value generation. [Figure 17] 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. [Figure 18] 10 shows an example of a log screen of the proxy signature process displayed on the representative terminal. [Figure 19A] 10 shows a schematic diagram of the log rotation process of the authentication / authorization server. [Figure 19B] 10 illustrates a schematic diagram of a log rotation process of a remote signing server. [Figure 20A] 10 shows an example of the configuration of an event log management table of an authentication / authorization server. [Figure 20B] 10 shows an example of the configuration of an event log management table of a remote signature server. DETAILED DESCRIPTION OF THE INVENTION

[0010] In the following, when necessary for convenience, the description will be divided into multiple sections or embodiments, but unless otherwise specified, they are not unrelated to each other, and one is related to the other as a partial or complete modification, detail, supplementary explanation, etc. Furthermore, in the following, when the number of elements, etc. (including the number, numerical value, amount, range, etc.) is mentioned, it is not limited to that specific number, and may be more or less than the specific number, unless otherwise specified or when it is clearly limited in principle to a specific number, etc.

[0011] The electronic signature system of one embodiment of this specification allows a delegated agent to electronically sign on behalf of a principal. In the following description, a representative of a corporation is used as an example of the principal, and an employee of the corporation is used as an example of the agent. The relationship between the principal and the 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.

[0012] 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 signature key of a representative. The system of one embodiment of this specification realizes the authorization setting and execution of the authorization of the agent.

[0013] Furthermore, a system according to an embodiment of the present specification activates a signing key and generates a signature according to the authorization status of the agent. For example, the system internally centrally manages the activation information of the signing key without disclosing it to the agent. The system activates a signing key according to the agent's authorization. This increases the security of the proxy signature using the signing key.

[0014] The system according to an embodiment of the present specification further enables post-facto verification of electronic proxy signatures by proxy, enables internal auditing of signature operation events, and ensures the authenticity of signature processing in remote signature services.

[0015] FIG. 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 FIG. 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.

[0016] The key management device 15 communicates with the remote signature server 30 and executes the necessary processing. The representative terminal 11, the agent terminal 13, the authentication and authorization server 20, the remote signature server 30, and the 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 one device, or functions implemented in one device may be distributed across multiple devices. For example, the functions of the authentication and authorization server 20 or the signature application server 40 may be included in the remote signature server 30.

[0017] FIG. 1B shows an example of a hardware configuration applicable to each component shown in FIG. 1A. FIG. 1B shows an information processing device having a computer configuration. Each component shown in FIG. 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.

[0018] 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 components of the information processing device 101 are communicably connected to each other via communication means such as a bus (not shown). Note that the information processing device 101 may be configured such that all or part of its configuration is realized by a virtual resource such as a cloud server.

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

[0020] The main memory device 103 is a device that stores programs and data, and is a read-only memory (ROM), a random access memory (RAM), a non-volatile RAM (NVRAM), or the like.

[0021] The auxiliary storage device 104 is, for example, an NVRAM such as an SSD (Solid State Drive), 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 of ​​a cloud server. The auxiliary storage device 104 includes a non-transitory storage medium for storing programs and data. The programs and data stored in the auxiliary storage device 104 are loaded into the main storage device 103 as needed.

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

[0023] The output device 106 is an interface that outputs various types of information, and is, for example, a screen display device such as a liquid crystal monitor, LCD (Liquid Crystal Display), or graphic 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 other devices via some kind of communication means. Some of the components shown in FIG. 1B may be omitted, and other components may be added.

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

[0025] 2 shows an example of the logical configuration of the authentication and authorization server 20. The authentication and 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 units may be implemented by a program or one or more processors that operate in accordance with a program.

[0026] 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.

[0027] 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 confirmation unit 33, a key management device cooperation unit 34, a log provider 35, and a trail management unit 36. These units may be implemented by a program or one or more processors that operate in accordance with a program.

[0028] 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 field 252 included in the key / certificate management table 371 may be implemented in a device with the same specifications as the key management device 15 as a more advanced leak prevention measure.

[0029] 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 units may be implemented by a program or one or more processors that operate in accordance with a program.

[0030] 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 in, for example, an auxiliary storage device.

[0031] Figures 5A and 5B show examples of the configuration 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 of the configuration of the account management table 271 before agent information is registered, and Figure 5B shows an example of the configuration of the account management table 271 after specific agent information has been registered.

[0032] 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.

[0033] 5A and 5B, the user with the user ID "A-1" is the representative who owns the signature key, and the users with the user IDs "A-2" and "A-3" are respectively agents authorized to sign on behalf of the representative using the signature key. As will be described later, the signatures by specific users are authorized and registered by the representative.

[0034] 6A and 6B show examples of the configuration of key information management table 272. Key information management table 272 manages information on signature keys. Fig. 6A shows an example of the configuration of key information management table 272 before proxy information is registered, and Fig. 6B shows an example of the configuration of key information management table 272 after specific proxy information has been registered.

[0035] 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, to refer to signature key information, and to 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 to refer to signature key information.

[0036] 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.

[0037] Fig. 7 shows an example of the configuration of a 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 Fig. 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.

[0038] 8 shows an example of the configuration of key and certificate management table 371. Key and certificate management table 371 manages information related to signature keys. Key and certificate management table 371 includes a signature key ID field 251, a real PIN field 252, a public key certificate identification information field 253, and a public key certificate file field 254.

[0039] 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.

[0040] <Delegation authority setting phase> An example of processing in an electronic signature system according to an embodiment of the present 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 in which proxy authority is granted from the representative to the agent. The representative uses the representative terminal 11 to grant proxy authority to the agent.

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

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

[0043] The representative terminal 11 accesses the redirect URL and transfers an authorization request for authority setting to the authentication and authorization server 20 (S13).

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

[0045] The representative terminal 11 displays a login screen (S15), receives input of authentication information for login from the representative, and transmits it to the authentication and authorization server 20 (S16). Specifically, the user ID and password of the representative are transmitted.

[0046] 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 transmits an access token and a redirect URL to the representative terminal 11. The access token may be a random character string that allows the agent to set the authorization to use the key.

[0047] 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, the signature key management unit 31 analyzes the authentication result to confirm that it is normal and extracts the user ID. Furthermore, the signature key management unit 31 queries the authentication / authorization server for the key owned by the corresponding user ID (S20). The key information provision unit 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.

[0048] The representative terminal 11 receives setting information for the proxy authority 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 transmits the input setting information to the remote signature server 30 (S23).

[0049] 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 and authorization server 20 to set up a proxy authority along with that information (S25). The authority setting unit 22 of the authentication and authorization server 20 registers information for the specified proxy authority in the account management table 271 and the key information management table 272, and returns the result to the remote signature server 30 (S26). The signature key management unit 31 transmits information on the registration result of the proxy authority to the representative terminal 11. The representative terminal 11 displays the information (S27).

[0050] According to the above sequence, for example, the information in account management table 271 shown in Fig. 5A changes to the information in account management table 271 shown in Fig. 5B. User information added to account management table 271 may be registered in advance in a user management table (not shown). Furthermore, according to the above sequence, the information in key information management table 272 shown in Fig. 6A changes to the information in key information management table 272 shown in Fig. 6B. Through the above processing, the owner of a signing key can safely set and register the proxy and scope of authority for that signing key.

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

[0052] In response to a predetermined URL specified by the agent via the input device, the agent terminal 13 accesses the signature application server 40, requests for and acquires a menu screen (S31).

[0053] 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).

[0054] 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 together with the redirect URL (S33).

[0055] The agent terminal 13 transfers the authorization request for the remote signature service to the authentication and authorization server 20 indicated by the redirect URL (S34).

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

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

[0058] 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). When the identity of the representative of the login request is confirmed and the verification is completed successfully, the service authentication unit 23 transmits an authorization code and a 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.

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

[0060] The service authentication request unit 42 of the signature application server 40 transmits a request for an access token together with the authorization code to the authentication and authorization server 20 (S40).

[0061] 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 for permitting use of the remote signature service.

[0062] Service authentication request unit 42 of signature application server 40 transmits the signature service screen to agent terminal 13, and agent terminal 13 displays it (S44).

[0063] 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.

[0064] 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).

[0065] Next, we will explain the process of selecting a delegated signature key by the agent, which is the next process in the proxy signature phase. Figure 11 shows a sequence diagram of an example of the process by which the agent selects a delegated signature key.

[0066] In response to an instruction from the agent, the agent terminal 13 transmits a request for the delegated signature key to the signature application server 40 (S51).

[0067] 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).

[0068] 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 and authorization server 20 about the access token and acquires information linked to the access token. Here, the signature key management unit 31 acquires the user ID of the agent registered in the account management table 271 (S54).

[0069] The signature key management unit 31 further requests the authentication and authorization server 20 for information on the signature key for which the specified user ID is a delegate (signing agent) (S55).

[0070] The key information providing unit 24 of the authentication / authorization server 20 refers to the key information management table 272 and returns signature key information including the key ID of the signature key whose user name is the agent (S56).

[0071] The signature key management unit 31 then requests the authentication and authorization server 20 for signature key ownership information, specifying the received key ID (S57). The key information provision unit 24 refers to the key information management table 272 and responds with information about the owner of the specified key ID (S58).

[0072] 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 transmits the list 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 transmits it to the agent terminal 13 (S60).

[0073] The agent terminal 13 displays the delegated signature key list on the display device (S61), and accepts the selection of the owner and signature key from the agent via the input device (S62).

[0074] Next, we will explain the process of proxy signature key authorization (second-stage authentication and authorization), which is the next process after the proxy signature phase. Figure 12 shows a sequence diagram of an example of key authorization processing when a proxy uses a delegated signature key to perform proxy signing.

[0075] Upon receiving an instruction from the agent regarding the signature key to be used for the proxy signature, the agent terminal 13 transmits a key authorization request indicating the signature key to the signature application server 40 (S71).

[0076] 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 together 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.

[0077] The agent terminal 13 transfers the authorization request for the delegated signature key to the redirect destination authentication and authorization server 20 (S73).

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

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

[0080] The agent terminal 13 transmits the authentication information including the response (signature value) and the public key certificate input by the agent to the authentication and 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 in the agent terminal or a recording medium.

[0081] 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 verifies that the public key certificate registered in the account management table 271 is correct.

[0082] 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 a challenge. The key authorization unit 25 confirms that the response 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 a redirect URL (S79).

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

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

[0085] The key authorization unit 25 of the authentication / authorization server 20 verifies the received authorization code (S82). If the received authorization code is correct, the key authorization unit 25 generates an access token to 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).

[0086] As described above, the security of the proxy signature by the proxy 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 signature. Performing service authentication using a password and ID enables efficient processing.

[0087] Fig. 13 shows an example of the configuration of an access token (authorization token) to the signing key. In the example configuration of Fig. 13, the access token indicates the scope indicating the processing permitted by the access token, the user ID of the agent, the signing key ID, the scope (scope of authority) of the signing key of the user 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 using a private key held by the authentication and authorization server 20. The access token allows the authentication result of the authentication and authorization server 20 to be properly presented to the remote signing server 30.

[0088] Next, the proxy signature process, which is the process that follows the proxy signature phase, will be described. Fig. 14 shows a sequence diagram of an example of proxy signature on a target document by a proxy using a delegated signature key.

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

[0090] 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 a 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 and authorization server 20 (S94).

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

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

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

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

[0095] The proxy authority confirmation unit 33 of the remote signature server 30 transmits the received proxy ticket to the signature application server 40 (S99). Here, the proxy authority confirmation 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).

[0096] The signature request unit 45 of the signature application server 40 transmits a proxy token request together with the proxy ticket and the access token to the authentication and authorization server 20 (S101).

[0097] The key authorization unit 25 of the authentication and authorization server 20 refers to the key information management table 272 to check whether the user indicated by the access token can use the signature key indicated by the access token within the range of the key scope (S102).

[0098] When it is confirmed that the designated user has the authority to use the signature key on behalf of the designated user, the key authorization unit 25 generates a proxy token and transmits it to the signature application server 40 (S103). The signature application server 40 stores the received proxy token in a storage device (S104).

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

[0100] 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 object hash value and signature key ID (information on the signature object and signature key) included in the access token of step S92 match the signature object hash value and signature key ID included in the proxy token. The proxy authority verification unit 33 cooperates with the key management device 15 to generate a signature value using the signature key (S107). This will be described later.

[0101] The proxy authority verification unit 33 transmits the generated signature value together 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).

[0102] 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 the generated document 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).

[0103] Fig. 15 shows an example of the configuration of the above-mentioned proxy token. In the example configuration of Fig. 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.

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

[0105] The key management device cooperation unit 34 of the remote signature server 30 acquires the signature key information of the signature key ID indicated by the proxy token from the key / certificate management table 371 (S121).

[0106] The key management device cooperation unit 34 searches for a key object stored in the key management device 15 (S122). Specifically, the key management device cooperation unit 34 transmits 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.

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

[0108] 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).

[0109] The key management device cooperation unit 34 of the remote signature server 30 transmits a signature value request accompanied by the key object handle and the hash value to the key management device 15 (S128).

[0110] 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).

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

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

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

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

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

[0116] 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 acquires the viewing log of the signature process and the proxy authority setting (S147). The log provider 35 acquires the audit log of the signature process and the proxy authority setting from the audit log management table 382 and transmits it to the signature application server 40 (S148).

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

[0118] 18 shows an example of a log screen for the proxy signature process displayed on the representative terminal 11. The proxy signature log screen shows the signature process log 310 and the proxy authority setting log 330 associated with the signature key ID and the proxy ID. By displaying the proxy authority setting log along with the signature process in this way, it is possible to simultaneously obtain information for determining 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 process log 310 or the proxy authority setting log 330 may be displayed.

[0119] 18, signature processing log 310 includes information such as the user ID of the person requesting the signature key (signer), the user IDs of the delegate and delegatee of the proxy authority, the user ID of the owner of the signature key, the hash value of the signature target, etc. Also, 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, the user ID of the owner of the signature key, etc.

[0120] <Log rotation process> The log rotation process is explained below. FIG. 19A shows a schematic representation of the log rotation process of the authentication and 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 shows a schematic representation of the log rotation process of the remote signing 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.

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

[0122] 14, the proxy authority confirmation unit 33 searches the event log management table 381 for a proxy authority setting log related to the signature key ID and the user ID of the proxy, associates it with 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 authorization setting process for the signature key in addition to the log of each signature process that uses the signature key. As described above, the log provider 35 of the remote signature server 30 selects and returns the log of the specified signature process and the authorization setting process for the proxy for that signature process from the audit log management table 382 in response to a request from the signature application server 40.

[0123] 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 when 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.

[0124] 20B shows an example of the 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 when 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.

[0125] 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 the present invention is 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, or 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.

[0126] Furthermore, the above-mentioned components, functions, processing units, etc. may be realized in part or in whole by hardware, for example, by designing them as integrated circuits. Furthermore, the above-mentioned components, functions, etc. may be realized in software by a processor interpreting and executing a program that realizes each function. Information such as the programs, tables, and files that realize each function can be stored in memory, a storage device such as a hard disk or SSD, or a storage medium such as an IC card or SD card.

[0127] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected. [Explanation of symbols]

[0128] 11 Representative terminal 13 Agent terminal 15 Key management device 20 Authentication and Authorization Server 30 Remote Signing Server 40 Signature Application Server 271 Account Management Table 272 Key Information Management Table 281, 381 Event log management table 282, 382 Audit Log Management Table 371 Key and Certificate Management Table 481 Signature target document management table 482 Signed Document Management Table

Claims

1. 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. 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.

3. 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. 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.

5. 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.

6. 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. 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. 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.

9. 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.

10. 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 electronic signature processing method is 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; The digital signature processing method further comprises transmitting the signed digital data to the first terminal.

11. 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.

12. 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.

Citation Information

Patent Citations

  • Proxy application approval system and proxy application approval method

    JP2015215839A

  • Signature generation device, signature system, signature generation method and program

    JP2016129302A

  • Electronic proxy system and electronic proxy method

    JP2022090506A

  • Document distribution and interaction with delegation of signature authority

    US20170083867A1