KR102827076B1 - Verifier specific method for distributing VP (Verifiable Credential) - Google Patents

Abstract

The present invention relates to DID technology, and relates to a method for specifying a verifier who decrypts and verifies personal information of a VP in which personal information is encrypted and inserted, and who can specify who distributed the VP containing the decrypted personal information when it is leaked without permission.

Description

Verifier specific method for distributing VP (Verifiable Credential)

The present invention relates to DID technology, and more specifically, to a method for specifying a verifier who decrypts and verifies personal information of a Verifiable Credential (hereinafter referred to as “VP”) in which personal information is encrypted and inserted, and who can distribute a VP containing the decrypted personal information when it is leaked without permission, by specifying a VP distribution verifier.

Decentralized identifiers (hereinafter referred to as 'DIDs') are globally unique identifiers that do not require a centralized registration agency such as a server by registering in a distributed repository using distributed ledger technology or other distributed network technologies, and are used in electronic identification systems built on blockchain technology.

In existing centralized identity management systems where a service provider centrally manages a user's digital identity, it is common to issue a user ID and credentials (e.g. password) to verify the ID, and to retain and manage user information such as user name and address. Since the user identity is delegated to and managed by a central agency, it is difficult for the user to control his or her identity, personal data, and related attribute information managed by the central agency.

In contrast, using distributed network technologies such as blockchain, individual users can manage their own identity information. This is called a distributed identity management system, and the identifier used for this is called a distributed DID.

Specifically, you can prove your identity by submitting your DID from your blockchain wallet in situations where it is necessary, such as taking out your resident registration card from your wallet to prove your identity. Compared to existing identity authentication methods, it is characterized by individuals exercising complete control over their own information during the identity verification process.

In this existing DID technology, a Verifiable Credential (VC, hereinafter referred to as 'VC') is received, a VP is submitted, and the VP is verified to confirm the authenticity of the identity. At this time, the VP may contain a lot of personal information, so there is a risk of personal information leakage due to the distribution of VP containing decrypted personal information.

Republic of Korea Patent No. 10-2439879 (2022.08.30)

The present invention has been created to solve the above problems, and the purpose of the present invention is to provide a method for specifying a verifier who decrypts and verifies personal information of a VP that is encrypted by applying a symmetric key encryption and a challenge value during the VP creation process, and who can distribute a VP containing the decrypted personal information when it is leaked without permission.

For the above purpose, the present invention provides a specific method for verifying VP distribution based on a DID, in which a VC issuer, a VP generator, and a VP verifier are registered in a server, and the VP generator generates a VP through a VC issued by the VC issuer and submits the VP to the VP verifier, the method comprising: a step in which the VC issuer generates a first symmetric key for encrypting the VC and a second symmetric key for encrypting DID information of the VP generator; a step in which the VP generator encrypts personal information included in the VC with the first symmetric key, encrypts DID information of the VP generator with the second symmetric key, generates a key value by encrypting the second symmetric key with the public key of the VP verifier, and includes a challenge value regarding the target of the document in the VC to generate a VP through the signature of the VP generator; The step of the VP generator recording the challenge value, the VP verifier's DID information, and the key value in the key storage and submitting the generated VP to the VP verifier; The step of the VP verifier submitting the submitted VP It is characterized by including a step of checking the DID information of the VP generator and verifying the signature of the VP generator by searching the kit value on the blockchain through the challenge value; a step of the VP verifier decrypting the encrypted personal information included in the VP.

At this time, in the step of generating the VP, the VP may include terms and conditions prohibiting third-party freedom of the VP.

Additionally, the key storage can be an offchain server or a blockchain network.

Additionally, in the step of generating the VP, the contents of the VC can be configured to be encrypted using JSON Web Encryption (jwe) so that only a designated verifier can decrypt it during communication and storage.

In addition, in the step of generating the VP, jwe1 including a public key encryption algorithm, a symmetric key encryption algorithm, the key value, an encryption initialization vector, and a value obtained by encrypting the VC with the first symmetric key, and jwe2 including a public key encryption algorithm, a symmetric key encryption algorithm, an encryption initialization vector, and a value obtained by encrypting the DID information of the VP generator with the second symmetric key are generated, and in the step of verifying the signature, jwe2 is decrypted, and in the step of decrypting the encrypted personal information, jwe1 can be decrypted.

Through the present invention, it is possible to specify a verifier who decrypts and verifies the personal information of a VP in which personal information is encrypted and inserted, and when the verifier leaks the decrypted personal information without permission, it is possible to protect the personal information of the VP creator by specifying who distributed the VP containing it. In addition, when the VP verifier arbitrarily changes the information of the VP to avoid such tracking, verification of the personal information included in the document becomes impossible, so that an attempt at information leakage can be neutralized.

