Information processing device, wallet device, information processing method, and program

Abstract

This information processing device comprises: a storage unit that stores history information of hardware associated with a wallet device; and a processing unit that issues, by referring to the storage unit, certification information including a public key of hardware with which the wallet device is associated and a public key of hardware with which the wallet device was associated in the past.

Description

Information Processing Apparatus, Wallet Apparatus, Information Processing Method, and Program

[0001] The present invention relates to the technology of a cloud wallet that manages digital identities.

[0002] In recent years, as a new concept of identity management, the concept of self-sovereign identity (SSI) and its implementation technologies (such as W3C Decentralized Identifiers (DID), W3C Verifiable Credentials (VC), etc.) in which users manage their own identifiers and identities by themselves and control the destinations without depending on a centralized identity provider (ID provider) have been studied.

[0003] In the world of SSI, there are three parties: Holder, Issuer, and Verifier. The Holder is a user who manages / holds their own digital identity. The Issuer issues an attribute / qualification certificate (VC) to a user or the like after proving attribute information (name, age, address, etc.), qualification information (being an employee of a certain company, being a member of a certain service, etc.). The Verifier requests and receives the necessary attribute / qualification certificate (VC) from the Holder to verify the Holder's attributes, qualifications, etc., and makes decisions such as service provision determination.

[0004] In order to show that this VC is indeed issued to the Holder and presented by the Holder, various Binding methods have been studied. As one of them, there is a method of showing the association between the VC and the Holder by Binding a device (hardware) equipped with a wallet for storing the VC owned by the Holder and the VC (Non-Patent Document 1).

[0005] Device Binding Work Item, https: / / github.com / decentralized-identity / wallet-security / blob / main / work_items / device_binding.md, Internet, searched September 4, 2024

[0006] The technology disclosed in Non-Patent Document 1 assumes that the device equipped with a wallet, which is the target of binding with the VC, is a terminal held by the user. On the other hand, it is anticipated that cloud wallets, which operate in the cloud, will become widespread in the future.

[0007] 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 be compatible, resulting in authentication failure by the verifier.

[0008] This invention has been made in view of the above points, and aims to provide a technology that enables proper authentication using credentials such as VC even when the hardware on which the wallet operates is changed.

[0009] According to the disclosed technology, an information processing device is provided which includes a storage unit for storing hardware history information associated with a wallet device, and a processing unit that, by referring to the storage unit, issues certification information including the public key of the hardware to which the wallet device is currently associated and the public keys of hardware to which the wallet device was previously associated.

[0010] According to the disclosed technology, a technology is provided that enables proper authentication using credentials such as VC even when the hardware on which the wallet operates is changed.

[0011] This is a diagram illustrating the association in the technology. This is a diagram for explaining the problem. This is a diagram illustrating the sequence of hardware binding based on Non-Patent Literature 1. This is a diagram illustrating the sequence of hardware binding based on Non-Patent Literature 1. This is a diagram illustrating the sequence of hardware binding based on Non-Patent Literature 1. This is a diagram for explaining the overview of the operation in the first embodiment. This is a diagram illustrating an example of the procedure when VC reissuance is performed when the wallet is started in the first embodiment. This is a diagram illustrating an example of the procedure when VC reissuance is performed when the wallet is started in the first embodiment. This is a diagram illustrating an example of the procedure when VC reissuance is performed when the wallet is started in the first embodiment. This is a diagram illustrating an example of the procedure when VC reissuance is performed when the wallet is started in the first embodiment. This is a diagram illustrating an example of the procedure when VC reissuance is performed when VC is presented in the first embodiment. This is a diagram illustrating an example of the procedure when VC reissuance is performed when VC is presented in the first embodiment. This is a diagram illustrating an example of the procedure when VC reissuance is performed when VC is presented in the first embodiment. This is a diagram illustrating the processing flow when VC reissuance is performed when the wallet is started in the first embodiment. This is a diagram illustrating the processing flow when VC reissuance is performed when VC is presented in the first embodiment. This figure shows an example configuration of the cloud wallet device 100 in the first embodiment. This figure illustrates an example of processing for MC in the first embodiment. This figure shows an example of the operation procedure in Example 1-1. This figure shows an example of the operation procedure in Example 1-2. This figure illustrates an overview of the operation in the second embodiment. This figure shows an example of the procedure for acquiring MC when the wallet is started in the second embodiment. This figure shows an example of the procedure for acquiring MC when the wallet is started in the second embodiment. This figure shows an example of the procedure for acquiring MC when the wallet is started in the second embodiment. This figure shows an example of the procedure for acquiring MC when the wallet is started in the second embodiment. This figure shows an example of the procedure for acquiring MC when the wallet is started in the second embodiment. This figure shows an example of the procedure for acquiring MC when VC is presented in the second embodiment. This figure shows an example of the procedure for acquiring MC when VC is presented in the second embodiment.This figure shows an example of the procedure for acquiring MC when presenting VC in the second embodiment. This figure shows an example of the procedure for acquiring MC when presenting VC in the second embodiment. This figure shows the processing flow when acquiring MC when starting the wallet in the second embodiment. This figure shows the processing flow when reissuing VC when presenting VC in the second embodiment. This figure shows an example of the configuration of the cloud wallet device 100 in the second embodiment. This figure illustrates an example of processing regarding MC in the second embodiment. This figure shows an example of the operation procedure in Example 2-1. This figure shows an example of the operation procedure in Example 2-2. This figure shows an example of the configuration of the information processing device 500. This figure shows an example of the configuration of the information processing device 500. This figure shows an example of the hardware configuration of the device.

[0012] Hereinafter, embodiments of the present invention (this embodiment) will be described with reference to the drawings. The embodiments described below are merely examples, and the embodiments to which the present invention is applied are not limited to the embodiments described below.

[0013] The following describes 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 may be modified in the cloud. First, the conventional technology and its challenges will be described in more detail, and then the technology related to this embodiment will be described.

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

[0015] However, it is difficult to apply the prior art disclosed in Non-Patent Document 1 to a configuration where the wallet operates in the cloud. This is because, in the case of the cloud, the hardware on which the wallet operates may change, and the wallet may be operating on different hardware than the one used when the VC was issued.

[0016] The above issues will be explained with reference to Figure 2. The upper part of Figure 2 shows the procedure in the technology disclosed in Non-Patent Document 1, and the lower part shows the procedure assuming that the said technology is implemented in the cloud.

[0017] In step S1 (Step 1) above, the user's (Holder's) device sends a public key generated by the hardware to the Issuer. In step S2, the Issuer issues a VC (Virtual Certificate) containing the public key to the device. In step S3, the device presents the VC containing the public key to the Verifyer. In step S4, the Verifyer performs challenge-response authentication with the device using the public key.

[0018] The lower part of Figure 2 shows the case where the wallet is cloud-based. Here, we assume that the server on which the wallet operates (an example of hardware) when the VC is issued is different from the server on which the wallet operates during authentication. In this case, since the public key will be different at the time of VC issuance and authentication, 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 Literature 1 will be explained with reference to Figures 3 to 5. Note that Non-Patent Literature 1 itself is publicly known, but Figures 3 to 5 themselves are not publicly known. Also, 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". Also, 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 the user. Note that Issuer 20 may be called the issuing device and Verifyer 30 may be called the verification device.

