System and Method

Abstract

This system improves the DID / VC system. The system includes a device and an issuing device. The device holds associated device authentication credentials, authentication data, and a private key. The device also holds delegation certificate data indicating that an individual recognizes the device as their agent. The device performs an identity verification process for the individual and, upon success of the verification process, sends signed identity verification certificate data to the issuing device. The issuing device verifies the individual's identity based on the identity verification certificate data and issues credentials to the individual based on the identity verification result. Furthermore, the issuing device associates the credentials with the identity verification certificate data.

Description

Technical Field

[0001] The present invention relates to a system, a method, a device, a method for controlling a device, and a storage medium.

Background Art

[0002] There are technologies related to verifiable credentials (VCs).

[0003] For example, Patent Document 1 describes providing a technique for making it difficult to collate, eliminating restrictions on claim submission destinations, and suppressing the amount of information held in a user device. The user device of Patent Document 1 includes a holding means for holding secret information, a generating means for generating a source, an arithmetic means, and an acquisition means. The arithmetic means obtains a commitment corresponding to the source based on the source and the secret information. The acquisition means transmits an acquisition request including the source and the commitment corresponding to the source to a first external device, thereby obtaining a verifiable claim (VC) including the source and the commitment corresponding to the source. The value of the source used by the acquisition means to obtain a new VC is different from the value of the source used by the acquisition means to obtain a VC in the past.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] There are various problems in existing decentralized identity (DID) / VC systems. For example, one of the problems of existing DID / VC systems is that the identity verification (holder's identity) performed when a VC is issued is not cryptographically guaranteed.

[0006] The primary objective of this invention is to provide a system, method, device, device control method, and storage medium that contribute to improving DID / VC systems. [Means for solving the problem]

[0007] According to a first aspect of the present invention, the present invention includes a device that can utilize a tamper-resistant execution environment, and an issuing device of an issuer that issues credentials, wherein the device holds device authentication credentials including public key information associated with the device, authentication data based on an individual's biometric information, and a private key held in a manner that prevents external extraction by the tamper-resistant execution environment, logically associated and holding such credentials that a signature process using the private key can be executed on the condition that the authentication based on the biometric information is successful, and further holds delegation certificate data indicating that the individual recognizes the device as their agent, and the issuing device holds the delegation certificate data presented from the device and A system is provided which, based on the device authentication credentials, cryptographically verifies that the device is a legitimate authentication device associated with the individual, the device performs an identity authentication process for the individual, and transmits a signed identity authentication certificate data to the issuing device upon the success of the identity authentication process, the issuing device verifies the identity of the individual based on the identity authentication certificate data, issues the credentials to the individual based on the identity verification result, and associates the credentials with the identity authentication certificate data so that a third party can verify that the credentials were issued based on the identity authentication certificate data.

[0008] According to a second aspect of the present invention, in a system comprising a device capable of using a tamper-resistant execution environment and an issuing device of an issuer that issues credentials, the device holds device authentication credentials including public key information associated with the device, authentication data based on an individual's biometric information, and a private key held in a manner that prevents external extraction by the tamper-resistant execution environment, logically associated and holding such credentials that a signature process using the private key can be executed on the condition that the authentication based on the biometric information is successful, and further holds delegation certificate data indicating that the individual recognizes the device as their agent, and the issuing device receives the delegation certificate presented from the device. A method is provided which, based on explicit data and the device authentication credentials, cryptographically verifies that the device is a legitimate authentication device associated with the individual; the device performs an identity authentication process for the individual; and, upon successful completion of the identity authentication process, transmits signed identity authentication certificate data to the issuing device; the issuing device verifies the identity of the individual based on the identity authentication certificate data, issues the credentials to the individual based on the identity verification result, and associates the credentials with the identity authentication certificate data, thereby enabling a third party to verify that the credentials were issued based on the identity authentication certificate data.

[0009] A third aspect of the present invention provides a device comprising: a storage means for storing device authentication credentials including the public key information of the device; delegation certificate data indicating that the user recognizes the device as their agent; and the user's biometric information; a generation means for, when requested by the issuer of the credentials to perform biometric authentication, to authenticate the person operating the device using the stored user's biometric information, and if authentication is successful, to generate personal authentication certificate data proving that the biometric authentication was successful; and a transmission means for transmitting the stored device authentication credentials, the stored delegation certificate data, and the generated personal authentication certificate data to the issuer of the credentials.

[0010] A fourth aspect of the present invention provides a device control method in which a device stores device authentication credentials including the public key information of the device, delegation certificate data indicating that the user recognizes the device as their agent, and the user's biometric information. When requested by the credential issuer to perform biometric authentication, the device authenticates the person operating the device using the stored user's biometric information. If authentication is successful, it generates personal authentication certificate data proving that the biometric authentication was successful, and transmits the stored device authentication credentials, the stored delegation certificate data, and the generated personal authentication certificate data to the credential issuer.

[0011] A fifth aspect of the present invention is provided, a computer-readable storage medium is provided which stores a program for causing a computer mounted on a device to execute: a process for storing device authentication credentials including the public key information of the device, delegation certificate data indicating that the user recognizes the device as their agent, and the user's biometric information; a process for, when requested by the issuer of the credentials to perform biometric authentication, to authenticate the person operating the device using the stored user's biometric information, and if authentication is successful, to generate personal authentication certificate data proving that the biometric authentication was successful; and a process for transmitting the stored device authentication credentials, the stored delegation certificate data, and the generated personal authentication certificate data to the issuer of the credentials. [Effects of the Invention]

[0012] According to each aspect of the present invention, a system, method, device, device control method, and storage medium are provided that contribute to improving a DID / VC system. However, the effects of the present invention are not limited to those described above. The present invention may produce other effects in place of, or in conjunction with, the aforementioned effects. [Brief explanation of the drawing]

[0013] [Figure 1]FIG. 1 is a diagram for explaining an overview of an embodiment. [Figure 2] FIG. 2 is a flowchart showing the operation of an embodiment. [Figure 3] FIG. 3 is a diagram showing an example of a schematic configuration of an information processing system according to an embodiment of the present disclosure. [Figure 4] FIG. 4 is a diagram showing an example of an internal configuration of a wallet device according to an embodiment of the present disclosure. [Figure 5] FIG. 5 is a sequence diagram showing an example of the operation of an information processing system according to an embodiment of the present disclosure. [Figure 6] FIG. 6 is a flowchart showing an example of the operation of a wallet device according to an embodiment of the present disclosure. [Figure 7] FIG. 7 is a sequence diagram showing an example of the operation of an information processing system according to an embodiment of the present disclosure. [Figure 8] FIG. 8 is a flowchart showing an example of the operation of an information processing system according to an embodiment of the present disclosure. [Figure 9] FIG. 9 is a sequence diagram showing an example of the operation of an information processing system according to an embodiment of the present disclosure. [Figure 10] FIG. 10 is a diagram showing an example of a schematic configuration of an information processing system according to an embodiment of the present disclosure. [Figure 11] FIG. 11 is a diagram for explaining the effects of the present disclosure. [Figure 12] FIG. 12 is a diagram for explaining the effects of the present disclosure. [Figure 13] FIG. 13 is a diagram for explaining the effects of the present disclosure. [Figure 14] FIG. 14 is a diagram showing an example of the hardware configuration of a wallet device according to the present disclosure.

MODE FOR CARRYING OUT THE INVENTION

[0014] First, an overview of one embodiment will be described. The reference numerals in the drawings attached to this overview are provided for convenience as examples to aid understanding, and this overview is not intended to be limiting in any way. Furthermore, unless otherwise specified, the blocks shown in each drawing represent functional units, not hardware units. The connecting lines between blocks in each drawing include both bidirectional and unidirectional lines. Unidirectional arrows schematically indicate the flow of the main signal (data) and do not exclude bidirectional flow. In this specification and in the drawings, elements that can be similarly described are given the same reference numerals to avoid redundant explanation.

[0015] One embodiment of the system includes a device 101 that can utilize a tamper-resistant execution environment, and an issuing device 102 of an issuer that issues credentials (see Figure 1). Device 101 holds device authentication credentials, which include public key information associated with device 101, authentication data based on an individual's biometric information, a private key that is held in a way that prevents external extraction by a tamper-resistant execution environment, and is logically associated with these credentials so that a signature process using the private key can be executed on the condition that authentication based on biometric information is successful (holds device authentication credentials, etc.; step S1). Device 101 further holds delegation certificate data indicating that the individual recognizes device 101 as their agent (step S2). The issuing device 102 cryptographically verifies that device 101 is a legitimate authentication device linked to an individual based on the delegation certificate data and device authentication credentials presented by device 101 (verifies device authentication credentials, etc.; step S3). Device 101 performs an identity verification process for the individual and, upon successful verification, transmits signed identity verification data to the issuing device 102 (step S4). The issuing device 102 verifies the individual's identity based on the identity verification data and issues credentials to the individual based on the identity verification result (step S5). Furthermore, the issuing device 102 associates the credentials with the identity verification data (step S6).

[0016] By associating credentials with personal authentication proof data, a third party can verify that the credentials were issued based on the personal authentication proof data. That is, the identity verification (the identity of the holder) performed when the credentials were issued is cryptographically guaranteed, and the problems of the DID / VC system are improved.

[0017] The present disclosure provides a VC (Verifiable Credentials) issuance and presentation framework that cryptographically and fully integrates identity guarantee.

[0018] In recent years, a personal information management method using decentralized identifiers (DIDs) and verifiable credentials has been increasingly popular. In a DID / VC system, credentials such as qualification information and attribute information are signed by an issuer, and a verifier can verify the signature. As a result, the tamper resistance and authenticity of the information are ensured.

[0019] However, in the DID / VC standard, there is no defined means to guarantee that "the presenter of the credentials is the same person as the holder of the credentials." That is, although the authenticity of the VC can be ensured by the issuer signing the VC, the DID / VC standard lacks a mechanism for the issuer and the verifier to reliably confirm the identity of the presenter.

[0020] For example, even if a medical license VC is presented to a Verifier, there is no guarantee that the presenter is the actual medical professional. Existing protocols such as DIDAuth, OpenID for Verifiable Credentials (OIDC4VC), SD-JWT, and BBS+ all merely prove that the Holder possesses the private key when presenting the VC. Current DIDAuth does not guarantee that "the private key has not been leaked to anyone other than the owner," "the private key is stored on an appropriate device," or "the KYC (Know Your Customer) results from the time of issuance are inherited in a cryptographically verifiable form."

[0021] Furthermore, the current VC ecosystem has the following structural limitations:

[0022] <Unable to perform encrypted KYC verification at the time of issuance> Verifier cannot verify from the issued VC what identity verification methods (KYC) the Issuer used to issue the VC. Therefore, Verifier has no choice but to blindly trust the Issuer's policy. Consequently, there is a problem in that Verifier cannot cryptographically reproduce the level of identity verification (LoA: Level of Assurance) at the time of VC issuance.

[0023] <The authenticity of the wallet is not guaranteed (impersonation is possible)> In existing DID / VC systems, the wallet merely serves as a storage device for private keys and VCs. In other words, the DID / VC standard does not provide fundamental guarantees such as "the wallet is the owner's device," "the device can only be operated by the owner through biometric authentication, etc.," or "the device itself has not been tampered with." As a result, if a third party copies the private key, the VC can be completely misused.

[0024] <Device security is not guaranteed> If a device on which a wallet operates has vulnerabilities, an attacker could potentially steal biometric information or extract private keys from the device. However, the concept of "Device Credentials (VC)" to guarantee the security of the device itself is not standardized, and there is no means for Issuers and Verifiers to identify devices that should be trusted. Furthermore, there is no generalized mechanism for quickly revoking a device if a vulnerability is discovered in it.

[0025] <Biometric authentication is confined to the local device, making external guarantees impossible.> When biometric authentication is performed locally (for example, within the device), there are no criteria for Issuers or Verifiers to determine whether the biometric authentication algorithm is secure, whether the biometric template is unextractable, or whether the biometric authentication result is tamper-proof. Since existing VC standards do not specify a mechanism for performing biometric authentication on the cloud side, security is highly dependent on the device's performance and vulnerabilities.

[0026] <There is no mechanism to securely transfer user identity when changing devices.> In existing systems (existing DID / VC systems), the migration of VCs and private keys is extremely vulnerable in the event of "device loss" or "switching to a new device," and there is no secure protocol for cryptographically transferring identity between devices. The "key rotation" and "inter-device synchronization" in current DID / VC systems are not linked to identity verification, making it possible for an attacker to hijack identity if they possess the old device.

[0027] As explained above, existing DID / VC technologies have the following limitations.

[0028] <Problem 1: The identity of the person issuing the VC cannot be cryptographically guaranteed.> There is no way for the Issuer to substantiate the fact that they performed KYC (Know Your Customer) procedures to the VC (Virtual Certificate), and the Verifier has no way to confirm whether the presenter was the person in question at the time of VC issuance. In other words, a mechanism is needed to cryptographically link proof of KYC at the time of issuance to the VC.

[0029] <Problem 2: There is no guarantee that the person presenting the VC proposal is the actual investor in the VC.> Since anyone holding the private key can present their device certificate (VC), there is no way to prevent impersonation by a third party. In other words, it is necessary to guarantee that the wallet is on the user's device using device VC, and to prevent use by anyone other than the user through biometric authentication.

[0030] <Problem 3: Device security cannot be verified, making it impossible to address vulnerabilities.> Existing VC (DID / VC systems) lack a means to verify the authenticity of devices. Furthermore, existing DID / VC systems lack a mechanism to revoke devices when vulnerabilities are discovered. In other words, it is necessary to integrate a tamper-resistant execution environment, a manufacturer-signed device VC, and a revoke mechanism.

[0031] <Problem 4: The security of biometric authentication is device-dependent, and cloud-based verification is not possible.> Local biometric authentication is implementation-dependent, and there is no guarantee that the Verifier or Issuer will trust the authentication results. In other words, an abstract framework is needed that can securely handle biometric authentication both locally and in the cloud.

[0032] <Problem 5: There is no secure method to inherit user identity when changing devices.> Existing DID / VC standards do not assume the transfer of identity verification between devices, which means identity theft can occur during device updates. In other words, a protocol is needed to securely transfer KYC information to a new device using the biometric authentication of the old device.

[0033] In light of the above issues, one of the objectives of this disclosure is to comprehensively resolve each of these issues. Specifically, this disclosure realizes an unprecedentedly robust trust framework that integrates "device reliability (Device VC)", "identity authentication (biometric or cloud verification)", "cryptographic guarantee of KYC at issuance", "cryptographic guarantee of identity at presentation", "device revoke mechanism", and "KYC transfer between devices".

[0034] <Solution> This disclosure provides a novel framework that cryptographically integrates device reliability, biometric authentication, KYC at issuance, identity verification at presentation, and device migration, in order to solve fundamental problems in existing DID / VC technologies such as "invisibility of KYC at issuance," "lack of assurance of identity at presentation," "lack of device reliability," "lack of standardization regarding biometric authentication," and "risk of identity transfer when changing devices."

[0035] The main means disclosed in this application are shown below.

[0036] <Implementation of device authentication credentials (device VC) to guarantee device reliability> In this disclosure, a manufacturer, public authority, certification authority, or an authority delegated by any of these issues a device VC for a device holding a private key and biometric authentication data, which includes a device-specific public key, functional verification results, and security attributes. The device VC is a device authentication credential that includes public key information associated with the device.

[0037] A device vulnerability (VC) provides information about the device's tamper resistance, giving issuers and verifiers a basis for trusting the device. Furthermore, this disclosure features a revoke mechanism that can be revoked by the manufacturer, certification body, issuer, or the device itself if a vulnerability in the device VC is discovered. This ensures a continuous guarantee of authenticity based on the device.

[0038] <Device and individual linking via Delegation Proof / Delegation VC data> In this disclosure, an individual (Holder) stores a device that has signed it using a private key corresponding to their identifier, and authorizes the device as a "Wallet." The Certificate of Authorization data is data indicating that the individual recognizes the device as their authorized agent. The Certificate of Authorization data can be in either a signature format signed by the individual or a power of attorney (VC) format verified and re-signed by a third-party organization. The Certificate of Authorization data cryptographically indicates the link between the device and the individual.

[0039] <Device-based identity verification and one-time proof as cryptographic evidence> In this disclosure, user authentication is performed based on biometric information. However, the entity and location of user authentication are not limited to a specific configuration. That is, user authentication may be performed in a tamper-proof execution environment provided on the device. Alternatively, user authentication may be performed in an external authentication service that can communicate with the device.

[0040] Biometric information, biometric features, templates, or data derived therefrom shall be protected under the control of the entity performing the authentication process and shall be held or used in a form that cannot be extracted outside of the entity performing the authentication process.

[0041] Upon successful authentication, the entity performing the authentication is: • The nonce presented by the Issuer or Verifier, • Verifier or Issuer identifier, • Expiration date, time information, It generates and signs identity verification data (One-time Proof) that includes [the necessary information].

[0042] The signature can be generated either by a tamper-resistant execution environment within the device or by an external authentication service. This ensures that the success of biometric authentication is securely verified against relay and replay attacks.

[0043] Issuer performs the following verifications when issuing VCs. • Device authenticity is verified using device VC. • Verification of the connection between the individual and the device using delegated certification data. • The device's generated authentication data confirms that the device is under the user's control.

[0044] Based on the verification results, the Issuer issues a VC with KYC (Know Your Customer) cryptographically established at the time of issuance, and associates the VC with the identity verification data. This allows the Verifier to cryptographically know that "the identity of the person at the time of issuance was verified" when they receive the VC.

[0045] The Verifier verifies the VC presented by the device and receives newly generated identity verification data from the device. The Verifier verifies the signature, which reflects the nonce, identifier, and expiration information contained in the identity verification data (One-time Proof). Through this process, the Verifier can reliably confirm that the presenter of the VC is the actual holder of the VC and is currently operating the device.

[0046] The system disclosed herein allows biometric authentication processing to operate in any of the following configurations: "in-device," "external cloud," or "a hybrid of both." In the cloud configuration, the device sends only encrypted data derived from biometric information to the cloud, and the cloud returns only the matching result to the device. As a result, leakage of biometric templates is prevented.

[0047] <Secure transfer of identity when changing devices (KYC transfer token)> When a device is changed, after the old device successfully authenticates the user, it generates and signs a KYC transfer token containing the identifier of the new device. The new device can securely inherit the KYC information from the time of issuance by presenting the "KYC transfer token" and its own device VC to the Issuer. This operation eliminates the risk of impersonation associated with device replacement.

[0048] This disclosure, through the means described above, realizes an unprecedentedly advanced identity assurance platform that cryptographically integrates "KYC at issuance," "identity verification at presentation," "device reliability," "security of biometric authentication," "device vulnerability countermeasures," and "transition between devices."

[0049] In this disclosure, "retention" does not mean that information is located in a specific physical storage area, but rather includes a state in which a usage relationship or reference relationship with a private key protected by a modification-resistant execution environment is maintained.

[0050] Furthermore, in this disclosure, the term "device" (wallet device) refers to the implementing entity involved in the execution of identity verification and the generation of identity verification data. It also does not mean that the implementing entity is limited to the physical information processing device itself.

[0051] Specifically, the device in this disclosure is interpreted as a concept that includes at least one of the following:

[0052] A functional unit that holds a private key and uses that key to generate a signature for user authentication data. • An execution environment with tamper-resistant features such as Secure Enclave, TEE (Trusted Execution Environment), and hardware-backed keystore. A wallet application or equivalent software execution entity that operates on existing information processing devices such as smartphones and uses a modification-resistant execution environment to protect private keys and generate signatures.

[0053] In other words, the device in the present disclosure is defined as a logical unit for functionally combining the authentication result and the cryptographic signature, and for presenting the combined result in a verifiable form for a third party, and is not limited to physical hardware provided by the terminal manufacturer.

[0054] In this disclosure, a device VC (device authentication credentials) refers to verifiable credentials that cryptographically prove that a device meets certain security requirements or trust requirements for user authentication purposes. Depending on the issuer and the basis of trust, such device VCs may be issued based on at least one of the following, or a combination thereof:

[0055] • Based on the authenticity or tamper-proof nature of the physical device, as provided by the device manufacturer, SoC (System on a Chip) vendor, or OS provider. This document certifies that the device meets the security requirements necessary for user authentication, based on verification results of attestation, terminal status information, and security attributes provided by the OS or OEM (Original Equipment Manufacturing). The certification provider evaluates and guarantees that the specified authentication method operates at the specified level of assurance (LoA) on the device or execution environment, and that the authentication results are reliable for identity assurance purposes.

[0056] A device VC includes, at least partially, the device's public key information, security attributes, attributes related to the authentication method, assurance level, or evaluation results related thereto. Furthermore, the device VC is used by the Issuer or Verifier to determine whether the device should be trusted for authentication purposes. In addition, the device VC may be configured to be revoked by the manufacturer, certification authority, Issuer, or the device itself in response to the discovery of vulnerabilities, configuration changes, detection of tampering, or revocation of authorization by the user.

[0057] Therefore, in this disclosure, "device authentication credentials (device VC)" refers to verifiable credentials that prove that a device meets specified security or trust requirements for user authentication purposes. Furthermore, the issuer of a device VC is not limited to the terminal manufacturer, but includes OS providers, certification authorities, third-party certification bodies, or organizations delegated by them. In addition, a device VC is not limited to the form of verifiable credentials, but includes electronic signatures, certificates, attestations, evaluation certificates, or equivalent cryptographic verification means. In this disclosure, "Issuer" refers to the entity that issues a VC that proves identity, but the verification of the user authentication result, the reliability evaluation of the device, or the verification process related to the transfer of identity between devices is not limited to the Issuer itself, but may be performed by a third-party organization with the legitimacy to perform such verification.

[0058] In this disclosure, "One-time Proof data" broadly encompasses data that can be generated solely on the condition of successful identity verification, regardless of its name or format, and whose success can be cryptographically verified by a third party. It should be noted that in this disclosure, One-time Proof data is data used to prove successful identity verification in the issuance or presentation of a VC, while KYC transfer tokens differ in purpose and scope of use, as they are generated to transfer existing identity to a new device.

[0059] In the disclosure of this application, the identity verification process that ensures the identity of the person is required to be a method that verifies in real time, with the present existence of the person, against biometric data that has been kept confidential from third parties and the biometric information of the person obtained at the time of presentation.

[0060] The biometric data is not stored in a form that allows a wallet, external service, or third party to arbitrarily acquire, reuse, or reconstruct it, and the success or failure of the matching directly determines whether or not identity verification data can be generated.

[0061] Authentication methods based on possessions cannot eliminate the structural risk that a third party could impersonate the person if those possessions are lost or stolen. Similarly, authentication methods based on memory can be compromised if the stored information is leaked or shared, allowing someone other than the person to authenticate. Therefore, methods that use possession authentication or memory authentication as the primary means of guaranteeing identity cannot achieve the effect that the present disclosure aims to achieve—that "cryptographic evidence cannot exist unless it is from the person themselves"—and thus contradict the technical concept of the present disclosure.

[0062] Each of the processes disclosed herein can be implemented by a person skilled in the art using existing cryptographic libraries, hardware security modules, cloud authentication infrastructure, or a combination thereof, and is not limited to any particular cryptographic scheme or implementation.

[0063] Specific embodiments will be described in more detail below with reference to the drawings.

[0064] [System Configuration] As shown in Figure 3, the information processing system (identity authentication framework) according to the first embodiment includes a wallet device 10, an issuing server 20 for the issuer that issues credentials, a verification server 30 for the verifier (service provider), a device VC issuing authority 40, a revocation database 50, and the like.

[0065] Figure 3 shows the interrelationships between the user (VC holder), wallet device 10, Issuer (issuance server 20), Verifier (verification server 30), device VC issuing authority 40, and revocation database 50.

[0066] The user will use wallet device 10.

[0067] Figure 4 shows the internal configuration (internal structure) of the wallet device 10. As shown in Figure 4, the wallet device 10 comprises a Secure Enclave or TEE201, a biometric authentication module 202, a device VC storage area 203, a delegated certificate data storage area 204, and a communication module 205.

[0068] Secure Enclave or TEE201 performs tasks such as generating private keys, generating signatures, and generating identity verification data (One-time Proof).

[0069] The biometric authentication module 202 comprises a biometric authentication sensor 211 and a biometric template storage area 212. The biometric authentication sensor 211 acquires the user's biometric information (e.g., facial image). The biometric template storage area 212 is an area for storing the original data used when performing biometric authentication, and is protected against reading and modification.

[0070] Device VC storage area 203 is the area where device VCs are stored.

[0071] The delegation certificate data storage area 204 is the area where delegation certificate data is stored.

[0072] The communication module 205 is used for secure communication with the issuer's device (issuance server 20) that issues VCs and the verifier's device (verification server 30) that verifies VCs.

[0073] Note that Figure 4 shows the functional configuration of the wallet device 10 and does not limit the physical arrangement or storage area of ​​each component.

[0074] The issuer is the entity that issues VCs. As shown in Figure 3, the issuer's issuance server 20 includes a KYC management module 301 and a VC issuance module 302. The KYC management module 301 manages KYC by the wallet device 10. The VC issuance module 302 issues VCs.

[0075] The verifier is the entity that verifies the VC. The verifier's verification server 30 is equipped with a VC verification module 401. The VC verification module 401 verifies the VC presented by the owner.

[0076] The device VC issuing authority 40 is the entity that certifies the trustworthiness of the device (wallet device 10). Examples of the device VC issuing authority 40 include the manufacturer of wallet device 10, a public institution, a certification body, or an institution delegated by any of these. The device VC issuing authority 40 issues device VCs.

[0077] For example, the manufacturer of wallet device 10 registers the device VC with wallet device 10 in advance as a device VC issuing authority 40. For example, the manufacturer generates a private key and a public key for the device, and generates a device VC that proves the public key, etc. For example, the manufacturer signs the device VC with the manufacturer's (device VC issuing authority 40) private key and stores it in the device VC storage area 203 of wallet device 10.

[0078] As mentioned above, a device VC is a credential that guarantees (proves) the security of the device itself. A device VC proves the device ID, device-specific public key, functional verification results, security attributes, etc. A device VC provides information about the device's tamper resistance and gives the issuer or verifier a basis for trusting the device.

[0079] The device ID is an ID associated with the wallet, and an example is a terminal ID that uniquely identifies the hardware of wallet device 10. However, the device ID is not limited to an ID that uniquely identifies the hardware.

[0080] The revocation database 50 manages the deactivation information of VCs, including device VCs. The revocation data is implemented in the DID / VC infrastructure.

[0081] [System operation] Next, the operation of the system according to the first embodiment will be described.

[0082] <Preparation> The user registers a biometric template to be used for identity verification with the wallet device 10. Specifically, the biometric sensor 211 of the biometric authentication module 202 acquires a facial image from an identification document such as a passport or driver's license. The biometric sensor 211 also acquires a selfie facial image of the user. The biometric authentication module 202 performs identity verification using the two facial images. If the identity verification is successful, the biometric authentication module 202 saves, for example, the selfie facial image as a biometric template in the biometric template storage area 212.

[0083] The wallet device 10 generates delegation certificate data in response to user actions. The generation of delegation certificate data establishes a connection between the device and the user.

[0084] The Secure Enclave or TEE201 of the wallet device 10 generates the user's (holder's) private key, public key, and holder DID (Decentralized Identity). The wallet device 10 generates delegation certificate data, for example, when the wallet is first launched. The wallet device 10 generates delegation certificate data including the device ID and holder DID, and signs the delegation certificate data with the private key corresponding to the holder DID or the private key of a third party. The signed delegation certificate data is stored in the delegation certificate data storage area 204.

