Hardware device

Abstract

Provided is a specific hardware device in a cloud wallet system including a plurality of hardware devices, each having a wallet, the specific hardware device comprising an agent that: identifies a corresponding hardware device, which is a hardware device corresponding to a public key included in qualification information received from the wallet; if the corresponding hardware device is the specific hardware device, decodes authentication data received from a verifier or an issuer; and if the corresponding hardware device is not the specific hardware device, requests the corresponding hardware device to decode the authentication data.

Description

hardware devices

[0001] The present invention relates to a cloud wallet technology for managing digital identities.

[0002] In recent years, the concept of Self-Sovereign Identity (SSI) and the technologies to realize it (W3C Decentralized Identifiers (DID), W3C Verifiable Credentials (VC), etc.) have been considered as a new approach to identity management, in which users manage their own identifiers and identities and control who provides them, without relying on centralized identity providers (ID providers).

[0003] In the world of SSI, there are three parties: Holder, Issuer, and Verifier. A Holder is a user who manages / holds their own digital identity. An Issuer certifies attribute information (name, age, address, etc.) and qualification information (employee of a certain company, membership of a certain service, etc.) to a user, etc., and then issues an attribute / qualification certificate (VC). A Verifier verifies the Holder's attributes, qualifications, etc. by requesting and receiving the attribute / qualification certificate (VC) required to provide a service from the Holder, and makes decisions on providing the service, etc.

[0004] Various binding methods have been studied to show that this VC has been issued to a Holder and presented by that Holder. One of them is a method of showing the association between a VC and a Holder by binding the VC to a device (hardware) equipped with a wallet for storing the VC held by the Holder (Non-Patent Document 1).

[0005] Device binding draft, https: / / github.com / decentralized-identity / wallet-security / blob / main / work_items / device_binding.md, Internet, retrieved April 16, 2024

[0006] In the technology disclosed in Non-Patent Document 1, it is assumed that the device equipped with the wallet that is the target of binding with VC is a terminal held by the user. Meanwhile, it is expected that cloud wallets, which operate in the cloud, will become widespread in the future.

[0007] However, in the case of cloud, there is a possibility that the hardware on which the wallet operates may be changed, making it difficult to apply the technology disclosed in Non-Patent Document 1 to cloud wallets. In other words, with the technology disclosed in Non-Patent Document 1, if the hardware on which the wallet operates is changed, the VC and the hardware will no longer correspond, and authentication by the verifier will fail.

[0008] The present invention has been made in consideration of the above points, and aims to provide a technology that enables appropriate authentication using qualification information such as VC even when the hardware on which the wallet operates is changed.

[0009] According to the disclosed technology, there is provided a hardware device including an agent that is a specific hardware device in a cloud wallet system that includes multiple hardware devices each having a wallet, and that identifies a corresponding hardware device that is a hardware device corresponding to a public key included in credentials received from a wallet, and if the corresponding hardware device is the specific hardware device, performs decryption processing of authentication data received from a verifier or issuer, and if the corresponding hardware device is not the specific hardware device, requests the corresponding hardware device to decrypt the authentication data.

[0010] The disclosed technology provides a technology that enables appropriate authentication using qualification information such as VC even when the hardware on which the wallet operates is changed.

[0011] 1 is a diagram illustrating an image of association in technology. A diagram for explaining a problem. A diagram for explaining a hardware binding sequence based on Non-Patent Document 1. A diagram for explaining a hardware binding sequence based on Non-Patent Document 1. A diagram for explaining an overview of an operation according to the present embodiment. A diagram for explaining a configuration example of a cloud wallet system 100. A diagram for explaining a first example of a HW discovery procedure. A diagram for explaining a second example of a HW discovery procedure. A diagram for explaining a third example of a HW discovery procedure. A diagram for explaining an example of an issuance process procedure in Example 1. A diagram for explaining an example of an authentication process 1 procedure in Example 1. A diagram for explaining an example of an authentication process 2 procedure in Example 1. A diagram for explaining an example of an initial setup and authentication / proof in Example 2. A diagram for explaining an example of an issuance process 1 procedure in Example 2. A diagram for explaining an example of an issuance process 2 procedure in Example 2. A diagram for explaining an example of an authentication process 1 procedure in Example 2. A diagram for explaining an example of an authentication process 2 procedure in Example 2. A diagram for explaining an example of a process performed by an agent 15 at the time of authentication. A diagram for explaining an example of a process performed by an agent 15 at the time of VC issuance. A diagram for explaining an example of a hardware configuration of a device.

[0012] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0013] Below, we will explain a technology that enables appropriate authentication using credentials such as VC even when the device equipped with the wallet is not a terminal owned by the Holder but is hardware that can be changed in the cloud. First, we will explain in more detail the conventional technology and its problems, and then we will explain the technology related to this embodiment.