[0020] In Figure 3, steps S11 to S13 represent the initial setup stage, and steps S14 to S20 represent the authentication / certification stage.

[0021] In S11 of Figure 3, the Certifying entity 40 performs wallet auditing and three-party authentication on the wallet 10. The Certifying entity 40 is the entity that performs authentication and may also be called an "authentication device".

[0022] In S12, the Certifying entity 40 registers the wallet and the three-party certificate with the Trust registry 50. The Trust registry 50 is a trusted storage device and 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.

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

[0024] In S18, wallet 10 sends wallet verification, key, and key verification to Certifying entity 40. In S19, Certifying entity 40 checks the verification of the app and key. In S20, Certifying entity 40 issues wallet bilateral authentication credentials to wallet 10.

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

[0026] Referring to Figure 4, the issuance sequence based on Non-Patent Document 1 will be explained. In S31, Issuer 20 requests wallet functionality from wallet 10. In S32, wallet 10 notifies Issuer 20 of wallet security functionality.

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

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

[0029] In S37, Issuer20 checks the wallet two-party authentication and also checks the challenge-response.

[0030] In S38, Issuer 20 proposes to Wallet 10 the issuance of credentials bound to the hardware key. In S39, Wallet 10 requests Issuer 20 to issue credentials bound to the hardware key. In S40, Issuer 20 issues credentials bound to the hardware key to Wallet 10.

