WO2025163752A1 - Information processing device, terminal, communication system, communication method, and program - Google Patents

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

The present invention relates to digital identity wallets.

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) (Non-Patent Documents 1 and 2).

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, qualifications, etc. for users 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 about providing services.

In addition, a digital identity wallet (DIW) function has been proposed that stores user (holder) ID data and uses it for identity verification or attribute certification (Non-Patent Document 3). DIWs can be implemented in two ways: local wallets that are deployed on the user's operating terminal (also called UE), and cloud wallets that are provided on a platform hosted by a cloud service provider or similar.

"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

Using a cloud-based DIW reduces the effort required for users to properly manage their own devices that host ID data and its processing functions (programs, etc.). It also reduces the risk of ID data being accessed externally due to factors such as loss of the user device or inadequate security settings.

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 user privacy may be violated by unauthorized access by the administrator, such as by viewing ID data.

The present invention was 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.

According to the disclosed technology, a physical security environment in which a wallet application operates;
An information processing device is provided, comprising: 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.

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.

FIG. 1 is a diagram for explaining an overview of an embodiment. 1 is a configuration diagram of a communication system according to an embodiment of the present invention. 3 is a diagram showing a specific example of data stored in a user data DB 230. FIG. 1 is a configuration diagram of a communication system according to an embodiment of the present invention. FIG. 2 is a diagram illustrating an example of the configuration of ID data. 1 is a configuration diagram of a communication system according to an embodiment of the present invention. FIG. 2 illustrates an example of a hardware configuration of the apparatus.

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

Furthermore, in the following explanation, unless otherwise clearly indicated from the context, "A/B" means "A or B." Furthermore, "A or B" includes A only, B only, and "A and B."

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

