Wallet device, processing method, and program

Abstract

A wallet device comprising: an acquisition unit that acquires qualification information including a plurality of public keys from an issuer; and a presentation unit that presents the qualification information and a public key or an identifier of hardware associated with the wallet device to a verifier.

Description

Wallet device, processing method, and program

[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] Wallet Security, Device Binding 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 wallet device comprising: an acquisition unit that acquires credentials including a plurality of public keys from an issuer; and a presentation unit that presents the credentials and a public key or identifier of hardware associated with the wallet device to a verifier.

[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] FIG. 1 is a diagram showing an image of association. FIG. 2 is a diagram for explaining the problem. FIG. 3 is a diagram showing a hardware binding sequence based on Non-Patent Document 1. FIG. 4 is a diagram showing a hardware binding sequence based on Non-Patent Document 1. FIG. 5 is a diagram for explaining an overview of operations according to this embodiment. FIG. 6 is a diagram showing a hardware binding sequence according to this embodiment. FIG. 7 is a diagram showing a hardware binding sequence according to this embodiment. FIG. 8 is a diagram showing a hardware binding sequence according to this embodiment. FIG. 9 is a diagram showing an example of the configuration of the cloud wallet device 100. FIG. 10 is a diagram showing a sequence according to this embodiment. FIG. 11 is a diagram showing an example of the hardware configuration of the 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, we assume that the server (a hardware example) 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 "credentials" with "credential." Furthermore, in the explanation of Figures 3 to 5, it is assumed that the wallet 10 is an application that runs on a device (terminal) held by a user.