[0031] In steps S38-S40 above, the VC (labeled "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 a different piece of hardware, the wallet two-party authentication and VC must be re-obtained.

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

[0033] Next, optional steps S53 to S55 are performed. In S53, the Verified 30 requests wallet bi-party authentication credentials from the wallet 10. In S54, the wallet 10 displays the wallet bi-party authentication credentials to the Verified 30. In S55, the Verified 30 checks the wallet bi-party authentication.

[0034] In S56, the Verified 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 Verified 30. In S58, a challenge-response procedure is performed between the Verified 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 hardware-bound credentials. However, because the wallet and credentials are bound to the hardware, if the wallet is moved to a different piece of hardware, credential verification will fail.

[0036] The following describes the first and second embodiments as technologies for solving the above-mentioned problems.

[0037] [First Embodiment] First, the first embodiment will be described.

[0038] As mentioned above, if the hardware on which the wallet operates is changed, and the wallet operates on hardware different from the original hardware, there is a problem in that the wallet authentication will fail.

[0039] To solve the above problems, in this embodiment, at the timing of (1) or (2) below, the wallet operator issues a migration certificate to the wallet, and the Issuer uses the migration certificate presented by the wallet to reissue a VC including the new hardware's public key. The migration certificate functions as proof that the holder of the migration certificate is the legitimate owner of the VC.

[0040] (1) When the wallet is launched on different hardware.

[0041] (2) When it is discovered that the public key contained in the VC presented from the wallet is different from the public key of the current hardware.

[0042] At the timing of (1) above, the operation outline when the wallet re-acquires the VC is shown in FIG. 6. In FIG. 6, when the VC is issued at S1 to S2, the user's wallet operates on HW1. After that, at S3, the wallet starts on HW2.

[0043] At S4, the wallet transmits the VC including the public key and the newly generated public key from the hardware (HW2) to the wallet operator 60.

[0044] At S5, the wallet operator 60 issues a migration certificate including the public key contained in the VC and the newly generated public key to the wallet.

[0045] At S6, the wallet presents the migration certificate to the Issuer and receives the re-issuance of the VC from the Issuer.

[0046] At S7, the wallet presents the VC including the public key of HW2 to the Verifier, and authentication at S8 is successful.

[0047] In the first embodiment, as described above, by re-issuing the VC using the migration certificate, it is possible to prevent the VC from being re-issued to anyone other than the person himself / herself. In addition, the vulnerability that the Issuer issues a new VC to a different hardware partner and re-issues the VC to someone other than the person himself / herself can be reduced.

[0048] Hereinafter, regarding how the VC re-acquisition (re-issuance) at the timing of (1) above and the VC re-acquisition (re-issuance) at the timing of (2) above are performed in the processes of the above-described hardware binding (FIGS. 3 to FIG. 5), it will be described with reference to FIGS. 7 to FIG. 11.

[0049] In Figures 7 to 11, the "wallet 10" in Figures 3 to 5 is replaced by the "cloud wallet device 100". The cloud wallet device 100 is a device realized by launching a wallet application (wallet AP) on the cloud. The cloud wallet device 100 may also be called a "wallet device," "cloud wallet system," or "wallet." The wallet AP may also be called a "wallet instance." In addition, a wallet service provider 60 appears in Figures 7 to 11. In the first and second embodiments, the wallet service provider 60 is specifically a computer (information processing device) such as a server or terminal.

[0050] 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 up (operates) on the HW. When the cloud wallet device 100 starts up (operates) on the HW, the cloud wallet device 100 can use the public key and private key corresponding to the HW.

[0051] Furthermore, for the cloud wallet device 100 to be linked to the hardware, it may also mean that the cloud wallet device 100 does not start (operate) on the hardware, but the public key and private key used by the cloud wallet device 100 correspond to the hardware. The configuration of the cloud wallet device 100 will be described later with reference to Figure 17.

[0052] ((1) Reissuing VC when the wallet is started) First, refer to Figures 7 to 11 to explain the processing procedure when "(1) Reissuing when the wallet is started".

[0053] Steps S101 to S103 in Figure 7 are the same as steps S11 to S13 in Figure 3. In step S104, the cloud wallet provider (e.g., wallet provider 60) starts a wallet instance on the server (example hardware). Steps S105 to S110 in Figure 7 are the same as steps S15 to S20 in Figure 3. The process then proceeds to VC issuance in Figure 8.

[0054] Figure 8 shows the VC issuance sequence. Steps S121 to S130 in Figure 8 are the same as steps S31 to S40 in Figure 4. After VC issuance, the process proceeds to VC utilization shown in Figure 9.

[0055] Figure 9 shows the sequence using VC. Steps S142 to S148 in Figure 9 are the same as steps S52 to S58 in Figure 5.

[0056] Figure 10 shows the sequence when the cloud wallet device 100 is stopped and then started. In S151, the cloud wallet device 100 starts up. In S152, if the cloud wallet device 100 detects that the hardware associated with the cloud wallet device 100 has changed, in S153, the authentication / proof process (S105 to S110) in Figure 7 (A) is executed. This proves that the cloud wallet device 100 is bound to the new hardware after the change.

[0057] In S154, the cloud wallet device 100 sends a request to the wallet service provider 60 for the issuance of a migration certificate (including the public key of the VC already held and the new hardware). In S155, the wallet service provider 60 issues a migration certificate (including the public key that was included in the VC and the new public key) to the cloud wallet device 100. The process then proceeds to the VC reissuance shown in Figure 11.

[0058] In step S152 of Figure 10, if it is determined that there are no hardware changes, the VC usage process shown in Figure 9 is performed.

[0059] Referring to Figure 11, the VC reissuance sequence will be explained. In S161, the cloud wallet device 100 notifies Issuer 20 of the wallet security function.

[0060] In S162, Issuer 20 requests wallet bilateral authentication credentials from the cloud wallet device 100. In S163, the cloud wallet device 100 presents wallet bilateral authentication credentials to Issuer 20.

[0061] In S164, Issuer 20 requests a challenge from the cloud wallet device 100. In S165, the cloud wallet device 100 presents Issuer 20 with a challenge response using a hardware key.

[0062] In S166, Issuer20 checks the wallet two-party authentication and also checks the challenge-response.

[0063] In S167, Issuer 20 proposes to the cloud wallet device 100 that it issue credentials bound to a hardware key. In S168, the cloud wallet device 100 presents Issuer 20 with a migration certificate and requests that it issue credentials bound to a hardware key. In S169, Issuer 20 issues credentials bound to a hardware key to the cloud wallet device 100. After that, the process proceeds to the use of VC as shown in Figure 9.

[0064] ((2) Reissuance when VC is presented) Next, referring to Figures 12 to 14, the hardware binding processing procedure in the case of "(2) Reissuance when VC is presented" will be explained.

[0065] Steps S171 to S173 in Figure 12 are the same as steps S11 to S13 in Figure 3. In step S174, the cloud wallet provider (e.g., wallet provider 60) starts a wallet instance on the server. Steps S175 to S180 in Figure 12 are the same as steps S15 to S20 in Figure 3. Next, the process proceeds to VC issuance.

[0066] Figure 13 shows the sequence for issuing a VC. Steps S191 to S200 in Figure 13 are the same as steps S31 to S40 in Figure 4. Next, we proceed to using the VC.

[0067] Figure 14 shows the sequence of VC usage (verification). Steps S211 to S216 in Figure 14 are the same as steps S51 to S56 in Figure 5.

[0068] In response to the request in S216, the cloud wallet device 100 checks in S217 whether the hardware associated with the cloud wallet device 100 has changed. If it detects that the hardware has changed, the authentication / proof process (S105-S110) shown in Figure 7 (A) is executed in S218. This verifies that the cloud wallet device 100 is bound to the new hardware after the change.

[0069] In S219, the cloud wallet device 100 sends a request to the wallet provider 60 for the issuance of a migration certificate (including the VC already held and the new public key). In S219, the wallet provider 60 issues a migration certificate (including the public key included in the VC and the new public key) to the cloud wallet device 100. In S221, the reissuance process (B-1) in Figure 11 is executed.

[0070] In S222, the cloud wallet device 100 displays the credentials bound to the hardware key to the Verifyer 30. In S223, a challenge-response process is performed between the cloud wallet device 100 and the Verifyer 30.

[0071] In step S217 of Figure 14, if it is determined that there are no hardware changes, the process proceeds to step S222 without reissuing the document.

[0072] (Processing Flow) Referring to Figure 15, the processing flow for (1) reissuing VC when the wallet is started will be explained.

[0073] In S510, the cloud wallet device 100 starts up. If there is a change in the hardware on which the cloud wallet device 100 operates, proceed to S512 (Yes in S511); otherwise, proceed to S13 (No in S511).

[0074] In S512, VC reissuance using MC is performed. In S513, the cloud wallet device 100 presents the VC. In S514, the VC is verified, and in S515, the content is used.

[0075] Referring to Figure 16, the processing flow for (2) reissuing a VC when presenting a VC will be explained.

[0076] In S520, the cloud wallet device 100 is activated. In S521, the cloud wallet device 100 presents the VC.

[0077] If there is a change in the hardware on which the cloud wallet device 100 operates, proceed to S523 (Yes in S522); otherwise, proceed to S524 (No in S522).

[0078] In S523, VC reissuance using MC is performed. In S524, VC verification is performed, and in S525, the content is used.

[0079] (System Configuration Example) Figure 17 shows an example configuration of the cloud wallet device 100 in the first embodiment. Figure 17 also shows the Holder 12, Issuer 20, Verifyer 30, and wallet service provider 60 that communicate with the cloud wallet device 100. Holder 12 is, for example, a terminal held by the user. Issuer 20 and Verifyer 30 are, for example, information processing devices such as servers.

[0080] Figure 17 shows HWj as hardware 160 associated with the cloud wallet device 100. In Figure 17, PBLC_key represents the public key, PRVT_key represents the private key (which may also be called the secret key), and MC represents the migration certificate.

[0081] Furthermore, the cloud wallet device 100 includes a wallet management unit 130, a VC request unit 110, a VC receiving unit 120, a VC presentation unit 140, a VC authentication unit 150, a VC issuance acceptance unit 170, a VC issuance notification unit 180, an MC request unit 190, and an MC receiving unit 195.

[0082] Furthermore, some or all of the "wallet management unit 130, VC request unit 110, VC receiving unit 120, VC presentation unit 140, VC authentication unit 150, VC issuance acceptance unit 170, VC issuance notification unit 180, MC request unit 190, and MC receiving unit 195" may be collectively referred to as a processing unit (or processor).

[0083] Furthermore, the cloud wallet device 100 that performed the VC issuance process holds the VC, including the public key. In this embodiment, if the hardware associated with the cloud wallet device 100 is changed, the VC already held by the cloud wallet device 100 will be transferred to the changed hardware.

[0084] For example, if a cloud wallet device 100 operating on HW-A holds VC-A, and the hardware is modified so that the cloud wallet device 100 operates on HW-B, then the cloud wallet device 100 operating on HW-B will hold VC-A.

[0085] The wallet management unit 130 manages the cloud wallet device 100. 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.

[0086] The VC presentation unit 140 presents the Verifier 30 with a VC containing the public key of the HW 160 associated with the cloud wallet device 100 (for example, the HW on which the cloud wallet device 100 is operating). The VC authentication unit 150 sends and receives challenge requests and challenge responses. The VC issuance reception unit 170 receives a VC issuance request from the Holder 12. The VC issuance notification unit 180 notifies the Holder 12 that a VC has been issued.

[0087] The MC request unit 190 requests the wallet provider 60 to issue a migration certificate. The MC receiving unit 195 receives the migration certificate from the wallet provider 60.

[0088] The wallet management unit 130 determines whether the public key in the VC held by the cloud wallet device 100 is different from the public key of the HW160 associated with the cloud wallet device 100. If they are different, it obtains a migration certificate and uses the public key of the HW160 associated with the cloud wallet device 100 and the obtained migration certificate to reacquire the VC. More specifically, regarding the reacquisition of the VC, the wallet management unit 130 instructs each functional unit to perform the operation to reacquire the VC.

[0089] (Verification by MC) As explained above, in this embodiment, when a VC is reissued, the cloud wallet device 100 requests the issuer 20 to reissue the VC by presenting the MC along with the new public key. At this time, the issuer 20 can verify that the cloud wallet device 100 is the legitimate VC owner using the MC. This will be explained with reference to Figure 18.

[0090] Here, a driver's license is used as an example of a virtual currency (VC). Furthermore, it is assumed that the hardware associated with the cloud wallet device 100 has changed from HW-A to HW-B.

[0091] The wallet provider 60 can find out what hardware the cloud wallet device 100 that requests MC issuance has been operating on in the past, and can verify that information.

[0092] For example, when wallet provider 60 receives a request from cloud wallet device 100 to issue a VC containing the public key of HW-A and an MC containing the public key of HW-B (new public key), wallet provider 60 can know that cloud wallet device 100 was indeed operating on HW-A and is now operating on HW-B. Based on this information, wallet provider 60 can issue an MC containing the public key of HW-A and the public key of HW-B to cloud wallet device 100.

[0093] Two specific examples of methods to achieve the above are Pattern A and Pattern B shown below. Either Pattern A or Pattern B may be used.

[0094] Pattern A: As shown in Figure 18, in Pattern A, the wallet provider 60 uses the wallet ID as a basis to refer to the history database and verify the history information.

[0095] In other words, the wallet provider 60 has a history database that stores records (information linking hardware and wallet IDs) indicating which cloud wallet device 100 was associated with which hardware. The history database can be created in any way. For example, as in pattern B described later, it may be created based on reports of the public key of the associated hardware from the cloud wallet device 100.

[0096] When the cloud wallet device 100 presents a wallet ID to the wallet service provider 60, the wallet service provider 60 can obtain and verify information about the hardware on which the cloud wallet device 100 operates (e.g., that it is running on HW-B after HW-A) based on the linking information between the hardware it manages and the wallet ID. The wallet ID is included in the MC issuance request from the cloud wallet device 100 to the wallet service provider 60. The wallet ID may also be included in the VC. The wallet ID may also be the public key of the wallet (cloud wallet device 100). The wallet ID may also be called the wallet identification information.

[0097] The wallet operator 60 can, by referring to the history database, issue an MC to the cloud wallet device 100 that includes, for example, the public key of HW-A and the public key of HW-B.

[0098] Pattern B: In Pattern B, the wallet provider 60 issues a wallet operation certificate VC linked to the wallet ID and the hardware's public key each time the cloud wallet device 100 is started and when a change in the hardware of the cloud wallet device 100 is detected, and stores it in the wallet provider 60's wallet. The above information is verified using the wallet operation certificate VC.

[0099] For example, in the example shown in Figure 18, if the hardware of the cloud wallet device 100 is changed and it starts up with HW-A, the cloud wallet device 100 presents the wallet ID and the public key generated from the hardware (HW-A) to the wallet provider 60. The legitimacy of ownership of this public key can be verified by a hardware-based challenge response. The wallet provider 60 uses the information presented by the cloud wallet device 100 to generate a wallet operation certificate VC containing the public key and stores it in the wallet provider 60's storage unit. The storage unit may also be the wallet itself.

[0100] Since the wallet operator 60 maintains wallet operation certificates (VCs) for each piece of hardware on which the cloud wallet device 100 has operated, it can, for example, detect when the hardware of the cloud wallet device 100 has changed from HW-A to HW-B. Therefore, it can issue a Certificate Key (MC) containing the public key of HW-A and the public key of HW-B.

[0101] In the first embodiment, when Issuer 20 reissues a VC (changes from a VC containing the public key of HW-A to a VC containing the public key of HW-B), for example, it uses the information shown in (1) and (2) in Figure 18. Information (1) is the public key of HW-B after the change, and information (2) is an MC containing the public key of HW-A and the public key of HW-B. With this information, Issuer 20 can confirm (verify) that the hardware of the cloud wallet device 100 has been changed from HW-A to HW-B and is now operating on HW-B, and can reissue a VC containing the public key of HW-B.

[0102] Below, we will describe a specific procedure for performing a VC update when the wallet is launched as Example 1-1, and a specific procedure for performing a VC update when the VC is presented as Example 1-2.

[0103] (Example 1-1: VC update performed when wallet is started) First, Example 1-1 will be explained with reference to Figure 19. Figure 19 is a diagram showing example sequences when a VC is issued and when content is used. S231 to S235 correspond to the operation when a VC is issued, and S236 to S244 correspond to the operation when content is used.

[0104] In S231, Holder12 sends a VC issuance request. In S232, the wallet application (wallet AP) is launched. Here, the wallet AP is launched on the HWi.

[0105] In S233, the cloud wallet device 100 sends a VC issuance request to Issuer 20. This VC issuance request includes public key i, which is the public key of HWi. In S234, Issuer 20 issues a VC containing public key i to the cloud wallet device 100. In S235, a VC issuance notification is sent to Holder 12.

[0106] Next, we will explain the operation when using content. In S236, the wallet AP (cloud wallet device 100) starts up. Here, we assume that the wallet AP is started up on the new hardware, HWj. In other words, the cloud wallet device 100 operates on HWj. Also, any VC already acquired by the cloud wallet device 100 that was operating on HWi is transferred to the cloud wallet device 100 operating on HWj.

[0107] When the cloud wallet device 100 detects that a public key in a VC it ​​already holds does not match the public key of the HW on which the cloud wallet device 100 is currently operating, it decides to reacquire all VCs. The cloud wallet device 100 executes steps S237 to S240 for each VC to be reacquired.

[0108] In S237, the cloud wallet device 100 sends an MC issuance request (including the VC and the new public key j) to the wallet service provider 60. In S238, the wallet service provider 60 sends an MC (including the old public key i and the new public key j) to the cloud wallet device 100. The old public key i is the public key i included in the current VC.

[0109] In S239, the cloud wallet device 100 sends a VC issuance request (including the new public key j and MC) to the Issuer 20. In S240, the Issuer 20 issues a VC containing the new public key j to the cloud wallet device 100.

[0110] In S241, Holder 12 sends a content request to the cloud wallet device 100.

[0111] In S242, the cloud wallet device 100 sends a content request to the Verifyer 30. The content request includes a VC containing the public key j of the hardware on which the cloud wallet device 100 is operating.

[0112] In S243, a challenge request / challenge response exchange takes place between the cloud wallet device 100 and the Verifyer 30. Specifically, the Verifyer 30 sends a challenge request to the cloud wallet device 100, which includes encrypted authentication data encrypted using the public key. The cloud wallet device 100 decrypts the authentication data using the private key corresponding to the public key and sends a challenge response containing the decrypted authentication data to the Verifyer 30. The Verifyer 30 checks the challenge response and confirms that it is OK. This OK means that the binding between the hardware on which the cloud wallet device 100 operates and the VC has been confirmed to be correct.

[0113] In S244, the Verifier 30 provides content to the Holder 12.

[0114] (Example 1-2: VC update performed when VC is presented) Next, Example 1-2 will be described with reference to Figure 20. Figure 20 is a diagram showing example sequences when a VC is issued and when content is used. S251 to S255 correspond to the operation when a VC is issued, and S256 to S265 correspond to the operation when content is used.

[0115] In S251, Holder12 sends a VC issuance request. In S252, the wallet application (wallet AP) starts up on a certain piece of hardware.

[0116] In S253, the cloud wallet device 100 sends a VC issuance request to Issuer 20. This VC issuance request includes the public key i of the hardware. In S254, Issuer 20 issues a VC containing the public key i to the cloud wallet device 100. In S255, the cloud wallet device 100 sends a VC issuance notification to Holder 12.

[0117] Next, we will explain the operation when using content. In S256, the wallet AP (cloud wallet device 100) starts up. Here, we assume that the wallet AP is started up on hardware different from the hardware mentioned above. Also, any VC already acquired by the cloud wallet device 100 that was running on the previous hardware is transferred to the cloud wallet device 100 running on the new hardware.

[0118] In S257, Holder 12 sends a content request to the cloud wallet device 100.

[0119] In S258, if the cloud wallet device 100 detects that the public key i in the VC it ​​already holds does not match the public key j of the HW on which the cloud wallet device 100 is currently operating, it decides to reacquire the VC corresponding to the content requested in S257.

[0120] The cloud wallet device 100 executes S259 to S262 for the VC to be reacquired.

[0121] In S259, the cloud wallet device 100 sends an MC issuance request (including the VC and the new public key j) to the wallet service provider 60. In S260, the wallet service provider 60 sends an MC (including the old public key i and the new public key j) to the cloud wallet device 100. The old public key i is the public key i included in the current VC.

[0122] In S261, the cloud wallet device 100 sends a VC issuance request (including the new public key j and MC) to the Issuer 20. In S262, the Issuer 20 issues a VC containing the new public key j to the cloud wallet device 100.

[0123] In S263, the cloud wallet device 100 sends a content request to the Verifyer 30. The content request includes a VC containing the public key j of the hardware on which the wallet (cloud wallet device 100) is operating.

[0124] In S264, a challenge request / challenge response exchange takes place between the cloud wallet device 100 and the Verifyer 30. The specific method is as described above.

[0125] In S233, the Verifyer 30 provides content to the Holder 12.

[0126] [Second Embodiment] Next, a second embodiment, which is another embodiment for solving the aforementioned problems, will be described.

[0127] (Summary of the second embodiment) As mentioned above, if the hardware on which the wallet operates is changed and the wallet operates on hardware different from the original hardware, there is a problem in that the wallet authentication fails.

[0128] To solve the above problems, in the second embodiment, at the timing of (1) or (2) below, the wallet provider 60 issues a migration certificate, and the wallet uses the migration certificate to enable the use of VC. VC is not reissued. The process for issuing the migration certificate is the same as in the first embodiment.

[0129] (1) When the wallet is launched on different hardware.

[0130] (2) When it is discovered that the public key contained in the VC presented from the wallet is different from the public key of the current hardware.

[0131] Figure 21 shows an overview of the operation when the wallet obtains a migration certificate at the timing described in (1) above. In Figure 21, when the VC is issued in S1 to S2, the user's wallet operates on HW1. Subsequently, in S3, the wallet starts up on HW2.

[0132] In S4, the wallet sends the VC, which includes the public key, and the newly generated public key from the hardware (HW2), to the wallet provider.

[0133] In S5, the wallet provider issues a migration certificate to the wallet that includes the public key contained in the VC and the newly generated public key.

[0134] In S6, the wallet presents the VC containing the migration certificate and the public key of HW1 to the Verifyer. In S7, authentication is successfully performed between the wallet and the Verifyer using a challenge-response with the new public key.

[0135] In the second embodiment, the Verifier utilizes migration certificates to mitigate the vulnerability of unauthorized use of the VC. Furthermore, in the second embodiment, reissuance of the VC is unnecessary, thus reducing the processing load when using the VC.

[0136] The following explains how MC acquisition (MC issuance) at timing (1) and timing (2) are performed within the hardware binding process described above (Figures 3 to 5), with reference to Figures 22 to 26.

[0137] In Figures 22 to 26, the "wallet 10" in Figures 3 to 5 is replaced by the "cloud wallet device 100". The cloud wallet device 100 is a device realized by launching a wallet application (wallet AP) on the cloud. The cloud wallet device 100 may also be called the "wallet device," "cloud wallet system," or "wallet." The wallet AP may also be called a "wallet instance." Furthermore, in Figures 22 to 26, a wallet service provider 60 appears.

[0138] Similar to the first embodiment, 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 up (operates) on the HW. When the cloud wallet device 100 starts up (operates) on the HW, the cloud wallet device 100 uses the public key and private key corresponding to the HW.

[0139] Furthermore, for the cloud wallet device 100 to be linked to the hardware, it may also mean that the cloud wallet device 100 does not start (operate) on the hardware, but the public key and private key used by the cloud wallet device 100 correspond to the hardware. The configuration of the cloud wallet device 100 in the second embodiment will be described later with reference to Figure 33.

[0140] (1) Issuance of MC when the wallet is started) First, refer to Figures 22 to 26 to explain the processing procedure when "(1) Issuance of MC when the wallet is started".