[0085] In this way, the user (the user who will become the holder of the VC) shows that the device is his / her "agent entity" by holding the delegation proof data signed with the private key corresponding to his / her DID in the wallet. The delegation proof data is verified by the issuer and the verifier, and the association between the device and the individual (the VC holder) is cryptographically guaranteed.

[0086] In the present disclosure, the association between the device and the individual is guaranteed by the delegation proof data (Delegation Proof / Delegation VC). In the present disclosure, the device holds the delegation proof data signed by the individual (holder) using the private key corresponding to his / her identifier, and approves the device as the "agent entity (wallet)".

[0087] Note that the delegation proof data may be in either the "signature format signed by the individual" or the "delegation VC format verified and re-signed by a third-party institution". The delegation proof data is data that cryptographically indicates the connection between the device and the individual. For example, the wallet device 10 sends the delegation data (delegation proof data) signed by the user to the server of a public certification institution or a third-party certification institution. The server of the third-party institution verifies the delegation data signed by the individual, and if the verification is successful, issues a delegation credential to the user to prove the content described in the delegation data. That is, the delegation proof data may be a delegation credential issued after being verified by the device manufacturer, a public certification institution or a third-party certification institution based on the delegation data signed by the individual.

[0088] <VC Issuance> FIG. 5 is a sequence diagram showing a series of processes when the VC is issued. FIG. 5 is a sequence diagram showing the authenticity guarantee protocol at the time of VC issuance according to an embodiment of the present disclosure, and shows biometric authentication by the wallet, generation of the identity authentication proof data, device VC verification, and VC issuance processing by the Issuer. Referring to FIG. 5, the authenticity guarantee protocol at the time of VC issuance in the present disclosure will be described.