Figure 1 is a conceptual diagram of the present invention;
Figure 2 is a flow chart according to an embodiment of the present invention.
Figure 3 is a protocol description diagram according to an embodiment of the present invention.
Figure 4 is a block diagram showing the configuration and connection relationship according to an embodiment of the present invention.

Hereinafter, a specific method for verifying the VP distribution of the present invention will be specifically described with reference to the attached drawings.

FIG. 1 is a conceptual diagram of the present invention, FIG. 2 is a flow chart according to an embodiment of the present invention, and FIG. 3 is a protocol explanatory diagram according to an embodiment of the present invention.

In the basic DID concept, a VC is issued by a VC issuer (did:sov:ABC1) to a VC requester (=VP creator, did:sov:123), and is a verifiable certificate issued by putting the requester's property in the Claim and the signature value signed with the issuer's private key in the proof. For example, the career certificate issued to did:sov:123 by the company he worked for, did:sov:ABC1, becomes a VC.

VP is a certificate that did:sov:123 collects the VCs he received with his career certificates (did:sov:ABC1, did:sov:ABC2...), signs them with did:sov:123's private key, and puts the signature value in the proof.

In the present invention, a method is proposed to prevent personal information from being leaked when a VP generator (did:sov:123) issues a certificate of career (VP) to a recruiting company (=VP verifier, did:sov:BCD) to prove his/her career, and to trace who leaked the personal information if it is leaked.

These DIDs are based on blockchain and are based on a DID creation process in which each of the three entities, a VC issuer (A), a VP creator (B), and a VP verifier (C), registers their own public keys and is assigned a DID address.

The above VC issuer (A) is the Issuer, which is the entity that issues the VC, which is the user's identity information, and is an institution that issues identity information and DID at the request of the user, who is the information subject. The Issuer delivers reliable identity information for the information it issues.

The above VP creator (B) is a user, Holder, who owns the identity information and is a user who wants to prove his/her identity by using DID as the information subject. The system issues and submits a DID.

The above VP Verifier is a service provider that verifies identity information. It receives VP from the user, who is the information subject, and verifies the identity information.

At the request of the VP generator (B), the VC issuer (A) issues a VC, which is a credential that includes the identity information of the VP generator (B), by signing it with the VC issuer's (A) private key, and the details of this signing and issuance are stored on the blockchain.

The VP generator (B) stores the VC issued by the VC issuer (A) in a personal terminal, signs the necessary information with the VP generator's (B) private key to create a VP, and submits it to the VP verifier (C).

The general concept of DID is that the VP verifier (C) verifies the information of the VC issuer and VP creator through the submitted VP, and the fact that the VC issuer has issued the VC through the blockchain.

At this time, the VC consists of Credential metadata, Claims(s), and Proof(s). Credential metadata includes the VC issuer, the specified object, expiration period, disposal method, etc., and Claim(s) stores information about the ID attribute of the Credential subject in the 'Subject-Property-Value' format. Proof(s) contains values required to verify the authenticity of the VC, so the verifying subject can verify whether the VC was issued by the issuer specified in the VC by verifying the Proof of the VC.

VP consists of Presentation Metadata, Verifiable Credential(s), and Proof(s). Presentation Metadata includes data required for VP verification, such as type, terms of use, and evidence that specify that the data is a VP. Verifiable Credential(s) is an area where the verifier selects and enters VCs with ID attributes required by the verifier. The VP creator selects and enters only Claims with ID attributes required by the VP verifier, thereby protecting privacy. Proof includes the VP creator's signature.

Based on such conventional DID, the present invention encrypts personal information and places it in a VP through the following procedure when generating a VP, and enables the identification of a person who decrypts and verifies the personal information.

First, a step (S 110) is performed in which the VP generator selects the information it wants from among the VCs issued by the VC issuer and generates a first symmetric key for encrypting the VC and a second symmetric key for encrypting the DID information of the VP generator when generating a VP. The VP generator encrypts the VC contents and the DID information of the VP generator using their respective symmetric keys and submits them to the VP verifier, and through a series of authentication processes described below, the VP verifier is enabled to decrypt the VC contents, including the DID information of the VP generator encrypted using the symmetric key.

In the step of generating the next VP (S 120), the VP generator encrypts the personal information included in the VC and the DID information of the VP generator, respectively, with the first and second symmetric keys generated in the step of generating the symmetric key (S 110). At this time, in order to transmit the second symmetric key to the VP verifier, a key value is generated by encrypting the symmetric key with the public key of the VP verifier, and a challenge value regarding the target of the document is included in the VP to generate the VP through the signature of the VP generator.

The reason why the above challenge value is included in the VP at this time is that the VP verifier and key storage have the challenge value together so that the VP can confirm who the document is targeting and, if the VP verifier leaks personal information, it can be used to confirm who leaked it.