[0141] Steps S271 to S273 in Figure 22 are the same as steps S11 to S13 in Figure 3. In step S274, the cloud wallet provider (e.g., wallet provider 60) starts a wallet instance on the server (example hardware). Steps S275 to S280 in Figure 22 are the same as steps S15 to S20 in Figure 3. The process then proceeds to VC issuance in Figure 23.

[0142] Figure 23 shows the VC issuance sequence. Steps S291 to S300 in Figure 23 are the same as steps S31 to S40 in Figure 4. After VC issuance, the process proceeds to VC utilization shown in Figure 24.

[0143] Figure 24 shows the sequence using VC. Steps S312 to S318 in Figure 24 are the same as steps S52 to S58 in Figure 5.

[0144] Figure 25 shows the sequence when the cloud wallet device 100 is started. In S321, the cloud wallet device 100 is started. In S322, if the cloud wallet device 100 detects that the hardware associated with the cloud wallet device 100 has changed, in S323, the authentication / proof process (S275-S280) in Figure 22 (A) is executed. This proves that the cloud wallet device 100 is bound to the new hardware after the change.

[0145] In S324, the cloud wallet device 100 sends a request to the wallet provider 60 to issue a migration certificate. In S325, the wallet provider 60 issues a migration certificate to the cloud wallet device 100. The process then proceeds to VC usage via MC, as shown in Figure 26.

