WO2025224893A1 - Hardware device - Google Patents

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

The present invention relates to cloud wallet technology for managing digital identities.

In recent years, the concept of Self-Sovereign Identity (SSI) and the technologies to implement 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 they provide to, without relying on centralized identity providers (ID providers).

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, and then issues an Attribute/Qualification Certificate (VC). A Verifier requests and receives the Attribute/Qualification Certificate (VC) required to provide a service from the Holder, thereby verifying the Holder's attributes, qualifications, etc., and making decisions about providing the service.

Various binding methods are being considered to show that this VC was indeed issued to the Holder and presented by that Holder. One method is to show the association between the VC and the 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).

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

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. However, it is expected that cloud wallets, which operate in the cloud, will become more widespread in the future.

However, in the case of cloud wallets, the hardware on which the wallet operates may change, 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 changes, the VC and the hardware will no longer correspond, and authentication by the Verifier will fail.

The present invention was made in consideration of the above points, and aims to provide technology that enables appropriate authentication using credentials such as VC, even when the hardware on which the wallet operates is changed.

According to the disclosed technology, a specific hardware device in a cloud wallet system including a plurality of hardware devices each having a wallet,
identifying a corresponding hardware device, the corresponding hardware device corresponding to the public key included in the credential received from the wallet;
If the corresponding hardware device is the specific hardware device, decrypting the authentication data received from the verifier or issuer;
A hardware device is provided that includes an agent that, if the corresponding hardware device is not the specific hardware device, requests the corresponding hardware device to perform a process of decrypting the authentication data.

The disclosed technology provides a technique that enables proper authentication using credentials such as VC, even when the hardware on which the wallet operates is changed.

FIG. 1 is a diagram illustrating an image of association in the technology. FIG. 1 is a diagram for explaining a problem. FIG. 1 is a diagram showing a hardware binding sequence based on Non-Patent Document 1. FIG. 1 is a diagram showing a hardware binding sequence based on Non-Patent Document 1. FIG. 1 is a diagram showing a hardware binding sequence based on Non-Patent Document 1. FIG. 1 is a diagram for explaining an outline of the operation according to the present embodiment. FIG. 1 is a diagram illustrating an example of the configuration of a cloud wallet system 100. FIG. 10 is a diagram illustrating an example 1 of a discovery procedure for HW. FIG. 10 is a diagram illustrating an example 2 of a discovery procedure for HW. FIG. 10 is a diagram illustrating an example 3 of a HW discovery procedure. FIG. 10 is a diagram illustrating an example of a procedure for issuing a certificate according to the first embodiment. FIG. 10 is a diagram illustrating an example of a procedure of authentication processing 1 in the first embodiment. FIG. 10 is a diagram illustrating an example of a procedure of authentication processing 2 in the first embodiment. FIG. 10 is a diagram illustrating an example of a procedure related to initial setting and authentication/certification in the second embodiment. FIG. 10 is a diagram illustrating an example of a procedure of an issuing process 1 in a second embodiment. FIG. 10 is a diagram illustrating an example of a procedure of an issuance process 2 in the second embodiment. FIG. 10 is a diagram illustrating an example of a procedure of authentication processing 1 in the second embodiment. FIG. 10 is a diagram illustrating an example of a procedure of authentication process 2 in the second embodiment. FIG. 10 is a diagram illustrating an example of a procedure of a process executed by the agent 15 during authentication. FIG. 10 is a diagram showing an example of a procedure of processing executed by the agent 15 when issuing a VC. FIG. 2 illustrates an example of a hardware configuration of the apparatus.

Below, an embodiment of the present invention (present embodiment) will be described with reference to the drawings. The embodiment described below is merely an example, and embodiments to which the present invention can be applied are not limited to the following embodiment.

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

(Regarding conventional technologies 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). Figure 1 shows an example of the association in this technology. In the conventional binding method shown in Figure 1, binding between a 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 runs.

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 for this is that in the cloud, the hardware on which the wallet operates may change, and the wallet may be operating on hardware that is different from the one in place when the VC was issued.

The above issues will be explained with reference to Figure 2. The upper part of Figure 2 shows the procedure for the technology disclosed in Non-Patent Document 1, and the lower part shows the procedure when this technology is implemented on the cloud.

In S1 (step 1) at the top, the user (holder) device sends 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 via a challenge-response using the public key.

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

(Example of hardware binding)
Here, in order to explain the problem more clearly, the hardware binding sequence 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-partyauthentication" with "authentication,""proof" with "attestation," and "qualification information" with "credential."

