Information processing device, terminal, communication system, communication method, and program

Abstract

This information processing device comprises: a physical security environment for operating a wallet application; and a communication unit for transmitting, to a terminal, a message including a trail for verifying the validity of the wallet application and a signature for the trail.

Description

Information processing device, 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] Also, a digital identity wallet (DIW) function has been proposed that stores the ID data of users (holders) and uses it for identity verification or attribute certification (Non-Patent Document 3). There are two implementation forms of DIW: a local wallet that is deployed in the user's operating terminal (also called UE), and a cloud wallet that is provided on a platform hosted by a cloud service provider or the like.

[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 / European digital identity wallet Architecture and Reference Framework, January 2023 https: / / digital-strategy.ec.europa.eu / en / library / european-digital-identity-wallet-architecture-and-reference-framework

[0006] The use of cloud-based DIW reduces the effort required for users to properly manage their own terminals that contain ID data and its processing functions (programs, etc.). It also reduces the risk of ID data being accessed from outside due to factors such as loss of the terminal or improper security settings.

[0007] However, since user ID data and its processing functions are under the control of the cloud wallet platform administrator (the administrator may also be called the "business operator"), there is a risk that the user's privacy may be violated due to misconduct by the administrator, such as by viewing the ID data.

[0008] The present invention has been made in consideration of the above points, and aims to provide technology for realizing a cloud wallet that reduces the risk of attacks and fraud from administrators and improves users' privacy and self-sovereignty.

[0009] According to the disclosed technology, an information processing device is provided that includes: a physical security environment in which a wallet application operates; and a communication unit that transmits to a terminal a message including a trail for verifying the validity of the wallet application and a signature for the trail.

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

[0011] It is a diagram for explaining an overview of an embodiment. It is a configuration diagram of a communication system in an embodiment of the present invention. It is a diagram showing a specific example of data stored in a user data DB 230. It is a configuration diagram of a communication system in an embodiment of the present invention. It is a diagram showing an example of the configuration of ID data. It is a configuration diagram of a communication system in an embodiment of the present invention. It is a diagram showing an example of the hardware configuration of a device.

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

[0013] 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."

[0014] In this 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 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.

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

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

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

[0018] 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)".

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

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

[0021] 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."

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

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

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

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

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

[0027] (System Configuration Example) Fig. 2 shows a configuration example of a communication system according to this 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 be called a "terminal," and the cloud wallet platform 200 may be called a "cloud wallet system" or an "information processing device."

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

[0029] 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."

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

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

[0032] 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0054] 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0071] "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.

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

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

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

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

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

[0077] 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).

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

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

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

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

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

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

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

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

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

[0087] 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, a distributed ledger such as a blockchain, or is otherwise obtainable, as in the case of communication system operation example 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0133] (Hardware Configuration Example) Any of the devices described in this embodiment (cloud wallet platform, information processing device, terminal, user terminal, UE, etc.) can be realized, for example, by causing a computer to execute a program. This computer may be a physical computer or a virtual machine on the cloud.

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

[0135] Fig. 7 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 7 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.

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

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

[0138] (Effects of the embodiment) As described above, the technology described in this 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.

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

[0140] <Additional Notes> (Additional Item 1) An information processing device comprising: a physical security environment that runs a wallet application; and a communication unit that transmits to a terminal a message including a trail for verifying the legitimacy of the wallet application and a signature for the trail. (Additional Item 2) The information processing device according to Additional Item 1, wherein the physical security environment generates a key for encrypting or decrypting data, and the communication unit transmits to the terminal information including a message including the key and a signature for the message that has been generated using a unique key of the physical security environment. (Additional Item 3) A terminal comprising: a receiving unit that receives, from an information processing device having a physical security environment that runs a wallet application, a message including a trail for verifying the legitimacy of the wallet application and a signature for the trail; 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. (Supplementary Item 4) The terminal according to Supplementary Item 3, wherein the receiving unit receives information from the information processing device, the information including a message including a key for encrypting or decrypting data and a signature for the message generated using a unique key of the physical security environment, and the verifying unit verifies the signature. (Supplementary Item 5) The terminal according to Supplementary Item 3 or 4, wherein the receiving unit receives and stores user data or an integrity verification trail of the user data from the information processing device, and receives the user data from the information processing device at a predetermined timing, and the verifying unit confirms whether the user data has been tampered with by comparing the integrity verification trail of the user data received at the predetermined timing with the stored integrity verification trail, or confirms whether the user data has been tampered with by comparing the user data received at the predetermined timing with the stored user data. (Supplementary Item 6) A communication system comprising the information processing device according to Supplementary Item 1 or 2, and the terminal according to any one of Supplementary Items 3 to 5.(Supplementary Item 7) A communication method executed by an information processing device having a physical security environment in which a wallet application operates, the communication method comprising: a communication step of transmitting a message including a trail for verifying the legitimacy of the wallet application and a signature for the trail to a terminal. (Supplementary Item 8) A non-transitory storage medium storing a program for causing a computer to function as each unit in a terminal described in any one of Supplementary Items 3 to 5.

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

[0142] 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 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 physical security environment in which a wallet application operates; and a communication unit that transmits to a terminal a message including a trail for verifying the legitimacy of the wallet application and a signature for the trail.

2. The information processing device described in claim 1, wherein the physical security environment generates a key for encrypting or decrypting data, and the communication unit transmits to the terminal information including a message containing the key and a signature for the message generated using a unique key of the physical security environment.

3. A terminal comprising: a receiving unit that receives a message including a trail for verifying the validity of a wallet application and a signature for the trail from an information processing device that has a physical security environment in which the wallet application operates; and a verifying unit that verifies the signature and verifies the validity of the wallet application by comparing the trail with a value obtained from an external database.

4. The terminal according to claim 3, wherein the receiving unit receives information from the information processing device, the information including a message containing a key for encrypting or decrypting data and a signature for the message generated using a unique key of the physical security environment, and the verifying unit verifies the signature.

5. The terminal according to claim 3, wherein the receiving unit receives and stores user data or an integrity verification trail of the user data from the information processing device, and receives the user data from the information processing device at a predetermined timing, and the verifying unit confirms whether the user data has been tampered with by comparing the integrity verification trail of the user data received at the predetermined timing with the integrity verification trail it stores, or confirms whether the user data has been tampered with by comparing the user data received at the predetermined timing with the user data it stores.

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

7. A communication method executed by an information processing device having a physical security environment in which a wallet application operates, the communication method comprising a communication step of sending a message to a terminal, the message including a trail for verifying the legitimacy of the wallet application and a signature for the trail.

8. A program for causing a computer to function as each unit of the terminal according to any one of claims 3 to 5.

Images