[0089] The wallet device 10 accesses the issuing server 20 and requests the transmission (provision) of the nonce and issuer ID. In response to this request, the issuing server 20 sends the nonce and issuer DID to the wallet device 10.

[0090] Upon receiving a nonce or similar information, the wallet device 10 performs identity verification using biometric information (performs biometric authentication; step S01).

[0091] Specifically, the wallet device 10 performs biometric authentication according to the flowchart shown in Figure 6. Figure 6 is a flowchart of the biometric authentication process within the wallet according to the embodiment of the present disclosure, showing biometric information acquisition, template matching, generation of identity verification data, and defensive actions in the event of authentication failure (backoff, lock, self-revocation request, etc.).

[0092] The wallet device 10 obtains the user's biometric information (step S101).

[0093] The wallet device 10 compares the acquired biometric information with the biometric template stored in the biometric template storage area 212 (template matching; step S102). For example, the wallet device 10 calculates the similarity between features and determines authentication success or failure based on the result of thresholding the calculated similarity.

[0094] If authentication is successful (step S103, Yes branch), the wallet device 10 generates identity verification data (step S104).

[0095] If authentication fails (step S103, No branch), the wallet device 10 performs at least one of the following processes (perform security function processing; step S105). (1) Limitation process. The wallet device 10 repeats the authentication process a predetermined number of times, and if it is unsuccessful, it stops the process. (2) Exponential increase in authentication waiting time. The wallet device 10 exponentially increases the waiting time each time the authentication process fails. (3) Locking process. The wallet device 10 prohibits the user from operating its own device. (4) Processing of device VC revocation request. The wallet device 10 sends a self-revocation request to the DID / VC infrastructure requesting the revocation of the device VC. In response to this request, the DID / VC infrastructure registers the device VC's credential ID, etc., in the revocation database 50.

[0096] Thus, if the wallet device 10 experiences a predetermined number of failures in the authentication process, it may perform at least one of the following actions: exponentially increase the authentication waiting time, lock the device, and issue a self-revocation request that revoke the device authentication credentials.

[0097] Furthermore, the above-mentioned security function processing prevents brute-force attacks and sensor attacks. In addition, the biometric authentication processing disclosed in this application does not necessarily limit the storage location of the biometric template or the execution environment of the matching process, and includes configurations in which biometric matching is performed in the application execution environment.

[0098] As described above, upon successful identity verification, the wallet device 10 generates identity verification data via Secure Enclave or TEE103 (step S02 in Figure 5).

[0099] The wallet device 10 generates identity verification data that includes the nonce, issuer DID, device ID, expiration date, time information, and proof of successful biometric authentication received from the issuing server 20. The wallet device 10 signs the identity verification data with the device's private key.

[0100] The wallet device 10 sends the holder DID, delegation certificate data, identity verification certificate data, and device VC (or a reference thereof) to the issuing server 20.

[0101] Upon receiving the delegation certificate data, etc., the issuing server 20 performs device reliability verification (device VC verification process; step S03). The issuing server 20 performs device reliability verification using the KYC management module 301. The issuing server 20 sends the device VC to the DID / VC infrastructure. By sending the device VC to the DID / VC infrastructure, the issuing server 20 requests verification of the device VC.

[0102] The DID / VC infrastructure verifies the signature attached to the device VC, verifies that the device VC has not been invalidated, and verifies that the device VC has not expired. The DID / VC infrastructure sends the verification result of the device VC (verification successful, verification failed) to the issuing server 20.

[0103] Once successful verification is notified (i.e., the device is confirmed to be legitimate), the issuing server 20 verifies the received delegation certificate data.