In an embodiment of the present invention, the characteristic form of VP is as follows.

{

Presentation Metadata: .... Omitted

“verifiableCrednetial”:[{

jwe1: Contents

challenge: content

}]

“Proof”:{

.... Omitted,

“id”: jwe2 content,

“keystorage”: URL or blockchain A,

“verifier: did:sov:BCD,

“jws”: ... content

}

},

termOfUser:[{

....omission

“action”: [“3rdPartyCorrelation”]

}]

The omitted DID-related content is a known technology, and to prevent the purpose of the present invention from being obscured, the same content as the existing DID is omitted.

In the step (S 120) of generating a VP in an embodiment of the present invention, the contents of the VC and Proof are encrypted using JSON Web Encryption (jwe) and configured so that only a designated verifier can decrypt them during communication and storage, and jwe1 and jwe2 are generated in a desirable form.

Specifically, jwe1 including a public key encryption algorithm, a symmetric key encryption algorithm, and a value obtained by encrypting the above-mentioned key value, an encryption initialization vector, and a VC using a first symmetric key, and jwe2 including a value obtained by encrypting the public key encryption algorithm, a symmetric key encryption algorithm, an encryption initialization vector, and the DID information of the VP generator using a second symmetric key can be generated, respectively.

In an embodiment of the present invention, the contents of jwe1 can be configured as follows.

“header” : { “alg”: public key encryption algorithm, “enc”: symmetric key encryption algorithm “ },

“encrypted_key”: The key value encrypted using the public key encryption algorithm of did:sov:BCD, which is the symmetric key used to encrypt VCs.

“iv”: Initial Vector (value encrypted with public key)

“chipertext”: “Encrypted value of VCs

Additionally, in an embodiment of the present invention, the contents of jwe2 can be configured as follows.

“header” : { “alg”: public key encryption algorithm, “enc”: symmetric key encryption algorithm “ },

“iv”: Initial Vector (value encrypted with public key)

“chipertext”: “did:sov:123” encrypted with the second symmetric key

VP includes the value of VC encrypted with the first symmetric key, the VP generator's DID information (ID, etc.) encrypted with the second symmetric key, and the IV (Initialization Vector) encrypted with the public key.

In addition, in the step of generating the VP (S 120), the VP includes a termOfUser that prohibits third-party corruption of the VP, thereby ensuring that primary measures are taken against the VP verifier violating the terms and conditions and leaking personal information.

Next, a step (S 130) is performed in which the VP generator encrypts the challenge value, the VP verifier's DID information, and the second symmetric key missing from the jwe2 with the VP verifier's public key and records the key in the key storage, and submits the generated VP to the VP verifier.

The above key storage can be an off-chain server or a blockchain network. The blockchain network is on-chain, and all transaction information on the on-chain is included in the block, and recorded transactions cannot be permanently deleted. It has high stability because it forms its own network and all records in the blockchain are recorded and disclosed to all users.

Off-chain, unlike on-chain, records specific transaction details in an independent external location, not directly on the blockchain. Unlike on-chain, it can process quickly because it does not require a consensus process or verification. Only core data is recorded on the blockchain, and data that requires high speed is recorded on the DAPP central server, not on the blockchain, and it is fast and inexpensive.

The value stored in this key storage is the key value (encrypted_key) that is the second symmetric key missing from the challenge value/VP verifier DID/jwe2 encrypted using the VP verifier's public key encryption algorithm.

After that, the VP verifier receives the VP A step (S 140) is performed in which the above-mentioned key value is searched on the blockchain using the challenge value, the key value is decrypted with the private key to obtain a second symmetric key, and the DID information of the above-mentioned VP generator is decrypted and confirmed with the second symmetric key to verify the signature of the VP generator.

The jwe2 explained above is an encrypted ID in the Proof that constitutes the VP. To decrypt it, the VP verifier requests the key storage with the challenge value and its own ID (did:sov:BCD) to receive the second key value (encrypted_key), which can be used to verify the ID of the user, i.e. the VP creator, and through this, the proof of the VP can be verified based on the ID of the VP creator.

Finally, in the step (S 150) where the VP verifier decrypts the encrypted personal information included in the VP, the signature is verified using the VP generator's public key and jwe1 is decrypted, allowing the VP verifier to verify the personal information of the VP.

That is, in the step of verifying the signature (S 140), jwe2 is decrypted, and in the step of decrypting the encrypted personal information (S 150), jwe1 is decrypted.

Through this process, if a VP verifier leaks a VP, the challenge value stored in the VP document can be used to identify who leaked it. If the challenge value is changed to avoid this tracking, the VP cannot be verified, and it is impossible to verify whether the personal information in the VC is true.

