Terminal, communication system, communication method, and program

Abstract

This terminal is provided with: a request processing unit that requests an information processing device for operating a wallet application to transmit a digital identity requested by an external service, and receives the digital identity from the information processing device; and a transmission unit that transmits the digital identity to the external service.

Description

Terminal, communication system, communication method, and program

[0001] The present invention relates to digital identity wallets.

[0002] Self-sovereign identity (SSI) technology is being considered, which allows users to manage their own identifiers and identities and control who receives them, without relying on a centralized identity provider (IdP) or the like (Non-Patent Documents 1 and 2).

[0003] In the world of SSI, there are three parties: Holders, such as users who manage / hold their own digital identity data (ID); Issuers, who certify attribute information, qualification information, etc. for users, etc. and issue attribute / qualification certificates (e.g., VCs); and Verifiers, who verify the Holder's attributes, qualifications, etc. by requesting and receiving attribute / qualification certificates containing the user's identity information necessary to provide services from the Holder, and make decisions on providing services, etc.

[0004] Furthermore, there is a conventional technology in which a digital identity wallet is provided as a cloud service with the aim of reducing the burden on users (holders) associated with wallet management.

[0005] "Decentralized Identifiers (DIDs) v1.0," W3C Recommendation, 19 July 2022https: / / www.w3.org / TR / did-core / "Verifiable Credentials Data Model v1.1," W3C Recommendation, 03 March 2022 https: / / www.w3.org / TR / vc-data-model /

[0006] Generally, in a cloud wallet system, it is conceivable that a wallet application running on the cloud wallet system will communicate directly with an issuer or a verifier. However, when the wallet application communicates directly with an issuer or a verifier, there is a problem in that information about which service (issuer / verifier) ​​the wallet application is communicating with is revealed to the cloud wallet operator, etc.

[0007] The present invention has been made in consideration of the above points, and aims to provide a technology for concealing communication destination information of a wallet application from cloud wallet operators and the like in a cloud wallet system.

[0008] According to the disclosed technology, a terminal is provided which includes a request processing unit that requests an information processing device running a wallet application to transmit a digital identity requested by an external service and receives the digital identity from the information processing device, and a transmission unit that transmits the digital identity to the external service.

[0009] The disclosed technology provides a technology for realizing a cloud wallet that reduces the risk of attacks and fraud from administrators and improves user privacy and self-sovereignty.

[0010] FIG. 1 is a diagram for explaining an overview of a first embodiment. FIG. 2 is a diagram showing the configuration of a communication system in the first embodiment. FIG. 3 is a diagram showing a specific example of data stored in a user data DB 230. FIG. 4 is a diagram showing the configuration of a communication system in the first embodiment. FIG. 5 is a diagram showing an example of the configuration of ID data. FIG. 6 is a diagram showing the configuration of a communication system in the first embodiment. FIG. 7 is a diagram for explaining a problem. FIG. 8 is a diagram showing the configuration of a communication system in a second embodiment. FIG. 9 is a diagram showing the configuration of a user terminal 100 in the second embodiment. FIG. 10 is a diagram showing an example of the hardware configuration of a device.

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

[0012] In the following description, unless otherwise clearly indicated from the context, "A / B" means "A or B." Also, "A or B" includes A only, B only, and "A and B."

[0013] The first and second embodiments will be described below. The second embodiment is based on the first embodiment. However, the application of the technology according to the second embodiment is not limited to the cloud wallet system according to the first embodiment. The technology according to the second embodiment may also be applied to a general cloud wallet system.

[0014] [First embodiment]

[0015] In the first embodiment, a technology for realizing a cloud-based digital identity wallet with improved user privacy and self-sovereignty will be described. In this embodiment, a cloud-based digital identity wallet with improved user privacy and self-sovereignty is realized in a cloud wallet infrastructure (which may also be called a cloud wallet system) by providing protection using a physical security environment such as a TEE and by making the protection status verifiable by the user. Specific technologies for realizing this will be described below.

[0016] (Outline of First Embodiment) Before describing the technology according to this embodiment in detail, an outline of the target attack and the solution will be first described with reference to FIG.

[0017] In this embodiment, there are provided a user terminal 100 (which may be referred to as a UE) and a cloud wallet infrastructure 200. The cloud wallet infrastructure 200 is provided on the cloud, and the user terminal 100 can communicate with the cloud wallet infrastructure 200 via a communication network.

[0018] The user terminal 100 accesses the cloud wallet infrastructure 200 to obtain, for example, ID data to be presented to an SSI-based service. In addition, the user terminal 100 can safely store, for example, ID data created by itself in the cloud wallet infrastructure 200.

[0019] The cloud wallet infrastructure 200 has a physical security environment (e.g., HSM, TEE, etc.). Note that HSM and TEE are existing technologies, and HSM is disclosed in "https: / / link.springer.com / chapter / 10.1007 / 978-3-031-33386-6_16", and TEE is disclosed in "Introduction-to-Trusted-Execution-Environment-15May2018.pdf (globalplatform.org)".

[0020] A wallet application runs in the physical security environment. The wallet application performs processing using ID data or key data in the physical security environment. The configuration and operation of the cloud wallet platform 200 will be described in detail later.

[0021] The configuration in Figure 1 allows only users to access their own cloud wallets using any access authentication method. In addition to preventing fraud by general attackers, it is also possible to prevent fraud by cloud service providers / administrators.

[0022] In this specification, the term "user" includes not only a person but also a device such as a terminal used by the user, unless the context clearly indicates that the term refers to a person. Also, "app" is an abbreviation for "application."