[0014] (Regarding conventional technology and issues) The Identity Foundation (DIF) Wallet Security Working Group (https: / / github.com / decentralized-identity / wallet-security) has been studying Device Binding (Non-Patent Document 1: https: / / github.com / decentralized-identity / wallet-security / blob / main / work_items / device_binding.md). An illustration of the association in this technology is shown in Figure 1. In the conventional binding method shown in Figure 1, binding between the VC, device, and Holder is performed by including in the VC a public key generated by the hardware of the device on which the wallet operates.

[0015] However, it is difficult to apply the conventional technology disclosed in Non-Patent Document 1 to a configuration in which a wallet operates in the cloud. The reason is that in the case of a cloud, the hardware on which the wallet operates may be changed, and the wallet may be operating on hardware different from that when the VC was issued.

[0016] The above problem will be described with reference to Fig. 2. The upper part of Fig. 2 shows the procedure in the technology disclosed in Non-Patent Document 1, and the lower part shows the procedure when this technology is implemented in a cloud environment.

[0017] In the upper part, S1 (step 1), the user (holder) device transmits a public key generated from the hardware to the issuer. In S2, the issuer issues a VC including the public key to the device. In S3, the device presents the VC including the public key to the verifier. In S4, the verifier authenticates the device by a challenge-response using the public key.

[0018] The bottom part of Figure 2 shows the case where the wallet is cloud-based. Here, it is assumed that the server on which the wallet runs when the VC is issued is different from the server on which the wallet runs when the VC is authenticated. In this case, the public key will be different between when the VC is issued and when the VC is authenticated, so authentication will fail.

[0019] (Example of Hardware Binding) Here, in order to explain the problem more clearly, the sequence of hardware binding based on Non-Patent Document 1 will be explained with reference to Figures 3 to 5. Note that Non-Patent Document 1 itself is publicly known, but Figures 3 to 5 themselves are not publicly known. Furthermore, in the explanation of Figures 3 to 5, "three-party authentication" may be replaced with "certification," "two-party authentication" with "authentication," "proof" with "attestation," and "qualification information" with "credential."

[0020] In FIG. 3, steps S11 to S13 are the initial setting steps, and steps S14 to S20 are the authentication / certification steps.

[0021] 3, the certifying entity 40 performs a wallet audit and three-party authentication for the wallet 10. The certifying entity 40 is an entity that performs authentication, and may be called an "authentication device."

[0022] In S12, the Certifying entity 40 registers the wallet and the three-party certificate in the Trust registry 50. The Trust registry 50 is a trusted storage device and may also be referred to as a "storage device." In S13, the Issuer 20 requests the Trust registry 50 for wallet information that the Issuer 20 requires.

[0023] At S14, the user installs the wallet on the device. At S15, the wallet 10 requests a wallet two-party authentication VC from the Certifying entity 40. At S16, application attestation (SafetyNet / DeviceChecker) is performed between the wallet 10 and the Certifying entity 40. At S17, the wallet 10 generates a hardware-backed key.

[0024] In S18, the wallet 10 transmits the wallet certificate, the key, and the key certificate to the certifying entity 40. In S19, the certifying entity 40 checks the certificates of the app and the key. In S20, the certifying entity 40 issues wallet bilateral authentication credentials to the wallet 10.

[0025] Through the above-described process, the wallet 10 is bound to the hardware and two-party authentication is performed. In this method, since the wallet 10 and the hardware are bound, if the wallet 10 is moved to another piece of hardware, two-party authentication must be obtained again.

[0026] The issuance sequence based on Non-Patent Document 1 will be described with reference to Fig. 4. In S31, the Issuer 20 requests the wallet function from the wallet 10. In S32, the wallet 10 notifies the Issuer 20 of the wallet security function.

[0027] In S33, Issuer 20 requests wallet bilateral authentication credentials from wallet 10. In S34, wallet 10 presents the wallet bilateral authentication credentials to Issuer 20.

[0028] In S35, the Issuer 20 requests a challenge from the wallet 10. In S36, the wallet 10 presents the Issuer 20 with a challenge response using a hardware key.

[0029] In S37, Issuer 20 checks the two-party authentication of the wallet and checks the challenge response.

[0030] In S38, Issuer 20 proposes issuing credentials bound to a hardware key to the wallet 10. In S39, the wallet 10 requests Issuer 20 to issue credentials bound to a hardware key. In S40, Issuer 20 issues credentials bound to a hardware key to the wallet 10.

[0031] In the above S38, the VC is bound to the hardware and issued. In this method, since the wallet and VC are bound to the hardware, if the wallet is moved to another hardware, it is necessary to re-acquire the wallet two-party authentication and VC.

[0032] Next, the verification sequence will be described with reference to Fig. 5. In S51, the verifier 30 requests the wallet function from the wallet 10. In S52, the wallet 10 notifies the verifier 30 of the wallet security function.

[0033] Next, steps S53 to S55 are performed as optional steps. In S53, the verifier 30 requests wallet bilateral authentication credential information from the wallet 10. In S54, the wallet 10 displays the wallet bilateral authentication credential information to the verifier 30. In S55, the verifier 30 checks the wallet bilateral authentication.