[0146] In step S322 of Figure 25, if it is determined that there are no hardware changes, the VC usage process shown in Figure 24 is performed.

[0147] Referring to Figure 26, the process of using VC with MC will be explained. In S331, the cloud wallet device 100 notifies the Verifyer 30 of the wallet security function.

[0148] Next, optional steps S332 to S334 are performed. In S332, the Verified 30 requests wallet bi-party authentication credentials from the cloud wallet device 100. In S333, the cloud wallet device 100 displays the wallet bi-party authentication credentials to the Verified 30. In S334, the Verified 30 checks the wallet bi-party authentication.

[0149] In S335, the Verified 30 requests the cloud wallet device 100 to display the credentials bound to the hardware key. In S336, the cloud wallet device 100 presents the migration certificate to the Verified 30 and displays the credentials bound to the hardware key (the hardware key before the change). In S337, a challenge-response procedure using the new public key (hardware key) is performed between the Verified 30 and the wallet 10. An example of the challenge-response procedure is as described above.

[0150] ((2) MC issuance when VC is presented) Next, referring to Figures 27 to 30, the hardware binding processing procedure when "(2) MC issuance when VC is presented" will be explained.

[0151] Steps S341 to S343 in Figure 27 are the same as steps S11 to S13 in Figure 3. In step S344, the cloud wallet provider (e.g., wallet provider 60) starts a wallet instance on the server. Steps S345 to S350 in Figure 27 are the same as steps S15 to S20 in Figure 3. Next, the VC issuance process begins.

[0152] Figure 28 shows the sequence for issuing a VC. Steps S361 to S370 in Figure 28 are the same as steps S31 to S40 in Figure 4. Next, we proceed to using the VC.

[0153] Referring to Figure 29, the process of using VC will be explained. In S381, the cloud wallet device 100 notifies the Verifyer 30 of the wallet security function.

[0154] Next, optional steps S382 to S384 are performed. In S382, the Verified 30 requests wallet bi-party authentication credentials from the cloud wallet device 100. In S383, the cloud wallet device 100 displays the wallet bi-party authentication credentials to the Verified 30. In S384, the Verified 30 checks the wallet bi-party authentication.