[0023] The targeted attacks (1) to (4) and the solutions to each attack are outlined below.

[0024] (1) Deploying and providing a compromised wallet app This problem can be solved by allowing users to verify the deployment of a legitimate app. This is called "Solution 1."

[0025] (2) Providing a wallet app launched in a normal environment, disguised as a physical security environment. This problem is solved by enabling users to verify that the wallet app is running in a physical security environment. This is called "Solution 2."

[0026] (3) Tampering or Exploitation of Stored ID Data This problem can be solved by making encrypted user data decryptable only by the user, the UE, and the wallet application in the physical security environment built for the user. This is called "Solution 3." It can also be solved by making the integrity of the data verifiable by the user, which is called "Solution 4."

[0027] (4) Unauthorized access with admin privileges This issue is resolved by Solution 2, which allows users to verify that they are operating within a physical security environment.

[0028] (System Configuration Example) Fig. 2 shows a configuration example of a communication system according to the first embodiment. As shown in Fig. 2, this communication system includes a user terminal 100, a cloud wallet platform 200, and an external service 500. The external service 500 is a device / system equivalent to an issuer / verifier, etc. The user terminal 100 may also be called a "terminal," and the cloud wallet platform 200 may also be called a "cloud wallet system" or an "information processing device."

[0029] As shown in Fig. 2, the user terminal 100 has a wallet verification function 110, an authentication function 120, a UI 130, a key DB (database) 140, and a wallet access information DB 150. Note that Fig. 2 does not show functions that are generally provided in a device / terminal, such as a communication function.

[0030] The cloud wallet infrastructure 200 has a wallet application data DB 210, an authentication data DB 220, a user data DB 230, a physical access environment management function 240, an access authentication function 250, a physical security environment 260, and a wallet application communication control unit 270. The wallet application data DB 210, the authentication data DB 220, and the user data DB 230 may be collectively referred to as "databases."

[0031] Furthermore, physical security environment 260 has wallet application 261 (ID management function 262). Wallet application 261 is a function that is realized by executing program code that defines the processing procedures of ID management function 262 on physical security environment 260. In other words, wallet application 261 may also be called ID management function 262.

[0032] Note that any one, any two, or all of the wallet application data DB 210 , the authentication data DB 220 , and the user data DB 230 may be provided outside the cloud wallet platform 200 .

[0033] The physical security environment 260 is generated (constructed) for each user. Note that the "physical security environment for each user" also includes a form that provides an isolated virtual security environment for each user by using virtualization technology on hardware that realizes a physical security environment such as a TEE (e.g., AMD-SEV, https: / / www.amd.com / ja / developer / sev.html).

[0034] A communication system with the above-described configuration provides a wallet application 261 protected by a physical security environment 260 for each user, generates and certifies data encryption keys / decryption keys, provides a mechanism that allows only the user, UE, and the physical security environment 260 for each user to decrypt user data, and provides a mechanism for detecting / preventing data tampering.

[0035] An overview of the functions, the data contents of the database, and an example of the operation of the communication system related to the realization of the above mechanism will be explained below.

[0036] <User Terminal 100> The authentication function 120 (which may include authentication information for authentication) is a function related to user authentication when the user terminal 100 accesses the cloud wallet infrastructure 200 / wallet application 261.

[0037] The wallet verification function 110 verifies that the wallet application 261 is running on the physical security environment 260 and that it is a legitimate wallet application 261, using information notified from the cloud wallet platform 200. This function corresponds to Solution 1 and Solution 2. The wallet verification function 110 also includes a function for Solution 4.

[0038] The UI 130 is a browser or client application used when accessing the cloud wallet platform 200 / wallet application 261.

[0039] Key DB 140 stores keys for encrypting and decrypting data. For example, if the key is a common key, the common key can be used for encryption and decryption. If the key is a pair of a public key and a private key, for example, the public key can be used for encryption and the private key can be used for decryption.

[0040] Wallet access information DB150 stores wallet access information such as "identifier, private key, password, etc." for wallet access.

[0041] The method of user authentication using the authentication function 120 (and the access authentication function 250 on the cloud wallet platform 200 side) is not limited to a specific method, but for example, the following method can be used.

[0042] The user public key for access authentication is provided directly to the cloud wallet infrastructure 200, or the cloud wallet infrastructure 200 is provided with a means for accessing a database or the like in which the user public key is stored. Then, the authentication function 120 notifies the cloud wallet infrastructure 200 of a message signed with the user private key corresponding to the user public key, and the access authentication function 250 of the cloud wallet infrastructure 200 verifies that the signature is correct using the public key.

[0043] Alternatively, an access authentication method based on ID / password or biometric authentication such as FIDO may be used.

[0044] <Cloud Wallet Platform 200> The wallet application data DB 210 stores wallet application data such as application codes and hash values ​​of application codes. The wallet application data is used in Solution 4, for example.

[0045] The authentication data DB 220 stores authentication data such as an "identifier, public key, password, etc." used in the cloud wallet platform 200 for user wallet access.

[0046] Encrypted user data is stored in the user data DB 230. The user data is, for example, a DID / VC or "ID data such as a private key, a public key, and setting data" associated with the DID.

[0047] Fig. 3 shows a specific example of data stored in the user data DB 230. As shown in Fig. 3, the user data DB 230 stores user identifiers such as DIDs and encrypted user data in association with each other.

[0048] With regard to the data stored in the user data DB 230, among the user setting data necessary for building a TEE environment or an application, data with low privacy may be stored in the unencrypted state without being encrypted.