[0034] In S56, the verifier 30 requests the wallet 10 to display the credentials bound to the hardware key. In S57, the wallet 10 displays the credentials bound to the hardware key to the verifier 30. In S58, a challenge-response procedure is executed between the verifier 30 and the wallet 10.

[0035] In steps S56 and S57, verification is performed using the credentials bound to the hardware. However, since the wallet and the credentials are bound to the hardware, if the wallet is moved to another hardware, the verification of the credentials will fail.

[0036] In order to solve the above problems, a technique according to the present embodiment will be described below.

[0037] (Outline of the embodiment) In this embodiment, a cloud wallet system is provided with multiple pieces of hardware (HW) each capable of running a wallet. In addition, a resident agent is deployed in each of all HW that a user can use (i.e., that can perform binding), and the agent takes over authentication. In this embodiment, the HW is a TEE (Trusted Execution Environment). However, the HW is not limited to being a TEE. In this embodiment, the HW on which a wallet of a certain user (holder) runs may be changed from one HW to another.

[0038] An outline of the operation according to this embodiment will be described with reference to Fig. 6. In Fig. 6, it is assumed that when a VC is issued, the user's wallet operates on HW1, and when authentication is performed, the wallet operates on HW2.

[0039] As shown in the lower diagram of Fig. 6, each HW discovers each other HW and acquires the public key of each HW. Assume that HW2 receives a challenge request (encrypted data, etc.) during authentication in S4 shown in the upper diagram of Fig. 6. The agent of HW2 determines that decryption by HW1 corresponding to the public key included in the VC is necessary, and requests decryption from the agent of HW1, thereby obtaining the decrypted data required for the challenge response.

[0040] (System Configuration Example) Fig. 7 shows a configuration example of a cloud wallet system 100 according to this embodiment. Note that the "cloud wallet system" may also be called a "cloud wallet device." Furthermore, the hardware and HW described below may also be called a hardware device and an HW device, respectively.

[0041] 7 also shows a Holder 12, an Issuer 20, and a Verifier 30 that communicate with the cloud wallet system 100. The Holder 12 is, for example, a terminal held by a user. The Issuer 20 and the Verifier 30 are, for example, servers.

[0042] As shown in Fig. 7, the cloud wallet system 100 includes multiple pieces of hardware (HW_1 to HW_N) on which wallets 10 operate. Each piece of hardware 160 is equipped with an agent 15 that performs authentication processing with the verifier 30 by challenge-response while cooperating with the other hardware. In this embodiment, the agent 15 resides in the hardware 160. However, the agent 15 is not limited to being resident in the hardware 160. In Fig. 7, PK_n indicates the public key of hardware n (n = 1, 2, ..., N) on which the wallet 10 is operating at the time of issuing the VC.

[0043] The cloud wallet system 100 also includes a wallet management unit 130, a VC request unit 110, a VC receiving unit 120, a VC presenting unit 140, a responding unit 150, a receiving unit 170, and a notifying unit 180.

[0044] The wallet management unit 130 manages the wallet 10. The VC request unit 110 requests the issuer 20 to issue a VC. The VC receiving unit 120 receives the VC issued by the issuer 20. The VC presenting unit 140 presents the VC to the verifier 30. The responding unit 150 responds with a challenge response. The accepting unit 170 accepts a VC issuance request and an authentication request from the holder 12. The notifying unit 180 notifies the holder 12 of the VC issuance notification and the authentication result. An example of the procedure for the operation of a system having the configuration shown in FIG. 7 will be described in detail below.

[0045] (HW Discovery Procedure Example 1) First, HW discovery procedure example 1 will be described with reference to Fig. 8. HW discovery procedure example 1 describes a procedure in which each HW holds in advance a list of all HW and public key combinations. Figs. 8 to 10 show a case in which hardware A to C are provided in the cloud wallet system 100. The wallets 10 and agents 15 of hardware A to C will be represented as wallets 10A to 10C and agents 15A to 15C, respectively.

[0046] 8, in S101, the agent 15A transmits a hardware key request to the agent 15B. In S102, the agent 15B transmits the hardware key of B to the agent 15A.

[0047] In S103, the agent 15A transmits a hardware key request to the agent 15C. In S104, the agent 15C transmits the hardware key of C to the agent 15A. In S105, the agent 15A holds a combination of hardware and a hardware key for each of A to C.

[0048] Similarly, through steps S106 to S110, the agent 15B holds a combination of HW and HW key for each of A to C. Through steps S111 to S115, the agent 15C holds a combination of HW and HW key for each of A to C.

[0049] (HW Discovery Procedure Example 2) Next, HW discovery procedure example 2 will be described with reference to Fig. 9. HW discovery procedure example 2 describes a procedure in which a list of combinations of all HW and public keys is stored in advance in the public key DB 60. The public key DB 60 may be provided within the cloud wallet system 100 or may be provided outside the cloud wallet system 100.