[0155] In S385, the Verified 30 requests the cloud wallet device 100 to display the credentials bound to the hardware key. In S386, the cloud wallet device 100 displays the credentials bound to the hardware key to the Verified 30. In S387, a challenge-response procedure is performed between the Verified 30 and the wallet 10. An example of the challenge-response procedure is as described above.

[0156] Figure 30 shows the sequence when an MC is issued when a VC is presented after a VC has been issued. Steps S391 to S396 in Figure 30 are the same as steps S51 to S56 in Figure 5.

[0157] In response to the request in S396, the cloud wallet device 100 checks in S397 whether the hardware associated with the cloud wallet device 100 has changed. If it detects that the hardware has changed, the authentication / proof process (S344-S350) shown in Figure 27 (A) is executed in S398. This verifies that the cloud wallet device 100 is bound to the new hardware after the change.

[0158] In S399, the cloud wallet device 100 sends a request to the wallet provider 60 to issue a migration certificate. In S400, the wallet provider 60 issues a migration certificate to the cloud wallet device 100. In S401, the process of using VC with MC (C) shown in Figure 26 is executed.

[0159] In S397 of Figure 30, if it is determined that there are no hardware changes, the process proceeds to S402 without issuing an MC. In S402, the cloud wallet device 100 displays the credentials bound to the hardware key to the Verifyer 30. In S403, a challenge-response process is performed between the cloud wallet device 100 and the Verifyer 30.

[0160] (Processing Flow) Referring to Figure 31, the processing flow for (1) issuing MC when the wallet is started will be explained.

[0161] In S530, the cloud wallet device 100 starts up. If there is a change in the hardware on which the cloud wallet device 100 operates, proceed to S532 (Yes in S531); if there is no hardware change, proceed to S533 (No in S531).

[0162] In S532, MC issuance is performed. In S533, the cloud wallet device 100 presents the VC and MC to the Verifyer 30. In S534, verification is performed using challenge response, and in S535, the Holder 12 uses the content.

[0163] Referring to Figure 32, the processing flow when (2) MC is issued when VC is presented will be explained.

[0164] In S540, the cloud wallet device 100 starts up. In S541, the cloud wallet device 100 receives a VC request.

[0165] If there is a change in the hardware on which the cloud wallet device 100 operates, proceed to S543 (Yes in S542); otherwise, proceed to S547 (No in S542).

[0166] In S543, the MC is issued. In S544, the cloud wallet device 100 presents the VC and MC to the Verifyer 30.

[0167] In S545, a challenge-response verification is performed, and in S546, the content is used by Holder 12 and the process ends.

[0168] Furthermore, in S547, which proceeds if there are no hardware changes, a challenge-response verification is performed, and in S548, the content is used.

[0169] (System Configuration Example) Figure 33 shows an example of the configuration of the cloud wallet device 100 in the second embodiment. As shown in Figure 33, the configuration of the cloud wallet device 100 in the second embodiment is the same as the configuration of the cloud wallet device 100 in the second embodiment, however, the information that the cloud wallet device 100 sends and receives with other devices may differ between the first and second embodiments.

[0170] Figure 33 also shows the Holder 12, Issuer 20, Verifyer 30, and wallet service provider 60 that communicate with the cloud wallet device 100. Holder 12 is, for example, a terminal held by the user. Issuer 20 and Verifyer 30 are, for example, servers.

[0171] As shown in Figure 33, the cloud wallet device 100 includes hardware (HWj) associated with the cloud wallet device 100. In Figure 33, PBLC_key represents the public key, PRVT_key represents the private key (which may also be called the secret key), and MC represents the migration certificate.

[0172] Furthermore, the cloud wallet device 100 includes a wallet management unit 130, a VC request unit 110, a VC receiving unit 120, a VC presentation unit 140, a VC authentication unit 150, a VC issuance acceptance unit 170, a VC issuance notification unit 180, an MC request unit 190, and an MC receiving unit 195.

[0173] Furthermore, some or all of the "wallet management unit 130, VC request unit 110, VC receiving unit 120, VC presentation unit 140, VC authentication unit 150, VC issuance acceptance unit 170, VC issuance notification unit 180, MC request unit 190, and MC receiving unit 195" may be collectively referred to as a processing unit (or processor).

[0174] Furthermore, the cloud wallet device 100 that performed the VC issuance process holds the VC, including the public key. In this embodiment, if the hardware associated with the cloud wallet device 100 is changed, the VC already held by the cloud wallet device 100 will be transferred to the changed hardware.

[0175] The wallet management unit 130 manages the cloud wallet device 100. 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.

[0176] The VC presentation unit 140 presents the VC, including the public key, to the verifier 30. The VC authentication unit 150 sends and receives challenge requests and challenge responses. The VC issuance reception unit 170 receives a VC issuance request from the holder 12. The VC issuance notification unit 180 notifies the holder 12 that the VC has been issued.

[0177] The MC request unit 190 requests the wallet provider 60 to issue a migration certificate. The MC receiving unit 195 receives the migration certificate from the wallet provider 60.

[0178] The wallet management unit 130 determines whether the public key in the VC held by the cloud wallet device 100 is different from the public key of the HW160 associated with the cloud wallet device 100. If they are different, it obtains a migration certificate. It also presents the held VC to the verifier 30 along with the migration certificate. More specifically, the wallet management unit 130 instructs the relevant function units to perform these operations.

[0179] (Regarding verification by MC) As explained above, in this embodiment, when verifying the VC (when using content), the cloud wallet device 100 presents the VC containing the old public key and the MC to the Verifyer 30, and the Verifyer 30 accepts the VC. At this time, the Verifyer 30 can use the MC to verify that the cloud wallet device 100 is the legitimate owner of the VC. This will be explained with reference to Figure 34. The basic mechanism is the same as in the first embodiment (Figure 18).

[0180] Here, a driver's license is used as an example of a virtual currency (VC). Furthermore, it is assumed that the hardware associated with the cloud wallet device 100 has changed from HW-A to HW-B.

[0181] The wallet provider 60 can find out what hardware the cloud wallet device 100 that requests MC issuance has been operating on in the past, and can verify that information.

[0182] For example, when wallet provider 60 receives a request from cloud wallet device 100 to issue a VC containing the public key of HW-A and an MC containing the public key of HW-B (new public key), wallet provider 60 can know that cloud wallet device 100 was indeed operating on HW-A and is now operating on HW-B. Based on this information, wallet provider 60 can issue an MC containing the public key of HW-A and the public key of HW-B to cloud wallet device 100.

[0183] Two specific examples of methods to achieve the above are Pattern A and Pattern B below. Either Pattern A or Pattern B may be used.

[0184] Pattern A: As shown in Figure 34, in Pattern A, the wallet provider 60 uses the wallet ID as a basis to refer to the history database and verify the history information.

[0185] In other words, the wallet provider 60 has a history database that stores records (information linking hardware and wallet IDs) indicating which cloud wallet device 100 was associated with which hardware. The history database can be created in any way. For example, as in pattern B described later, it may be created based on reports of the public key of the associated hardware from the cloud wallet device 100.