[0049] Note that the key for decrypting the encrypted ID data held by the user data DB 230 is handled only within the user terminal 100 and the physical security environment 260 for each user so that it cannot be obtained by the wallet platform administrator or other applications, and is sent to the user terminal 100 before resources are released in the physical security environment 260. The encryption key is generated for each user within the physical security environment 260. These functions correspond to Solution 3.

[0050] In addition, in preparation for risks such as loss of the user terminal 100, it is also possible to back up the encryption key received by the user terminal 100 from the user terminal 100 to cloud storage under an administrator other than the administrator of the cloud wallet platform 200.

[0051] The access authentication function 250 performs the above-mentioned user authentication as well as authentication of external systems 300 such as issuers / verifiers that are allowed to access the wallet application 260 .

[0052] (Operation Example 1 of Communication System) Operation example 1 of the communication system will be described in accordance with the step numbers (S1, etc.) shown in FIG.

[0053] In S1, the user terminal 100 accesses the access authentication function 250 in the cloud wallet platform 200. The access authentication function 250 performs user authentication.

[0054] In S2, if the access authentication function 250 succeeds in user authentication, it instructs the physical security environment management function 240 to construct a physical security environment 260 for the user and a wallet application 261. The physical security environment management function 240 is, for example, a hypervisor that manages a virtual machine that operates as the physical security environment 260.

[0055] In S3-1, the physical security environment management function 240 creates, for example, a user TEE environment as the user's physical security environment 260. The physical security environment management function 240 also generates the user's wallet application 261. In generating the user's wallet application 261, the physical security environment 260 acquires user data and wallet application data from a database (S4).

[0056] In S3-2, the physical security environment management function 240 issues access destination information to the user wallet application 261, performs authorization settings for the access authentication function 250, and performs communication settings for the wallet application communication control unit 270.

[0057] In S5, the access authentication function 250 notifies the user terminal 100 of the access destination information (URL, etc.) of the wallet application 261.

[0058] In S6, user terminal 100 accesses wallet application 261 via wallet application communication control unit 270. Note that communication between user terminal 100 and wallet application 261 is encrypted. Also in S6, wallet application communication control unit 270 requests authentication from access authentication function 250, and a decision is made as to whether access is permitted or denied based on the authentication result.

[0059] In S1 and S6, authentication when accessing the cloud wallet platform 200 / wallet application 261 does not have to be key-based, and may be, for example, ID / password-based.

[0060] If the access in S6 is the user's first access to wallet application 261, then in S7 physical security environment 260 generates a key pair (public key, private key) or a common key for encrypting / decrypting the user's data ("encryption / decryption" means "encryption or decryption") and notifies the user of the key. If the access in S6 is the second or subsequent access to wallet application 261 from user terminal 100, physical security environment 260 receives from the user the private key or common key for encrypting / decrypting the user's data. This type of processing corresponds to Solution 3.

[0061] The trigger and timing of generating / receiving a key for encrypting / decrypting data for each user are not limited to the above example. For example, the UI 130 of the wallet application 261 may have a button for key generation and key registration, and when the user operates the button, the key may be generated and sent from the user.

[0062] When the physical security environment 260 transmits a key (called UK) for encrypting / decrypting data to the user terminal 100, it must prove that the key was generated within the legitimate physical security environment 260. This proof is realized, for example, by the following operation / processing.

[0063] When manufacturing the physical security environment 260, the manufacturer of the physical security environment 260 loads the physical security environment 260 with a unique key (specifically, the manufacturer's private key) and a certificate of the manufacturer, which are difficult to tamper with later.

[0064] The generated (activated) physical security environment 260 signs a message addressed to the user terminal 100, including the UK, with the physical security environment 260's unique key (the manufacturer's private key), and notifies the user terminal 100 of the message, the signature, and the manufacturer's certificate as a set.

[0065] The user terminal 100 (e.g., wallet verification function 110) verifies the authenticity of the signature using the manufacturer's public key. If the verification is successful, it is proven that the key (UK) included in the message was generated within the valid physical security environment 260.

[0066] It is assumed that the public key corresponding to the private key is included in the received manufacturer certificate, or is published on the manufacturer's website, a distributed ledger such as a blockchain, or is otherwise available for acquisition. The above message may be sent using technology such as IETF Remote Attestation.

[0067] In the above example, it is assumed that the manufacturer's certificate is embedded in the physical security environment 260, but the present invention is not limited to this. For example, an external certificate management system that manages certificates of manufacturers, etc. may be provided, and the user terminal 100 or the cloud wallet platform 200 may obtain the manufacturer's certificate from the certificate management system.

[0068] Furthermore, the user terminal 100 may obtain the manufacturer's certificate separately from the notification of the "message including the key and the signature." The example of using a certificate management system as described above is one example. In addition to this, the user terminal 100 may obtain the manufacturer's certificate by accessing the manufacturer's website or a distributed ledger such as a blockchain.

[0069] In addition, in order to make it possible to detect when the platform administrator deletes or tampers with user data stored on the cloud wallet platform 200 side, for example, the following processing is performed. The following processing corresponds to Solution 4.

[0070] The physical security environment 260 acquires a user data integrity verification trail, such as a hash value of "user data / encrypted user data," each time data is updated or at any timing, such as when the user logs out of the wallet, and transmits the user data integrity verification trail to the user terminal 100 via the wallet application communication control unit 270. In other words, the physical security environment 260 and the user terminal 100 share the user data integrity verification trail.