[0050] 9, the public key DB 60 transmits a hardware key request to the agent 15A. In S122, the agent 15A transmits the hardware key of A to the public key DB 60. Similarly, by executing S123 to S126, the public key DB 60 holds a combination of hardware and a hardware key for each of A to C in S127.

[0051] (HW Discovery Procedure Example 3) Next, HW Discovery Procedure Example 3 will be described with reference to Fig. 10. In HW Discovery Procedure Example 3, HW information corresponding to a public key is dynamically acquired each time it is needed. Here, it is assumed that the agent 15B performs this operation.

[0052] In S131, the agent 15B checks the HW key included in the VC. In S132, the agent 15B sends a query including the HW key to the agent 15A. In S133, the agent 15B sends a query including the HW key to the agent 15C.

[0053] 10, in S134, agent 15A compares its own HW public key with the public key received from agent 15B and determines that they match, and in S136 replies that it is the HW key of A. On the other hand, in S135, agent 15C compares its own HW public key with the public key received from agent 15B and determines that they do not match, and in S137 replies that it is not the HW key of C.

[0054] Hereinafter, a first embodiment and a second embodiment will be described as specific examples of the issuance process and the authentication process.

[0055] (First Embodiment: Issuance Process) The issuance process of a VC including a HW key (a public key of the HW) in the first embodiment will be described with reference to Fig. 11. The VC including the HW key corresponds to the "qualification information bound to the hardware key" shown in Fig. 4.

[0056] In S201, the wallet AP is started in the hardware A. In S202, the holder 12 sends a VC issuance request to the wallet 10A. In S203, the wallet 10A requests the HW key from the agent 15A.

[0057] In S203, to ensure that the key generated by the HW is unique to the wallet, information such as the wallet ID is sent to the agent 15A as needed at the time of the request. In other words, if the key generated by the HW is the same regardless of the wallet, the same key will be issued even if different users' wallets request the same key. For this reason, it is necessary to generate the key using, for example, the wallet ID as a seed.

[0058] In S204, the agent 15A transmits its own HW key (the public key of hardware A) to the wallet 10A. Note that in S204, a public key acquired from a predetermined specific HW may be returned instead of the public key of its own HW. In this way, when the public key of a specific HW is used, an agent deployed on HW other than the specific HW will always request an agent deployed on the specific HW to decrypt the encrypted authentication data, making HW discovery unnecessary.

[0059] In S205, wallet 10A sends a VC issuance request including the HW key to Issuer 20. In S206, Issuer 20 sends a challenge request (authentication data encrypted with the HW key) to wallet 10A. In S207, wallet 10A sends the encrypted authentication data to agent 15A.

[0060] In S208, the agent 15A decrypts the authentication data with the private key, and in S209, transmits the decrypted authentication data to the wallet 10A.

[0061] In S210, wallet 10A sends a challenge response (decryption authentication data) to Issuer 20. In S211, Issuer 20 checks the challenge response and determines that it is OK. In S212, Issuer 20 issues a VC including the HW key to wallet 10A. In S213, wallet 10A sends a VC issuance notification to Holder 12.

[0062] (Embodiment 1: Authentication Process 1) Next, authentication process 1 using a VC including a HW key in embodiment 1 will be described with reference to Fig. 12. Authentication process 1 is an example in which authentication is performed using the same HW as when the VC was issued.

[0063] In S221, the wallet AP is started in hardware A. In S222, Holder 12 sends an authentication request to wallet 10A. In S223, wallet 10A sends a VC including the HW key as an authentication request to Verifier 30. In S224, Verifier 30 sends a challenge request (authentication data encrypted with the HW key) to wallet 10A.

[0064] In S225, the wallet 10A transmits the VC including the HW key and the encrypted authentication data to the agent 15A.

[0065] In S225, when performing authentication, it is necessary to generate the same key as when the VC was issued, so it is necessary to request regeneration of the key by passing the information provided in the seed when the VC was issued, such as the wallet ID, to the agent 15A. In other words, in S225, in order to regenerate the associated key, it is necessary to send the information such as the wallet ID sent during the issuance process.

[0066] In S226, the agent 15A checks the HW key included in the VC and determines that the key belongs to its own HW. In S227, the agent 15A decrypts the authentication data with the private key. In S228, the agent 15A transmits the decrypted authentication data to the wallet 10A.

[0067] In S229, the wallet 10A transmits a challenge response (decrypted authentication data) to the verifier 30. In S230, the verifier 30 checks the challenge response and determines that it is OK. In S231, the verifier 30 transmits an authentication pass notification to the wallet 10A. In S232, the wallet 10A transmits an authentication pass notification to the holder 12.

[0068] (Embodiment 1: Authentication Process 2) Next, authentication process 2 using a VC including a HW key in embodiment 1 will be described with reference to Fig. 13. Authentication process 2 is an example in which authentication is performed using HW different from that used when issuing the VC.