[0104] Specifically, the issuing server 20 verifies the signature attached to the delegation certificate data. For example, the issuing server 20 obtains the public key published as public metadata using the holder DID as the key. The issuing server 20 then verifies the signature using the public key corresponding to the obtained holder DID.

[0105] Furthermore, the issuing server 20 verifies the device ID. The issuing server 20 determines whether the device ID listed in the delegation certificate data matches the device ID listed in the device VC. If the device IDs match, the device ID verification is deemed successful. If the device IDs do not match, the device ID verification is deemed to have failed.

[0106] Furthermore, the issuing server 20 verifies the holder DID. The issuing server 20 determines whether the holder DID described in the delegation certificate data matches the holder DID received from the wallet device 10. If the holder DIDs match, it is determined that the holder DID verification was successful. If the holder DIDs do not match, it is determined that the holder DID verification failed.

[0107] If each verification of the delegation certificate data is successful, the issuing server 20 verifies the received identity authentication certificate data.

[0108] Specifically, the issuing server 20 verifies the nonce. The issuing server 20 determines whether the nonce sent to the wallet device 10 matches the nonce included in the identity verification data. If the nonces match, it is determined that the nonce verification was successful. If the nonces do not match, it is determined that the nonce verification failed.

[0109] Furthermore, the issuing server 20 verifies the device signature. The issuing server 20 obtains the public key of the device VC issuing authority 40 and uses the obtained public key to verify the signature attached to the device VC.

[0110] Furthermore, the issuing server 20 verifies the matching of the device VC (device ID). The issuing server 20 determines whether the device ID listed in the identity verification data matches the device ID listed in the device VC. If the device IDs match, it is determined that the device ID verification was successful. If the device IDs do not match, it is determined that the device ID verification failed.

[0111] Furthermore, the issuing server 20 performs a verification of the biometric authentication success trail (confirmation that identity verification was successful).

[0112] If each verification regarding the user authentication data is successful, the issuing server 20 issues a VC to the user (step S04). The issuing server 20 determines that the user's identity has been guaranteed and issues the VC. The VC issuing module 302 of the issuing server 20 issues the VC.

[0113] At that time, the issuing server 20 associates the VC with the personal authentication proof data. By associating the VC with the personal authentication proof data, the issuing server 20 enables a third party to verify that the credential has been issued based on the personal authentication proof data. The personal authentication proof data (One-Time Proof) is associated with the VC in any of the following methods.

[0114] · Embedding into the VC. · URI (Uniform Resource Identifier) reference as part of the VC metadata. · Linking as an external proof file.

[0115] That is, the association between the credential and the personal authentication proof data includes at least one of direct embedding of the personal authentication proof data into the credential, assignment of an external reference URI (Uniform Resource Identifier) to the personal authentication proof data to the credential, and attachment of the personal authentication data as metadata of the credential.

[0116] <VC Presentation> Figure 7 is a sequence diagram showing a series of processes when the VC is presented. Figure 7 is a sequence diagram showing the authenticity assurance protocol at the time of VC presentation according to the embodiment of the present disclosure, showing biometric authentication at the time of presentation by the wallet, generation of personal authentication proof data, expiration check, and final personal confirmation process by the Verifier. Referring to Figure 7, the authenticity assurance protocol at the time of VC presentation of the present disclosure will be described.

[0117] The wallet device 10 accesses the verification server 30. In response to the access, the verification server 30 transmits a nonce and a verifier ID to the wallet device 10.

[0118] Upon receiving the nonce or the like, the wallet device 10 performs personal confirmation using biometric information (performs biometric authentication; step S11).

[0119] The wallet device 10 performs identity verification in the same way as when issuing the VC. If identity verification is successful, the wallet device 10 generates new identity verification data (step S12). The wallet device 10 generates identity verification data that includes a verifier DID instead of the issuer DID. The wallet device 10 signs the generated identity verification data using the private key corresponding to the holder DID.

[0120] The wallet device 10 sends the VC, holder DID, delegation certificate data, newly generated identity verification certificate data, and device VC to the verification server 30 to present to the verifier.

[0121] Upon receiving the VC, the verification server 30 performs verification processing for the received device VC and VC (step S13). Specifically, the verification server 30 requests verification of these VCs by sending the device VC and VC to the DID / VI infrastructure.

[0122] When the DID / VC infrastructure notifies the verification of the device VC and VC, the verification server 30 verifies the received delegation certificate data. The verification server 30 verifies the delegation certificate data in the same way as the issuing server 20.

[0123] If the verification of the delegation certificate data is successful, the verification server 30 verifies both the identity verification certificate data associated with the presented VC and the newly generated identity verification certificate data. The verification server 30 verifies the identity verification certificate data associated with the presented VC in the same way as the issuing server 20.

[0124] Furthermore, the verification server 30 verifies the newly generated identity authentication data. Specifically, the verification server 30 verifies the transmitted and received nonce. This nonce verification prevents replays.

[0125] The verification server 30 verifies that the verifier ID included in the newly generated identity authentication certificate data matches its own verifier ID. Verification of the verifier ID prevents relay attacks. The verification server 30 verifies the expiration date of the newly generated identity authentication certificate data. The verification server 30 also verifies the device signature and the consistency with the device VC (concordance of the device ID).

[0126] Upon successful verification of each identity authentication data, the verification server 30 accepts the received VC. By successfully verifying the delegation certificate data, identity authentication certificate data, etc., the verification server 30 can determine that the VC presenter is the principal entity of the VC.

[0127] <Biometric authentication using external authentication services (cloud / external execution)> In this disclosure, a configuration in which biometric authentication is performed within the device and a configuration in which it is performed in an external authentication service are included as technically equivalent means of guaranteeing identity.

[0128] The wallet device 10 may send derived data of the biometric information, which has been irreversibly transformed or encrypted, to an external authentication service, rather than the biometric information itself. The external authentication service may then perform a verification process based on this derived data and return the result. In other words, the authentication process performed by the device may involve sending irreversibly transformed or encrypted data derived from the biometric information acquired by the device to the cloud, and the cloud returning a verification result based on the data to the device.

[0129] Since the derived data is generated in a format that can be verified while remaining encrypted, or in a transformed format that is difficult to reuse or restore, biometric templates and original biometric information are not directly acquired or reconstructed by external authentication services. This operation ensures that privacy and security are maintained even in external execution configurations.

[0130] Thus, the biometric authentication in the present disclosure is (A) A method that is executed in an execution environment that has resistance to modification of the device's internal workings. (B) Methods implemented in external authentication services, (C) A method that is executed in the application execution environment on the device. This includes all of the above.

[0131] In either method, successful authentication is represented as a signed one-time proof of identity, which is technically equivalent in that it can be cryptographically verified by a third party.

[0132] <Device VC revocation process> Figure 8 is a flowchart showing the revocation process of a device VC according to the embodiment of the present disclosure, illustrating the processes of vulnerability detection, revocation request generation, registration in the revocation database 50, and presentation verification by Verifier.

[0133] As shown in Figure 8, the vulnerability is detected by the manufacturer of the wallet device 10 or by the device itself (step S21).

[0134] When a device vulnerability is detected, the device VC issuing authority 40 or the wallet device 10 itself (self-revoke) generates a revocation request (step S22).

[0135] The revocation request is sent to the DID / VC infrastructure and registered in the revocation database 50 (step S23). When the DID / VC infrastructure verifies a device VC, it checks whether the device VC to be verified is registered in the revocation database 50 (step S24). If the device VC is registered in the revocation database 50, it is determined that the verification of the device VC has failed. As a result, the device is disabled and unauthorized use is prevented.

[0136] This operation enables "device reliability lifecycle management," which was not present in existing VCs (existing systems).

[0137] Furthermore, in this disclosure, a holder who is the legitimate user of a device may express their intention to revoke the authorization of the device by signing based on biometric authentication and their own identifier. This includes a configuration in which the device authentication credentials of the device are revoked based on such expression.

[0138] <Device migration> Figure 9 is a diagram illustrating the secure transfer flow of KYC information. Figure 9 is a sequence diagram showing the process of transferring KYC information when changing devices according to the embodiment of the present disclosure, and shows the generation of a transfer token by the old device, the presentation of a device VC by the new device, and the KYC transfer process by a third-party organization.

[0139] The old device (wallet A) performs user identity verification (biometric authentication) (step S31). The old device performs identity verification using the biometric template stored in the biometric template storage area 212 and the user's biometric information.

[0140] If identity verification is successful, the old device generates a KYC transfer token (step S32). The user operates the new device to obtain the device ID of the new device and registers the obtained device ID with the old device. The old device generates a KYC transfer token that includes the device ID registered by the user. The old device signs the KYC transfer token using the device's private key.

[0141] The user (VC holder) operates the old device and the new device (wallet B) to transfer the KYC transfer token from the old device to the new device (step S33).

[0142] The new device presents the KYC transfer token obtained from the old device and the device VC of its own device (new device) to Issue (step S34). Alternatively, the new device may present the KYC transfer token and device VC to a legitimate third-party organization that performs verification.

[0143] The Issuer and third-party organizations verify the presented KYC transfer token and device VC. Specifically, the Issuer (issuing server 20), etc., verifies the signature of the KYC transfer token. The Issuer, etc., verifies the signature attached to the KYC transfer token using the public key of the old device.

[0144] Furthermore, Issuers verify the device VC of the new device. Issuers determine whether the device ID of the new device obtained from the KYC transfer token matches the device ID obtained from the device VC of the new device. If the two device IDs match, the device VC verification is considered successful.

[0145] Furthermore, Issuers may perform holder DID verification (holder DID consistency verification). In this case, the old device generates a KYC transfer token containing the holder DID stored in the device. The new device presents the holder DID stored in the device to the Issuer, along with the KYC transfer token and device VC. The Issuer determines that the holder DID verification was successful if the holder DID obtained from the KYC transfer token matches the holder DID presented by the new device.

[0146] Upon successful verification, the Issuer or third-party organization determines that identity can be transferred to the new device. Specifically, the Issuer or third-party organization reissues a KYC certificate (VC associated with identity verification data; KYC inheritance VC) to the new device. The Issuer, etc., sends the VC linked to the holder's DID to the new device.

[0147] Thus, the system disclosed in this application further includes a destination device, which may generate a KYC transfer token containing the identifier of the destination device after successfully authenticating the identity of the individual. The destination device presents the KYC transfer token and the destination device's device authentication credentials to the issuer or a legitimate third-party organization that performs verification. The issuer or third-party organization verifies the signature of the KYC transfer token and the destination device's device authentication credentials, thereby enabling the transfer of identity without having to repeat the identity verification process performed at the time of credential issuance.

[0148] This process allows for the transfer of identity without impersonation, even when smartphones or other devices are replaced or lost.

[0149] Furthermore, the present disclosure includes a configuration in which multiple devices are delegated in parallel to the same entity. In this case, each device has independent device authentication credentials and identity verification data. In this case, a process is performed to transfer identity to a new device based on the identity established in an existing device, and a new identity verification result is justified for the new device.

[0150] This operation allows both the old and new devices to be used simultaneously as active devices. However, since authentication and identity verification are performed independently for each device, the authentication result or private key breach on one device will not affect the identity verification on the other device. Authentication and identity verification are performed independently for each device. Therefore, the identity verification result or revocation status on a particular device will not automatically propagate to other devices. Identity inheritance can be performed starting from any existing device, and multiple devices can maintain a parallel delegated state.