[0071] The user terminal 100 (e.g., the wallet verification function 110) acquires (calculates) a user data integrity verification trail of the "user data / encrypted user data" read from the wallet application 261 at a predetermined timing, such as the next time the wallet application 261 is accessed, and detects whether the "user data / encrypted user data" has been tampered with by comparing the user data integrity verification trail with the user data integrity verification trail stored within the user terminal 100.

[0072] "The next time the wallet application 261 is accessed" may be after the physical security environment 260 is restarted, or may not be after the physical security environment 260 is restarted.

[0073] Furthermore, the physical security environment 260 and the user terminal 100 share (store) the "user data / encrypted user data" itself, and for example, when the user terminal 100 next accesses the wallet app 261, it receives the "user data / encrypted user data" from the physical security environment 260 and compares the received "user data / encrypted user data" with the "user data / encrypted user data" that it stores, thereby detecting whether the "user data / encrypted user data" has been tampered with.

[0074] In the above process, when the user data integrity verification trail or "user data / encrypted user data" is notified from the physical security environment 260 to the user terminal 100, it is signed with a key unique to the physical security environment and notified together with a certificate, just like the notification of the key (UK) described above. As described above, the user terminal 100 may obtain the certificate separately from the notification of the key and signature.

[0075] An example of a user data integrity verification trail is a hash value (which may also be called a digest), but any information that can be used to perform user data integrity verification may be used as a user data integrity verification trail.

[0076] Furthermore, the meaning of "user data" may include "unencrypted user data" and "encrypted user data."

[0077] (Operation Example 2 of Communication System) Next, Operation Example 2 of the communication system will be described with reference to Fig. 4. Operation Example 2 of the communication system is an operation example related to wallet integrity proof, and corresponds to Solutions 1 and 2.

[0078] Wallet integrity certification is a mechanism that certifies the integrity of the wallet application 261 operating within the physical security environment 260 and the physical security environment 260, which is the execution environment of the wallet application 261, to an external actor (the user in this embodiment).