In Figure 3, S11 to S13 are the initial setup stages, and S14 to S20 are the authentication/certification stages.

In S11 of Figure 3, the certifying entity 40 performs a wallet audit and three-party authentication for the wallet 10. Note that the certifying entity 40 is the entity that performs the authentication, and may also be called an "authentication device."

In S12, the Certifying entity 40 registers the wallet and three-party certificate with the Trust registry 50. The Trust registry 50 is a trusted storage device, which may also be referred to as the "storage device." In S13, the Issuer 20 requests the wallet information required by the Issuer 20 from the Trust registry 50.

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

In S18, the wallet 10 sends the wallet attestation, key, and key attestation to the certifying entity 40. In S19, the certifying entity 40 checks the attestations for the app and key. In S20, the certifying entity 40 issues wallet bilateral authentication credentials to the wallet 10.

The above process binds the wallet 10 to the hardware and performs two-party authentication. With this method, the wallet 10 and the hardware are bound, so if the wallet 10 is moved to another piece of hardware, two-party authentication must be obtained again.

With reference to Figure 4, the issuance sequence based on Non-Patent Document 1 will be explained. In S31, Issuer 20 requests wallet functions from Wallet 10. In S32, Wallet 10 notifies Issuer 20 of its wallet security functions.

In S33, Issuer 20 requests wallet two-party authentication credentials from Wallet 10. In S34, Wallet 10 presents the wallet two-party authentication credentials to Issuer 20.

In S35, Issuer 20 requests a challenge from Wallet 10. In S36, Wallet 10 presents Issuer 20 with a challenge response using a hardware key.

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

In S38, Issuer 20 proposes to Wallet 10 that it issue credentials bound to a hardware key. In S39, 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 Wallet 10.

In S38 above, the VC is bound to the hardware and issued. With this method, the wallet and VC are bound to the hardware, so if the wallet is moved to another piece of hardware, the wallet two-party authentication and VC must be re-obtained.

Next, the verification sequence will be explained with reference to Figure 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.

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.

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.

In steps S56 and S57, verification is performed using credentials bound to the hardware. However, because the wallet and credentials are bound to the hardware, credential verification will fail if the wallet is moved to a different piece of hardware.

The technology related to this embodiment will be described below to solve the above problems.

(Outline of the embodiment)
In this embodiment, a cloud wallet system includes multiple pieces of hardware (HW) each capable of running a wallet. 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.

An overview of the operation of this embodiment will be explained with reference to Figure 6. In Figure 6, when a VC is issued, the user's wallet operates on HW1, and when authentication is performed, the wallet operates on HW2.

As shown in the lower diagram of Figure 6, each HW discovers each of the other HWs and obtains their public keys. During authentication at S4 shown in the upper diagram of Figure 6, let's assume that HW2 receives a challenge request (encrypted data, etc.). The agent of HW2 determines that decryption by HW1, which corresponds 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.

(System configuration example)
7 shows an example of the configuration 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.

FIG. 7 also shows Holder 12, Issuer 20, and Verifier 30, which communicate with the cloud wallet system 100. Holder 12 is, for example, a terminal held by a user. Issuer 20 and Verifier 30 are, for example, servers.

As shown in Figure 7, the cloud wallet system 100 comprises 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 challenge-response authentication processing with the verifier 30 while coordinating with the other hardware. In this embodiment, the agent 15 resides in the hardware 160. However, this is not limited to being resident. In Figure 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 VC issuance.

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.

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 operating procedure of a system having the configuration shown in Figure 7 will be explained in detail below.

(HW discovery procedure example 1)
First, with reference to Fig. 8, Example 1 of HW discovery procedure will be described. In Example 1 of HW discovery procedure, a procedure will be described 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.

In S101 of FIG. 8, agent 15A sends a hardware key request to agent 15B. In S102, agent 15B sends agent B's hardware key to agent 15A.

In S103, agent 15A sends a hardware key request to agent 15C. In S104, agent 15C sends C's hardware key to agent 15A. In S105, agent 15A holds the combination of hardware and hardware key for each of A to C.

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

(HW discovery procedure example 2)
Next, a second example of a HW discovery procedure will be described with reference to Fig. 9. In the second example of a HW discovery procedure, a procedure will be described in which a list of all combinations of 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 outside the cloud wallet system 100.