[0186] When the cloud wallet device 100 presents a wallet ID to the wallet service provider 60, the wallet service provider 60 can obtain and verify information about the hardware on which the cloud wallet device 100 operates (e.g., that it is running on HW-B after HW-A) based on the linking information between the hardware it manages and the wallet ID. The wallet ID is included in the MC issuance request from the cloud wallet device 100 to the wallet service provider 60. The wallet ID may also be included in the VC. The wallet ID may also be the public key of the wallet (cloud wallet device 100). The wallet ID may also be called the wallet identification information.

[0187] The wallet operator 60 can, by referring to the history database, issue an MC to the cloud wallet device 100 that includes, for example, the public key of HW-A and the public key of HW-B.

[0188] Pattern B: In Pattern B, the wallet provider 60 issues a wallet operation certificate VC linked to the wallet ID and the hardware's public key each time the cloud wallet device 100 is started and when a change in the hardware of the cloud wallet device 100 is detected, and stores it in the wallet provider 60's wallet. The above information is verified using the wallet operation certificate VC.

[0189] For example, in the example shown in Figure 34, if the hardware of the cloud wallet device 100 is changed and it starts up with HW-A, the cloud wallet device 100 presents the wallet ID and the public key generated from the hardware (HW-A) to the wallet provider 60. The legitimacy of ownership of this public key can be verified by a hardware-based challenge response. The wallet provider 60 uses the information presented by the cloud wallet device 100 to generate a wallet operation certificate VC containing the public key and stores it in the wallet provider 60's storage unit. The storage unit may also be the wallet itself.

[0190] Since the wallet operator 60 maintains wallet operation certificates (VCs) for each piece of hardware on which the cloud wallet device 100 has operated, it can, for example, detect when the hardware of the cloud wallet device 100 has changed from HW-A to HW-B. Therefore, it can issue a Certificate Key (MC) containing the public key of HW-A and the public key of HW-B.

[0191] As shown in Figure 34, in the second embodiment, the Verifier 30 receives the old VC and MC from the cloud wallet device 100. The Verifier 30 can confirm (verify) that the hardware associated with the cloud wallet device 100 has changed from HW-A to HW-B using the MC, and can therefore accept the old VC and provide content.

[0192] Below, we will explain a specific procedure for obtaining MC when the wallet is launched as Example 2-1, and a specific procedure for obtaining MC when VC is presented as Example 2-2.

[0193] (Example 2-1: MC acquisition performed when wallet is started) First, Example 2-1 will be explained with reference to Figure 35. Figure 35 is a diagram showing example sequences when VC is issued and when content is used. S411 to S415 correspond to the operation when VC is issued, and S416 to S422 correspond to the operation when content is used.

[0194] In S411, Holder 12 sends a VC issuance request. In S412, the wallet application (wallet AP) is launched. Here, the wallet AP is launched on the HWi. That is, the cloud wallet device 100 operates on the HWi.

[0195] In S413, the cloud wallet device 100 sends a VC issuance request to Issuer 20. This VC issuance request includes the public key i, which is the public key of HWi. In S414, Issuer 20 issues a VC containing the public key i to the cloud wallet device 100. In S415, a VC issuance notification is sent to Holder 12.

[0196] Next, we will explain the operation when using content. In S416, the wallet AP (cloud wallet device 100) starts up. Here, we assume that the wallet AP is started up on the new hardware, HWj. In other words, the cloud wallet device 100 operates on HWj. Also, any VC already acquired by the cloud wallet device 100 that was operating on HWi is transferred to the cloud wallet device 100 operating on HWj.

[0197] When the cloud wallet device 100 detects that the public key i in the VC it ​​already holds does not match the public key j of the HW on which the cloud wallet device 100 is currently operating, it decides to acquire the MC.

[0198] In S417, the cloud wallet device 100 sends an MC issuance request (including the VC and the new public key j) to the wallet service provider 60. In S238, the wallet service provider 60 sends an MC (including the old public key i and the new public key j) to the cloud wallet device 100. The old public key i is the public key i included in the current VC.

[0199] In S419, Holder 12 sends a content request to the cloud wallet device 100.

[0200] In S420, the cloud wallet device 100 sends a content request to the Verifyer 30. This content request includes the VC, which contains the hardware public key i used when the VC was acquired, and the MC, if the Verifyer possesses one.

[0201] In S422, a challenge request / challenge response exchange takes place between the cloud wallet device 100 and the Verifyer 30. When the MC is presented to the Verifyer 30, specifically, the Verifyer 30 sends a challenge request to the cloud wallet device 100 that includes encrypted authentication data encrypted using the new public key j. The cloud wallet device 100 decrypts the authentication data using the private key corresponding to the public key j and sends a challenge response containing the decrypted authentication data to the Verifyer 30. The Verifyer 30 checks the challenge response and confirms that it is OK. This OK means that the binding between the HW on which the cloud wallet device 100 operates and the VC has been confirmed to be correct via the MC.

[0202] In S422, the Verifier 30 provides content to the Holder 12.

[0203] (Example 2-2: VC update performed when VC is presented) Next, Example 2-2 will be described with reference to Figure 36. Figure 36 is a diagram showing example sequences when a VC is issued and when content is used. S431 to S435 correspond to the operations when a VC is issued, and S436 to S443 correspond to the operations when content is used.

[0204] In S431, Holder 12 sends a VC issuance request. In S432, the wallet application (wallet AP) starts up on a certain piece of hardware.

[0205] In S433, the cloud wallet device 100 sends a VC issuance request to Issuer 20. This VC issuance request includes the public key i of the hardware. In S434, Issuer 20 issues a VC containing the public key i to the cloud wallet device 100. In S435, the cloud wallet device 100 sends a VC issuance notification to Holder 12.

[0206] Next, we will explain the operation when using content. In S436, the wallet AP (cloud wallet device 100) starts up. Here, we assume that the wallet AP is started up on hardware different from the hardware mentioned above. Also, any VC already acquired by the cloud wallet device 100 that was running on the previous hardware is transferred to the cloud wallet device 100 running on the new hardware.

[0207] In S437, Holder 12 sends a content request to the cloud wallet device 100.

[0208] In S438, when the cloud wallet device 100 detects that the public key i in the VC it ​​already holds does not match the public key j of the HW on which the cloud wallet device 100 is currently operating, it decides to acquire the MC.

[0209] In S439, the cloud wallet device 100 sends an MC issuance request (including the VC and the new public key j) to the wallet service provider 60. In S440, the wallet service provider 60 sends an MC (including the old public key i and the new public key j) to the cloud wallet device 100. The old public key i is the public key included in the current VC.

[0210] In S441, the cloud wallet device 100 sends a content request to the Verifyer 30. This content request includes the VC, which contains the hardware public key i used when the VC was acquired, and the MC, if one is held.

[0211] In S442, a challenge request / challenge response exchange takes place between the cloud wallet device 100 and the Verifyer 30. The challenge response procedure is the same as in Example 2-1. An OK result in the challenge response means that the binding between the hardware on which the cloud wallet device 100 operates and the VC has been confirmed to be correct via the MC.

[0212] In S443, the Verifier 30 provides content to the Holder 12.

[0213] (Example configuration of wallet operator 60) Figures 37 and 38 show an example configuration of the information processing device 500 that functions as a wallet operator 60 common to the first and second embodiments.