[0079] In S1, when the user accesses the cloud wallet platform 200 (S6 in FIG. 3 ), or when the user requests this process from the cloud wallet platform 200, the cloud wallet platform 200 acquires (calculates) a hash value of the wallet application 261 running on the physical security environment 260, signs the hash value with a key unique to the physical security environment (specifically, the manufacturer's private key), and then notifies the wallet verification function 110 of the user terminal 100 of a message including the hash value, the signature, and the manufacturer's certificate. This message may be notified using, for example, IETF Remote Attestation.

[0080] As described above, the message in S1 includes the hash value of the wallet application 261, the signature of the hash value (a signature using the unique key of the physical security environment), and the manufacturer's certificate.

[0081] The hash value of the wallet application 261 is an example of a trail for verifying the authenticity of the wallet application 261. As a trail other than the hash value of the wallet application 261, the program code / executable file of the wallet application 261 may be used. Also, something other than these may be used as the trail. The trail is signed with the unique key of the physical security environment.

[0082] The wallet application data DB 210 registers and makes publicly available verification data (correct answer information) for matching with the evidence obtained by the user terminal 100 from the cloud wallet platform 200, such as the source code and hash value of the wallet application 261.

[0083] In S2, the wallet verification function 110 acquires wallet application data (hash value, source code) from the wallet application data DB 210.

[0084] It should be noted that the wallet application data is not limited to being stored in the wallet application data DB 210. For example, the wallet application data may be stored in a location not under the control of the cloud wallet operator and using a public blockchain or the like. This can further increase resistance to tampering by the cloud wallet operator.

[0085] In S3, the wallet verification function 110 verifies that the genuine wallet application 261 is operating on the physical security environment 260 by comparing the hash value of the wallet application 261 notified from the cloud wallet platform 200 with the hash value obtained from the wallet application data DB 210.

[0086] In the above example, it is assumed that the manufacturer's certificate is embedded in the physical security environment 260, but the present invention is not limited to this. For example, an external certificate management system that manages certificates of manufacturers, etc. may be provided, and the user terminal 100 or the cloud wallet platform 200 may obtain the manufacturer's certificate from the certificate management system.

[0087] Furthermore, the user terminal 100 may obtain a certificate from the manufacturer separately from the notification of the hash value (an example of a trail) and the signature. The example of using a certificate management system as described above is one example. In addition to this, the user terminal 100 may obtain the manufacturer's certificate by accessing the manufacturer's website or a distributed ledger such as a blockchain.

[0088] In addition, it is assumed that the public key corresponding to the private key used to verify the signature is included in the manufacturer's certificate, or is made public on the manufacturer's website or in a distributed ledger such as a blockchain, and is therefore obtainable, as in the case of communication system operation example 1.

[0089] (Detailed Description) The ID data, the ID management function 262, the physical security environment 260, etc. will be described in more detail below.

[0090] In this embodiment, for example, a cloud wallet platform 200, which is a cloud service operated by an external cloud operator / administrator, manages users' digital identity data (ID data). The cloud wallet service provided to users by the cloud wallet platform 200 protects the confidentiality and integrity of the ID data from others, including the cloud operator / administrator. This reduces the risk of attacks and fraud not only from ordinary others but also from the cloud operator / administrator.

[0091] 3, the cloud wallet platform 200 includes an ID management function 262 (wallet application 261) that manages and stores user ID data. The ID management function 262 accesses the ID data stored in the user data DB 230 and performs ID management.

[0092] The user data DB 230 may be provided in an external device rather than in the cloud wallet platform 200. In this case, for example, access information to the external device may be held in the cloud wallet platform 200, and the access information may be used to access the ID data.

[0093] The identity data is kept confidential and has integrity, and the identity management function 262 operates in an integrity-preserving environment.

[0094] Specifically, the ID management function 262 is stored and operated in a hardware security module (HSM) or a trusted execution environment (TEE), which are existing technologies, to protect the confidentiality and integrity of the ID data and the ID management function 262, including while the data is being processed.

[0095] Generally, HSMs provide higher levels of confidentiality and integrity protection than TEEs, but the ID management functions they include are fixed for each product, making TEEs more suitable for cloud providers who want to implement their own unique ID management functions.

[0096] Therefore, although the present embodiment assumes the use of a TEE, in principle, a similar configuration can be realized with an HSM. The physical security environment 260 provided in the cloud wallet platform 200 may use either a TEE or an HSM.

[0097] As described above, the wallet application 261 is program code that defines the processing procedure of the ID management function 262. The cloud wallet platform 200 according to this embodiment is equipped with a physical security environment 260, in which the wallet application 261 is executed. Also, a mechanism is provided that enables an external actor, such as a user, to verify that the legitimate wallet application 261 is operating in the legitimate physical security environment 260 and that user data has not been tampered with.

[0098] (Detailed Example of ID Data) Next, a detailed example of ID data will be described.

[0099] <Basics of ID Data> In the management of digital identities in this embodiment, the following ID data (1) to (5) are handled, for example. Note that the user (entity / subject) described below refers to a unit for managing attributes such as people, organizations, devices (including terminals), data, and services, and is not necessarily limited to individuals. Also, only some of the following (1) to (5) may be handled.

[0100] (1) Multiple User Identifiers Corresponding to a User A single user has multiple user identifiers depending on the purpose, such as an employee number and a payment service membership number.

[0101] (2) Key Data Corresponding to User Identifier Each user identifier is associated with key data generated to authenticate the user. The key data may be, for example, a password or a key pair for public key encryption.

[0102] (3) Key certification data that proves the correspondence between the user identifier and key data Each key data has key certification data that proves the correspondence between the user identifier and key data. In particular, if the key data is a key pair for public key cryptography, it has key certification data that proves the correspondence between the user identifier and the public key.

[0103] Examples of key certification data include public key certificates in PKI and DID documents in Distributed Identity (DID). Key certification data becomes effective when the correspondence between a public key and a user identifier is registered with a trusted external service. A trusted external service is a certification authority in the case of a public key certificate, or a distributed ledger in the case of a DID document.

[0104] (4) Multiple Attributes Corresponding to User Identifiers Each user identifier is associated with corresponding attribute data. For example, "name, organization, and job title" in an employee ID, or "name, bank account number, and service type" in a payment service ID. There are also cases where an ID or its attributes are attributes of another ID. For example, the name in the above example.

[0105] (5) Attribute certification data proving the correspondence between a user identifier and an attribute Each attribute has attribute certification data that proves the correspondence between the user identifier and the attribute. Attribute certification data is, for example, an attribute certificate in a PKI or a Verification Credential (VC) in a DID. Attribute certification data becomes valid when signed by a trusted external service. The trusted external service is an attribute authority in the case of an attribute certificate, and an issuer in the case of a VC.

[0106] <Accompanying Information> The user must also handle the following information that accompanies each of the above ID data, and the following information can also be considered as part of the ID data. Note that there may be cases where the accompanying information is not used.

[0107] - ID usage, registration destination, usage history, cancellation / expiration rules: Users use their ID based on this data.

[0108] - Key data generation method, encryption attributes (algorithm, key size, other parameters), validity period, and expiration time regulations: Users manage key data securely based on this data.

[0109] Registration destination of key certification data, validity period, usage history, and expiration time rules: Users use ID authentication based on this data.

[0110] - Attribute certification data registration destination, validity period, usage history, and expiration regulations: Users use attribute authentication based on this data.

[0111] <ID Data Structure> FIG. 5 shows an example of the structure of ID data based on the above content.

[0112] (Details of ID Management Function 262) The ID management function 262 can access the ID data to manage the ID data and execute the following processes (1) to (6), for example.

[0113] (1) User Identifier Generation User identifiers can be generated by the user themselves or generated externally and stored by the user as ID data. Employee numbers and membership numbers for existing services such as payment services are often the latter type, but in systems that emphasize "self-sovereignty," such as DID, the user generates the identifier themselves.

[0114] The ID management function 262 is used when a user generates a user identifier or when the user stores an externally generated user identifier as ID data. For example, the user accesses the ID management function 262, and the ID management function 262 stores the generated user identifier.

[0115] (2) Key Data Generation Similarly, keys can be generated by the user themselves or generated externally and stored by the user as ID data. In some cases, keys are generated simultaneously in the key certification data registration service. In the case of key data generation, the ID management function 262 is used for storage processing, etc., just as in the case of user identifier generation.

[0116] (3) Key certification data registration The ID management function 262 selects the registration destination service (collects options, determines selection criteria), creates registration application data (parameter setting based on regulations and security policies, signature), verifies and stores registration response data, etc.

[0117] (4) Attribute certification data registration The ID management function 262 selects the service to register to (collects options, determines selection criteria), creates registration application data (parameter settings based on regulations and security policies, signature), verifies and stores registration response data, etc.

[0118] (5) ID Authentication The ID management function 262 authenticates the user ID to others by submitting a signature using key data and key certification data.

[0119] (6) Attribute Authentication The ID management function 262 authenticates the user's attributes to others by signing using key data, presenting key certification data, and presenting attribute certification data.

[0120] (Protection by Physical Security Environment and Proof of Protection) Next, the functions of the physical security environment 260 in this embodiment will be described in more detail. The physical security environment 260 in this embodiment has the following functions.

[0121] (a) Wallet Integrity Proof (Corresponding to Solutions 1 and 2) Wallet application 261 operating within physical security environment 260 and physical security environment 260, which is the execution environment of wallet application 261, are set as the subject of proof, and the integrity of this subject of proof is proven to an external actor (e.g., user). A specific example is as described with reference to FIG. 4.

[0122] (b) Generating a key for encrypting / decrypting data and certifying the generated key (corresponding to Solution 3) The wallet application 261 running within the physical security environment 260 generates a key (a key for encrypting / decrypting data for each user) to exchange with an external actor (e.g., a user) and certifies to the external actor that the key was generated within the physical security environment 260.

[0123] Specifically, for example, a key pair (EK) and a certificate of the manufacturer that are installed in the physical security environment 260 by the manufacturer of the physical security environment 260 at the time of manufacturing and that are difficult to tamper with later are used.

[0124] When transmitting any key generated within physical security environment 260 to an external actor, physical security environment 260 can prove to the external actor that the key was generated within physical security environment 260 by signing the key with its private key (the private key of the key pair).As already explained, it is assumed that the public key corresponding to the private key is published on the manufacturer's website or the like and can be obtained.

[0125] When a TPM (Trusted Platform Module) is used, a multi-stage certification scheme is adopted in which an EK (Endorsement Key) is used to certify the generation of another key, an AIK (Attestation Identity Key), and the AIK is used to certify that yet another key was generated within the physical security environment 260. This type of certification scheme may be used in this embodiment.

[0126] (c) Persistence of user data in the wallet and detection / prevention of tampering (corresponding to solutions 3 and 4) In a physical security environment 260 such as a TEE, there are cases where user data and the wallet application 261 cannot be persisted. For example, this is the case when deleting the physical security environment 260 volatilizes the data in the environment.

[0127] In such a case, the physical security environment 260 encrypts the data handled within the physical security environment 260 with a key for each user and stores it in external storage or a database, etc. After the physical security environment 260 is shut down and then restarted / reconstructed, it restores this data from the storage, etc. where it was stored.

[0128] In addition, a mechanism is provided that allows the user to detect that the data restored in the above manner has not been tampered with.

[0129] For example, the physical security environment 260 stores a digest of the encrypted data in a "secure element (SE) or storage" associated with the physical security environment 260. The physical security environment 260 also transmits the digest to the user terminal 100, and the user terminal 100 stores the digest.

[0130] For example, after rebooting the physical security environment 260, the user terminal 100 calculates a digest of the encrypted data read from the physical security environment 260, compares the digest with the stored digest, and confirms that they match (that the data has not been tampered with). Also, as described above, the user data itself may be shared and stored between the physical security environment 260 and the user terminal 100, and after rebooting the physical security environment 260, the user terminal 100 may receive the data, thereby confirming whether the user data has been tampered with.

[0131] (Other Configuration Examples) The communication system in this embodiment may have the configuration shown in Fig. 6. As shown in Fig. 6, this communication system includes an information processing device 400 and a terminal 300. The cloud wallet platform 200 is an example of the information processing device 400, and the user terminal 100 is an example of the terminal 300.

[0132] The information processing device 400 includes a physical security environment 410 that runs a wallet application, and a communication unit 420. The communication unit 420 transmits to the terminal 300, for example, a message including a trail for verifying the validity of the wallet application, a signature for the trail, and a certificate corresponding to the signature.

[0133] Terminal 300 includes a receiving unit 310 and a verifying unit 320. Receiving unit 310 receives, for example, from information processing device 400, a message including a trail for verifying the legitimacy of a wallet application, a signature for the trail, and a certificate corresponding to the signature. Verification unit 320 verifies the signature and verifies the legitimacy of the wallet application by, for example, comparing the trail with a value obtained from an external database.

[0134] (Effects of the technology according to the first embodiment) As described above, the technology described in the first embodiment makes it possible to realize a cloud wallet that reduces the risk of attacks and fraud from an administrator and improves the privacy and self-sovereignty of users.

[0135] [Second Embodiment] Next, a second embodiment will be described. The second embodiment is based on the first embodiment, and functions are added to the first embodiment. However, the technology according to the second embodiment is not limited to that based on the first embodiment.

[0136] (Regarding the Technical Issues of the First Embodiment) In the communication system of the first embodiment, although user data handled by the cloud wallet is concealed from all but the user himself / herself, information about which service (issuer / verifier) ​​each user's wallet is communicating with is exposed to the cloud wallet operator / system. Therefore, collection and analysis of communication destination information may result in the infringement of privacy information such as the user's service usage trends. Note that, in order to explain the issues in an easy-to-understand manner, the issues are explained using the configuration of the first embodiment, but such issues may exist in general cloud wallet systems. The communication system of the first embodiment may not have this issue.

[0137] The problem will be described with reference to Fig. 7. Fig. 7 more specifically illustrates the external service 500 shown in the first embodiment as an issuer 510 and a verifier 520. Fig. 7 also illustrates a situation in which the user terminal 100 accesses a service after accessing the wallet application 261.

[0138] After S1 to S5 described in the first embodiment, in S6, the user terminal 100 accesses the wallet application 261. Specifically, the user inputs access destination information (Endpoint) of the wallet application 261 into the user terminal 100, and performs a login operation to the wallet application 261 using, for example, DID / VC.

[0139] In S7, the user terminal 100 accesses the verifier 520 to use the service provided by the verifier 520. In S8, the verifier 520 requests the user terminal 100 to present a digital identity (here, assumed to be a VC as an example).

[0140] Thereafter, in S9, the user terminal 100 requests the wallet application 261 to send the VC requested by the verifier 520. In S10, the wallet application 261 notifies the verifier 520 of the VC.

[0141] As described above, the wallet application 261 in the cloud wallet platform 200 directly communicates with the issuer / verifier. This poses a problem in that the cloud wallet platform 200 is able to obtain the user's communication destination information. As mentioned above, this problem is also a problem that general cloud wallet systems have. Below, a technique for solving this problem will be described.

[0142] (System Configuration in Second Embodiment) Fig. 8 shows an example of the configuration of a communication system in the second embodiment. The second embodiment differs from the first embodiment in that a digital identity processing function 160 is added to the user terminal 100. Other than this, the configurations of the first and second embodiments are basically the same.

[0143] The user terminal 100 may also include the wallet verification function 110, authentication 120, and UI 130 described in the first embodiment. In the cloud wallet platform 200, the wallet application data DB 210 is not shown.

[0144] The digital identity processing function 160 in the second embodiment requests, presents, communicates, etc. a digital identity.

[0145] More specifically, the digital identity processing function 160 supports certificate exchange protocols (e.g., OpenID4VP, DIDComm, DIF Presentation Exchange, Credential Handler API, etc.) for exchanging digital identities (e.g., attributes / credentials) with the Verifier 520 (mainly presentation processing).

[0146] In addition, the digital identity processing function 160 supports certificate issuance protocols (e.g., OpenID4VCI, DIDComm, DIF Issue Credential, Credential Handler API, etc.) for exchanging digital identities (e.g., attributes / credential certificates) with the Issuer 510 (mainly for issuance processing).

[0147] Furthermore, in relation to the key DB 140 in the second embodiment, any data encryption method may be used, as in the first embodiment. For example, when a common key encryption method is used, the same key is used for encryption and decryption. When a public key encryption method is used, encryption is performed using a public key and decryption is performed using a private key.

[0148] Furthermore, in relation to the wallet access information DB 150 in the second embodiment, when an access authentication method based on a public key cryptosystem is used, the wallet access information DB 150 has a private key for wallet access. However, the authentication method when accessing the cloud wallet platform 200 / wallet application 261 from the user terminal 100 is not limited to a specific method, and for example, an ID / password, a biometric authentication-based method such as FIDO, etc. may be used.

[0149] In the second embodiment, the wallet application 261 in the physical security environment 260 provided in the cloud wallet infrastructure 200 may have, in addition to a function of referencing stored user data and a function of storing user data, a function of converting a W3C VC into a VP to be presented to the Verifier 520, and a function of selecting a VC that meets the requirements of the VC presented by the Verifier 520 and presenting it to the user terminal 100.

[0150] It is assumed that the digital identity includes an identifier such as a W3C DID and attributes / credentials such as a W3C VC, but the digital identity is not limited to including these.

[0151] (Processing procedure in the second embodiment) In the second embodiment, communication between the cloud wallet infrastructure 200 and the Issuer 510 / Verifier 520 is carried out via the user terminal 100, thereby concealing the communication destination of the user terminal 100 from the cloud wallet infrastructure 200.

[0152] The processing procedure for realizing the above-described concealment of communication destinations will be described with reference to Fig. 8. Steps S1 to S6 are the same as steps S1 to S6 in the first embodiment.

[0153] In S6, the user terminal 100 accesses the wallet application 261, and then in S7, the digital identity processing function 160 of the user terminal 100 accesses the verifier 520. In S8, the verifier 520 requests the digital identity processing function 160 of the user terminal 100 to present a digital identity (e.g., VC).

[0154] In S9, the digital identity processing function 160 requests the digital identity requested by the verifier 520 from the wallet application 261, and the wallet application 261 responds to the digital identity processing function 160 with the requested digital identity.

[0155] In S10 , the digital identity processing function 160 presents the digital identity (e.g., VC / VP) received from the wallet application 261 to the verifier 520 .

[0156] Next, an example of the procedure for communication with the Issuer 510 will be described. The digital identity processing function 160 of the user terminal 100 receives the DID to be linked to the VC from the wallet application 261 and presents it to the Issuer 510. The digital identity processing function 160 of the user terminal 100 sends the VC received from the Issuer 510 to the wallet application 261. The wallet application 261 encrypts the VC and stores it in a database, for example, when logging out of the wallet. A more specific procedure is as follows. Note that S11 below is an optional procedure.

[0157] S11: The digital identity processing function 160 of the user terminal 100 accesses the wallet application 261 and obtains the stored identifier information (e.g., DID).

[0158] S12: The digital identity processing function 160 of the user terminal 100 accesses the Issuer 510 and requests the issuance of a digital identity (e.g., VC, attribute / credentials). When requesting a VC as a digital identity, the user may notify the Issuer 510 of the identifier information (e.g., DID) that should be linked to the VC.

[0159] S13: The Issuer 510 issues a digital identity to the user terminal 100.

[0160] S14: The digital identity processing function 160 of the user terminal 100 encrypts the digital identity received from the issuer 510 and sends it to the wallet application 261.

[0161] S15: The wallet application 261 stores the digital identity received from the user terminal 100 in the encrypted form in the database for that user in the cloud wallet platform 200.

[0162] (Other Configuration Examples) The user terminal 100 in this embodiment may have the configuration shown in Fig. 9. As shown in Fig. 9, this user terminal 100 includes a request processing unit 180 and a transmission unit 190. The digital identity processing function 160 is an example of the "request processing unit 180 and transmission unit 190." Note that the user terminal 100 may further include the receiving unit 310 and the verifying unit 320 in the first embodiment.

[0163] The request processing unit 180 requests the information processing device running the wallet application to send the digital identity requested by the external service, receives the digital identity from the information processing device, and the transmission unit 190 transmits the digital identity to the external service.

[0164] In addition, the request processing unit 180 may request an external service to issue a digital identity, receive the digital identity from the external service, and the transmission unit 190 may transmit the digital identity to an information processing device running a wallet application.

[0165] The information processing device may be the cloud wallet platform 200 described in the second embodiment, or may be a general cloud wallet system.

[0166] (Summary and effects of the technology related to the second embodiment) In the second embodiment, by introducing a digital identity processing function 160 that requests / presents / communicates a digital identity into the user terminal 100, the communication destination of the user terminal 100 can be concealed from the cloud wallet platform 200.

[0167] That is, the digital identity processing function 160 communicates between the cloud wallet platform 200, the Issuer 510, and the Verifier 520, appropriately acquires the digital identity stored in the cloud wallet platform 200, requests the digital identity from the Issuer 510, processes the receipt, and stores the received digital identity in the wallet system.

[0168] In addition, the digital identity processing function 160 appropriately acquires the digital identity stored in the cloud wallet platform 200 , receives a request to send the digital identity from the verifier 520 , and performs the process of sending the digital identity to the verifier 520 .

[0169] The above functions make it possible to conceal wallet communication destination information from cloud wallet operators / systems in a communication system using the cloud wallet infrastructure 200, thereby improving the privacy of wallet users.

[0170] (Hardware Configuration Example) Any of the devices (cloud wallet platform, information processing device, terminal, user terminal, UE, etc.) described in the first and second embodiments can be realized, for example, by running a program on a computer. This computer may be a physical computer or a virtual machine on the cloud.

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

[0172] Fig. 10 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 10 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 by a bus BS. The computer may further include a GPU.

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

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

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

[0176] <Additional Notes> (Additional Item 1) A terminal comprising: a request processing unit that requests an information processing device running a wallet application to transmit a digital identity requested by an external service and receives the digital identity from the information processing device; and a transmission unit that transmits the digital identity to the external service. (Additional Item 2) A terminal comprising: a request processing unit that requests an external service to issue a digital identity and receives the digital identity from the external service; and a transmission unit that transmits the digital identity to the information processing device running a wallet application. (Additional Item 3) The terminal according to Additional Item 1 or 2, further comprising: a reception unit that receives from the information processing device a message having a trail for verifying the legitimacy of the wallet application running in a physical security environment, a signature for the trail, and a certificate corresponding to the signature; and a verification unit that verifies the signature and verifies the legitimacy of the wallet application by comparing the trail with a value obtained from an external database. (Additional Item 4) A communication system comprising the terminal according to Additional Item 1 and the information processing device according to Additional Item 1. (Supplementary Item 5) A communication system comprising the terminal according to Supplementary Item 2 and the information processing device according to Supplementary Item 2. (Supplementary Item 6) A communication method executed by a terminal, comprising: a request processing step of requesting an information processing device running a wallet application to transmit a digital identity requested by an external service, and receiving the digital identity from the information processing device, and a transmission step of transmitting the digital identity to the external service. (Supplementary Item 7) A communication method executed by a terminal, comprising: a request processing step of requesting an external service to issue a digital identity, and receiving the digital identity from the external service, and a transmission step of transmitting the digital identity to an information processing device running a wallet application.(Supplementary Item 8) A non-transitory storage medium storing a program for causing a computer to function as each unit in the terminal according to Supplementary Item 1 or 2.

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

[0178] 100 User terminal 110 Wallet verification function 120 Authentication function 130 UI 140 Key DB 150 Wallet access information DB 200 Cloud wallet platform 210 Wallet application data DB 220 Authentication data DB 230 User data DB 240 Physical access environment management function 250 Access authentication function 260 Physical security environment 261 Wallet application 262 ID management function 270 Wallet application communication control unit 300 Terminal 310 Receiving unit 320 Verification unit 400 Information processing device 410 Physical security environment 420 Communication unit 500 External service 510 Issuer 520 Verifier 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 terminal comprising: a request processing unit that requests an information processing device running a wallet application to transmit a digital identity requested by an external service and receives the digital identity from the information processing device; and a transmission unit that transmits the digital identity to the external service.

2. A terminal comprising: a request processing unit that requests an external service to issue a digital identity and receives the digital identity from the external service; and a transmission unit that transmits the digital identity to an information processing device running a wallet application.

3. A terminal as described in claim 1 or 2, further comprising: a receiving unit that receives from the information processing device a message including a trail for verifying the legitimacy of the wallet application operating in a physical security environment and a signature for the trail; and a verifying unit that verifies the signature and verifies the legitimacy of the wallet application by comparing the trail with a value obtained from an external database.

4. A communication system comprising the terminal according to claim 1 and the information processing device according to claim 1.

5. A communication system comprising the terminal according to claim 2 and the information processing device according to claim 2.

6. A communication method executed by a terminal, comprising: a request processing step of requesting an information processing device running a wallet application to transmit a digital identity requested by an external service and receiving the digital identity from the information processing device; and a transmission step of transmitting the digital identity to the external service.

7. A communication method executed by a terminal, comprising: a request processing step of requesting an external service to issue a digital identity and receiving the digital identity from the external service; and a transmission step of transmitting the digital identity to an information processing device running a wallet application.

8. A program for causing a computer to function as each part of the terminal according to claim 1 or 2.

Images