[0151] Furthermore, this disclosure includes a configuration that justifies the attribution of biometric authentication across multiple devices to the same entity based on identity verification by the manufacturer or a publicly accredited body. In this case, the biometric information, features, templates, or data derived therefrom used for biometric authentication may be transferred, replicated, regenerated, or independently generated between devices. Regardless of these implementations, the biometric authentication results on each device may be configured to be verifiable as being based on the same entity. The verification and reissuance process related to the inheritance of identity may be performed by the Issuer itself, or by a legitimate third-party organization that verifies device authentication credentials and identity verification data without being individually delegated by the Issuer. In either case, the verification process is performed cryptographically based on the KYC transfer token generated based on successful identity verification on the old device and the device VC of the new device. The KYC transfer token includes a specific destination device identifier and an expiration date, and is generated as a token usable only for one-time identity transfer.

[0152] Next, we will describe an embodiment in which a certification provider issues a device VC.

[0153] Figure 10 shows an example configuration according to the embodiment of the present invention, in which an authentication service provider treats a wallet execution environment on an existing smartphone as a device and issues device authentication credentials (device VC) to that execution environment.

[0154] Referring to Figure 10, an embodiment is described in which a certification business operator, which is not a terminal manufacturer, evaluates a trustworthy execution environment for user authentication purposes on an existing smartphone (physical information processing device) and issues device authentication credentials (device VC) to that execution environment.

[0155] <System Configuration> The system shown in Figure 10 includes at least the following components. • Existing information processing device (smartphone) 801. • A wallet application 802 that runs on the information processing device 801. • A tamper-resistant execution environment 803 within the information processing device 801 (Secure Enclave, TEE, hardware-backed keystore, etc.). • Authentication infrastructure 804 operated by the certification authority • Verify device VC using Issuer or Verifier805

[0156] The wallet application 802 is the execution entity that holds the private key and generates the signature for the identity verification data (One-time Proof). In this embodiment, this wallet execution environment is treated as a "device". The wallet application 802 also generates identity verification triggers.

[0157] The tamper-resistant execution environment 803 has key non-extractability and generates signatures.

[0158] <Device evaluation and verification process> Prior to issuing a device VC, the authentication infrastructure (certification provider) 804 obtains or verifies at least some of the following: • Attestation information provided by the OS or OEM of the information processing device 801 (terminal integrity, boot status, key protection attributes, etc.). • Authenticity of the wallet application 802 (code signing, tamper detection, version information, etc.). • The private key is protected by an execution environment 803 that is tamper-resistant and cannot be extracted externally. • The specified identity verification method (including local biometric authentication and integration with external authentication services) must be executable at the specified level of assurance (LoA) within the wallet execution environment.

[0159] In this way, the execution environment, key protection attributes, app authenticity, setting status, personal authentication method, LoA, etc. are notified from the information processing device 801 to the authentication infrastructure 804. The authentication infrastructure 804 performs attestation verification of the terminal / OS, verification of wallet authenticity, evaluation of the personal authentication method, determination of the level of assurance (LoA), etc.

[0160] Note that the verification by the authentication infrastructure 804 does not prove the authenticity of the physical device itself, but aims to evaluate "whether it is an execution environment that can be trusted for personal authentication purposes".

[0161] <Issuance of Device VC by the Authentication Provider (L3 Device VC)> Based on the above verification results, the authentication infrastructure 804 generates and signs a device authentication credential (device VC) indicating that "the wallet execution environment can execute a predetermined personal authentication method at a predetermined level of assurance (LoA), and the personal authentication result can be trusted for the purpose of identity assurance".

[0162] The device VC may include at least the following information. · An identifier that identifies the device (wallet execution environment). · The protection method of the secret key and the execution environment attributes. · The type of personal authentication method and the level of assurance (LoA). · The identifier and signature of the authentication provider.

[0163] <Usage at the time of VC issuance and presentation> Issuer or Verifier 805 verifies the device VC together with the VC or personal authentication proof data presented from the wallet. Through this verification, it is determined whether "the personal authentication proof data (One-time Proof) was generated in an execution environment that can be trusted for personal authentication purposes". Even when not premised on the physical device VC (L1) issued by the terminal manufacturer, identity assurance can be established based on the L2 / L3 level of device reliability guaranteed by the authentication infrastructure 804 (authentication provider).

[0164] <Revoke and reliability lifecycle management> Furthermore, the authentication infrastructure 804 can revoke device VCs in response to "discovery of vulnerabilities," "changes in OS / wallet settings," "detection of tampering," "revocation of delegation by the user," etc. The Issuer or Verifier 805 can dynamically reject user authentication data generated from untrusted execution environments by checking the revocation status when the VC is presented.

[0165] Issuer or Verifier805 can determine whether a wallet is trustworthy for authentication purposes (whether it is a trustworthy device) by verifying the device VC, checking the expiration status of the device VC, and verifying the identity verification data.

[0166] <Other application examples> The framework of this disclosure is available to the following: • National Digital ID • Professional VCs such as medical license VCs and caregiver qualifications VCs • Opening a bank account • KYC • Access to medical data • Zero Trust Certification for Companies • International Travel Certificate (Digital Travel Credential)

[0167] In each of the above usage scenarios, "guarantee of identity at the time of issuance" and "guarantee of identity at the time of presentation" are achieved cryptographically.

[0168] The system disclosed in this application, through the configuration and procedures described above, provides an unprecedented and advanced identity assurance framework that integrates "device trust," "KYC at issuance," "biometric authentication," "identity at presentation," "device migration," and "vulnerability management."

[0169] As described above, the system disclosed in this application includes a device (e.g., a wallet device 10) that can utilize a tamper-resistant execution environment, and an issuing device (e.g., an issuing server 20) of an issuer that issues credentials. The device holds a device authentication credential (device VC) containing public key information associated with the device, authentication data based on the individual's biometric information (e.g., a biometric template), and a private key held in a way that prevents external extraction by a tamper-resistant execution environment. The device holds the device VC, authentication data, and private key in a logical association such that a signing process using the private key can be executed on the condition that the biometric authentication is successful. The device further holds delegation certificate data indicating that the individual recognizes the device as their agent. The issuing device cryptographically verifies that the device is a legitimate authentication device associated with the individual based on the delegation certificate data and device authentication credentials presented by the device. The device performs an individual identity authentication process and, upon success of the authentication process, transmits signed identity authentication certificate data to the issuing device. The issuing device verifies the individual's identity based on identity verification data and issues credentials to the individual based on the identity verification results. By associating the credentials with identity verification data, the issuing device makes it possible for a third party to verify that the credentials were issued based on the identity verification data.

[0170] Delegation certificate data is data signed by an individual with a private key corresponding to their identifier (e.g., holder DID), and includes information designating the device as the individual's agent (e.g., device ID), and is held by the device.

[0171] The user authentication process is performed on the device, and the execution environment for the user authentication process is an environment that has been confirmed to be reliable for user authentication purposes through tamper detection or authenticity verification (for example, an execution environment 803 that is tamper-resistant). Furthermore, biometric information or biometric data cannot be extracted outside of the entity that performs the user authentication process.

[0172] The identity verification data includes a nonce issued by the credential verifier or issuer, the identifier of the credential verifier or issuer (e.g., verifier DID, issuer DID), and expiration information for the identity verification data. The signature of the identity verification data is generated using a private key, or a key with equivalent security, that is held in a tamper-resistant execution environment and cannot be extracted externally.

[0173] Device authentication credentials (device VCs) can be revoked based on the detection of vulnerabilities or signs of tampering in the device by the device manufacturer, public authority, certification body, issuer, or an organization authorized by the manufacturer, public authority, or certification body, or based on the detection of vulnerabilities or signs of tampering in the device by the device itself.

[0174] <Effects> According to this disclosure, it is possible to comprehensively and cryptographically resolve multiple issues related to identity assurance, device reliability, KYC verification, authentication at presentation, and inter-device migration, which have remained unresolved in existing DID / VC technologies.

[0175] Figure 11 shows the correspondence between the main constituent elements of the system disclosed in this application and effects 1 to 7. Effects 1 to 7 shown in Figure 11 will be explained in order below.

[0176] The main effects of the system disclosed in this application, including effects 1 to 7 described above, are shown below.

[0177] <Effect 1: It becomes possible to cryptographically prove that identity verification was performed when the VC was issued.> In existing DID / VC technologies, there was no cryptographically verifiable evidence by a third party to determine whether or not identity verification (KYC) was performed on the holder at the time of VC issuance, or when and by what means such verification was performed. Therefore, verifiers were effectively forced to blindly trust the issuer's operational policies and statements, and it was impossible to reproduce and verify the "fact that identity verification was performed" from the VC itself.

[0178] In contrast, the present disclosure is technically characterized by introducing "one-time proof data (One-time Proof) that is generated on the condition of successful identity verification" immediately before or within the same processing flow as the VC issuance process, and cryptographically associating said Proof with the VC.

[0179] The personal authentication data in question simultaneously satisfies the following properties: • It cannot be generated without successful biometric authentication. The personal authentication data is signed with a private key that can be used as a trigger condition upon successful biometric authentication in a tamper-resistant execution environment (such as Secure Enclave / TEE) or an external authentication service. Therefore, the very existence of the Proof (personal authentication data) cryptographically implies the fact that "biometric authentication was actually successful." • It is linked one-to-one with the VC issuing session. The identity verification data includes the nonce provided by the Issuer, the Issuer's identifier, and the issuance time or expiration date information. This ensures that the Proof (identity verification data) is valid only for a specific VC issuance session by a specific Issuer, and cannot be used in other issuance processes, subsequent generation, or reuse. • The ability to conduct post-event verification by a third party. The Verifier can cryptographically confirm that identity verification was performed at the time of VC issuance, without relying on the Issuer's declaration, by verifying the following about the identity verification data associated with the VC: "the validity of the signature," "the matching of the Issuer identifier and nonce," "that it is within its validity period," and "that the signing key is based on a legitimate device VC."

[0180] Thus, in the present disclosure, a logical chain of events is established: successful biometric authentication (essential condition) → generation of identity verification data (constrained by the Issuer nonce) → integration with the VC issuance process → subsequent cryptographic verification by a third party. Therefore, the very existence of the identity verification data functions as cryptographic evidence that identity authentication was reliably performed at the time of VC issuance.

[0181] In other words, this disclosure differs fundamentally from existing systems that "claim that the Issuer has performed identity verification," and is characterized by its technical means of "combining cryptographic evidence that cannot be generated without identity verification with the VC issuance result," thereby guaranteeing in an objective and verifiable manner that identity verification is performed at the time of VC issuance.

[0182] Furthermore, the guarantee of identity in this disclosure does not merely indicate the fact that biometric authentication was successful once. The essence of this guarantee of identity lies in the fact that a third party can verify that the same entity that performed the biometric authentication used a private key that was only usable at that time, and that identity verification data was generated.