In S121 of FIG. 9, the public key DB 60 sends a hardware key request to agent 15A. In S122, agent 15A sends A's hardware key to the public key DB 60. Similarly, steps S123 to S126 are executed, and in S127 the public key DB 60 stores a combination of hardware and hardware key for each of A to C.

(HW discovery procedure example 3)
Next, a third example of a HW discovery procedure will be described with reference to Fig. 10. In the third example of a HW discovery procedure, 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.

In S131, agent 15B checks the HW key included in the VC. In S132, agent 15B sends an inquiry including the HW key to agent 15A. In S133, agent 15B sends an inquiry including the HW key to agent 15C.

In the example of Figure 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 A's HW key. 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 C's HW key.

Below, Examples 1 and 2 will be explained as specific examples of the issuance process and authentication process.

(Example 1: Issuance process)
The process of issuing 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.

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

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 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 it. For this reason, it is necessary to generate the key using, for example, the wallet ID as a seed.

In S204, agent 15A sends its own HW key (the public key of hardware A) to wallet 10A. Note that in S204, a public key obtained from a predetermined specific HW may be returned instead of the public key of its own HW. In this way, when using the public key of a specific HW, agents deployed on HW other than that specific HW will always request an agent deployed on that specific HW to decrypt the encrypted authentication data, eliminating the need for HW discovery.

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.

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

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.

(Example 1: Authentication Process 1)
Next, authentication process 1 using a VC including a HW key in the first embodiment 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.

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 to Verifier 30 as an authentication request. In S224, Verifier 30 sends a challenge request (authentication data encrypted using the HW key) to wallet 10A.

At S225, wallet 10A sends the VC containing the HW key and the encrypted authentication data to agent 15A.

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

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

In S229, wallet 10A sends a challenge response (decrypted authentication data) to Verifier 30. In S230, Verifier 30 checks the challenge response and determines that it is OK. In S231, Verifier 30 sends an authentication pass notification to wallet 10A. In S232, wallet 10A sends an authentication pass notification to Holder 12.

(Example 1: Authentication Process 2)
Next, authentication process 2 using a VC including a HW key in the first embodiment 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.

In S242, the VC is transferred from wallet 10A to wallet 10B. The wallet AP in wallet 10A is stopped (S241), and the wallet AP in wallet 10B is started (S243).

In S244, Holder 12 sends an authentication request to Wallet 10B.

In S245, wallet 10B sends a VC including the HW key as an authentication request to verifier 30. In S246, verifier 30 sends a challenge request (authentication data encrypted using the HW key) to wallet 10B.

In S247, wallet 10B sends the VC containing the HW key and the encrypted authentication data to agent 15B.

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.

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

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

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

In S254, wallet 10B sends 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 sends an authentication pass notification to wallet 10B. In S257, wallet 10B sends an authentication pass notification to Holder 12.

(Example 2: Initial Setup, Authentication/Certification)
Next, a second embodiment will be described. In the second embodiment, a processing example will be described in which a wallet authentication certificate including a HW key (a public key of the HW) is used. The "wallet authentication certificate" corresponds to the "wallet two-party authentication credential information" shown in FIG. 5. The "wallet authentication certificate" is information that proves that the wallet is authenticated. The wallet authentication certificate and the VC may be collectively referred to as credential information.

First, referring to Figure 14, an example of the procedure for initial setup and authentication/certification in Example 2 will be described. Steps S261 to S264 are the initial setup procedure, and steps S265 to S272 are the authentication/certification procedure.

In S261, Certifying entity 40 performs a wallet audit and authentication for wallet 10A. In S262, Certifying entity 40 performs a wallet audit and authentication for wallet 10B.

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

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

In S268, wallet 10A requests the HW key from agent 15A. Note that in S268, since the key generated from the HW is generated uniquely for the wallet, information such as the wallet ID is sent as necessary at the time of the request. In S269, agent 15A sends its own HW key to wallet 10A.

At S270, wallet 10A sends the wallet certification, HW key, and HW key certification to certifying entity 40.

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

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

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

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

In S284, Issuer 20 sends a challenge request (authentication data encrypted using the HW key) to wallet 10A. In S285, wallet 10A sends a wallet authentication certificate and encrypted authentication data to agent 15A.

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

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

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

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 the issuance of a VC including a HW key, and the VC may be issued in response to a request from wallet 10A. In S292, wallet 10A sends a VC issuance notification to Holder 12.