(Outline of the 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.

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

The user terminal 100 accesses the cloud wallet platform 200 to obtain, for example, ID data to be presented to SSI-based services. The user terminal 100 can also securely store, for example, ID data that it has created itself in the cloud wallet platform 200.

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

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

With the configuration shown in Figure 1, only users can access their own cloud wallets using any access authentication method. Furthermore, in addition to preventing fraud by general attackers, it is also possible to prevent fraud by cloud service providers/administrators.

In this specification, "user" refers not only to a person, but also to devices such as terminals used by the user, unless the context clearly indicates that it refers to a person. Also, "app" is an abbreviation for "application."

The targeted attacks (1) to (4) and an overview of the solutions to each attack are as follows:

(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."

(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."

(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."

(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.

(System configuration example)
Fig. 2 shows an example of the configuration 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 also be called a "terminal," and the cloud wallet platform 200 may also be called a "cloud wallet system" or an "information processing device."

As shown in Figure 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 Figure 2 does not show functions that are generally provided in devices/terminals, such as communication functions.

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."

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

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

The physical security environment 260 is generated (constructed) for each user. Note that "physical security environment for each user" also includes a form that provides an isolated virtual security environment for each user 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).

A communications system with the above-described configuration provides a wallet app 261 protected by a physical security environment 260 for each user, generates and certifies data encryption keys/decryption keys, ensures that only the user, UE, and the user's physical security environment 260 can decrypt user data, and realizes a mechanism for detecting and preventing data tampering.

This section explains the overview of the functions, the data contents of the database, and an example of the operation of the communication system involved in realizing the above mechanism.

<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.

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.

The UI 130 is a browser or client application used to access the cloud wallet platform 200/wallet application 261.

Key DB 140 stores keys for encrypting/decrypting data. For example, if the key is a common key, the common key can be used for encryption and decryption. Also, 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.

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

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 the following methods can be used, for example.

The user public key for access authentication is provided directly to the cloud wallet infrastructure 200, or the cloud wallet infrastructure 200 has a means of accessing a database or the like in which the user public key is stored. The authentication function 120 then 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 uses the public key to verify that the signature is correct.

Other access authentication methods may also be used, such as ID/password or biometric authentication such as FIDO.

<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, for example, Solution 4.

The authentication data DB220 stores authentication data such as the "identifier, public key, password, etc." used by the cloud wallet platform 200 for user wallet access.

User data DB230 stores encrypted user data. User data is, for example, DID/VC or "ID data such as private keys and public keys, and setting data, etc." linked to the DID.

Figure 3 shows a specific example of data stored in user data DB 230. As shown in Figure 3, user identifiers such as DIDs are stored in user data DB 230 in association with encrypted user data.

With regard to the data stored in the user data DB 230, among the user setting data required for building the TEE environment or application, data with low privacy requirements may be stored unencrypted.

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 in the physical security environment 260 are released. The encryption key is generated for each user within the physical security environment 260. These functions correspond to Solution 3.

In addition, to prepare for the risk of the user terminal 100 being lost, it is also possible to back up the encryption key received by the user terminal 100 from the user terminal 100 to cloud storage or the like under an administrator other than the administrator of the cloud wallet platform 200.

The access authentication function 250 performs the user authentication described above, as well as authentication of external systems 300 such as issuers/verifiers that are allowed to access the wallet application 260.

(Operation example 1 of communication system)
The first example of the operation of the communication system will be described in accordance with the step numbers (S1, etc.) shown in FIG.

In S1, the user terminal 100 accesses the access authentication function 250 in the cloud wallet platform 200. User authentication is performed by the access authentication function 250.

In S2, if the access authentication function 250 is successful in user authentication, it instructs the physical security environment management function 240 to construct a physical security environment 260 and wallet application 261 for the user. 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.

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 a user's wallet application 261. During generation, the physical security environment 260 obtains user data and wallet application data from the database (S4).

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

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

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

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

If the access in S6 is the user's first access to the wallet app 261, then in S7 the 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 the wallet app 261 from the user terminal 100, the 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.

The trigger and timing for generating/receiving a key for data encryption/decryption for each user are not limited to the above example. For example, the UI 130 of the wallet app 261 may be provided with a button for key generation and key registration, and when the user operates that button, the key may be generated and sent from the user.

When the physical security environment 260 sends 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 achieved, for example, by the following operations/processing.

When manufacturing the physical security environment 260, the manufacturer of the physical security environment 260 installs into the physical security environment 260 a unique key (specifically, the manufacturer's private key) and a certificate of the manufacturer that are difficult to tamper with later.

The generated (activated) physical security environment 260 signs the 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.

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

It is assumed that the public key corresponding to the above private key is either included in the received manufacturer certificate, or is published on the manufacturer's website or in a distributed ledger such as a blockchain, and is therefore available for acquisition. Technologies such as IETF Remote Attestation may be used to notify the above message.

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

Furthermore, the user terminal 100 may obtain the manufacturer's certificate separately from the notification of the "message containing the key and the signature." The use of 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.

Furthermore, in order to make it possible to detect if 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.

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 time, such as when the user logs out of the wallet, and transmits this trail to the user terminal 100 via the wallet application communication control unit 270. In other words, the user data integrity verification trail is shared between the physical security environment 260 and the user terminal 100.

The user terminal 100 (e.g., wallet verification function 110) acquires (calculates) a user data integrity verification trail for 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 compares the user data integrity verification trail with the user data integrity verification trail stored within the user terminal 100 to detect whether the "user data/encrypted user data" has been tampered with.

"The next time the wallet app 261 is accessed" may or may not be after the physical security environment 260 is restarted.

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 next wallet app 261 is accessed, the user terminal 100 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.

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 specific to the physical security environment and notified together with a certificate, just as with 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.

Note that one 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 verify user data integrity may be used as a user data integrity verification trail.

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

(Operation example 2 of communication system)
Next, a second operational example of the communication system will be described with reference to Fig. 4. The second operational example of the communication system is an operational example related to wallet integrity proof, and corresponds to solutions 1 and 2.

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).

In S1, when the user accesses the cloud wallet infrastructure 200 (S6 in Figure 3), or when the user requests this process from the cloud wallet infrastructure 200, the cloud wallet infrastructure 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 specific 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, signature, and manufacturer's certificate. This message may be notified using, for example, IETF Remote Attestation.

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

Note that the hash value of wallet application 261 is an example of a trail for verifying the authenticity of wallet application 261. As a trail other than the hash value of wallet application 261, the program code/executable file of wallet application 261 may also be used. Furthermore, other things may also be used as the trail. The trail is signed with the unique key of the physical security environment.

Verification data (correct answer information) such as the source code and hash values of the wallet application 261, which are used by the user terminal 100 to match the evidence obtained from the cloud wallet platform 200, is registered and made public in the wallet application data DB 210.

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

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

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

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

Furthermore, the user terminal 100 may obtain the manufacturer's certificate separately from the notification of the hash value (an example of a trail) and signature. The use of 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.

Furthermore, as in the case of communication system operation example 1, 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 available for acquisition.

(Detailed explanation)
The ID data, ID management function 262, physical security environment 260, etc. will be described in more detail below.

In this embodiment, for example, the 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 third parties, but also from the cloud operator/administrator.

As shown in Figure 3, the cloud wallet platform 200 has 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.

The user data DB 230 may be provided in an external device rather than within the cloud wallet platform 200. In this case, for example, access information for the external device may be held in the cloud wallet platform 200, and the ID data may be accessible using this access information.

The confidentiality and integrity of ID data is maintained, and the ID management function 262 operates in an environment where integrity is maintained.

Specifically, by storing and running the ID management function 262 in a hardware security module (HSM) or trusted execution environment (TEE), which are existing technologies, the confidentiality and integrity of the ID data and the ID management function 262 are protected, including while the data is being processed.

In general, HSMs offer 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 wanting to implement their own unique ID management functions.

For this reason, although this embodiment assumes the use of TEE, in principle it is possible to achieve a similar configuration with HSM. The physical security environment 260 provided in the cloud wallet platform 200 may use either TEE or HSM.

As mentioned above, the wallet application 261 is program code that defines the processing procedures of the ID management function 262. The cloud wallet infrastructure 200 according to this embodiment is equipped with a physical security environment 260, in which the wallet application 261 is executed. In addition, a mechanism is provided that allows an external actor, such as a user, to verify that a legitimate wallet application 261 is operating in a legitimate physical security environment 260 and that user data has not been tampered with.

(Detailed example of ID data)
Next, a detailed example of ID data will be described.

<Basics of ID data>
In the management of digital identities in this embodiment, for example, the following ID data (1) to (5) are handled. 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.

(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.

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

(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.

Key certification data includes, for example, 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 public key certificates, or a distributed ledger in the case of a DID document.

(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.

(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.

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

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

- Key data generation method, cryptographic attributes (algorithm, key size, other parameters), validity period, and expiration date: Users will securely manage key data based on this information.

- Key certification data registration location, validity period, usage history, and expiration regulations: Users use this data for ID authentication.

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

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

(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.

(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.

The ID management function 262 is used when a user generates a user identifier, and when a user stores an externally generated 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.

(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.

(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.

(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.

(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.

(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.

(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.

(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 used as the subject of attestation, and the integrity of this subject of attestation is proven to an external actor (e.g., a user). A specific example is as described with reference to FIG. 4.

(b) Generating a key for encrypting/decrypting data and verifying the generated key (corresponding to Solution 3)
A 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 proves to the external actor that the key was generated within the physical security environment 260.

Specifically, for example, a key pair (EK) and the manufacturer's certificate, which are installed in the physical security environment 260 by the manufacturer at the time of manufacture and are difficult to tamper with later, are used.

When sending any key generated within the physical security environment 260 to an external actor, the physical security environment 260 can prove to the external actor that the key was generated within the 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, etc., and is therefore available for acquisition.

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

(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 wallet application 261 cannot be made permanent, for example, when deleting physical security environment 260, the data in the environment is volatilized.

In such cases, 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 restarted/reconstructed, it restores this data from the storage, etc. where it was stored.

In addition, a mechanism is provided that allows users to detect that data restored in the manner described above has not been tampered with.

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, which then stores the digest.

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

(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.

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

The terminal 300 includes a receiving unit 310 and a verifying unit 320. The receiving unit 310 receives, for example, from the information processing device 400, 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. The verifying unit 320 verifies the signature and verifies the validity of the wallet application by, for example, comparing the trail with values obtained from an external database.

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

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

FIG. 7 is a diagram showing an example of the hardware configuration of the computer. The computer in FIG. 7 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, all of which are interconnected by a bus BS. The computer may also be equipped with a GPU.

The program that realizes processing on the computer is provided by a recording medium 1001, such as a CD-ROM or memory card. When the recording medium 1001 storing the program is inserted into the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001; it can also be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

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

(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 administrators and improves users' privacy and self-sovereignty.

The following additional notes are provided regarding the above embodiments.

<Additional Notes>
(Additional note 1)
A physical security environment in which the wallet application operates;
an information processing device comprising: 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 note 2)
the physical security environment generates a key for encrypting or decrypting data;
2. The information processing device according to claim 1, wherein the communication unit transmits to the terminal information including a message including the key and a signature for the message generated using a unique key of the physical security environment.
(Additional note 3)
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;
a verification unit that verifies the signature and verifies the authenticity of the wallet application by comparing the trail with a value obtained from an external database.
(Additional note 4)
The terminal described in Appendix 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.
(Additional note 5)
The receiving unit
receiving and storing user data or a consistency verification trail of the user data from the information processing device, and receiving the user data from the information processing device at a predetermined timing;
The verification unit
Checking 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 that is stored, or
The terminal according to claim 3 or 4, wherein the terminal checks whether the user data has been tampered with by comparing the user data received at the predetermined timing with the user data it holds.
(Additional note 6)
A communication system comprising the information processing device according to claim 1 or 2 and the terminal according to any one of claims 3 to 5.
(Supplementary Note 7)
A communication method executed by an information processing device having a physical security environment in which a wallet application operates, comprising:
A communication method comprising: a communication step of transmitting a message to a terminal, the message including a trail for verifying the legitimacy of the wallet application and a signature for the trail.
(Supplementary Note 8)
A non-transitory storage medium storing a program for causing a computer to function as each unit of the terminal described in any one of appendixes 3 to 5.

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

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

A physical security environment in which the wallet application operates;
an information processing device comprising: 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. the physical security environment generates a key for encrypting or decrypting data;
The information processing apparatus according to claim 1 , wherein the communication unit transmits to the terminal information including a message including the key and a signature for the message generated using a unique key of the physical security environment. 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;
a verification unit that verifies the signature and verifies the authenticity of the wallet application by comparing the trail with a value obtained from an external database. The terminal according to claim 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. The receiving unit
receiving and storing user data or a consistency verification trail of the user data from the information processing device, and receiving the user data from the information processing device at a predetermined timing;
The verification unit
Checking 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 that is stored, or
The terminal according to claim 3 , wherein the terminal checks whether the user data has been tampered with by comparing the user data received at the predetermined timing with the user data it holds. A communication system comprising the information processing device of claim 1 and the terminal of claim 3. A communication method executed by an information processing device having a physical security environment in which a wallet application operates, comprising:
a communication step of transmitting a message to a terminal, the message including a trail for verifying the legitimacy of the wallet application and a signature for the trail. A program for causing a computer to function as each component of a terminal described in any one of claims 3 to 5.