[0183] Therefore, in a configuration where biometric authentication processing and the use of private keys are separated into different implementing entities or different management areas, for example, where private keys are aggregated on the cloud side, it is not possible to cryptographically verify whether the identity authentication data was generated by the person currently operating a specific device. In other words, such a configuration cannot achieve the identity assurance intended by the present disclosure.

[0184] <Effect 2: When a VC is presented, it can cryptographically guarantee that the presenter is the person they claim to be.> In existing DID / VC technologies, the electronic signature of the Issuer attached to the VC allows verification that the VC has not been tampered with and was issued by a legitimate issuer. However, there was no technical means to guarantee whether the person presenting the VC was the person who possessed the qualifications and attributes listed on the VC.

[0185] In other words, the existing method had a fundamental limitation: while it could verify that a legitimate wallet that had properly issued genuine VC was correctly presenting it, it could not guarantee that the presenter was the person in question.

[0186] (a) Limitations of conventionally proposed "biometric authentication VP methods"> Some conventional methods propose a configuration in which the authentication provider issues biometric credentials (biometric VC) within the wallet, the wallet performs biometric authentication in real time when the VC is presented, and presents the result to the Verifier as VP. However, in this method, what the Verifier actually verifies is merely the fact that "the wallet claims that biometric authentication was successful," and does not cryptographically guarantee that the presenter is the real person. The reason for this is as follows:

[0187] (b) Problem 1: The biometric authentication result and the VP are not cryptographically linked. In existing systems, "executing biometric authentication" and "generating and signing a VP" are logically related but cryptographically independent. That is, the VP signature does not cryptographically bind whether biometric authentication was "actually performed" or "when and to whom" it was performed. Therefore, the Verifier cannot prevent malicious wallets from "reusing previously successful biometric authentication results" or "generating a VP without performing biometric authentication."

[0188] (c) Problem 2: Not bound to Verifier's request (nonce) For identity verification to be valid when presenting a biometric authentication certificate (VC), it is essential that "identity authentication was performed at this very moment in response to this request from this Verifier." However, in conventional methods, biometric authentication VCs tend to be generic, reusable, and Verifier-independent. As a result, replay attacks and relay attacks cannot be eliminated in principle.

[0189] (d) Problem 3: The entity performing biometric authentication cannot be verified. In existing methods, biometric authentication is performed by wallet applications or OS APIs (Application Programming Interfaces). However, Verifier has no way of verifying whether "authentication was performed on a Secure Enclave / TEE" or "on an untampered execution environment." As a result, it can only confirm that "someone seems to have performed biometric authentication," and does not guarantee that "a legitimate person authenticated on a trusted execution environment."

[0190] (e) Problem 4: The wallet itself becomes the "authentication authority" In existing systems, the wallet effectively acts as the performer of biometric authentication, the claimant of the authentication result, and the signer of the VP (Verifier). In other words, the wallet itself is claiming to be the legitimate user, and the Verifier is forced to make its judgment based on the wallet's integrity. Such a structure cannot be said to provide cryptographic assurance of identity.

[0191] (f) Key differences in the method of disclosure in this application. In contrast, in the present disclosure, the following causal relationship is cryptographically enforced at the time of VC presentation: Successful biometric authentication (essential condition) → Permission to use the device private key → Generation of identity verification data including the Verifier nonce. What is important here is that the condition for generating the identity verification data itself is the success of biometric authentication. In other words, "it is mathematically impossible to generate the Proof (identity verification data) without performing biometric authentication," and there is no room for the wallet to arbitrarily claim or reuse past results.

[0192] <(g) Essential differences in what Verifier is verifying> In the present disclosure, the Verifier does not rely on the wallet's claim of being "the real person" or the biometric authentication provider's declaration, but rather verifies "cryptographic evidence that could not exist without successful biometric authentication." In this respect, the method disclosed in the present disclosure is not a method that shows the "likeness" of being the real person, but a method that cryptographically guarantees that the presenter is the real person.

[0193] <(h) Conclusion> As described above, according to the disclosure in this application, the fact that "at the time of VC presentation, in response to the Verifier's request, a legitimate person performed biometric authentication in a trustworthy execution environment at that time" can be cryptographically verified by a third party, without relying on the wallet's claims. This is a qualitatively different guarantee of identity that could not be achieved with existing VC / VP technologies or biometric authentication VP methods, and is a remarkable technical effect of the disclosure in this application.

[0194] <Effect 3: Device reliability can be guaranteed in a standardized format and based on multi-layered RoT (Root of Trust)> Existing DID / VC technologies lacked a standardized means for Issuers or Verifiers to verify whether the execution environment (device, OS, application) on which the wallet storing and presenting VCs operates was trustworthy. In particular, the lack of a generalized mechanism for quickly disabling a device (or execution environment) when a vulnerability is discovered represented a significant operational gap in identity assurance.

[0195] In contrast, the present disclosure introduces device authentication credentials (device VCs) issued by manufacturers, public institutions, certification bodies, etc., for devices (including the execution environment involved in user authentication and the generation of user authentication data). The device VCs provide device-specific keys, functional verification results, security attributes, etc., as cryptographic credentials.

[0196] The device VC in this disclosure encompasses at least the following multi-layered structure (multi-layered Root of Trust) depending on the issuer. • L1 (Physical Authenticity Layer): A device VC where the terminal manufacturer, SoC, etc., verifies the authenticity, tamper resistance, and ownership of the device's unique key for the physical device. L2 (Security Attribute Layer): A device VC that proves that the device meets the security requirements necessary for user authentication, such as terminal state, boot integrity, and key protection attributes, based on measurement results such as attestation provided by the OS / OEM, etc. • L3 (Verification Layer): A device VC that certifies that a specified verification method (including local / cloud) can operate with a specified LoA on the execution environment, and that the verification result is reliable for identity assurance purposes.

[0197] The important point here is that device VCs are not always required to issue L1 (physical authenticity) certificates; they can be issued as "evaluation certificates based on measurement and verification results," similar to L2 / L3. In other words, even if a third party does not possess the root key held by the terminal manufacturer, objective evidence such as OS / OEM attestation can be verified, and the verification results (security attributes, configuration status, integrity, compliant LoA, etc.) can be standardized and presented as credentials. Therefore, the Issuer or Verifier can make a trust judgment by combining L1 to L3 according to the policy of the application.

[0198] Furthermore, the present disclosure does not limit the concept of a device to a physical terminal, but also includes a configuration in which the execution environment of a wallet application, etc., is considered a "device" in order to enable authentication service providers to implement it as software on existing smartphones. In other words, a "device" in the present disclosure is an execution entity that is involved in at least the holding of private keys and the generation of identity authentication data, and includes cases in which such entity uses an execution environment (Secure Enclave / TEE, etc.) on the terminal that is resistant to modification.

[0199] In this case, the certification authority may issue an L2 / L3 device VC stating that the wallet execution environment meets the necessary security requirements for user authentication, based on app authenticity (code signing, tamper detection), device integrity (OS / OEM attestation), key protection attributes, etc. This makes it possible to provide a standardized trust base for identity assurance that can be implemented on existing smartphones, without relying on L1, which presupposes collaboration with device manufacturers.

[0200] Furthermore, the present disclosure provides a device VC with a revoke mechanism (including self-revoke) that can be revoked by the manufacturer, certification body, issuer, or the device itself when a vulnerability is discovered. This allows the issuer or verifier to check the revocation status at the time of presentation and dynamically eliminate untrusted terminals / execution environments, thereby realizing "device reliability lifecycle management" that was not present in conventional VCs.

[0201] Therefore, according to the present disclosure, the Issuer can verify whether the device (execution environment) is trusted at the time of issuance, the Verifier can determine whether the device should be trusted as a standardized credential at the time of presentation, and furthermore, vulnerabilities can be quickly disabled when discovered.

[0202] <Effect 4: The security and flexibility of biometric authentication are significantly improved> This disclosure provides a general-purpose framework that supports any of the following: "biometric authentication in an execution environment with resistance to modification within the device," "biometric verification using an external cloud service," or "a hybrid method combining both."

[0203] This enables advanced authentication regardless of device performance, allows authentication to be performed externally without leaking biometric templates, facilitates biometric authentication updates (algorithm updates) in the cloud, and enables the integration of authentication infrastructures that differ from country to country or business to business. A major feature is that it provides a secure abstract interface for biometric authentication, which was not present in the current VC standard.

[0204] <Effect 5: Identity can be securely transferred when changing devices, and "inheritance of identity" can be cryptographically fixed as a state transition.> The KYC Transfer Token disclosed in this application allows a new device to verify the user's identity using the old device's biometric authentication and device VC. This means that "identity theft is prevented even if the device is lost," "there is no need to perform KYC again on the new device," "the burden on the user when switching devices is reduced," and "it is impossible to transfer identity even if an attacker possesses the old device." As a result, the continuity of identity is cryptographically guaranteed.

[0205] In this disclosure, the transfer of identity upon device change is not achieved through the duplication or transfer of private keys or credentials, but rather as an irreversible cryptographic transition of identity status starting from successful biometric authentication. Therefore, even if a third party possesses the old device, that third party cannot generate cryptographic evidence to transfer identity to the new device, and thus identity hijacking is structurally impossible.

[0206] <Effect 6: In principle, relay attacks and replay attacks can be eliminated> In existing VC / VP technologies, as well as identity verification methods using biometric VP, the biometric authentication result or the claim of successful authentication is not cryptographically bound to a specific Verifier's request or a specific point in time. Therefore, it is fundamentally impossible to eliminate "reuse of previously generated authentication results (replay attacks)" and "relay attacks that relay communication between legitimate users and Verifiers (relay attacks)."

[0207] <(a) Structural characteristics of the identity verification data disclosed in this application> The identity verification data generated in this disclosure includes at least the following: The nonce provided by the Verifier (or Issuer). The identifier of the Verifier (or Issuer). • Expiration date or creation time. • Signing with a device private key, which can only be used after successful biometric authentication. With this configuration, the identity verification data is meaningful only in relation to a specific verifier, a specific request (nonce), and a specific point in time.

[0208] <(b) Reasons why replay attacks are impossible> For a replay attack to succeed, it is necessary that previously generated, correctly generated authentication results can be reused in another presentation request. However, in the present disclosure, "the nonce is different for each Verifier and each request," "the authentication data is signed including the nonce," and "the nonce is accepted only once." Therefore, even if past Proof (authentication data) is resent, it will always fail at the signature verification or nonce verification stage. This is not merely an operational limitation, but an inevitable consequence stemming from the mathematical structure of Proof itself.

[0209] Furthermore, in this disclosure, the nonce is not merely a value for preventing reuse, but functions as an existence condition for combining cryptographic evidence, which cannot exist unless identity authentication is successful, with a specific verification request and a specific point in time. For this reason, it is cryptographically impossible to reuse authentication results generated in the past, or Proof (identity authentication data) generated for other verifiers.

[0210] <(c) Reasons why a relay attack is impossible> A relay attack is an attack in which an attacker relays an authentication request to a legitimate user and then forwards the obtained authentication result to another Verifier.

