Processing authority transfer system and processing authority transfer method
The processing authority delegation system addresses the issue of unintended processing by verifying execution conditions using biometric-based certificates, ensuring authorized and intended processing execution.
Patent Information
- Application Number
- JP2022161248
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-10-05
- Publication Date
- 2026-03-02
- Estimated Expiration
- 2042-10-05
AI Technical Summary
Existing signature verification systems do not define conditions for approving transactions, leading to the risk of unintended processing execution.
A processing authority delegation system that includes a first terminal and an execution entity, where the first terminal holds a certificate indicating delegation details and verifies execution conditions before delegating authority based on biometric information.
Prevents the execution of processes not intended by the delegator, ensuring legitimate and authorized processing.
Smart Images

Figure 0007822296000001 
Figure 0007822296000002 
Figure 0007822296000003
Abstract
Description
[Technical Field]
[0001] The present invention relates to a processing authority delegation system and a processing authority delegation method. [Background technology]
[0002] Background art in this technical field includes Japanese Patent Application Laid-Open No. 2018-14622 (Patent Document 1) and Japanese Patent Application Laid-Open No. 2013-123142 (Patent Document 2).
[0003] Patent Document 1 states, "A signature verification system that verifies a signature using a computer equipped with a processor and memory, comprising: a biometric information acquisition unit that acquires a user's biometric information; a public template certificate generation unit that performs predetermined processing on the biometric information to generate a public template certificate; a key pair generation unit that generates a pair of a private key and a public key; a public key certificate generation unit that generates a public key certificate by attaching a biometric signature to the public key using the biometric information as a key; and a verification unit that accepts a transaction including the public template certificate, the public key certificate, and a signature, verifies the validity of the public key certificate using the public template certificate, and further verifies the signature using the public key certificate" (see abstract).
[0004] Patent Document 2 states that "at the time of registration, a predetermined private key is embedded in the feature of the user's biometric information, and a biometric certificate is issued in combination with the corresponding public key. When signing, a new pair of temporary private key and temporary public key is generated for the signature feature of the user's biometric information, a signature for the message is created using the temporary private key, a commitment is created by embedding the temporary private key in the signature feature, the set of the temporary public key, the signature, and the commitment is used as a biometric signature, and when verifying the biometric signature, the signature is verified with the temporary public key, and a differential private key and differential public key are generated from the biometric certificate, commitment, and temporary public key to verify the correspondence" (see abstract). [Prior art documents] [Patent documents]
[0005] [Patent Document 1] Japanese Patent Application Publication No. 2018-14622 [Patent Document 2] Japanese Patent Application Laid-Open No. 2013-123142 Summary of the Invention [Problem to be solved by the invention]
[0006] The technology described in Patent Document 1 approves a transaction if the transaction is successfully verified based on the verification results of the public template certificate and the public key certificate, but the public template certificate and public key certificate do not define the conditions for approving a transaction or the details of the processing to be performed when the transaction is approved, which raises the risk of processing being performed that is not intended by the user. Furthermore, Patent Document 2 does not describe information that defines these conditions or the details of the processing to be performed.
[0007] Therefore, one aspect of the present invention prevents the execution subject from executing a process that is not intended by the delegator. [Means for solving the problem]
[0008] In order to solve the above problem, one aspect of the present invention employs the following configuration: A processing authority delegation system includes a first terminal and an execution entity of a process, wherein the first terminal holds a first certificate indicating delegation details indicating execution conditions and execution details of the process and an identifier of an execution entity to which authority to execute the process is to be delegated, the first certificate being based on biometric information of the delegator of the process, the execution entity transmitting information indicating whether the execution conditions are satisfied and the identifier of the execution entity to the first terminal, the first terminal performing first certificate verification based on the delegation details and the identifier indicated in the first certificate, and if the first terminal determines, based on the information received from the execution entity, that there is an execution entity that has transmitted information indicating that the execution conditions are satisfied, the first terminal determines whether the identifier of the execution entity matches the identifier indicated in the first certificate, and delegates the authority for the process indicated by the execution details to the execution entity based on the result of the first certificate verification. [Effects of the Invention]
[0009] According to one aspect of the present invention, it is possible to prevent the execution entity from executing a process that is not intended by the delegator.
[0010] Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]
[0011] [Figure 1] 1 is a block diagram showing an example of the configuration of a processing authority delegation system according to a first embodiment. [Figure 2] 10 is a flowchart showing a processing procedure for initial registration of an entrustor template certificate in the first embodiment. [Figure 3] 10 is a flowchart illustrating an example of a specific procedure of an initial registration process according to the first embodiment. [Figure 4A] 10 is a flowchart illustrating an example of a right transfer process according to the first embodiment. [Figure 4B] 10 is a flowchart illustrating an example of a right transfer process according to the first embodiment. [Figure 5] 10 is a flowchart illustrating an example of details of a device certificate verification process according to the first embodiment. [Figure 6] 10 is a flowchart illustrating an example of details of an entrustor template certificate verification process according to the first embodiment. [Figure 7A] FIG. 4 is a diagram illustrating an example of a data structure of a device certificate according to the first embodiment. [Figure 7B] FIG. 10 is a diagram illustrating an example of a data structure of an entrustor template certificate according to the first embodiment. [Figure 8] FIG. 2 is a block diagram illustrating an example of the hardware configuration of an IoT terminal, a verification terminal, and a delegator template repository in the processing authority delegation system according to the first embodiment. [Figure 9] 10 is a flowchart illustrating an example of a verification process by the verification terminal according to the first embodiment. [Figure 10] FIG. 2 is an explanatory diagram illustrating an example of an outline of the overall processing by the processing authority delegation system according to the first embodiment. [Figure 11A] FIG. 10 is an explanatory diagram illustrating an example of delegation authority of a delegator in the second embodiment. [Figure 11B] FIG. 10 is an explanatory diagram illustrating an example of delegation authority of a delegator in the second embodiment. DETAILED DESCRIPTION OF THE INVENTION
[0012] Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings. In this embodiment, the same components are generally designated by the same reference numerals, and repeated explanations will be omitted. It should be noted that this embodiment is merely an example for realizing the present invention, and does not limit the technical scope of the present invention. [Example]
[0013] In this embodiment, after verifying the attributes of the delegator and the signature of the delegator's superior, and verifying whether the conditions for executing the processing are met, the delegator transfers processing authority to the device / application, and the device / application to which the processing authority has been transferred autonomously executes the processing.
[0014] The procedure will be described below with reference to the drawings.
[0015] 1 is a block diagram showing an example of the configuration of a processing authority delegation system. The processing authority delegation system includes, for example, an IoT (Internet of Things) terminal 1000 (an example of a first terminal) having functions as a signing terminal and an issuing terminal, a verification terminal 1100 (an example of a second terminal), a delegator template repository 1200, one or more devices / applications 1300, and one or more IoT terminals 1400, all of which are connected to one another via a network 100 such as the Internet.
[0016] In this figure, the IoT terminal 1000 includes a communication unit 1010, a biometric information acquisition unit 1020, a delegater template generation unit 1030, a device key pair generation unit 1040, a device certificate generation unit 1050, an execution information acquisition unit 1060, a signature generation unit 1070, a delegation information acquisition unit 1080, a key storage unit 1090, a delegater template certificate storage unit 1091, a hash value generation unit 1092, a certificate verification unit 1093, and a delegater condition storage unit 1094.
[0017] The communication unit 1010 communicates between the verification terminal 1100, the delegate template repository 1200, the device / application 1300, and the IoT terminal 1400 via the network 100.
[0018] The biometric information acquisition unit 1020 acquires biometric information such as a fingerprint, vein, and / or face image from a user via, for example, a fingerprint sensor, a vein sensor, and / or a camera, etc. Note that the fingerprint sensor, vein sensor, or camera of a mobile phone or smartphone can be used as the sensor for acquiring biometric information.
[0019] The delegater template generation unit 1030 generates a delegater template as a public template by performing one-way (irreversible) conversion on the biometric information acquired by the biometric information acquisition unit 1020 in accordance with the method of Patent Document 2. Note that as the one-way conversion, a publicly known or well-known conversion process may be applied.
[0020] The device key pair generation unit 1040 generates a pair of a device private key and a device public key using public key cryptography (RSA, DSA (Digital Signature Algorithm), etc.) that is publicly known or well-known. A pair of a device private key and a device public key is generated for each device / application 1300. When a process is executed by the device / application 1300 to which processing authority has been transferred, a signature using the device private key corresponding to the device / application 1300 is attached to execution information (described later). Furthermore, the signature is verified using the device public key corresponding to the device private key.
[0021] The device certificate generation unit 1050 generates a device certificate (an example of a first certificate) as a public key certificate by adding a biometric signature using the biometric information acquired by the biometric information acquisition unit 1020 as a key to the device public key generated by the device key pair generation unit 1040.
[0022] The execution information acquisition unit 1060 acquires the execution information by inputting it from an input device or receiving it from another system, etc. The execution information indicates, for example, the execution content, which is the content of the process executed by the device / application 1300.
[0023] The delegation information acquisition unit 1080 acquires delegation information. The delegation information indicates, for example, an identifier of a delegator who delegates processing authority to the device / application 1300, attributes of the delegator, information about the delegator's superior (if necessary), the expiration date of the delegator template certificate, the serial number of the device / application 1300 to which the processing authority is delegated, the delegation details (including, for example, the execution conditions of the process and the execution details of the process), the expiration date of the device certificate, etc.
[0024] The key storage unit 1090 stores a device private key and a device certificate. The delegater template certificate storage unit 1091 stores a delegater template certificate (an example of a second certificate) generated by a delegater template certificate generation unit 1220 (described later) of the delegater template repository 1200.
[0025] The hash value generation unit 1092 generates a hash value by inputting the execution information acquired by the execution information acquisition unit 1060 and other information into a predetermined hash function.
[0026] The signature generation unit 1070 generates a signature value for the hash value generated by the hash value generation unit 1092 using the device private key.
[0027] The certificate verification unit 1093 verifies the delegate template certificate generated by the delegate template certificate generation unit 1220 and the device certificate generated by the device certificate generation unit 1050 .
[0028] The delegator condition storage unit 1094 stores predetermined delegator conditions. The delegator conditions indicate, for example, attributes of delegators who can delegate processing authority to the device / application 1300. Note that the attributes of delegators who can delegate processing authority indicated by the delegator conditions may be defined for each device / application 1300, for each execution content, or for each combination of a device / application 1300 and an execution content. Furthermore, the delegator conditions may describe a list of identifiers of delegators who can delegate processing authority to the device / application 1300. Note that the delegator conditions may be stored in the delegator template repository 1200 instead of or in addition to the IoT terminal 1000.
[0029] Next, the verification terminal 1100 is configured to include a communication unit 1110 , a certificate verification unit 1120 , and a signature verification unit 1130 .
[0030] The certificate verification unit 1120 verifies the delegate template certificate generated by the delegate template certificate generation unit 1220 and the device certificate generated by the device certificate generation unit 1050, for example, after processing authority is transferred to the device / application 1300 (or after processing is executed by the device / application 1300).
[0031] The signature verification unit 1130 verifies various signatures, for example, after processing authority is transferred to the device / application 1300 (or after processing is executed by the device / application 1300).
[0032] The communication unit 1110 performs communication between the IoT terminal 1000, the delegate template repository 1200, the device / application 1300, and the IoT terminal 1400 via the network 100.
[0033] It is desirable that the verification terminal 1100 be managed by an organization separate from the organization that owns the IoT terminal 1000, the device / application 1300, and the IoT terminal 1400. In other words, the verification terminal 1100 verifies various certificates and various signatures, and thereby the legitimacy of the processing (procedure) is verified by a third party that receives the processing results.
[0034] Next, the delegator template repository 1200 is configured to include a communication unit 1210 , a delegator template certificate generation unit 1220 , a delegator template certificate storage unit 1230 , and a delegation information storage unit 1240 .
[0035] The delegater template certificate generation unit 1220 generates a delegater template certificate from the delegater template generated by the delegater template generation unit 1030 of the IoT terminal 1000.
[0036] The delegate template certificate storage unit 1230 stores the delegate template certificate generated by the delegate template certificate generation unit 1220 .
[0037] The delegation information storage unit 1240 stores, for example, the delegation information acquired by the delegation information acquisition unit 1080 of the IoT terminal 1000.
[0038] The communication unit 1210 performs communication between the IoT terminal 1000, the verification terminal 1100, the device / application 1300, and the IoT terminal 1400 via the network 100.
[0039] Device / application 1300 is an entity that receives the transfer of processing authority and executes processing based on the transferred processing authority. Note that the device / application 1300 may be integrated with either IoT terminal 1000 or IoT terminal 1400, or the application of device / application 1300 may be installed in either IoT terminal 1000 or IoT terminal 1400. In other words, either IoT terminal 1000 or IoT terminal 1400 itself may be an entity that receives the transfer of processing authority and executes processing based on the transferred processing authority.
[0040] Although not shown in the figure, the IoT terminal 1400 has a configuration similar to that of the IoT terminal 1000, for example.
[0041] 2 is a flowchart showing the processing steps for initial registration of an entruster template certificate. In this processing, the IoT terminal 1000 acquires biometric information from a user, and the entruster template repository 1200 generates an entruster template certificate. Each step will be explained below.
[0042] The IoT terminal 1000 performs initial registration (S2010). The specific procedure for initial registration will be explained later with reference to Fig. 3. Through this procedure, a delegate template is generated.
[0043] The IoT device 1000 transmits the delegator template to the delegator template repository 1200 (S2020). At this time, the IoT device 1000 also transmits information required to generate a delegator template certificate, such as the user name, the biometric signature algorithm used to generate the delegator template, and at least part of the delegation information (e.g., the identifier of the delegator who transfers processing authority to the device / app 1300, the delegator's attributes, information about the delegator's superior, and information including the expiration date of the delegator template). Note that a biometric signature may be added to this information to prevent tampering.
[0044] The delegator template repository 1200 receives the delegator template (S2110) and issues a serial number for the received delegator template (S2120). The serial number is a number that is uniquely assigned to the delegator template and is managed in the delegator template repository 1200 to prevent duplication.
[0045] The delegator template repository 1200 assigns a signature to the delegator template, generates a delegator template certificate, and registers it in the delegator template certificate storage unit 1230 (S2130). The delegator template is also assigned the delegator's identifier, information indicating the delegator's attributes, an expiration date, etc. The delegator template may also be assigned the signature of the delegator's superior (generated using any signature algorithm, such as a biometric signature, for example). The data structure of the delegator template certificate will be described later with reference to FIG. 7B. The delegator template repository 1200 also stores at least a portion of the delegation information received from the IoT terminal 1000 in the delegation information storage unit 1240.
[0046] In the first embodiment, it is assumed that the delegate template repository 1200 functions as a trusted third party and that no fraudulent activity will occur.
[0047] For this reason, the signature for the delegate template is generated using, for example, the private key of the certification authority stored in the delegate template repository 1200. This makes it difficult for a third party who does not have the private key of the certification authority to generate a delegate template certificate, making it possible to prevent the issuance of an unauthorized delegate template certificate and the occurrence of impersonation, etc.
[0048] The delegator template repository 1200 transmits the delegator template certificate generated in step S2130 to the IoT terminal 1000 (S2140), and the IoT terminal 1000 receives the delegator template certificate (S2030).
[0049] The IoT terminal 1000 stores the delegator template certificate received in step S2030 in the delegator template certificate storage unit 1091 (S2040). In this way, by the IoT terminal 1000 holding the delegator template certificate, as will be described later, the IoT terminal 1000 can transmit the delegator template certificate to the verification terminal 1100 after the device / app 1300 to which the processing authority has been delegated executes processing, and thus can verify the delegator template certificate even in a situation where the verification terminal 1100 cannot access the delegator template repository 1200.
[0050] This completes the initial registration of the delegate template certificate.
[0051] Next, the specific steps of the initial registration process performed in step S2010 of FIG. 2 will be described with reference to FIG.
[0052] The biometric information acquisition unit 1020 of the IoT terminal 1000 acquires biometric information of the delegate (e.g., the administrator, owner, or user of the IoT terminal 1000) (S3010). The IoT terminal 1000 is connected to biometric sensors such as a fingerprint sensor, a vein sensor, and a camera, and the biometric information acquisition unit 1020 uses these sensors to acquire biometric information such as the delegate's fingerprint, vein, and facial image.
[0053] The delegation information acquisition unit 1080 acquires delegation information via input to the input device of the IoT terminal 1000 (S3020).
[0054] The delegate template generation unit 1030 generates a delegate template as a public template by performing one-way transformation on the delegate's biometric information acquired in step S3010 (S3030). This transformation employs, for example, a biometric encryption method that corrects errors contained in the biometric information to generate unique data and performs encryption processing using the obtained data as a key. Methods that can be used for this transformation include, for example, Fuzzy Commitment, Fuzzy Vault, and the biometric signature disclosed in Patent Document 2. The following description will be based on the biometric signature disclosed in Patent Document 2.
[0055] In a biometric signature, a public template (the delegater template in this embodiment) is generated by performing a one-way conversion on the biometric information. Even if a third party obtains the public template (the delegater template in this embodiment), it is extremely difficult to restore the biometric information, and the public template can be treated as public information, just like a public key.
[0056] The device key pair generation unit 1040 of the IoT terminal 1000 generates a device key pair consisting of a device private key and a device public key (S3040). This device key pair is generated based on a public key cryptosystem known or well known, such as RSA cryptography, DSA cryptography, or Elgamal cryptography.
[0057] The device certificate generation unit 1050 of the IoT terminal 1000 generates a device certificate by adding a biometric signature using the biometric information of the delegator acquired in step S3010 as a key to the device public key obtained in step S3040 (S3050). Furthermore, the device certificate is added with at least part of the delegation information (e.g., the identifier of the delegator who delegates the processing authority to the device / application 1300, the serial number of the device / application 1300 to which the processing authority is delegated, the content of the delegated processing (the execution conditions of the processing and the execution content of the processing), and the expiration date of the device certificate). The data structure of the device certificate is shown in FIG. 7. A This will be explained later with reference to
[0058] The IoT terminal 1000 associates the device private key generated in step S3040 with the device certificate generated in step S3050 and stores them in the key storage unit 1090 (S3060).
[0059] In this way, a device key pair and a device certificate are generated, and the initial registration process in step S2010 is completed.
[0060] 4A and 4B are flowcharts showing an example of a permission transfer process. Note that this process may be executed periodically or may be started in response to an instruction from the user of the IoT terminal 1000, for example.
[0061] The execution information acquisition unit 1060 of the IoT terminal 1000 acquires execution information in accordance with, for example, an input from an input device (S4010).
[0062] The certificate verification unit 1093 searches for and obtains a device certificate corresponding to the execution information obtained in step S4010 from the key storage unit 1090 (S4020). Note that the execution information indicates, for example, the execution content of the process by the device / application 1300, and the execution content is stored in the device certificate as part of the delegation content. Therefore, in step S4020, a device certificate including the execution content indicated by the execution information obtained in step S4010 is obtained. Note that the execution information may further indicate information for searching for a device certificate (for example, an identifier of the delegator or a serial number of the device / application 1300) that is different from the execution content.
[0063] The certificate validation unit 1093 identifies an execution condition included in the delegation content from the device certificate acquired in step S4020, and acquires information for determining whether the identified execution condition is satisfied (S4030). The execution condition is defined by, for example, internal factors such as the internal state of the device / application 1300 and processes already executed by the device / application 1300, and / or external factors such as the environment to which the device / application 1300 belongs and the state of a target to be processed by the device / application 1300. Therefore, in step S4030, for example, the certificate validation unit 1093 transmits a request to acquire the information from a predetermined plurality of devices / applications 1300 (for example, all of the devices / applications 1300) via the communication unit 1010, and receives responses including the information and the device / application serial number of the device / application 1300 from each of the plurality of devices / applications 1300.
[0064] For example, if the device certificate defines an electricity trading system as the device / application 1300, defines that the electricity price is equal to or greater than a predetermined value as an execution condition, and defines selling electricity as an execution content, the certificate verification unit 1093 acquires, for example, the electricity price from an external electricity price monitoring system, as information for determining whether the execution condition is satisfied. Note that the method for acquiring the information for determining whether the execution condition is satisfied may be determined in advance for each execution condition, or may be described as part of the delegation content included in the device certificate.
[0065] The certificate verification unit 1093 verifies the device certificate acquired in step S4020 (S4040). The device certificate includes an expiration date 7060 of the device certificate, delegation details 7080 (including execution conditions and execution details), and a target device / application serial number 7081, which will be described later with reference to FIG. 7A. In this procedure, the certificate verification unit 1093 verifies whether the device certificate is within the expiration date, whether the execution conditions are satisfied, whether a device / application serial number that matches the serial number of the target device / application 1300 has been acquired, etc.
[0066] This allows the correct device / application 1300 to execute a process that is described in a valid device certificate, satisfies the execution conditions, and is in line with the execution content, thereby preventing the execution of a process not intended by the delegator (e.g., the administrator or owner of the IoT terminal 1000).
[0067] Furthermore, in step S3050, a biometric signature using biometric information as a key is added to the device certificate. In step S4040, the certificate verification unit 1093 may further execute a process of verifying the legitimacy of the biometric signature using the delegate template certificate to determine whether the biometric signature was indeed added by the principal. Through this verification, the verification terminal 1100 can verify that the user who generated the delegate template certificate and the user who generated the device certificate are the same. For example, the user who generated the delegate template certificate and the user who generated the device certificate included in the existing transaction are the delegate (e.g., the owner, administrator, or user of the IoT terminal 1000). That is, in this embodiment, this verification indicates that the execution of a legitimate process has been delegated by a legitimate delegate.
[0068] The certificate validation unit 1093 performs conditional branching based on the verification result of step S4040 (S4050), and if all verifications performed in step S4040 are successful, the process proceeds to step S4060 and subsequent steps, but if the verifications fail, the execution condition verification result is assigned a failure (S4091). Details of the processes of steps S4040 and S4050 will be described later using FIG. 5. After the process of step S4091 is performed, the certificate validation unit 1093 notifies the delegate by outputting an alert indicating that the execution condition verification result is a failure to the output device of the IoT terminal 1000 (S4092), and ends the authority delegation process. In addition, when the certificate verification unit 1093 executes the processing of step S4091 (when the execution condition verification result is assigned a failure), it may record a log of the delegate template certificate verification processing and the device certificate verification processing (however, if the delegate template certificate verification processing is not executed, the log of the delegate template certificate verification processing is not recorded) and store it in the IoT terminal 1000.
[0069] The certificate verification unit 1093 searches and obtains from the delegator template certificate storage unit 1091 the delegator template certificate (the device certificate and the delegator template certificate contain the delegator's identifier) that matches the delegator indicated by the device certificate obtained in step S4020 (S4060).
[0070] The certificate verification unit 1093 verifies the delegate template certificate acquired in step S4060 (S4070). Toshiba The certificate includes the expiration date 7160 of the delegater template certificate, delegater attributes 7180, and (if necessary) the delegater's superior signature 7190, which will be described later with reference to Figure 7B. In this procedure, the certificate validation unit 1093 verifies whether the delegater template certificate is within its expiration date, whether the delegater's attributes satisfy the delegater conditions, and if the delegater's attributes do not satisfy the delegater conditions, whether the delegater's superior signature has been affixed.
[0071] This makes it possible to verify that a delegator template that is within its expiration date was created with proper authority (i.e., created by a delegator with proper authority or approved by a superior with proper authority).
[0072] Furthermore, the delegate template certificate is assigned a signature value generated with the certificate authority's private key in step S2130, and in step S4070, the certificate validation unit 1093 may further execute processing to verify the signature value using the certificate authority's public key. Through this verification, the certificate validation unit 1093 can verify that the delegate template certificate was indeed issued by the certificate authority.
[0073] The certificate validation unit 1093 performs conditional branching based on the verification result of step S4070 (S4080), and if all verifications executed in step S4070 are successful, assigns success to the execution condition verification result (S4090) and proceeds to processing from step S4100 onwards, but if the verifications fail, assigns failure to the execution condition verification result (S4091). Details of the processing of steps S4070 and S4080 will be described later using FIG. 6.
[0074] If success is assigned to the execution condition verification result in step S4090, the certificate verification unit 1093 transfers processing authority to the target device / application 1300 and causes the target device / application 1300 to execute the processing (S4100). Specifically, in step S4100, for example, the certificate verification unit 1093 acquires the target device / application serial number and delegation content from the device certificate acquired in step S4020, and the communication unit 1010 instructs the device / application 1300 indicated by the acquired target device / application serial number to execute processing of the execution content indicated by the acquired delegation content.
[0075] The hash value generation unit 1092 generates a hash value for the execution information acquired in step S4010 (S4110).
[0076] The signature generation unit 1070 obtains the device private key corresponding to the device certificate obtained in step S4020 from the key storage unit 1090, and adds a signature with the obtained device private key to the hash value generated in step S4110 (S4120). By adding a signature with the device private key to the execution information, it is possible to prevent tampering with the execution information.
[0077] The certificate validation unit 1093 records a log of the delegator template certificate validation process and the device certificate validation process, as well as a log (received from the device / app 1300) of the process executed by the device / app 1300 to which processing authority was delegated in step S4100 based on the processing authority (the process indicated by the execution content included in the delegation content), and retains these logs in the IoT terminal 1000 (S4130). The delegator, a superior, or a stakeholder related to the process can confirm from these logs and the device certificate that the process executed by the device / app 1300 was executed based on the processing authority delegated from the legitimate delegator, and that the process executed by the device / app 1300 to which processing authority was delegated was the process intended by the delegator.
[0078] The communication unit 1010 transmits the delegater template certificate acquired in step S4070, the device certificate acquired in step S4020, and the execution information to which the signature was added in step S4120 to the verification terminal 1100 (S4140). Note that the verification terminal 1100 may acquire the delegater template certificate from the delegater template repository 1200 (for example, the communication unit 1010 notifies the verification terminal 1100 of the delegater template certificate serial number of the delegater template certificate acquired in step S4070, and the verification terminal 1100 requests the delegater template repository 1200 to transmit the delegater template certificate corresponding to the delegater template certificate serial number).
[0079] Note that either the device certificate verification process in steps S4040 and S4050 or the delegate template certificate verification process in steps S4070 and S4080 may be omitted.
[0080] This completes the authority transfer process by the IoT terminal 1000.
[0081] FIG. 5 is a flowchart showing an example of details of the device certificate verification process in steps S4040 and S4050.
[0082] The certificate validation unit 1093 verifies whether the expiration date 7060 of the device certificate is after the current time (S5010). The certificate validation unit 1093 performs conditional branching based on the verification result of step S5010 (S5020), and if the verification of step S5010 is successful, proceeds to the processing of step S5021 and thereafter, but if the verification of step S5010 is unsuccessful, assigns failure to the device certificate verification result (S5030). Note that if failure is assigned to the device certificate verification result, it is determined that the device certificate verification result in step S4050 is a failure.
[0083] The certificate validation unit 1093 verifies whether the execution conditions are satisfied (S5021). Specifically, for example, the certificate validation unit 1093 determines whether any device / application 1300 has transmitted a response indicating that the execution conditions are satisfied, based on information included in the response received from each device / application 1300 in step S4030 (i.e., information for determining whether the execution conditions are satisfied). If the certificate validation unit 1093 determines that any device / application 1300 has transmitted a response indicating that the execution conditions are satisfied, the certificate validation unit 1093 determines that the verification in step S5021 has succeeded. If the certificate validation unit 1093 determines that any device / application 1300 has transmitted a response indicating that the execution conditions are satisfied, the certificate validation unit 1093 determines that the verification in step S5021 has failed.
[0084] The certificate verification unit 1093 performs conditional branching based on the verification result of step S5021 (S5022), and 1 If the verification is successful, the process from step S5023 onward is executed, and step S502 1If the verification fails, the device certificate verification result is set to "failure" (S5030).
[0085] The certificate validation unit 1093 verifies the serial number of the target device / application 1300 (S5023). Specifically, for example, the certificate validation unit 1093 determines whether any of the devices / applications 1300 that have transmitted responses indicating that the execution conditions are satisfied (the responses include the device / application serial number, as described above) have a device / application serial number that matches the target device / application serial number 7081 in the device certificate. If the certificate validation unit 1093 determines that any of the devices / applications 1300 that have transmitted responses indicating that the execution conditions are satisfied have a device / application serial number that matches the target device / application serial number 7081 in the device certificate, the certificate validation unit 1093 determines that the verification in step S5023 is successful. If the certificate validation unit 1093 determines that no device / application has a device / application serial number that matches the target device / application serial number 7081 in the device certificate, the certificate validation unit 1093 determines that the verification in step S5023 is unsuccessful.
[0086] For example, if the certificate verification unit 1093 determines that there are multiple devices / apps 1300 that have sent responses indicating that the execution conditions are met and have device / app serial numbers that match the target device / app serial number 7081 of the device certificate, it may determine, for example, the device / app 1300 that sent the response first among the multiple devices / apps 1300 as the target device / app 1300 to which processing authority is to be transferred (as a candidate).
[0087] The certificate verification unit 1093 performs conditional branching based on the verification result of step S5023 (S5024), and 3 If the verification is successful, the device certificate verification result is set to success (S5025), and the process returns to step S502. 3 If the verification fails, failure is substituted for the device certificate verification result (S5030). Note that if success is substituted for the device certificate verification result, the device certificate verification result in step S4050 is determined to be successful.
[0088] In the above example, in the process of step S5021 included in the device certificate verification process of step S4040, the certificate verification unit 1093 verifies whether the execution conditions are met and then transfers the processing authority to the target device / application 1300. However, it is also possible to have the target device / application 1300 determine whether the execution conditions are met.
[0089] Specifically, for example, the process of acquiring execution information is omitted in step S4030, and the processes of steps S5021 and S5022 are omitted in the device certificate verification process of step S4040 (in this case, if the process of step S5020 is determined to be "successful," the process proceeds to step S5023), thereby omitting the determination of the execution condition by the certificate verification unit 1093. Furthermore, in step S4100, the certificate verification unit 1093 acquires the target device / application serial number and the delegation content from the device certificate acquired in step S4020, and the communication unit 1010 instructs the device / application 1300 indicated by the acquired target device / application serial number to execute the processing indicated by the execution content if it is determined that the execution condition indicated in the acquired delegation content is satisfied. In other words, the target device / application 1300 acquires execution information, for example, periodically, and determines for itself whether the execution condition is satisfied, and executes the processing of the execution content if it determines that the execution condition is satisfied.
[0090] Furthermore, any one or two of the three verifications shown in FIG. 5 (verification regarding the expiration date, verification regarding the execution conditions, and verification regarding the target device / application serial number) may be omitted.
[0091] This completes the device certificate verification process by the certificate verification unit 1093.
[0092] FIG. 6 shows the delegate template in steps S4070 and S4080. certificate 10 is a flowchart illustrating an example of details of a verification process.
[0093] The certificate validation unit 1093 verifies whether the expiration date 7160 of the delegate template certificate is after the current time (S6010).
[0094] The certificate validation unit 1093 performs conditional branching based on the verification result of step S6010 (S6020), and if the verification is successful, proceeds to the processing of step S6030 and thereafter, but if the verification is unsuccessful, assigns failure to the delegater template certificate verification result (S6043). Note that if failure is assigned to the delegater template certificate verification result, it is determined that the delegater template certificate verification result in step S4080 is a failure.
[0095] The certificate validation unit 1093 verifies the delegater attributes 7180 of the delegater template certificate (S6030). The delegater attributes 7180 include, for example, at least one of the delegater's rating, the delegater's business performance (experience), and the delegater's qualifications (all of which are information indicating the delegater's capabilities).
[0096] The delegator conditions stored in advance in the delegator condition storage unit 1094 define the attributes of a delegator who can delegate processing authority to the device / application 1300. If the attribute indicated by the delegator attribute 7180 is included in the attributes defined in the delegator conditions, it is determined that the verification in step S6030 is successful.
[0097] As described above, the attributes of a delegator to which processing authority indicated by the delegator condition can be transferred may be defined for each device / application 1300, for each execution content, or for each combination of device / application 1300 and execution content. In this case, the certificate validation unit 1093 identifies the execution content indicated by the target device / application serial number 7081 or delegation content 7080 of the device certificate, and verifies whether the delegator condition corresponding to the identified device / application 1300 or execution content is satisfied.
[0098] As described above, the delegator condition may include a list of identifiers of delegators who can delegate processing authority to the device / application 1300. In this case, if the delegator 7070 indicated by the delegator template is included in the list, the certificate validation unit 1093 determines that the verification in step S6030 is successful.
[0099] The certificate validation unit 1093 performs conditional branching based on the verification result of step S6030 (S6040), and if the verification is successful, assigns success to the delegate template certificate verification result (S6050), and if the verification is unsuccessful, proceeds to processing from step S6041 onwards. Note that if success is assigned to the delegate template certificate verification result, the delegate template certificate verification result in step S4080 is determined to be successful.
[0100] The certificate verification unit 1093 verifies the delegater's superior signature 7190 of the delegater template certificate (S6041).
[0101] If the certificate validating unit 1093 determines that the signature value is included in the delegater's superior signature 7190 of the delegater template certificate, it determines that the verification in step S6041 is successful.
[0102] Also, for example, a list of superior identifiers may be described as the delegate condition, and the certificate verification unit 1093 may verify the list of superior identifiers by using the delegate template certificate If the ID of the superior indicated by the delegater superior signature 7190 is included in the list, it may be determined that the verification in step S6041 is successful.
[0103] In addition, the certificate verification unit 1093 may verify the superior's signature according to the algorithm by which the signature was generated (for example, as described in the delegate superior signature 7190 of the delegate template certificate), and may determine that the verification of step S6041 is successful only if the verification of the signature is successful.
[0104] The certificate verification unit 1093 performs conditional branching based on the verification result of step S6041 (S6042), and 1 If the verification is successful, the result of the verification of the delegate template certificate is set to success (S6050), and the process returns to step S604. 1 If the verification fails, the result of the verification of the delegate template certificate is set to failure (S6043).
[0105] It should be noted that one or two of the three verifications shown in FIG. 6 (verification regarding the expiration date, verification regarding the delegate attribute, and verification regarding the delegate superior's signature) may be omitted.
[0106] As a result of the above, the certificate verification unit 1093 certificate The verification process is complete.
[0107] 7A and 7B are diagrams showing the data structures of a device certificate and a delegate template certificate, respectively.
[0108] FIG. 7A is a diagram showing an example of the data structure of the device certificate 7000.
[0109] The device certificate 7000 is data generated in step S3040 in which a biometric signature using biometric information as a key is added to the device public key, and complies with X.509, which is the standard for public key certificates (device certificates in this embodiment) in PKI (Public Key Infrastructure). The following description will be made with reference to the drawings.
[0110] The version 7010 indicates a string that represents the version of the device certificate.
[0111] The delegater template serial number 7020 is a serial number that is uniquely assigned to the delegater template by the delegater template repository 1200 corresponding to the device certificate 7000, and is assigned so as not to be duplicated.
[0112] The device public key serial number 7030 is a unique character string that is assigned to the device public key by the device key pair generation unit 1040 of the IoT terminal 1000, and is generated so that there is no duplication among different device public keys.
[0113] The biometric signature algorithm 7040 indicates an algorithm for generating the biometric signature value 7093 .
[0114] The issuer 7050 indicates the entity that issues the delegate template certificate, that is, the certificate authority.
[0115] The expiration date 7060 indicates the date and time until which the device certificate expires.
[0116] The delegator 7070 indicates the delegator (the subject of the device certificate, that is, the user who requests issuance).
[0117] The delegation content 7080 indicates the execution conditions of the process for which authority is delegated to the device / application 1300, the execution content of the process, and the like.
[0118] The target device / application serial number 7081 indicates the serial number (identifier) of the device / application 1300 to which the authority is to be transferred. In principle, the target device / application serial number 7081 stores the serial number of one device / application 1300, but may store the serial numbers of multiple devices / applications 1300. If the target device / application serial number 7081 stores the serial numbers of multiple devices / applications 1300, when the processing authority is transferred based on the device certificate, the processing authority is transferred to all of the multiple devices / applications 1300.
[0119] The device public key algorithm 7091 indicates an algorithm for generating the device public key 7092 .
[0120] The device public key 7092 indicates the device public key generated in step S3040.
[0121] The biometric signature value 7093 is a value obtained by inputting the data from the version 7010 to the device public key 7092 into a predetermined hash function (e.g., SHA1, SHA256, etc.) and generating a biometric signature using the biometric information as a key for the obtained hash value.
[0122] The above is the data structure of the device certificate 7000.
[0123] Fig. 7B is a diagram showing an example of the data structure of an entrustor template certificate 7100. The entrustor template certificate 7100 is data generated in step S2130 of Fig. 2. The basic data structure is an entrustor template 7192 to which other header information, such as information about the entrustor and the entrustor's superior, is added, and a signature value 7193 is added, and is compliant with X.509, the standard for public key certificates (device certificates in this embodiment) in PKI (Public Key Infrastructure). Each piece of data will be explained below.
[0124] The version 7110 indicates the version of the delegate template certificate as a string.
[0125] The delegater template serial number 7120 is a character string that is uniquely assigned to each delegater template by the delegater template repository 1200, and is assigned so as not to cause duplication.
[0126] The signature algorithm 7140 indicates an algorithm for generating the signature value 7193 to be assigned to the delegate template certificate.
[0127] The issuer 7150 indicates the entity that issues the delegate template certificate, that is, the certificate authority.
[0128] The expiration date 7160 indicates the date and time of expiration of the delegate template certificate.
[0129] The delegator 7170 indicates the delegator who delegates the transfer of processing authority to the target device / application 1300 (the subject of the delegator template certificate, that is, the user who requests issuance).
[0130] The delegator attributes 7180 indicate the attributes of the delegator (for example, the delegator's rating, track record, or experience, as described above).
[0131] The delegate's superior's signature 7190 indicates the signature of the delegate's superior.
[0132] The biometric signature algorithm 7191 indicates an algorithm for generating the delegate template certificate 7100 .
[0133] Delegator template 7192 indicates the delegator template generated in step S3030 of FIG.
[0134] The signature value 7193 is a value obtained by inputting the data from version 7110 to delegate template 7192 into a predetermined hash function (for example, SHA1, SHA256, etc.) and converting the resulting hash value with the private key of the certificate authority.
[0135] The above is the data structure of the delegate template certificate 7100.
[0136] FIG. 8 is a block diagram showing an example of the hardware configuration of the IoT terminal 1000, the verification terminal 1100, the delegator template repository 1200, and the IoT terminal 1400 in the processing authority delegation system.
[0137] The IoT terminal 1000, the verification terminal 1100, the delegate template repository 1200, and the IoT terminal 1400 are each composed of a computer including, for example, a CPU (Central Processing Unit) 10, a main memory device 20, an auxiliary memory device 30, an input device 40, an output device 50, and a communication device 60.
[0138] The CPU 10 includes a biometric information acquisition unit 1020, an authorizer template generation unit 1030, a device key pair generation unit 1040, a device certificate generation unit 1050, an execution information acquisition unit 1060, a signature generation unit 1070, Delegation information acquisition unit 1080, The hash value generation unit 1092, the certificate verification unit 1093, the certificate verification unit 1120, the signature verification unit 1130, and the delegate template certificate generation unit 1220 execute their corresponding programs.
[0139] The main memory device 20 is a device equivalent to the memory of a computer, and stores programs corresponding to the biometric information acquisition unit 1020, the delegate template generation unit 1030, the device key pair generation unit 1040, the device certificate generation unit 1050, the execution information acquisition unit 1060, the signature generation unit 1070, the delegation information acquisition unit 1080, the hash value generation unit 1092, the certificate verification unit 1093, the certificate verification unit 1120, the signature verification unit 1130, and the delegate template certificate generation unit 1220. Each process is realized by executing these programs on the CPU 10.
[0140] The auxiliary storage device 30 is a storage device represented by an HDD (Hard Disk Drive) or an SSD (Solid State Drive), and corresponds to a key storage unit 1090, an entruster template certificate storage unit 1091, an entruster condition storage unit 1094, an entruster template certificate storage unit 1230, and an entrustment information storage unit 1240. The data stored in each unit is accumulated as data on the auxiliary storage device 30.
[0141] The input device 40 includes a mouse and keyboard for receiving input from an operator, and a sensor for acquiring biometric information. The output device 50 includes a display and a printer, and outputs the results of program execution and information on the main memory device 20. The communication device 60 is used when communicating with other devices, and realizes communication via the communication unit 1010, the communication unit 1110, and the communication unit 1210.
[0142] The CPU 10 operates as a functional unit that provides a predetermined function by executing processing in accordance with the programs of each functional unit loaded into the main memory device 20. For example, the CPU 10 functions as the delegator template generation unit 1030 by executing processing in accordance with the delegator template generation program loaded into the main memory device 20. The same applies to other programs. Furthermore, the CPU 10 also operates as a functional unit that provides the functions of each of the multiple processes executed by each program. A computer and a computer system are devices and systems that include these functional units.
[0143] Information such as programs and tables that realize each function can be stored in a storage device such as an auxiliary storage device 30, a non-volatile semiconductor memory, a hard disk drive, or an SSD (Solid State Drive), or in a computer-readable non-transitory data storage medium such as an IC card, an SD card, or a DVD.
[0144] 9 is a flowchart showing an example of the verification process by the verification terminal 1100. In this process, the verification terminal 1100 verifies the delegate template certificate, the device certificate, and the signature attached to the execution information transmitted in step S2140.
[0145] The certificate verification unit 1120 and signature verification unit 1130 of the verification terminal 1100 execute the delegate template certificate verification process (S9010). Specifically, for example, the certificate verification unit 1120 executes the same verification as in step S4070 (note that the verification terminal 1100 acquires the delegate condition from the IoT terminal 1000), and in addition, the signature verification unit 1130 verifies whether there is a signature of the issuer of the delegate template certificate (that is, whether the signature is stored in the signature value 7193). Furthermore, since the signature value 7193 is generated using the private key of the certification authority, the signature verification unit 1130 may verify the signature value 7193 using, for example, the public key of the certification authority.
[0146] The certificate validation unit 1120 performs conditional branching based on the verification result of step S9010 (S9020), and if all verifications performed in step S9010 are successful, proceeds to processing from step S9030 onwards, and if the verification fails, assigns failure to the processing content verification result (S9071).
[0147] The certificate validation unit 1120 executes a device certificate validation process (S9030). Specifically, for example, the certificate validation unit 1120 executes the same validation as in step S4040. Note that the validation in step S5021, which is included in the process of step S4040, requires information indicating whether the execution condition is satisfied, and the validation in step S5023, which is included in the process of step S4040, requires information indicating the device / application serial number of the device / application 1300 that responded that the execution condition is satisfied. For example, in the process of step S4140, the communication unit 1010 includes this information in the execution information (to which a signature is attached) and transmits the information to the verification terminal 1100, thereby disclosing this information to the verification terminal 1100. Alternatively, this information may not be disclosed to the verification terminal 1100. In this case, in step S9030, the validation process similar to that in step S5021 and the validation process similar to that in step S5023 may be omitted.
[0148] The certificate validation unit 1120 performs conditional branching based on the verification result of step S9030 (S9040), and if all verifications performed in step S9030 are successful, proceeds to processing from step S9050 onwards, and if the verification fails, assigns failure to the processing content verification result (S9071).
[0149] The signature verification unit 1130 verifies the signature attached to the execution information (S9050). Specifically, for example, the signature verification unit 1130 verifies whether the signature attached to the execution information was generated using the device private key by using the device public key 7092 included in the device certificate.
[0150] The certificate validation unit 1120 performs a conditional branch based on the verification result of step S9050 (S9060), and if the verification performed in step S9050 is successful, assigns success to the processing content verification result (S9070), and if the verification fails, assigns failure to the processing content verification result (S9071).
[0151] If the certificate verification unit 1120 assigns success to the processing content verification result, it records a log of the delegate template certificate verification, the device certificate verification, and the signature verification added to the execution information by the verification terminal 1100, and stores the log in the verification terminal 1100 (S9080). Note that if the certificate verification unit 1120 assigns failure to the processing content verification result, it may execute the log recording process in step S9080.
[0152] With the above, the verification process by the verification terminal 1100 is completed.
[0153] 9, verification terminal 1100 can verify that a valid device / application 1300 performed processing in accordance with the execution details described in a valid device certificate, that the processing was in accordance with the execution details based on execution information that has been verified to satisfy the execution conditions and not have been tampered with. Furthermore, verification terminal 1100 can verify that a valid delegator template was generated with legitimate authority (i.e., generated by a delegator with legitimate authority or approved by a superior with legitimate authority).
[0154] Fig. 10 is an explanatory diagram showing an example of an outline of the overall processing by the processing authority delegation system. As shown in Fig. 10, the processing authority delegation system may further include an audit server 1600. In addition, in the example of Fig. 10, some of the components included in the processing authority delegation system shown in Fig. 1 are not shown.
[0155] The IoT device 1000 generates a device key pair, a delegator template based on the biometric signature, and a device certificate according to the process shown in Fig. 3. The IoT device 1000 transmits the delegator template to the delegator template repository 1200, which generates a delegator template certificate including the delegator attributes (and the delegator's superior signature, if necessary) according to the method shown in Fig. 2, and stores the certificate in itself and transmits it to the IoT device 1000. The IoT device 1000 stores the generated device certificate and the device private key included in the device key pair in its own key storage unit 1090.
[0156] In step S4120, the IoT terminal 1000 signs the execution information using the device private key. The IoT terminal 1000 executes the device certificate verification process in step S4040 and the delegate template certificate verification process in step S4070, and if these verifications are successful, transfers the processing authority to the target device / application 1300 in step S4100.
[0157] The device / application 1300 to which processing authority has been delegated executes the processing indicated by the execution content. The IoT terminal 1000 stores the processing data 1510 in the log 1520 (S4130). The processing data 1510 includes data generated by the executed processing (the data is transmitted from the device / application 1300 to the IoT terminal 1000) and execution information to which a signature has been added in step S4120. The IoT terminal 1000 may also store logs of the generation processing of each certificate and the logs of the authority delegation processing of FIGS. 4A and 4B in the log 1520.
[0158] In addition, the IoT terminal 1000 may transmit the processing data 1510 to the verification terminal 1100, and the verification terminal 1100 may confirm the processing content (S2401). The verification terminal 1100 obtains the delegater template certificate from the IoT terminal 1000 or the delegater template repository 1200, and obtains the device certificate from the IoT terminal 1000.
[0159] The verification terminal 1100 executes the delegate template certificate verification process of step S9010, the device certificate verification process of step S9030, and the signature verification process attached to the execution information of step S9050, and stores the results of these verification processes and the results of the processing content confirmation process of step S2401 in the log 1150.
[0160] The verification terminal 1100 transmits a log 1150 to the audit server 1600, and the audit server 1600 verifies the received log. Specifically, for example, the audit server 1600 verifies, based on the log 1150, when and for what processing (or when and for what processing authority to be transferred) the delegate template certificate and the device certificate were used, verifies which verification terminal 1100 performed the verification process, and verifies the verification results by the verification terminal 1100. Verification of the log 1150 by the audit server 1600 enables a user (e.g., a third party) of the audit server 1600 to manage whether the cycle of transfer of processing authority is functioning correctly.
[0161] As described above, according to the first embodiment, a delegate template certificate is generated from the user's biometric information, a pair of a device private key and a device public key is generated, a device certificate is generated by adding a biometric signature to the device public key using the user's biometric information as a key, the validity of the device certificate is verified using the delegate template certificate, and further the validity of the user's signature is verified using the device certificate.
[0162] Furthermore, a signature using the certificate authority's private key is added to the delegate template certificate, and when verifying the signature, the validity can be verified using the certificate authority's public key that corresponds to the certificate authority's private key.
[0163] The delegater template certificate also includes the attributes of the delegater and, if necessary, the signature of the delegater's superior, and the delegater template certificate verification process verifies whether the attributes of the delegater satisfy the delegater conditions, or whether the signature of the delegater's superior has been added even if the attributes of the delegater do not satisfy the delegater conditions. This allows a person with legitimate authority to transfer processing authority to device / application 1300.
[0164] The device certificate is assigned with the serial number of device / application 1300, execution conditions, and execution details of the process for which authority is transferred, and the device certificate verification process verifies that the process is executed by a legitimate device / application 1300 and that the execution conditions are met. This not only ensures that the process is executed by a legitimate device / application 1300, but also prevents the device / application 1300 from executing a process not intended by the delegator.
[0165] The processing authority delegation system does not need to include the delegator template repository 1200. In this case, for example, the IoT terminal 1000 executes the processing by the delegator template repository 1200 shown in this embodiment, and the IoT terminal 1000 holds the information held by the delegator template repository 1200 shown in this embodiment. In this case, the communication between the IoT terminal 1000 and the delegator template repository 1200 shown in this embodiment is omitted. [Example]
[0166] In this embodiment, an example of delegation authority of a delegator in the processing authority delegation system of embodiment 1 will be described. Unless otherwise specified below, the configuration of the processing authority delegation system in this embodiment and the processing executed by the processing authority delegation system are the same as those in embodiment 1.
[0167] As described in Example 1, a delegator template certificate and a device certificate corresponding to a certain delegator are generated, and the IoT terminal 1000 verifies the delegator template certificate and the device certificate, thereby transferring processing authority for the execution conditions and execution content indicated by the device certificate to the device / app 1300 indicated by the device certificate.
[0168] 11A is an explanatory diagram showing an example of delegators' delegation authority. In the example of Fig. 11A, there are three delegators (referred to as delegator α, delegator β, and delegator γ, respectively), three IoT terminals 1000 (referred to as IoT terminal 1, IoT terminal 2, and IoT terminal 3, respectively), three devices / applications 1300 (referred to as device / application a, device / application b, and device / application c, respectively), and three processes (process A performed by device / application a, process B performed by device / application b, and process C performed by device / application c).
[0169] Furthermore, device / app a is granted processing authority to execute step A by delegator α, device / app b is granted processing authority to execute step B by delegator β, and device / app c is granted processing authority to execute step C by delegator γ. That is, for example, the IoT terminal 1 generates a delegator template for delegator α and a device certificate for delegator α to transfer processing authority for step A to device / app a, verifies the delegator template certificate corresponding to the delegator template, and verifies the device certificate, and transfers the processing authority to device / app a. The same applies to the transfer of processing authority for step B and the transfer of processing authority for step C.
[0170] Furthermore, step B can be executed only after step A has been executed, and step C can be executed only after step B has been executed. Therefore, for example, if the execution conditions of the device certificate corresponding to the delegator β state that step A has been executed, and the execution conditions of the device certificate corresponding to the delegator γ state that step A has been executed, B If it is described that the above steps have been executed, the processing will be executed in the order of step A, step B, and step C.
[0171] As shown in FIG. 11A, each of the different (series) processes such as process A, process B, and process C may be executed by a different device / application 1300, and the delegate template generation process, device certificate generation process, and various certificate verification processes for transferring processing authority by each of the different devices / applications 1300 may be executed by a different IoT terminal 1000.
[0172] Fig. 11B is an explanatory diagram showing an example of the delegator's delegation authority. The example in Fig. 11B differs from the example in Fig. 11A in that there is one IoT terminal 1000 (referred to as IoT terminal 1), there are six devices / apps 1300 (device / app a', device / app b', and device / app c' have been added), and process A, process B, and process C are also executed by device / app a', device / app b', and device / app c', respectively.
[0173] The example in Figure 11B differs from the example in Figure 11A in that device / app a and device / app a' are granted processing authority to execute step A by delegator α, delegator β, or delegator δ (however, delegator δ requires the signature of a superior); device / app b and device / app b' are granted processing authority to execute step B by delegator β, delegator γ, or delegator δ (however, delegator δ requires the signature of a superior); and device / app c and device / app c' are granted processing authority to execute step C by delegator γ, delegator α, or delegator δ (however, delegator δ requires the signature of a superior).
[0174] Each of the multiple steps (execution contents) can be executed by one device / application 1300, or as in the example of Fig. 11B, can be executed by one of multiple different devices / applications 1300. Also, each of the multiple devices / applications 1300 can be delegated processing authority by one of a single delegator, or as in the example of Fig. 11B, can be delegated processing authority by one of multiple delegators. Also, although not shown in Fig. 11B, multiple different expiration dates can be set for the device certificate even for the same delegation contents, the same device / application serial number, and the same delegator.
[0175] Therefore, the maximum number of device certificates that can be prepared for the transfer of processing authority is the number of target devices / applications x the number of delegators x the number of delegation contents x the number of expiration dates.
[0176] As shown in Example 2, when there are multiple consecutive steps or when multiple devices / applications 1300 can execute the processing of one step, even if the delegator is different for each device / application 1300, the IoT terminal 1000 transfers the processing authority in advance, so that autonomous processing can be executed based on the will of the delegator. [Example]
[0177] In the third embodiment, a use case of the processing authority delegation system in the first embodiment will be described.
[0178] <Use case 1: Setting and processing instructions for equipment on a factory production line> In use case 1, the processing authority delegation system functions as a production management system for a factory manufacturing line, and device / application 1300 is a device included in the factory manufacturing line. Furthermore, a worker on the factory manufacturing line is the delegate, and a supervisor on the factory manufacturing line is the delegate's superior. In other words, a delegate template and a signature for the device certificate are generated using the worker's biometric information. Furthermore, the delegate template may include the supervisor's signature.
[0179] The execution conditions for use case 1 include, for example, that there is free time in the operation schedule of the device, that the excess inventory of the product manufactured by the device is below a specified amount, that the materials for the item manufactured by the device are secured, that an order for the product manufactured by the device has been received, and that there is a storage location for the product manufactured by the device, etc. Furthermore, the delegator conditions for use case 1 include, for example, that the delegator is a worker authorized to operate the device, etc.
[0180] If the verification in steps S4040 and S4080 is successful (however, if the verification in step S40 4 (The verification of the execution conditions in step S5021 included in step S500 may be performed by the device after the processing authority has been transferred to the device.) The processing authority is transferred to the device, and the execution information indicates the execution content, such as autonomous setting changes of the device and starting and stopping of processing by the device, and a signature is added to the execution information using the device private key. This allows the processing to be executed without the delegate having to present their biometric information each time a processing is executed.
[0181] The delegater conditions describe, for example, the correspondence between the importance of the execution content and the qualifications and track record of the worker. In step S6030, it is verified whether the qualifications and track record of the worker indicated in the delegater attribute 7180 of the delegater template certificate satisfy the qualifications and track record (in the delegater conditions) corresponding to the execution content indicated in the delegation content 7080 of the device certificate. If it is determined that this is not satisfied, the verification of step S6041 is executed.
[0182] The IoT terminal 1000 may, for example, periodically check the expiration date 7160 of the delegator template certificate stored in the delegator template certificate storage unit 1091 and the expiration date 7060 of the device certificate stored in the key storage unit 1090, and when the time remaining until these expiration dates falls within a predetermined time, may display a message on the output device 50 of the IoT terminal 1000 urging the user to update the certificate. This also applies to use cases described later.
[0183] Furthermore, purchasers of products manufactured by the device can confirm that the product was manufactured by the device through the execution of a process delegated to the device under the will of the worker (and supervisor) by using the delegate template certificate, device certificate, and execution information (signed).
[0184] <Use Case 2: Energy trading using an autonomous trading system> In use case 2, the processing authority delegation system functions as an energy trading system, and device / app 1300 is an energy trading terminal owned by an intermediary in energy trading. The energy consumer (buyer) and supplier (seller) are the delegates. That is, a delegate template and a signature for a device certificate are generated using biometric information of the energy consumer (buyer) and supplier (seller). The delegate template may also include the signatures of superiors of the energy consumer (buyer) and supplier (seller).
[0185] Execution conditions for the electricity consumer (buyer) side of Use Case 2 include, for example, that the predicted electricity shortage is greater than or equal to a predetermined value, that the source of the electricity consumed is of a predetermined type, that the trading price of electricity is less than or equal to a predetermined value, and that the length of time for which the electricity shortage is predicted is greater than or equal to a predetermined value.
[0186] Furthermore, execution conditions for the power supplier (seller) side of Use Case 2 include, for example, that the predicted surplus amount of power is equal to or greater than a predetermined value, that the source of the supplied power is of a predetermined type, that the trading price of the power is equal to or greater than a predetermined value, and that the length of time for which the surplus of power is predicted is equal to or greater than a predetermined value. The power trading system may include smart meters installed at the power consumer (buyer) or supplier (seller), and power generation facilities installed at the power supplier (seller).
[0187] If the verification in steps S4040 and S4080 is successful (however, if the verification in step S40 4(The verification of the execution conditions in step S5021 included in step S5000 may be performed by the energy trading terminal after the processing authority has been transferred to the energy trading terminal.) The processing authority is transferred to the energy trading terminal, and the energy trading terminal autonomously executes the transaction of electricity between the energy consumer (buyer) and the supplier (seller) as the execution content indicated by the execution information, and furthermore, a signature is attached to the execution information using the device private key. This allows the processing to be executed without the agent having to present their biometric information each time a processing is executed.
[0188] Furthermore, electricity consumers (buyers) and suppliers (sellers) can confirm that the electricity trading process was carried out by the electricity trading terminal at the will of the electricity consumers (buyers) and suppliers (sellers) by using the delegate template certificate, device certificate, and execution information (signed).
[0189] <Use Case 3: Autonomous Inspection Certificate Issuance> In use case 3, the processing authority delegation system functions as an inspection system that inspects products on a factory production line, and device / app 1300 is an issuing device that issues inspection certificates for products manufactured on the production line. An inspection worker on the factory production line is the agent, and an inspection supervisor on the factory production line is the agent's superior. In other words, a delegator template and a signature for a device certificate are generated using the inspection worker's biometric information. The delegator template may also include the signature of the inspection supervisor.
[0190] Conditions for executing Use Case 3 include, for example, that parts procured from a specified supplier are used in the product being inspected, that the product being inspected has been manufactured under the instructions (or delegation) of a worker authorized to use the issuing device, that inspections have been carried out on the product being inspected in accordance with a specified process, and that the product being inspected meets specified performance requirements.
[0191] If the verification in steps S4040 and S4080 is successful (however, if the verification in step S40 4(The verification of the execution conditions in step S5021 included in step S5000 may be performed by the issuing device after the processing authority has been transferred to the issuing device.) The processing authority is transferred to the issuing device, and the issuing device autonomously issues an inspection certificate as the execution content indicated by the execution information. Furthermore, a signature is added to the execution information using the device private key. This allows the processing to be executed without the delegate having to present their biometric information each time the processing is executed.
[0192] Furthermore, a purchaser of a product for which an inspection certificate has been issued by the issuing device can confirm from the delegate template certificate, device certificate, and execution information (signed) that the inspection of the product in question was carried out by the worker (and supervisor) under the will of the worker, through a process delegated to the device, and the product was manufactured.
[0193] <Summary> 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, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, with respect to part of the configuration of each embodiment, addition, deletion, or substitution of other configurations can be applied alone or in combination.
[0194] Furthermore, the above-described configurations, functions, processing units, and processing means may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations and functions may also be implemented in software, with a processor interpreting and executing a program that implements each function. Information such as the programs, tables, and files that implement each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.
[0195] 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]
[0196] 10 CPU, 20 main memory, 30 auxiliary memory, 60 communication device, 1000 IoT terminal, 1030 delegate template generation unit, 1040 device key pair generation unit, 1050 device certificate generation unit, 1060 execution information acquisition unit, 1070 signature generation unit, 1080 delegation information acquisition unit, 1090 key storage unit, 1091 delegate template certificate storage unit, 1092 hash value generation unit, 1093 certificate verification unit, 1100 verification terminal, 1120 certificate verification unit, 1130 signature verification unit, 1200 delegate template repository, 1220 delegate template certificate generation unit, 1230 delegate template certificate storage unit, 1240 delegation information storage unit, 1300 device / application
Claims
1. A processing authority transfer system, A first terminal and a processing execution entity are provided, the first terminal holds a first certificate indicating a delegation content indicating an execution condition and an execution content of the process, and an identifier of an execution subject to which authority to execute the process is delegated, and based on biometric information of a delegator of the process; The execution subject transmits information indicating whether the execution condition is satisfied and an identifier of the execution subject to the first terminal; The first terminal performing a first certificate verification based on the delegation content and the identifier indicated by the first certificate; When it is determined in the first certificate verification that there is an executing subject that has transmitted information indicating that the execution condition is satisfied based on the information received from the executing subject, it is determined whether the identifier of the executing subject matches the identifier indicated by the first certificate; A processing authority delegation system that delegates the authority for the processing indicated by the execution content to the execution subject based on the result of the first certificate verification.
2. 2. The processing authority transfer system according to claim 1, Further comprising a second terminal; the first terminal holds a plurality of the first certificates; each of the plurality of first certificates includes a public key associated with the first certificate; The first terminal maintaining a private key corresponding to each of said public keys; acquiring execution information indicating the execution content; obtaining a first certificate indicating the execution content indicated by the execution information from the plurality of first certificates; performing the first certificate verification based on the acquired first certificate; If the first certificate verification is successful, a signature is added to the execution information based on a private key corresponding to a public key included in the acquired first certificate; transmitting the execution information to which the signature has been added and the acquired first certificate to the second terminal; The second terminal verifies the signature attached to the execution information based on a public key included in the first certificate received from the first terminal.
3. 2. The processing authority transfer system according to claim 1, The first terminal a second certificate indicating an attribute of the delegate and based on the biometric information; a delegator condition regarding attributes of a delegator who can delegate the authority to the execution entity; performing a second certificate validation, including validating whether the attributes indicated by the second certificate satisfy the delegate condition; A processing authority delegation system that delegates the authority to the executing entity based on results of the first certificate verification and the second certificate verification.
4. 4. The processing authority transfer system according to claim 3, The attribute indicates at least one of a rating of the delegator, a business performance of the delegator, and a qualification of the delegator.
5. 4. The processing authority transfer system according to claim 3, the second certificate includes an area for storing a signature of the superior of the delegator; The first terminal In the second certificate verification, a processing authority delegation system that, when it is determined that the attribute indicated by the second certificate does not satisfy the delegate condition, performs verification of the signature of the superior in the second certificate;
6. 2. The processing authority transfer system according to claim 1, A plurality of successive processes can be executed by a plurality of execution entities, A plurality of the delegates correspond to each of the execution entities, The first terminal holding the first certificate corresponding to each combination of a process included in the plurality of processes, an execution subject included in the plurality of execution subjects, and a delegator included in the plurality of delegators; performing the first certificate validation based on any of the first certificates; A processing authority delegation system that delegates authority to execute a process corresponding to the first certificate to an executing entity corresponding to the first certificate based on a result of the first certificate verification.
7. A processing authority transfer method by a processing authority transfer system, The processing authority transfer system includes a first terminal and a processing execution entity, the first terminal holds a first certificate indicating a delegation content indicating an execution condition and an execution content of the process, and an identifier of an execution subject to which authority to execute the process is delegated, and based on biometric information of a delegator of the process; The processing authority transfer method includes: The execution subject transmits information indicating whether the execution condition is satisfied and an identifier of the execution subject to the first terminal; The first terminal performs first certificate verification based on the delegation content and the identifier indicated by the first certificate; When the first terminal determines, in the first certificate verification, based on the information received from the executing subject, that there is an executing subject that has transmitted information indicating that the execution condition is satisfied, it determines whether an identifier of the executing subject matches an identifier indicated by the first certificate; A processing authority transfer method, wherein the first terminal transfers the authority for the processing indicated by the execution content to the execution subject based on a result of the first certificate verification.
Citation Information
Patent Citations
Information processor, acting authority assignment method, program and information processing system
JP2010218291A
Biometric signature system
JP2013123142A
Signature verification system, signature verification method and program
JP2018014622A
Secure communication platform
US20200154278A1
System and method for variable presentation semantics of search results in a search environment
WO2015164278A1