[0069] In S242, the VC is taken over from wallet 10A to wallet 10B. The wallet AP is stopped in wallet 10A (S241), and the wallet AP is started in wallet 10B (S243).

[0070] In S244, Holder 12 transmits an authentication request to wallet 10B.

[0071] In S245, the wallet 10B transmits a VC including the HW key as an authentication request to the verifier 30. In S246, the verifier 30 transmits a challenge request (authentication data encrypted with the HW key) to the wallet 10B.

[0072] In S247, the wallet 10B transmits the VC including the HW key and the encrypted authentication data to the agent 15B.

[0073] In S247, when performing authentication, it is necessary to generate the same key as when the VC was issued, so it is necessary to request regeneration of the key by passing the information provided in the seed when the VC was issued, such as the wallet ID. In other words, in S247, in order to regenerate the associated key, information such as the wallet ID sent during the issuance process is sent.

[0074] In S248, the agent 15B checks the HW key included in the VC and determines that the key belongs to another HW. In S249, the agent 15B acquires HW information from a list or dynamically and determines that the key belongs to A.

[0075] In S250, the agent 15B transmits encrypted authentication data (decryption request) to the agent 15A. Note that, in this case, in order to regenerate the associated key, information such as the wallet ID transmitted during the issuance process is transmitted.

[0076] In S251, the agent 15A decrypts the authentication data with the private key. In S252, the agent 15A transmits the decrypted authentication data to the agent 15B. In S253, the agent 15B transmits the decrypted authentication data to the wallet 10B.

[0077] In S254, wallet 10B transmits a challenge response (decrypted authentication data) to Verifier 30. In S255, Verifier 30 checks the challenge response and determines that it is OK. In S256, Verifier 30 transmits an authentication pass notification to wallet 10B. In S257, wallet 10B transmits an authentication pass notification to Holder 12.

[0078] (Example 2: Initial Setting, Authentication / Certification) Next, Example 2 will be described. In Example 2, an example of processing will be described when a wallet authentication certificate including a HW key (a public key of the HW) is used. Note that the "wallet authentication certificate" corresponds to the "wallet two-party authentication credential information" shown in FIG. 5. The "wallet authentication certificate" is information that certifies that the wallet is authenticated. Note that the wallet authentication certificate and VC may be collectively referred to as credential information.

[0079] First, an example of a procedure relating to the initial setting and authentication / certification in the second embodiment will be described with reference to Fig. 14. Steps S261 to S264 are the initial setting procedure, and steps S265 to S272 are the authentication / certification procedure.

[0080] In S261, the certifying entity 40 performs a wallet audit and authentication for the wallet 10A. In S262, the certifying entity 40 performs a wallet audit and authentication for the wallet 10B.

[0081] In S263, the Certifying entity 40 registers the wallet and the certificate with the Trust registry 50. In S264, the Issuer 20 requests the Trust registry 50 for wallet information.

[0082] In S265, the wallet AP is installed in hardware A. In S266, the wallet 10A requests a wallet authentication certificate from the certifying entity 40. In S267, application authentication is performed between the wallet 10A and the certifying entity 40.

[0083] In S268, the wallet 10A requests the HW key from the agent 15A. In S268, since the key generated from the HW is unique to the wallet, information such as the wallet ID is sent as needed at the time of the request. In S269, the agent 15A sends its own HW key to the wallet 10A.

[0084] In S270, the wallet 10A transmits the wallet certification, the HW key, and the HW key certification to the certifying entity 40.

[0085] In S271, the certifying entity 40 checks the authentication of the wallet application and the key, and in S272, the certifying entity 40 issues a wallet authentication certificate to the wallet 10A.

[0086] (Example 2: Issuance Process 1) Next, an issuance process 1 of a VC including a HW key in Example 2 will be described with reference to Fig. 15. Issuance process 1 is a processing example in which a VC is issued using the same HW as when a wallet authentication certificate is issued.

[0087] In S281, the wallet AP is started up. In S282, the Holder 12 sends a VC issuance request to the wallet 10A.

[0088] In S283, wallet 10A transmits a wallet authentication certificate (VC issuance request) to Issuer 20. Note that, regarding the transmission of S283, a request for wallet functions from Issuer 20 may be made in advance, wallet 10A may respond with wallet security functions, and then wallet 10A may transmit this certificate as a response to the request for wallet authentication certificate from Issuer 20.

[0089] In S284, Issuer 20 transmits a challenge request (authentication data encrypted with the HW key) to wallet 10A. In S285, wallet 10A transmits the wallet authentication certificate and the encrypted authentication data to agent 15A.

[0090] In S286, the agent 15A checks the HW key included in the authentication certificate and determines that the key belongs to its own HW.

[0091] In S287, the agent 15A decrypts the authentication data with the private key, and in S288, transmits the decrypted authentication data to the wallet 10A.