[0211] Here, the identity verification data disclosed in this application includes the Verifier identifier and the nonce generated by that Verifier. Therefore, "Proof generated for Verifier A" will be "unverifiable by Verifier B". In other words, even if an attacker relays the communication, the verification of Proof (identity verification data) will always fail due to a mismatch in Verifier ID (Verifier identifier).

[0212] <(d) Conclusion (principle impossibility)> Based on the above, in the present disclosure, the conditions for a replay attack to succeed are not met due to the nonce structure, and for a relay attack due to Verifier ID binding, both due to the structure of the cryptographic protocol. Therefore, the present disclosure is an identity assurance method that "in principle" eliminates relay attacks and replay attacks. This is not due to the use of nonce itself, but is based on a structure in which successful authentication is a condition for the existence of Proof, and is fundamentally different from existing challenge-response methods.

[0213] <(7) Identity assurance structure that does not rely on the wallet as the trusting entity> In existing DID / VC technologies, as well as in many biometric authentication VP methods, the wallet is structured to simultaneously perform the following roles: • Perform identity verification. • Generate authentication results. • Signature and presentation of the VP. In this structure, the Verifier ultimately relies on "the claim that the wallet authenticated correctly," which inevitably implies the integrity and implementation quality of the wallet.

[0214] <(a) Basic idea of ​​the disclosure in this application: Wallet distrust model> This disclosure is based on a distinctly different philosophy from the above. Specifically, it adopts a design philosophy that the wallet is not a "subject that claims identity," but merely a "transition point" where evidence cannot be generated unless identity is established.

[0215] <(b) Security that is maintained even if the wallet is fraudulent> In this disclosure, "if biometric authentication is unsuccessful, the device's private key becomes unusable, and identity verification data cannot be generated." Therefore, even if "the wallet is tampered with" or "the wallet makes false claims," ​​the cryptographic evidence that Verifier verifies cannot be generated. In other words, security does not depend on "the good faith of the wallet" or "the quality of the wallet's implementation," but depends solely on the cryptographic existence conditions.

[0216] <(c) Clarification of what Verifier trusts> In this disclosure, Verifier relies on "the execution environment guaranteed by the device VC," "key usage constraints conditional on successful biometric authentication," and "Proof constrained by nonce and Verifier ID," and the wallet itself is not included in the trust assumptions. In this respect, this disclosure is the first to technically realize an "identity assurance model that does not trust the wallet."

[0217] <Effect 8: Can be added to existing DID / VC standards and has high interoperability> This disclosure is extensible without compromising compatibility with the following existing technologies: W3C DID ·W3C Verifiable Credentials(JSON-LD / JWT) ·OIDC4VCI / OIDC4VP ·SD-JWT-VC ·BBS+ / ZKP-based VC FIDO2 / WebAuthn This makes it easier to integrate into existing ecosystems and improves the level of identity assurance by several levels while remaining compliant with standards.

[0218] <Effect 9; Differences from existing authentication technologies and non-obviousness> Existing authentication methods, such as FIDO2 and DID Authentication (DIDAuth), utilize biometric authentication or signatures using private keys. However, these are primarily intended for online service login authentication or responding to authentication requests. Therefore, these methods do not cryptographically link the fact that authentication has been performed to the issuance of verifiable credentials, thereby fixing the information in a way that can be later verified by a third party.

[0219] In contrast, the present disclosure is characterized by the fact that identity verification data, which is generated only upon successful biometric authentication, is incorporated into the VC issuance process, and that a third party can verify even after issuance that the VC was issued based on identity verification.

[0220] The differences are explained below using a table (diagram).

[0221] Figure 12 shows the differences between FIDO2 / WebAuthn and the system disclosed in this application. FIDO2 is a "login authentication" system and is not a mechanism for generating and verifying identity verification that can be presented to third parties.

[0222] Figure 13 shows the difference between DIDAuth and the system disclosed in this application. DIDAuth is proof of "possession of the key," not proof of "identity."

[0223] <The core of non-triviality> The non-obviousness of the present disclosure lies not in the fact that it reuses existing authentication technologies, but in the fact that it redefines identity as a cryptographic existence condition within the context of VC (Virtual Certificate). In other words, the present disclosure consistently introduces the structure that "proof cannot exist unless the person is the person in question" into both the VC issuance and presentation phases, and is not something that a person skilled in the art could easily conceive by simply combining existing authentication technologies or changing their application.

[0224] <Effect 10: Highly reliable ID (eID), immediately usable for qualification verification, financial KYC, medical, and government applications> This disclosure will be particularly effective in areas where identity verification is essential, such as "government-issued digital IDs," "national qualification VCs such as medical licenses, nursing licenses, and lawyer qualifications," "My Number-linked IDs," "KYC for opening bank and securities accounts," and "strict access control."

[0225] Because this disclosure addresses the fundamental flaw of existing DID / VC systems—the inability to verify the identity of the person—it has extremely high value as a digital social infrastructure.

[0226] <Effect 11: Overall, an innovative invention that adds a "personality assurance layer" to the DID / VC ecosystem> This disclosure is not merely an improvement to cryptographic technology, but rather creates a new structural layer of "Identity Assurance" that was lacking in DID / VC systems. As a result, trusted devices, trusted biometric authentication, trusted KYC, and trusted presentations are linked together as a chain, eliminating the fundamental weaknesses of conventional technologies.

[0227] This disclosure provides a new trust framework that addresses the advanced security requirements of the digital society by adding a highly reliable identity verification platform to DID / VC technology.

[0228] Next, we will describe a specific example of the hardware of the wallet device 10. Figure 14 shows an example of the hardware configuration of the wallet device 10.

[0229] The wallet device 10 can be configured using an information processing device (a so-called computer), and has the configuration illustrated in Figure 14. For example, the wallet device 10 includes a processor 311, memory 312, input / output interface 313, and communication interface 314, etc. The components such as the processor 311 are connected by an internal bus or the like and are configured to communicate with each other.

[0230] However, the configuration shown in Figure 14 is not intended to limit the hardware configuration of the wallet device 10. The wallet device 10 may include hardware not shown, and it may not have an input / output interface 313 if necessary. Also, the number of processors 311 etc. included in the wallet device 10 is not intended to be limited to the example in Figure 14; for example, multiple processors 311 may be included in the wallet device 10.

[0231] The processor 311 is a programmable device such as a CPU (Central Processing Unit), MPU (Micro Processing Unit), or DSP (Digital Signal Processor). Alternatively, the processor 311 may be a device such as an FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit). The processor 311 executes various programs, including an operating system (OS).

[0232] Memory 312 includes RAM (Random Access Memory), ROM (Read Only Memory), HDD (Hard Disk Drive), SSD (Solid State Drive), etc. Memory 312 stores the OS program, application programs, and various data.

[0233] The input / output interface 313 is an interface for a display device or input device (not shown). The display device is, for example, a liquid crystal display. The input device is, for example, a device that accepts user input such as a keyboard or mouse.

[0234] The communication interface 314 is a circuit, module, etc., that communicates with other devices. For example, the communication interface 314 includes a NIC (Network Interface Card), etc.

[0235] The functions of the wallet device 10 are realized by various processing modules. These processing modules are realized, for example, by the processor 311 executing a program stored in the memory 312. The program can also be recorded on a computer-readable storage medium. The storage medium can be a non-transitory medium such as a semiconductor memory, hard disk, magnetic recording medium, or optical recording medium. In other words, the present invention can also be embodied as a computer program product. Furthermore, the program can be downloaded via a network or updated using the storage medium on which the program is stored. Moreover, the processing module may be realized by a semiconductor chip.

[0236] Furthermore, the issuing server 20 and the verification server 30 can also be configured using information processing devices, similar to the wallet device 10. Since their basic hardware configurations are identical to those of the wallet device 10, a detailed explanation will be omitted.

[0237] The wallet device 10, which is an information processing device, is equipped with a computer, and its functions can be realized by having the computer execute a program. Furthermore, the wallet device 10 executes a control method for the wallet device 10 using this program. Similarly, the issuing server 20 is equipped with a computer, and its functions can be realized by having the computer execute a program. Furthermore, the issuing server 20 executes a control method for the issuing server 20 using this program. Similarly, the verification server 30 is equipped with a computer, and its functions can be realized by having the computer execute a program. Furthermore, the verification server 30 executes a control method for the verification server 30 using this program.

[0238] The configuration and operation of the information processing system described in the above embodiment are illustrative examples and are not intended to limit the system configuration.

[0239] In the flowcharts (flowcharts, sequence diagrams) used in the above description, a plurality of steps (processes) are described in order, but the execution order of the steps executed in the embodiment is not limited to the order of the description. In the embodiment, for example, the order of the illustrated steps can be changed within a range that does not substantially affect the content, such as executing each process in parallel.

[0240] The above embodiments have been described in detail for the purpose of facilitating understanding of the present disclosure, and it is not intended that all the configurations described above are necessary. Also, when a plurality of embodiments are described, each embodiment may be used alone or in combination. For example, it is also possible to replace a part of the configuration of an embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of an embodiment. Furthermore, it is possible to add, delete, or replace other configurations to a part of the configuration of an embodiment.

[0241] From the above description, the industrial applicability of the present invention is clear, and the present invention is suitably applicable to an information processing system that issues a certification certificate to a user, etc.

[0242] Some or all of the above embodiments may be described as follows in the following supplementary notes, but are not limited thereto.

[0243] [Supplementary Note 1] A device capable of using an execution environment having modification resistance, An issuing device of an issuer that issues credentials, and includes The device logically associates and holds a device authentication credential including public key information associated with the device, authentication data based on personal biometric information, and a secret key held in a non-extractable manner by the execution environment having modification resistance, such that signature processing using the secret key can be executed on the condition of successful authentication based on the biometric information. The device further holds委任証明データ indicating that the individual authorizes the device as his / her proxy entity. The issuing device is, Based on the delegation certificate data and device authentication credentials presented from the device, the device is cryptographically verified to be a legitimate authentication device associated with the individual. The device described above, The process for authenticating the identity of the aforementioned individual is performed, and the signature-granted identity verification data is transmitted to the issuing device in response to the successful result of the identity verification process. The issuing device is, A system that verifies the identity of an individual based on the aforementioned identity verification data, issues the aforementioned credentials to the individual based on the verification result of the identity verification, and associates the aforementioned credentials with the aforementioned identity verification data, thereby enabling a third party to verify that the credentials were issued based on the aforementioned identity verification data.

[0244] [Note 2] The delegation certificate data is data signed by the individual with a private key corresponding to their identifier, and includes content designating the device as the individual's agent, and is held by the device, as described in Appendix 1 of the system.

[0245] [Note 3] The power of attorney data is a power of attorney credential issued by the device manufacturer, a public accreditation body, or a third-party certification body after verification based on the power of attorney data signed by the individual, as described in Appendix 1 or 2 of the system.

[0246] [Note 4] The aforementioned user authentication process is performed on the device, The execution environment for the personal authentication process is an environment that has been confirmed to be reliable for personal authentication purposes through tamper detection or authenticity verification, and the biometric information or the converted data of the biometric information cannot be extracted outside of the entity executing the personal authentication process, as described in any one of the items in Appendix 1 to 3.