(Example 2: Issuance process 2)
Next, a process 2 for issuing a VC including a HW key in the second embodiment will be described with reference to Fig. 16. The process 2 is an example of a process in which a VC is issued using HW different from that used when issuing a wallet authentication certificate.

In S302, the authentication certificate is transferred from wallet 10A to wallet 10B. The wallet AP in wallet 10A is stopped (S301), and the wallet AP in wallet 10B is started (S303).

In S304, Holder 12 sends a VC issuance request to Wallet 10B.

In S305, wallet 10B sends a wallet authentication certificate to Issuer 20 as a VC issuance request. Note that the transmission in S305 may be preceded by a request for wallet functionality from Issuer 20, followed by a wallet security functionality response from wallet 10B, and then this transmission may be made as a response to the subsequent wallet authentication certificate request from Issuer 20.

At S306, Issuer 20 sends a challenge request (authentication data encrypted using the HW key) to wallet 10B.

In S307, wallet 10B sends the wallet authentication certificate and encrypted authentication data to agent 15B.

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

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

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

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 the issuance of a VC including the HW key, and this issuance may be carried out in response to a request from wallet 10B in response to that proposal.

In S317, wallet 10B sends a VC issuance notification to Holder 12.

(Example 2: Authentication Process 1)
Next, authentication process 1 using a VC including a HW key in the second embodiment 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.

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 HW key to Verifier 30 as an authentication request. 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.

In S324, Verifier 30 checks the wallet authentication and determines that it is OK.

Note that S324 may optionally be 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, wallet 10A will request agent 15A of its own HW to decrypt the encrypted authentication data, just as when a VC is issued (Figure 15). Agent 15A will check the HW key included in the wallet authentication certificate, decrypt the encrypted authentication data itself, and return the decrypted authentication data to wallet 10A. Wallet 10A will then perform a challenge response using the decrypted authentication data.

At S325, the verifier 30 sends a challenge request (authentication data encrypted using the HW key) to the wallet 10A.

In S326, wallet 10A sends the VC containing the HW key and the encrypted authentication data to agent 15A. Note that, since authentication requires generating the same key as was used when issuing the VC, information such as the wallet ID is also sent in S326.

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

In S330, wallet 10A sends a challenge response (decrypted authentication data) to Verifier 30. In S331, Verifier 30 checks the challenge response and determines that it is OK. In S332, Verifier 30 sends an authentication pass notification to wallet 10A. In S333, wallet 10A sends an authentication pass notification to Holder 12.

(Example 2: Authentication Process 2)
Next, authentication process 2 using a VC including a HW key in the second embodiment 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.

In S341, VC is transferred 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).

In S343, Holder 12 sends an authentication request to wallet 10B. In S344, wallet 10B sends a VC including a wallet authentication certificate and 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 and a response from wallet 10B regarding wallet security functions, and then as a response to a request for a wallet authentication certificate from Verifier 30. The VC may also be sent as a response to a request from Verifier 30 after wallet authentication has been checked.

In S345, Verifier 30 checks the wallet authentication and determines that it is OK.

Note that S345 may optionally be 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 Verifier 30 during this processing, wallet 10B will request agent 15B of its own HW to decrypt the encrypted authentication data, just as when a VC is issued (Figure 16). Agent 15B will check the HW key included in the wallet authentication certificate and request agent 15A of the HW corresponding to the HW key included in the wallet authentication certificate to decrypt the encrypted authentication data. The decrypted authentication data will be returned to wallet 10B, and wallet 10B will perform a challenge response using the decrypted authentication data.

In S346, the verifier 30 sends a challenge request (authentication data encrypted using the HW key) to the wallet 10B.

In S347, wallet 10B sends a VC containing the HW key and encrypted authentication data to agent 15B. In order to regenerate the associated key, information such as the wallet ID is sent in S347.

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

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

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

In S354, wallet 10B sends 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 sends an authentication pass notification to wallet 10B. In S357, wallet 10B sends an authentication pass notification to Holder 12.

(Example of agent behavior during authentication)
Next, an example of the procedure of the process executed by the agent 15 at the time of authentication will be described with reference to the flowchart of Fig. 19. The procedure shown in Fig. 19 is common to the first and second embodiments.

At S401, the agent 15 receives a VC containing the HW key and encrypted authentication data from the wallet 10.

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 result of the determination is No, the process proceeds to S404; if the result is Yes, the process proceeds to S408.

In S404, the agent 15 obtains the HW information corresponding to the HW key from a list or dynamically obtains it.