[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 steps S38 to S40 above, the VC (referred to as "credentials" in Figure 4) 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 piece of 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 credential information bound to the hardware key. In S57, the wallet 10 displays the credential information 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. Here, the "challenge-response procedure" refers to the exchange of a challenge request and a challenge response.

[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] The following describes a technique according to the present embodiment for solving the above problems.

[0037] (Technology according to this embodiment) In this embodiment, as shown in FIG. 6(a), it is assumed that there are multiple pieces of hardware (HW) in the cloud that a user (Holder) can use to operate a wallet. A public key is associated with each HW. It is assumed that each HW on which a wallet operates in the cloud is a TEE (Trusted Execution Environment), but is not limited to a TEE. In this embodiment, the cloud wallet holds the public keys of multiple HWs that a user can use, and a VC including the public keys of the multiple HWs is obtained.

[0038] An overview of the operation in this embodiment is shown in Figure 6. In Figure 6, when a VC is issued in steps S1 and S2, the user's wallet operates on HW1. In S1, the wallet sends to the issuer a list of public keys generated from each of multiple pieces of hardware that the user can use. In S2, the issuer issues a VC to the wallet that includes the list of public keys.

[0039] In S3, the user's wallet is started up on HW2. In S4, the wallet presents a VC including a list of public keys to the verifier. At this time, the wallet notifies the verifier of the public key of HW2 on which the wallet is currently running or the identifier of HW2. That is, for example, public key 2 shown in FIG. 6(b) is notified. In S5, the verifier authenticates the wallet by a challenge-response using the notified public key of HW2.

[0040] How the above processing is performed in the above-mentioned hardware binding processing (FIGS. 3 to 5) will be described below with reference to FIGS.

[0041] In Figures 7 to 9, the "wallet 10" in Figures 3 to 5 is replaced with a "cloud wallet device 100." The cloud wallet device 100 is a device realized by running a wallet application (wallet AP) on the cloud. The cloud wallet device 100 may also be called a "wallet device," a "cloud wallet system," a "wallet," etc. The wallet AP may also be called a "wallet instance."

[0042] The cloud wallet device 100 is linked to hardware (HW). Linking the cloud wallet device 100 to HW means, for example, that the cloud wallet device 100 (wallet AP) starts (operates) on the HW. When the cloud wallet device 100 starts (operates) on the HW, the cloud wallet device 100 uses the public key and private key corresponding to the HW. As mentioned above, there are multiple HWs on which the cloud wallet device 100 (wallet AP) can operate.

[0043] Furthermore, the cloud wallet device 100 being linked to HW may mean that the cloud wallet device 100 does not start up (operate) on the HW, but the public key and private key used by the cloud wallet device 100 correspond to the HW. The configuration of the cloud wallet device 100 will be described later with reference to FIG. 10 .

[0044] S101 to S103 in Fig. 7 are the same as S11 to S13 in Fig. 3. In S104, the cloud wallet operator starts up a wallet instance on a server (example of hardware). S105 to S110 in Fig. 7 are the same as S15 to S20 in Fig. 3.

[0045] However, in this embodiment, the cloud wallet device 100 generates a key (public key) backed by each piece of hardware on which the cloud wallet device 100 may operate, and obtains authentication of the key. In other words, the cloud wallet device 100 obtains multiple keys corresponding to multiple pieces of hardware on which the cloud wallet device 100 may operate, and obtains authentication of each of the multiple keys. Therefore, S105 to S110 are executed repeatedly the number of times equal to the number of keys.

[0046] The issuing sequence is shown in Fig. 8. Steps S121 to S123 in Fig. 8 are the same as steps S31 to S33 in Fig. 4.

[0047] In S124, the cloud wallet device 100 presents the wallet two-party authentication credential information corresponding to the hardware on which the cloud wallet device 100 is running to the Issuer 20. S124 to S127 are the same as S34 to S37 in FIG.

[0048] In S128, Issuer 20 proposes to issue credentials bound to multiple hardware keys to the cloud wallet device 100. In S129, the cloud wallet device 100 requests Issuer 20 to issue credentials bound to multiple hardware keys. In S130, Issuer 20 issues credentials bound to multiple hardware keys to the cloud wallet device 100.

[0049] Note that "credentials bound to multiple hardware keys" means that the credentials include a list of multiple hardware keys.

[0050] The verification sequence is shown in Fig. 9. Steps S141 to S145 in Fig. 9 are the same as steps S51 to S55 in Fig. 5.

[0051] In S146, the verifier 30 requests the cloud wallet device 100 to display the credentials bound to multiple hardware keys.

[0052] In S147, the cloud wallet device 100 displays the credentials bound to multiple hardware keys to the verifier 30. Also in S147, the cloud wallet device 100 sends the verifier 30 the key (or identifier) ​​of the hardware on which the cloud wallet device 100 is operating.

[0053] In S148, a challenge-response procedure using the hardware key on which the cloud wallet device 100 is running is executed between the verifier 30 and the cloud wallet device 100. The "challenge-response procedure" here refers to the exchange of a challenge request and a challenge response.

[0054] (System Configuration Example) Fig. 10 shows a configuration example of the cloud wallet device 100 in this embodiment. Fig. 13 also shows the Holder 12, Issuer 20, and Verifier 30 that communicate with the cloud wallet device 100. The Holder 12 is, for example, a terminal held by a user. The Issuer 20 and Verifier 30 are, for example, servers.

[0055] The cloud (cloud wallet system) is equipped with HW_1, HW_2, ..., HW_n as hardware (HW) that can be used by a user (Holder 12). In the example shown in Fig. 10, it is assumed that the user is using HW_1. In other words, it is assumed that the wallet AP is running on HW_1.

[0056] The configuration of the cloud wallet device 100 shown in Fig. 10 is realized by the wallet AP operating on HW_1. Alternatively, the cloud wallet device 100 may be realized by the wallet AP operating on a device (such as a server) that includes HW_1.

[0057] 10 , the cloud wallet device 100 holds PK_i, which is a public key linked to HW_i (for example, a public key generated by HW_i), for i = 1, 2, ..., n. That is, the cloud wallet device 100 holds PK_1, PK_2, ..., PK_n in a storage unit (memory device, auxiliary storage device, etc.) within the cloud wallet device 100. The method by which the cloud wallet device 100 acquires PK_1, PK_2, ..., PK_n is not limited to a specific method, and any method may be used to acquire PK_1, PK_2, ..., PK_n.

[0058] The cloud wallet device 100 comprises a wallet management unit 130, a VC request unit 110, a VC receiving unit 120, a VC presenting unit 140, a VC authentication unit 150, a VC issuance acceptance unit 170, and a VC issuance notification unit 180. The "VC request unit 110 and the VC receiving unit 120" may also be called an acquisition unit. The VC presenting unit 140 may also be called a presenting unit.

[0059] The wallet management unit 130 manages the cloud wallet device 100. The VC request unit 110 requests the issuer 20 to issue a VC (qualification information). The VC issuance request includes PK_1 to PK_n held by the cloud wallet device 100. The VC reception unit 120 receives the VC issued by the issuer 20. The VC includes PK_1 to PK_n.

[0060] The VC presenter 140 transmits the public key (here, PK_1) of the HW (for example, the HW on which the cloud wallet device 100 is running) linked to the cloud wallet device 100 and the VC (PK_1 to PK_n) to the Verifier 30. The VC authentication unit 150 transmits and receives a challenge request / challenge response. The VC issuance receiver 170 receives a VC issuance request from the Holder 12. The VC issuance notification unit 150 notifies the Holder 12 that the VC has been issued.

[0061] Furthermore, the cloud wallet device 100 that has performed the VC issuance process holds a VC including PK_1 to PK_n. In this embodiment, when the HW linked to the cloud wallet device 100 is changed, the VC already held by the cloud wallet device 100 is carried over to the changed HW. For example, if the HW is changed from HW_1 to HW_2, after the change, the VC presentation unit 140 in Fig. 10 presents PK_2 to the verifier 30, and the VC authentication unit 150 performs a challenge-response using PK_2.

[0062] (Example of a sequence including a Holder) An example of a sequence when using the cloud wallet device 100 having the above configuration will be described below with reference to Fig. 11. Fig. 11 is a diagram showing an example of a sequence when issuing a VC and when using content. S201 to S205 correspond to the operations when issuing a VC, and S206 to S211 correspond to the operations when using content.

[0063] In S201, a VC issuance request is sent from Holder 12. In S202, a wallet application (wallet AP) is started. Here, it is assumed that the wallet AP is started on HW_1. In other words, the cloud wallet device 100 operates on HW_1.

[0064] In S203, the cloud wallet device 100 sends a VC issuance request to the Issuer 20. This VC issuance request includes multiple public keys (PK_1 to PK_n). In S204, the Issuer 20 issues a VC including the multiple public keys (PK_1 to PK_n) to the cloud wallet device 100. In S205, the cloud wallet device 100 sends a VC issuance notification to the Holder 12.

[0065] Next, the operation when using content will be described. In S206, the Holder 12 transmits a content request to the cloud wallet device 100.

[0066] In S207, the wallet AP (cloud wallet device 100) is started. Here, it is assumed that the wallet AP is started on HW_2. In other words, the cloud wallet device 100 operates on HW_2. In addition, the VC already acquired by the cloud wallet device 100 operating on HW_1 is taken over by the cloud wallet device 100 operating on HW_2.

[0067] In S208, the cloud wallet device 100 transmits a content request to the verifier 30. The content request includes the VC held by the cloud wallet device 100 and the public key PK_2 of HW_2 on which the cloud wallet device 100 is running. Note that the identifier of HW_2 may be included instead of the public key PK_2 of HW_2.

[0068] In S209, a challenge request / challenge response is exchanged between the cloud wallet device 100 and the verifier 30. Specifically, for example, the verifier 30 sends the cloud wallet device 100 a challenge request including encrypted authentication data encrypted using PK_2. The cloud wallet device 100 decrypts the authentication data using the private key corresponding to PK_2 (the private key of HW_2), and sends the verifier 30 a challenge response including the decrypted authentication data. The verifier 30 checks the challenge response and confirms that it is OK. If it is OK, this means that it has been confirmed that the binding between the VC and HW_2 on which the cloud wallet device 100 runs is correct.

[0069] In S210, the Verifier 30 provides the content to the Holder 12.

[0070] (Hardware Configuration Example) The cloud wallet device 100 (which may also be called a wallet device) 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.

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

[0072] Fig. 12 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 12 includes 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, and the like, all of which are interconnected via a bus B. The computer may further include a GPU.

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

[0074] The memory device 1003 reads and stores the program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes functions related to the cloud wallet device 100 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.

[0075] (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.

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

[0077] <Additional Notes> (Additional Item 1) A wallet device comprising: an acquisition unit that acquires credential information including multiple public keys from an issuer; and a presentation unit that presents the credential information and a public key or identifier of hardware linked to the wallet device to a verifier. (Additional Item 2) The wallet device according to Additional Item 1, wherein each of the multiple public keys is a public key of hardware on which the wallet device can operate. (Additional Item 3) A processing method executed by a wallet device, comprising: a step of acquiring credential information including multiple public keys from an issuer; and a step of presenting the credential information and a public key or identifier of hardware linked to the wallet device to a verifier. (Additional Item 4) A non-transitory storage medium that stores a program for causing a computer to function as each unit in the wallet device according to Additional Item 1 or 2.

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

[0079] 12 Holder 20 Issuer 30 Verifier 40 Certifying entity 50 Trust registry 10 Wallet 100 Cloud wallet device 110 VC request unit 120 VC receiving unit 130 Wallet management unit 140 VC presentation unit 150 VC authentication unit 170 VC issuance reception unit 180 VC issuance 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 wallet device comprising: an acquisition unit that acquires credentials from an issuer, the credentials including a plurality of public keys; and a presentation unit that presents the credentials and a hardware public key or identifier associated with the wallet device to a verifier.

2. The wallet device of claim 1, wherein each of the plurality of public keys is a public key of hardware on which the wallet device can operate.

3. A method executed by a wallet device, comprising the steps of: obtaining credentials from an issuer, the credentials including a plurality of public keys; and presenting the credentials and a hardware public key or identifier associated with the wallet device to a verifier.

4. A program for causing a computer to function as each unit of the wallet device according to claim 1 or 2.

Images