[0247] [Note 5] The user authentication process performed on the device is: The data derived from the biometric information acquired by the aforementioned device, which has undergone irreversible transformation or encryption, is transmitted to the cloud. The system described in Appendix 4, which includes a method by which the cloud returns matching results based on the data to the device.

[0248] [Note 6] The aforementioned identity verification data is The nonce issued by the verifier or issuer of the aforementioned credentials, the identifier of the verifier or issuer of the aforementioned credentials, and the expiration date information of the identity verification data, The signature of the aforementioned identity verification data is A system according to any one of the appendices 1 to 5, which is generated using a secret key that is held in a manner that prevents external extraction by the aforementioned modification-resistant execution environment, or a key that has security equivalent to the aforementioned secret key.

[0249] [Note 7] The aforementioned device authentication credentials are: A system according to any one of the appendices 1 to 6, which can be revoked based on the detection of a vulnerability or indication of tampering in the device by the device's manufacturer, public body, certification body, issuer, or an organization delegated by any of the manufacturer, public body, or certification body, or based on the device itself detecting the vulnerability or indication of tampering.

[0250] [Note 8] The system according to any one of the items in Appendix 1 to 7, wherein if the user authentication process fails a predetermined number of times, the device performs at least one of the following actions: exponentially increasing the authentication waiting time, locking the device, and issuing a self-revocation request that revoke the device authentication credentials.

[0251] [Note 9] Including the destination device for replication, The device described above, After successfully authenticating the individual, generate a KYC (Know Your Customer) transfer token including the identifier of the destination device for replication, The destination device for replication is, Present the KYC transfer token and the device authentication credentials of the destination device for replication to the issuer or a third-party institution having the legitimacy to conduct verification, The issuer or the third-party institution is, By verifying the signature of the KYC transfer token and the device authentication credentials of the destination device for replication, it is possible to inherit the authenticity without re-performing the authentication process performed at the time of issuance of the credentials. The system according to any one of Appendices 1 to 8.

[0252] [Appendix 10] The association between the credentials and the authentication proof data includes at least one of direct embedding of the authentication proof data into the credentials, assignment of an external reference URI (Uniform Resource Identifier) to the authentication proof data to the credentials, and attachment of the authentication data as metadata of the credentials. The system according to any one of Appendices 1 to 9.

[0253] [Appendix 11] A device capable of using an execution environment with tamper resistance, An issuing device of an issuer that issues credentials, In a system including, The device is, Device authentication credentials including public key information associated with the device, authentication data based on the biometric information of an individual, and a private key held in a tamper-resistant manner by the tamper-resistant execution environment, are logically associated and held so that signature processing using the private key can be executed on the condition of successful authentication based on the biometric information, Further hold委任証明データindicating that the individual authorizes the device as their proxy, The issuing device is, Based on the delegation certificate data and device authentication credentials presented from the device, the device is cryptographically verified to be a legitimate authentication device associated with the individual. The device described above, The process for authenticating the identity of the aforementioned individual is performed, and the signature-granted identity verification data is transmitted to the issuing device in response to the successful result of the identity verification process. The issuing device is, A method comprising verifying the identity of an individual based on the aforementioned identity verification data, issuing the credentials to the individual based on the results of the identity verification, and associating the credentials with the identity verification data, thereby enabling a third party to verify that the credentials were issued based on the identity verification data.

[0254] [Note 12] A storage means that stores device authentication credentials including the public key information of the device, delegate certification data indicating that the user recognizes the device as their agent, and the user's biometric information. When requested by the credential issuer to perform biometric authentication, the device generates authentication data that proves the success of the biometric authentication, using the stored user's biometric information to authenticate the person operating the device. A transmission means for transmitting the stored device authentication credentials, the stored delegation certificate data, and the generated identity authentication certificate data to the issuer of the credentials, A device equipped with the following features.

[0255] [Note 13] In the device, The device stores device authentication credentials including the public key information of the device, delegation certificate data indicating that the user recognizes the device as their agent, and the user's biometric information. When requested by the credential issuer to perform biometric authentication, the device authenticates the person operating it using the stored user biometric information, and if authentication is successful, generates authentication data that proves the biometric authentication was successful. A device control method for transmitting the stored device authentication credentials, the stored delegation certificate data, and the generated personal authentication certificate data to the issuer of the credentials.

[0256] [Note 14] The computer installed in the device A process for storing device authentication credentials including the public key information of the device, delegate certification data indicating that the user recognizes the device as their agent, and the user's biometric information. When requested by the credential issuer to perform biometric authentication, the system authenticates the person operating the device using the stored user biometric information, and if authentication is successful, generates authentication data to prove that the biometric authentication was successful. A process of transmitting the stored device authentication credentials, the stored delegation certificate data, and the generated personal authentication certificate data to the issuer of the credentials, A computer-readable storage medium that stores a program to execute.

[0257] Furthermore, some or all of the configurations described in Appendices 2 to 10, which are dependent on Appendice 1 above, may also be dependent on Appendice 11 in the same manner as those described in Appendices 2 to 10. Moreover, not limited to Appendices 1 and 11, some or all of the configurations described as appendices may also be dependent on various hardware, software, various recording means for recording software, or systems, without departing from the embodiments described above.

[0258] Furthermore, each disclosure of the above-mentioned prior art documents cited herein is incorporated herein by reference. Although embodiments of the present invention have been described above, the present invention is not limited to these embodiments. It will be understood by those skilled in the art that these embodiments are merely illustrative and that various modifications are possible without departing from the scope and spirit of the present invention. That is, the present invention naturally includes the entire disclosure, including the claims, and various modifications and alterations that can be made by those skilled in the art in accordance with the technical idea. [Explanation of symbols]

[0259] 10 Wallet Devices 20 publishing servers 30 Verification Servers 40 Device VC Issuers 50 Expired Database 101 devices 102 Issuing device 201 Secure Enclave or TEE 202 Biometric Module 203 Device VC storage area 204 Delegation Certificate Data Storage Area 205 Communication Module 211 Biometric Sensor 212 Biological template storage area 301 KYC Management Module 302 VC publishing module 311 Processors 312 memory 313 Input / Output Interfaces 314 Communication Interface 401 VC Verification Module 801 Information Processing Device 802 Wallet Application 803 Runtime environment with modification resistance 804 Authentication Infrastructure 805 Issuer or Verifier

Claims

1. Devices that can utilize a modification-resistant execution environment, The issuing device of the issuer that issues credentials, Includes, The device described above, Device authentication credentials including public key information associated with the device, authentication data based on the individual's biometric information, and a private key held in a way that prevents external extraction by the tamper-resistant execution environment are logically associated and maintained such that a signature process using the private key can be executed on the condition that the authentication based on the biometric information is successful. The aforementioned individual further holds delegation certificate data indicating that he / she recognizes the device as his / her agent, The issuing device is, Based on the delegation certificate data and device authentication credentials presented from the device, the device is cryptographically verified to be a legitimate authentication device associated with the individual. The device described above, The process for authenticating the identity of the aforementioned individual is performed, and the signature-granted identity verification data is transmitted to the issuing device in response to the successful result of the identity verification process. The issuing device is, A system that verifies the identity of an individual based on the aforementioned identity verification data, issues the aforementioned credentials to the individual based on the verification result of the identity verification, and associates the aforementioned credentials with the aforementioned identity verification data, thereby enabling a third party to verify that the credentials were issued based on the aforementioned identity verification data.

2. The system according to claim 1, wherein the delegation certificate data is data signed by the individual with a private key corresponding to their identifier, includes content designating the device as an agent of the individual, and is held by the device.

3. The system according to claim 1 or 2, wherein the delegation certificate data is a power of attorney credential issued by the device manufacturer, a public accreditation body, or a third-party certification body after verification based on the delegation data signed by the individual.

4. The aforementioned user authentication process is performed on the device, The system according to claim 1 or 2, wherein the execution environment for the identity authentication process is an environment that has been confirmed to be reliable for identity authentication purposes through tamper detection or authenticity verification, and the biometric information or the converted data of the biometric information cannot be extracted outside the entity executing the identity authentication process.

5. The user authentication process performed on the device is: The data derived from the biometric information acquired by the aforementioned device, which has undergone irreversible transformation or encryption, is transmitted to the cloud. The system according to claim 4, further comprising a method by which the cloud returns a matching result based on the data to the device.

6. The aforementioned identity verification data is The nonce issued by the verifier or issuer of the credentials, the identifier of the verifier or issuer of the credentials, and the expiration date information of the identity verification data are included. The signature of the aforementioned identity verification data is The system according to claim 1 or 2, wherein a secret key is held in a manner that prevents external extraction by the aforementioned modification-resistant execution environment, or a key is generated using a key having security equivalent to that of the secret key.

7. The aforementioned device authentication credentials are: The system according to claim 1 or 2, wherein the device can be revoked based on the detection of a vulnerability or indication of tampering by the device's manufacturer, public body, certification body, issuer, or an organization delegated by any of the manufacturer, public body, and certification body, or based on the device itself detecting the vulnerability or indication of tampering.

8. The system according to claim 1 or 2, wherein if the user authentication process fails a predetermined number of times, the device performs at least one of the following: exponentially increasing the authentication waiting time, locking the device, and issuing a self-revocation request that revoke the device authentication credentials.

9. Including the destination device for replication, The device described above, After successfully authenticating the identity of the aforementioned individual, a KYC (Know Your Customer) transfer token containing the identifier of the destination device is generated. The aforementioned destination device is The KYC transfer token and the device authentication credentials of the destination device are presented to the issuer or a legitimate third-party organization that performs verification. The aforementioned issuer or third-party organization, The system according to claim 1 or 2, which enables the transfer of identity without having to re-perform the identity authentication process performed at the time of issuance of the credentials, by verifying the signature of the KYC transfer token and the device authentication credentials of the destination device.

10. The system according to claim 1 or 2, wherein the association between the credentials and the identity verification data includes at least one of the following: direct embedding of the identity verification data within the credentials; assigning an external reference URI (Uniform Resource Identifier) ​​to the credentials for the identity verification data; and attaching the identity verification data as metadata to the credentials.

11. Devices that can utilize a modification-resistant execution environment, The issuing device of the issuer that issues credentials, In a system including, The device described above, Device authentication credentials including public key information associated with the device, authentication data based on the individual's biometric information, and a private key held in a way that prevents external extraction by the tamper-resistant execution environment are logically associated and maintained such that a signature process using the private key can be executed on the condition that the authentication based on the biometric information is successful. The aforementioned individual further holds delegation certificate data indicating that he / she recognizes the device as his / her agent, The issuing device is, Based on the delegation certificate data and device authentication credentials presented from the device, the device is cryptographically verified to be a legitimate authentication device associated with the individual. The device described above, The process for authenticating the identity of the aforementioned individual is performed, and the signature-granted identity verification data is transmitted to the issuing device in response to the successful result of the identity verification process. The issuing device is, A method comprising verifying the identity of an individual based on the aforementioned identity verification data, issuing the credentials to the individual based on the results of the identity verification, and associating the credentials with the identity verification data, thereby enabling a third party to verify that the credentials were issued based on the identity verification data.

Images