In addition, the VP verifier can decrypt VP's jwe1 and jwe2 and distribute VP by leaking personal information and violating the terms and conditions. In this case, in order to verify the leaked personal information, jwe1 can be encrypted with the VP verifier's public key and the VP can be verified with the public key of jwe2. However, once verified, the challenge value will not change, so it is still possible to identify who leaked it, and even if the challenge value and verifier are changed so that verification is not possible and it is impossible to identify who leaked it, the personal information included in the document cannot be verified, so such attempts can be neutralized.

FIG. 4 is a block diagram showing a configuration and connection relationship according to an embodiment of the present invention, and briefly shows a terminal owned by each entity in which a method according to the present invention is performed and a network environment in which it operates.

Basically, the above server (140) is configured to be able to communicate with the VC issuer terminal (110), the VP generator terminal (120), and the VP verifier terminal (130) via a network, either wired or wirelessly, and may be an off-chain server or a blockchain.

The above VC issuer terminal (110) is a terminal used by the entity issuing the VC and issues a VC, which is data for qualification authentication, to a user whose identity has been verified. For example, the terminal may be a public institution or a company or institution that issues various supporting documents requested by the user.

The above VP generator terminal (120) is a terminal used by the subject of generating the VP and is a terminal owned by the user who is the subject of the information. It has the role of requesting the issuance of a VC to the above VC issuer terminal (110), creating a VP through the issued VC, registering the information thereon with the server (140), and submitting the VP to the above VP verifier terminal (130).

The above VP verifier terminal (130) is a terminal used by an entity verifying a VP, and can be a terminal of an institution that receives a user's identity verification data and performs identity authentication based on the received identity verification data. Verification of the user can be performed using decryption information registered in the blockchain network.

The above VC issuer terminal (110), VP generator terminal (120), and VP verifier terminal (130) may be implemented as a computer that can access a remote server or terminal via a network. For example, the computer may include a notebook, desktop, laptop, etc. equipped with a web browser. In addition, the VP generator terminal (120) may include all types of portable personal terminal devices such as a smartphone, smartpad, tablet PC, etc., as a terminal that can access a remote server or other terminal via a network.

The rights of the present invention are not limited to the embodiments described above, but are defined by what is described in the claims, and it is obvious that a person skilled in the art in the field of the present invention can make various modifications and adaptations within the scope of the rights described in the claims.

110: VC issuer terminal 120: VP creator terminal
130: VP Verifier Terminal 140: Server

Claims (5)

In a specific method of VP distribution verification based on DID, where a VC issuer, a VP generator, and a VP verifier are registered on a server, and the VP generator generates a VP through a VC issued by the VC issuer and submits it to the VP verifier,
Step (S 110) in which the VC issuer generates a first symmetric key to encrypt the VC and a second symmetric key to encrypt the DID information of the VP generator;
A step (S 120) in which the VP generator encrypts personal information included in the VC with the first symmetric key, encrypts the VP generator's DID information with the second symmetric key, generates a key value by encrypting the second symmetric key with the VP verifier's public key, and generates a VP through the VP generator's signature by including a challenge value regarding the target of the document in the VC;
Step (S 130) where the VP generator records the challenge value, the VP verifier's DID information, and the key value in key storage and submits the generated VP to the VP verifier;
The VP verifier above submitted the VP Step (S 140) of checking the DID information of the VP creator by searching the above kit value on the blockchain using the challenge value and verifying the signature of the VP creator;
A specific method for VP distribution verification, characterized in that it includes a step (S 150) in which the VP verifier decrypts encrypted personal information included in the VP.
In the first paragraph,
In the step of generating the above VP (S 120),
A specific method of VP distribution validation, characterized in that the above VP includes a term prohibiting third-party freedom of VP.
In the first paragraph,
A specific method of VP distribution validation, characterized in that the above key storage is an offchain server or blockchain network.
In the first paragraph,
In the step of generating the above VP (S 120),
A specific method for distributing a VP verifier, characterized in that the content of the VC is encrypted using JSON Web Encryption (JWE) and configured so that only a designated verifier can decrypt it during communication and storage.
In paragraph 4,
In the step (S 120) of generating the above VP, jwe1 including a public key encryption algorithm, a symmetric key encryption algorithm, the key value, an encryption initialization vector, and a value obtained by encrypting the VC with the first symmetric key, and jwe2 including a public key encryption algorithm, a symmetric key encryption algorithm, an encryption initialization vector, and a value obtained by encrypting the DID information of the VP generator with the second symmetric key are generated, respectively.
In the step of verifying the above signature (S 140), the jwe2 is decrypted,
A specific method for verifying VP distribution, characterized in that in the step (S 150) of decrypting the encrypted personal information, the jwe1 is decrypted.