[0092] In S289, the wallet 10A transmits a challenge response (decrypted authentication data) to the Issuer 20. In S290, the Issuer 20 checks the wallet authentication and the challenge response and determines that they are OK.

[0093] In S291, Issuer 20 issues a VC including a HW key to wallet 10A. Note that with regard to the issuance in S291, Issuer 20 may propose issuance of a VC including a HW key, and the VC may be issued in response to a request from wallet 10A in response to that proposal. In S292, wallet 10A sends a VC issuance notification to Holder 12.

[0094] (Embodiment 2: Issuance Process 2) Next, with reference to Fig. 16, an issuance process 2 of a VC including a HW key in embodiment 2 will be described. Issuance process 2 is a processing example in which a VC is issued using HW different from that used when issuing a wallet authentication certificate.

[0095] In S302, the authentication certificate is taken over from wallet 10A to wallet 10B. The wallet AP in wallet 10A stops (S301), and the wallet AP in wallet 10B starts (S303).

[0096] In S304, Holder 12 sends a VC issuance request to wallet 10B.

[0097] In S305, wallet 10B transmits a wallet authentication certificate as a VC issuance request to Issuer 20. Note that, regarding the transmission of S305, a request for wallet functions from Issuer 20 may be made in advance, wallet 10B may respond with wallet security functions, and then wallet 10B may transmit this certificate as a response to the request for wallet authentication certificate from Issuer 20.

[0098] In S306, Issuer 20 transmits a challenge request (authentication data encrypted using the HW key) to wallet 10B.

[0099] In S307, the wallet 10B transmits the wallet authentication certificate and the encrypted authentication data to the agent 15B.

[0100] In S308, the agent 15B checks the HW key included in the authentication certificate and determines that the key belongs to another HW. In S309, the agent 15B acquires HW information from a list or dynamically and determines that the key belongs to A.

[0101] In S310, the agent 15B transmits encrypted authentication data (decryption request) to the agent 15A. Note that, in this case, in order to regenerate the associated key, information such as the wallet ID transmitted during the issuance process is transmitted.

[0102] In S311, the agent 15A decrypts the authentication data with the private key. In S312, the agent 15A transmits the decrypted authentication data to the agent 15B. In S313, the agent 15B transmits the decrypted authentication data to the wallet 10B.

[0103] In S314, wallet 10B sends a challenge response (decryption authentication data) to Issuer 20. In S315, Issuer 20 checks the challenge response and determines that it is OK. In S316, Issuer 20 issues a VC including the HW key to wallet 10B. Note that with regard to the issuance in S316, Issuer 20 may propose issuance of a VC including the HW key from Issuer 20, and issue the VC in response to a request from wallet 10B.

[0104] In S317, the wallet 10B sends a VC issuance notification to the Holder 12.

[0105] (Embodiment 2: Authentication Process 1) Next, authentication process 1 using a VC including a HW key in embodiment 2 will be described with reference to Fig. 17. Authentication process 1 is an example in which authentication is performed using the same HW as when the wallet authentication certificate was issued.

[0106] In S321, the wallet AP of hardware A is started. In S322, Holder 12 sends an authentication request to wallet 10A. In S323, wallet 10A sends a VC including a wallet authentication certificate and a HW key as an authentication request to Verifier 30. Note that in S323, the VC may be sent as a response to the request from Verifier 30 after checking wallet authentication using the wallet authentication certificate.

[0107] In S324, the verifier 30 checks the wallet authentication and determines that it is OK.

[0108] Note that S324 may be optionally omitted. When omitted, the sequence will be the same as in Example 1. If a challenge request based on the wallet authentication certificate is received from the verifier during this processing, the wallet 10A requests the agent 15A of its own HW to decrypt the encrypted authentication data, as when a VC is issued (FIG. 15), the agent 15A checks the HW key included in the wallet authentication certificate, decrypts the encrypted authentication data by itself, and returns the decrypted authentication data to the wallet 10A, and the wallet 10A performs a challenge response using the decrypted authentication data.

[0109] In S325, the verifier 30 transmits a challenge request (authentication data encrypted with the HW key) to the wallet 10A.

[0110] In S326, the wallet 10A transmits the VC including the HW key and the encrypted authentication data to the agent 15A. Note that when performing authentication, it is necessary to generate the same key as when the VC was issued, so in S326, information such as the wallet ID is transmitted.

[0111] In S327, the agent 15A checks the HW key included in the VC and determines that the key belongs to its own HW. In S328, the agent 15A decrypts the authentication data with the private key. In S329, the agent 15A transmits the decrypted authentication data to the wallet 10A.

[0112] In S330, the wallet 10A transmits a challenge response (decrypted authentication data) to the verifier 30. In S331, the verifier 30 checks the challenge response and determines that it is OK. In S332, the verifier 30 transmits an authentication pass notification to the wallet 10A. In S333, the wallet 10A transmits an authentication pass notification to the holder 12.