In S405, agent 15 sends the encrypted authentication data to the HW agent identified in S404 and requests decryption.

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

In S408, which is reached if the determination in S403 is No, the agent 15 decrypts the encrypted authentication data using its own HW private key, obtains the decrypted authentication data, and then proceeds to S407.

As mentioned above, agent 15 may obtain the public key to be passed to issuer 20 from a specific TEE (hardware). In this case, agents deployed on hardware other than that specific hardware will always request the agent deployed on that specific hardware to decrypt the encrypted authentication data, eliminating the need for HW discovery.

(Example of Agent Operation When VC Issuance)
An example of the procedure of the process 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.

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

In S413, the agent 15 determines whether the HW key belongs to its own HW. If the determination result is No, the process proceeds to S414; if the determination result is Yes, the process proceeds to S418.

In S414, the agent 15 obtains the HW information corresponding to the HW key from a list or dynamically obtains it.

In S415, agent 15 sends the encrypted authentication data to the HW agent identified in S414 and requests decryption.

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

In S418, which is reached if the determination in S413 is No, the agent 15 decrypts the encrypted authentication data using its own HW private key, obtains the decrypted authentication data, and then proceeds to S417.

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

In other words, the device can be realized by using hardware resources such as the CPU and memory built into the computer to execute a program corresponding to the processing performed by the device. The program can be recorded on a computer-readable recording medium (such as portable memory) and then saved or distributed. The program can also be provided via a network such as the Internet or email.

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., all of which are interconnected via bus B. The computer may also be equipped with a GPU.

The program that realizes processing on the computer is provided by a recording medium 1001, such as a CD-ROM or memory card. When the recording medium 1001 storing the program is inserted into 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; it can also be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

When an instruction to start a program is received, the memory device 1003 reads and stores the program from the auxiliary storage device 1002. The CPU 1004 implements the 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) based on the program, etc. The input device 1007 is composed of a keyboard, mouse, buttons, touch panel, etc., and is used to input various operational instructions. The output device 1008 outputs the results of calculations.

(Summary of the embodiment, effects, etc.)
As described 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.

Specifically, for example, even if Holder 12's wallet runs on hardware different from that used when Issuer 20 issued the VC, Verifier 30 can use the VC containing the public key generated by the hardware in its VC verification process.

The following additional notes are provided regarding the above embodiments.

<Additional Notes>
(Additional note 1)
A specific hardware device in a cloud wallet system having multiple hardware devices, each having a wallet,
identifying a corresponding hardware device, the corresponding hardware device corresponding to the public key included in the credential received from the wallet;
If the corresponding hardware device is the specific hardware device, decrypting the authentication data received from the verifier or issuer;
a hardware device including an agent that requests the corresponding hardware device to decrypt the authentication data if the corresponding hardware device is not the specific hardware device;
(Additional note 2)
The hardware device according to 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.
(Additional note 3)
The agent on the particular hardware device may:
obtaining public keys from the agents in each of the other hardware devices and maintaining a combination of the hardware device and the public keys;
In response to a request from a public key DB, transmit a public key corresponding to the specific hardware device to the public key DB; or
2. The hardware device according to claim 1, wherein a query including the public key is sent to an agent in each of the other hardware devices, thereby obtaining information about the hardware device corresponding to the public key.
(Additional note 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.

Although the present embodiment has been described above, the present invention is not limited to this specific embodiment, and various modifications and variations are possible within the scope of the gist of the present invention as set forth in the claims.

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 (4)

A specific hardware device in a cloud wallet system having multiple hardware devices, each having a wallet,
identifying a corresponding hardware device, the corresponding hardware device corresponding to the public key included in the credential received from the wallet;
If the corresponding hardware device is the specific hardware device, decrypting the authentication data received from the verifier or issuer;
a hardware device including an agent that requests the corresponding hardware device to decrypt the authentication data if the corresponding hardware device is not the specific hardware device; The hardware device according to claim 1 , wherein when the verifier verifies a Verifiable Credential (VC), the credential is a VC, and when the issuer issues a VC, the credential is a wallet authentication certificate. The agent on the particular hardware device may:
obtaining public keys from the agents in each of the other hardware devices and maintaining a combination of the hardware device and the public keys;
In response to a request from a public key DB, transmit a public key corresponding to the specific hardware device to the public key DB; or
The hardware device according to claim 1 , wherein the hardware device acquires information about the hardware device corresponding to the public key by sending a query including the public key to an agent in each of the other hardware devices. 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.