[0214] The information processing device 500 shown in Figure 37 includes a storage unit 510 for storing hardware history information associated with the cloud wallet device 100, and a processing unit 520 that, by referring to the storage unit 510, issues certification information including the public key of the hardware to which the cloud wallet device 100 is currently associated and the public keys of hardware to which the cloud wallet device 100 was previously associated. A migration certificate is an example of such certification information.

[0215] The information processing device 500 shown in Figure 38 has a storage unit 530. The information processing device 500 also includes a generation unit 540 that receives the public key of the hardware to which the cloud wallet device 100 is associated from the cloud wallet device 100, generates operational certification information for the cloud wallet device 100 including the public key, and stores the operational certification information in the storage unit 530, and a processing unit 550 that issues certification information based on the operational certification information, including the public key of the hardware to which the cloud wallet device 100 is associated and the public key of the hardware to which the wallet device was previously associated. A migration certificate is an example of such certification information.

[0216] (Hardware Configuration Example) The devices described in the first and second embodiments (cloud wallet device 100, Issuer 20, Verifyer 30, information processing device 500, etc.) can all 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.

[0217] In other words, the device can be realized by using hardware resources such as the CPU and memory built into a 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), saved, and distributed. It can also be provided via a network, such as the Internet or email.

[0218] Figure 39 shows an example of the hardware configuration of the computer described above. The computer in Figure 39 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 by bus B. The computer may also be equipped with a GPU.

[0219] The program that enables processing on the computer is provided on a recording medium 1001, such as a CD-ROM or memory card. When the recording medium 1001 containing 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; it may also be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files and data.

[0220] The memory device 1003 reads and stores a program from the auxiliary storage device 1002 when a program startup command is received. The CPU 1004 implements the functions related to the memory device 1003 according to 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) etc., based on a program. The input device 1007 consists of a keyboard and mouse, buttons, or a touch panel, etc., and is used to input various operation commands. The output device 1008 outputs the calculation results.

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

[0222] Further details regarding the above embodiments are disclosed below, specifically Appendix 1 and Appendix 2.

[0223] <Note 1> (Note 1) An information processing device comprising: a storage unit for storing hardware history information associated with a wallet device; and a processing unit that, by referring to the storage unit, issues certification information including the public key of the hardware to which the wallet device is associated and the public keys of hardware to which the wallet device was previously associated. (Note 2) An information processing device comprising: a generation unit that receives the public key of the hardware to which the wallet device is associated from a wallet device, generates operational certification information for the wallet device including the public key, and stores the operational certification information in the storage unit; and a processing unit that, based on the operational certification information, issues certification information including the public key of the hardware to which the wallet device is associated and the public keys of hardware to which the wallet device was previously associated. (Note 3) A wallet device for managing credential information, comprising a processing unit that, when the first public key of hardware associated with the wallet device and the second public key included in the credential information held by the wallet device are different, acquires certification information indicating that the hardware associated with the wallet device has been changed, and transmits an issuance request including the certification information to an issuing device to reacquire the credential information. (Note 4) The wallet device according to Note 3, wherein the certification information includes the first public key and the second public key. (Note 5) An information processing method executed by an information processing device, wherein the information processing device comprises a storage unit for storing history information of hardware associated with a wallet device, and an information processing method comprising the step of issuing certification information including the public key of the hardware associated with the wallet device and the public key of hardware to which the wallet device was previously associated, by referring to the storage unit.(Note 6) An information processing method to be executed by an information processing device, comprising the steps of: receiving the public key of the hardware to which the wallet device is associated from a wallet device, generating operational certification information for the wallet device including the public key, and storing the operational certification information in a storage unit; and issuing certification information based on the operational certification information, including the public key of the hardware to which the wallet device is associated and the public key of the hardware to which the wallet device was previously associated. (Note 7) A non-temporary storage medium storing a program for causing a computer to function as each part of the information processing device described in Note 1 or 2. (Note 8) A non-temporary storage medium storing a program for causing a computer to function as each part of the wallet device described in Note 3.

[0224] <Note 2> (Note 1) A wallet device for managing credential information, comprising a processing unit that, when the first public key of the hardware associated with the wallet device and the second public key included in the credential information held by the wallet device are different, acquires certification information indicating that the hardware associated with the wallet device has been changed, and transmits a content request including the credential information and the certification information to a verification device. (Note 2) The wallet device according to Note 1, wherein the certification information includes the first public key and the second public key. (Note 3) The wallet device according to Note 1, wherein the certification information is information issued based on the history information of the hardware associated with the wallet device. (Note 4) The wallet device according to Note 1, wherein the certification information is information issued based on the operation certification information of the wallet device. (Note 5) The wallet device according to Note 1, wherein the processing unit performs verification processing with the verification device using a challenge response with the first public key. (Appendix 6) An information processing method performed by a wallet device that manages credentials, comprising the steps of obtaining certification information indicating that the hardware associated with the wallet device has been changed when the first public key of the hardware associated with the wallet device and the second public key included in the credentials held by the wallet device are different, and transmitting a content request including the credentials and the certification information to a verification device. (Appendix 7) A non-temporary storage medium storing a program for causing a computer to function as each part of the wallet device described in any one of Appendix 1 to 5.

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

[0226] 12 Holder 20 Issuer 30 Verifyer 40 Certifying entity 50 Trust registry 10 Wallet 100 Cloud wallet device 110 VC request unit 120 VC receipt unit 130 Wallet management unit 140 VC presentation unit 150 VC authentication unit 160 Hardware 170 VC issuance acceptance unit 180 VC issuance notification unit 190 MC request unit 195 MC receipt unit 500 Information processing device 510, 530 Storage unit 520, 550 Processing unit 540 Generation 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. An information processing device comprising: a storage unit for storing hardware history information associated with a wallet device; and a processing unit that, by referring to the storage unit, issues certification information including the public key of the hardware to which the wallet device is currently associated and the public keys of hardware to which the wallet device was previously associated.

2. An information processing device comprising: a generation unit that receives the public key of the hardware to which the wallet device is associated from the wallet device, generates operational certification information for the wallet device including the public key, and stores the operational certification information in a storage unit; and a processing unit that issues certification information based on the operational certification information, including the public key of the hardware to which the wallet device is associated and the public key of the hardware to which the wallet device was previously associated.

3. A wallet device for managing credentials, comprising a processing unit that, when the first public key of hardware associated with the wallet device and the second public key included in the credentials held by the wallet device are different, acquires certification information indicating that the hardware associated with the wallet device has been changed, and transmits an issuance request including the certification information to an issuing device to reacquire the credentials.

4. The wallet device according to claim 3, wherein the certification information includes the first public key and the second public key.

5. An information processing method performed by an information processing device, wherein the information processing device includes a storage unit for storing historical information of hardware associated with a wallet device, and the information processing method comprises the step of issuing certification information including the public key of the hardware to which the wallet device is associated and the public keys of hardware to which the wallet device was previously associated, by referring to the storage unit.

6. An information processing method executed by an information processing device, comprising the steps of: receiving the public key of hardware to which the wallet device is associated from a wallet device, generating operational certification information for the wallet device including the public key, and storing the operational certification information in a storage unit; and issuing certification information based on the operational certification information, including the public key of hardware to which the wallet device is associated and the public key of hardware to which the wallet device was previously associated.

7. A program for causing a computer to function as a component of the information processing apparatus described in claim 1 or 2.

8. A program for causing a computer to function as a component of the wallet device described in claim 3.

Images