[0113] (Embodiment 2: Authentication Process 2) Next, authentication process 2 using a VC including a HW key in embodiment 2 will be described with reference to Fig. 18. Authentication process 2 is an example in which authentication is performed using HW different from that used when issuing the wallet authentication certificate.

[0114] In S341, VC is taken over from wallet 10A to wallet 10B. The wallet AP in wallet 10A is stopped (S340), and the wallet AP in wallet 10B is started (S342).

[0115] In S343, Holder 12 transmits an authentication request to wallet 10B. In S344, wallet 10B transmits a VC including a wallet authentication certificate and an HW key to Verifier 30 as an authentication request. Note that the transmission of S344 may be performed in advance after a request for wallet functions from the Verifier has been made and a wallet security function response from wallet 10B has been made, followed by a subsequent transmission of the VC as a response to a request for a wallet authentication certificate from Verifier 30. Furthermore, the VC may be transmitted as a response to a request from Verifier 30 after wallet authentication has been checked.

[0116] In S345, the verifier 30 checks the wallet authentication and determines that it is OK.

[0117] Note that S345 may be optionally omitted. When omitted, the sequence is the same as in Example 1. If a challenge request based on the wallet authentication certificate is received from the verifier 30 during this processing, the wallet 10B requests the agent 15B of its own HW to decrypt the encrypted authentication data, as when a VC is issued ( FIG. 16 ), the agent 15B checks the HW key included in the wallet authentication certificate, requests the agent 15A of the HW corresponding to the HW key included in the wallet authentication certificate to decrypt the encrypted authentication data, and returns the decrypted authentication data to the wallet 10B, and the wallet 10B performs a challenge response using the decrypted authentication data.

[0118] In S346, the verifier 30 transmits a challenge request (authentication data encrypted with the HW key) to the wallet 10B.

[0119] In S347, the wallet 10B transmits the VC including the HW key and the encrypted authentication data to the agent 15B. In order to regenerate the associated key, information such as the wallet ID is sent in S347.

[0120] In S348, the agent 15B checks the HW key included in the VC and determines that the key belongs to another HW. In S349, the agent 15B acquires HW information from a list or dynamically and determines that the key belongs to A.

[0121] In S350, the agent 15B transmits encrypted authentication data (decryption request) to the agent 15A. Note that, in this case, information such as the wallet ID is transmitted in order to regenerate the associated key.

[0122] In S351, the agent 15A decrypts the authentication data with the private key. In S352, the agent 15A transmits the decrypted authentication data to the agent 15B. In S353, the agent 15B transmits the decrypted authentication data to the wallet 10B.

[0123] In S354, wallet 10B transmits a challenge response (decrypted authentication data) to Verifier 30. In S355, Verifier 30 checks the challenge response and determines that it is OK. In S356, Verifier 30 transmits an authentication pass notification to wallet 10B. In S357, wallet 10B transmits an authentication pass notification to Holder 12.

[0124] (Example of Agent Operation During Authentication) Next, an example of the procedure of processing executed by the agent 15 during authentication will be described with reference to the flowchart in Fig. 19. Note that the procedure shown in Fig. 19 is common to the first and second embodiments.

[0125] In S401, the agent 15 receives the VC including the HW key and the encrypted authentication data from the wallet 10.

[0126] In S402, the agent 15 checks the HW key included in the VC. In S403, the agent 15 determines whether the HW key belongs to its own HW. If the determination result is No, the process proceeds to S404, and if the determination result is Yes, the process proceeds to S408.

[0127] In S404, the agent 15 acquires information on the HW corresponding to the HW key from a list or dynamically acquires the information.

[0128] In S405, the agent 15 transmits the encrypted authentication data to the agent of the HW identified in S404 and requests it to decrypt the data.

[0129] In S406, the agent 15 receives the decryption authentication data from the agent of the HW identified in S404. In S407, the agent 15 returns the decryption authentication data to the wallet 10.

[0130] In S408, which is reached when the determination in S403 is No, the agent 15 decrypts the encrypted authentication data with the private key of its own HW, acquires the decrypted authentication data, and then proceeds to S407.

[0131] As mentioned above, the agent 15 may obtain the public key to be passed to the issuer 20 from a specific TEE (hardware). In this case, an agent deployed on hardware other than the specific hardware will always request the agent deployed on the specific hardware to decrypt the encrypted authentication data, making hardware discovery unnecessary.

[0132] (Example of Agent Operation When Issuing a VC) An example of the procedure of processing executed by the agent 15 when issuing a VC will be described with reference to the flowchart of Fig. 20. This procedure is the procedure in the second embodiment.

[0133] In S411, the agent 15 receives the wallet authentication certificate and the encrypted authentication data from the wallet 10. In S412, the agent 15 checks the HW key included in the wallet authentication certificate.

[0134] In S413, the agent 15 determines whether the HW key is for its own HW. If the determination result is No, the process proceeds to S414, and if Yes, the process proceeds to S418.

[0135] In S414, the agent 15 acquires the HW information corresponding to the HW key from a list or dynamically acquires the information.

[0136] In S415, the agent 15 transmits the encrypted authentication data to the agent of the HW identified in S414 and requests it to decrypt the data.

[0137] In S416, the agent 15 receives the decryption authentication data from the agent of the HW identified in S414. In S417, the agent 15 returns the decryption authentication data to the wallet 10.

[0138] In S418, which is reached when the determination in S413 is No, the agent 15 decrypts the encrypted authentication data with the private key of its own HW, acquires the decrypted authentication data, and then the process proceeds to S417.

[0139] (Hardware Configuration Example) Any of the systems / devices (cloud wallet system 100, hardware 160, etc.) described in this embodiment can be realized, for example, by having a computer execute a program. This computer may be a physical computer or a virtual machine on the cloud.

[0140] That is, the device can be realized by executing a program corresponding to the processing performed by the device using hardware resources such as a CPU and memory built into a computer. The program can be recorded on a computer-readable recording medium (such as a portable memory) and stored or distributed. The program can also be provided via a network such as the Internet or email.

[0141] Fig. 21 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 14 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, etc., which are all connected to each other via a bus B. The computer may further include a GPU.

[0142] The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0143] The memory device 1003 reads and stores a program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes functions related to the device in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network, etc. The display device 1006 displays a GUI (Graphical User Interface) or the like according to the program. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, etc., and is used to input various operation instructions. The output device 1008 outputs the results of calculations.

[0144] (Summary of the embodiment, effects, etc.) As explained above, the technology described in this embodiment makes it possible to properly perform authentication using qualification information such as VC even when the hardware on which the wallet operates is changed.

[0145] Specifically, for example, even if Holder 12's wallet operates on hardware different from that used when Issuer 20 issued the VC, it is possible for Verifier 30 to use a VC containing a public key generated from the hardware in its VC verification process.

[0146] The following additional notes are provided regarding the above-described embodiments.

[0147] <Notes> (Note 1) A specific hardware device in a cloud wallet system comprising multiple hardware devices each having a wallet, the hardware device comprising an agent that identifies a compatible hardware device that is a hardware device corresponding to a public key included in credentials received from a wallet, and if the compatible hardware device is the specific hardware device, performs decryption processing of authentication data received from a verifier or issuer, and if the compatible hardware device is not the specific hardware device, requests the compatible hardware device to decrypt the authentication data. (Note 2) The hardware device according to Note 1, wherein when the verifier verifies a VC (Verifiable Credential), the credentials are a VC, and when the issuer issues the VC, the credentials are a wallet authentication certificate. (Supplementary Item 3) The hardware device according to Supplementary Item 1, wherein the agent in the specific hardware device: obtains public keys from agents in each of the other hardware devices and holds combinations of hardware devices and public keys, sends the public key corresponding to the specific hardware device to the public key DB in response to a request from a public key DB, or obtains information on the hardware devices corresponding to the public key by sending an inquiry including the public key to the agent in each of the other hardware devices. (Supplementary Item 4) The hardware device according to Supplementary Item 1, wherein the agent in the specific hardware device obtains information on the hardware devices corresponding to the public key by making an inquiry to the agent of each hardware device.

[0148] Although the present embodiment has been described above, the present invention is not limited to such a specific embodiment, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims.

[0149] 12 Holder 20 Issuer 30 Verifier 40 Certifying entity 50 Trust registry 60 Public key DB 10 Wallet 15 Agent 100 Cloud wallet system 110 VC request unit 120 VC receiving unit 130 Wallet management unit 140 VC presentation unit 150 Response unit 160 Hardware 170 Acceptance unit 180 Notification unit 1000 Drive device 1001 Recording medium 1002 Auxiliary storage device 1003 Memory device 1004 CPU 1005 Interface device 1006 Display device 1007 Input device 1008 Output device

Claims

1. A specific hardware device in a cloud wallet system comprising multiple hardware devices each having a wallet, the hardware device comprising an agent that identifies a corresponding hardware device that is a hardware device corresponding to a public key included in credentials received from a wallet, and if the corresponding hardware device is the specific hardware device, performs decryption processing of authentication data received from a verifier or issuer, and if the corresponding hardware device is not the specific hardware device, requests the corresponding hardware device to decrypt the authentication data.

2. The hardware device of claim 1, wherein when the verifier verifies a VC (Verifiable Credential), the credential is a VC, and when the issuer issues a VC, the credential is a wallet authentication certificate.

3. The hardware device according to claim 1, wherein the agent in the specific hardware device: obtains public keys from agents in each of the other hardware devices and stores combinations of hardware devices and public keys; sends the public key corresponding to the specific hardware device to the public key DB in response to a request from the public key DB; or obtains information about the hardware device corresponding to the public key by sending a query including the public key to the agent in each of the other hardware devices.

4. The hardware device according to claim 1, wherein the agent in the specific hardware device obtains information about the hardware device corresponding to the public key by inquiring of an agent in each hardware device.

Images