CN112311538B

CN112311538B - Identity verification method, device, storage medium and equipment

Info

Publication number: CN112311538B
Application number: CN202011194900.6A
Authority: CN
Inventors: 尹子栋; 孙春桂; 何江; 王丽红; 于佳良
Original assignee: Beijing Huahong Integrated Circuit Design Co ltd
Current assignee: Beijing Huahong Integrated Circuit Design Co ltd
Priority date: 2020-10-30
Filing date: 2020-10-30
Publication date: 2024-04-23
Anticipated expiration: 2040-10-30
Also published as: CN112311538A

Abstract

The application discloses an identity verification method, an identity verification device, a storage medium and equipment, wherein the identity verification method comprises the following steps: after the authorized party sends the verification request including the identity of the authorized party to the verifier, the verifier can generate a random number according to the verification request and return the random number to the authorized party. The authorized party can generate a verifiable report according to the random number and the verifiable credential data stored by the authorized party, and send the verifiable report and the identity of the authorized party stored by the authorized party to the verifying party, so that the verifying party can acquire the identity file of the authorized party from the registration system by utilizing the identity of the authorized party, verify the verifiable report according to the identity file of the authorized party, and return a verification result to the authorized party. And based on the decentralization advantage of the blockchain of the registration system and the advantage that the outside cannot be tampered, the accuracy and the reliability of the authentication result of the authorized party can be effectively improved.

Description

Identity verification method, device, storage medium and equipment

Technical Field

The present application relates to the field of data processing, and in particular, to a method, an apparatus, a storage medium, and a device for identity authentication.

Background

Currently, the identity authorization manner between an authorized party and an authorized party is generally based on a key pair manner, so as to hope to improve the security and reliability of the identity authorization. For example: for identity authorization of a user (authorized party) to a media platform (authorized party), after they issue corresponding digital certificates via a certificate authority (Certification Authority, CA), respectively, the identity relationship between them can be authorized based on the certificate authority. The certificate authority is an international generic term of the certification authority, and is an authority for issuing, managing and canceling the digital certificate by the applicant of the digital certificate.

However, in a practical scenario, the certificate authority may be attacked or manipulated maliciously, so that two parties that do not have any association relationship may be subjected to identity authorization, which results in an unreliable identity authorization relationship and thus an unreliable identity verification result of the authorized party, so that no further data processing operation can be performed on the authorized party.

Disclosure of Invention

In view of this, the embodiments of the present application provide a method, apparatus, storage medium and device for identity verification, so as to improve accuracy and reliability of an identity verification result of an authorized party.

In a first aspect, an embodiment of the present application provides a method for identity verification, which is applied to an identity authorization blockchain system including an authorized party and a verifier, where a registration system is deployed in the identity authorization blockchain system; the method comprises the following steps:

The authorized party sends a verification request to the verification party, wherein the verification request comprises the identity of the authorized party;

the verification party generates a random number according to the verification request and returns the random number to the authorized party;

The authorized party generates a verifiable report according to the random number and the verifiable credential data stored by the authorized party, and sends the verifiable report and the identity of the authorized party stored by the authorized party to the verifier;

The verification party acquires the identity file of the authorized party from the registration system by utilizing the identity of the authorized party, verifies the verifiable report according to the identity file of the authorized party, and returns a verification result to the authorized party.

In a possible implementation manner, the authorized party generates a verifiable report according to the random number and the verifiable credential data stored by the authorized party, and specifically includes:

The authorized party signs the random number by using a private key of the authorized party stored by the authorized party to obtain fourth signature data; signing the verifiable credential data by using the private key of the authorized party to obtain fifth signature data;

The authorized party generates the verifiable report by using the random number, the fourth signature data, the verifiable credential data and the fifth signature data;

the verification party verifies the verifiable report according to the identity file of the authorized party, and specifically comprises the following steps:

And the verifier acquires the public key of the authorized party from the identity file of the authorized party, and uses the public key of the authorized party to carry out signature verification on the fourth signature data and the fifth signature data respectively.

In a possible implementation manner, the signing verification is performed on the fourth signature data and the fifth signature data by using the public key of the authorized party, and specifically includes:

The verifier acquires the random number from the verifiable report, uses the public key of the authorized party and the random number to check the signature of the fourth signature data, and uses the public key of the authorized party and the verifiable credential data to check the signature of the fifth signature data if the signature check passes;

Or alternatively

And the verifier uses the public key of the authorized party and the verifiable credential data to verify the signature of the fifth signature data, and if the signature verification passes, the random number is obtained from the verifiable report, and the public key of the authorized party and the random number are used for verifying the signature of the fourth signature data.

In a possible implementation manner, after the verification party verifies the verifiable report according to the identity file of the authorized party, before the verification returns a verification result to the authorized party, the method further includes:

The verifier acquires the verifiable credential data from the verifiable report, extracts the identity of the authorizer and the identity of the verifiable credential data from the acquired verifiable credential data, and sends the identity of the authorizer and the identity of the verifiable credential data to the registration system;

The registration system checks whether the identity of the authorized party and the identity of the verifiable credential data are in a valid verifiable credential data list, and returns a valid or invalid query result of the authorized party to the verifier;

and the verification party returns the verification result to the authorized party according to the query result.

In one possible implementation, the identity authorization block chain system is provided with an authorizer; the method comprises the following steps:

The authorized party acquires declaration information of the authorized party from the registration system, requests the authorized party to carry out identity verification on the authorized party according to the identity of the authorized party stored by the authorized party, generates an identity authorization request according to the declaration information of the authorized party when the identity verification result of the authorized party on the authorized party is passed, and sends the identity authorization request to the authorized party;

The authorizer generates verifiable credential data according to the identity authorization request and sends the identification of the verifiable credential data in the verifiable credential data to the registration system;

the registration system updates according to the identification of the verifiable credential data and returns an update result to the authorized party;

the authorizer sends the verifiable credential data to the authorized party for storage by the authorized party.

In a possible implementation manner, the authorized party requests the authorized party to perform identity verification on the authorized party according to the identity of the authorized party stored in the authorized party, and specifically includes:

the authorized party generates an identity verification request according to the identity of the authorized party and sends the identity verification request to the authorized party;

the authorizing party generates a first random number and returns the first random number to the authorized party;

The authorized party signs the first random number according to a private key of the authorized party stored by the authorized party to obtain a first signature result, and sends the first signature result, the first random number and the identity of the authorized party to the authorized party;

The authorized party obtains an identity file of the authorized party from the registration system according to the identity of the authorized party, obtains a public key of the authorized party from the identity file of the authorized party, and uses the obtained public key of the authorized party and the first random number to check the first signature result.

In a possible implementation manner, the authorized party obtains the statement information of the authorized party from the registration system, and specifically includes:

The authorized party obtains the identity of the authorized party and sends the identity of the authorized party to the registration system;

And the registration system searches a statement template list bound with the authorized party according to the identity of the authorized party and sends the statement template list to the authorized party.

In a possible implementation manner, the authorized party generates an identity authorization request according to the statement information of the authorized party, specifically:

The authorized party selects a required declaration template from a declaration template list of the authorized party, generates declaration data of the authorized party according to the selected declaration template, and generates the identity authorization request according to the declaration data of the authorized party.

In a possible implementation manner, after the authorized party obtains the statement information of the authorized party, the method further includes: the authorized party generates declaration data of the authorized party according to the declaration information of the authorized party; the identity authorization request comprises declaration data of the authorized party;

the authorizing party generates verifiable credential data, which specifically comprises:

The authorizer generates the identifier of the verifiable credential data according to a preset rule, and signs the declaration data of the authorized party by using a private key of the authorizer stored by the authorizer to obtain the signature of the declaration data of the authorized party;

The authorizer generates the verifiable credential data based on the authorizer claim data, a signature of the authorizer claim data, and an identification of the verifiable credential data.

In a possible implementation manner, before the authorizing party sends the identifier of the verifiable credential data to the registration system, the method further includes:

The authorizer signs the identification of the verifiable credential data by using a private key of the authorizer to obtain a signature of the verifiable credential data identification;

Before the registration system updates according to the identifier of the verifiable credential data, the registration system further comprises: the authorizing party sends the signature of the verifiable credential data identifier and the identity of the authorizing party to the registration system;

the registration system finds the public key of the corresponding authorizing party according to the identity of the authorizing party, and uses the public key of the authorizing party and the identifier of the verifiable credential data to check the signature of the verifiable credential data identifier.

In a possible implementation manner, the registration system updates according to the identifier of the verifiable credential data, specifically: when the signature verification result is that the signature passes, the registration system adds the identification of the verifiable credential data to a verifiable credential data list of the authorized party.

In a possible implementation manner, the authorizing party sends the verifiable credential data to the authorized party so that the authorized party can store the verifiable credential data, including:

The authorizer sends the verifiable credential data and the identity of the authorizer to the authorized party;

the authorized party sends a query request to the registration system according to the identification of the verifiable credential data and the identification of the authorized party;

The registration system searches whether the identifier of the verifiable credential data of the authorizer exists in a verifiable credential data list of the authorizer according to the identity of the authorizer, if so, the registration system indicates that the identifier of the verifiable credential data is valid, and returns a query result and an identity file of the authorizer corresponding to the identity of the authorizer to the authorized party;

And the authorized party verifies the verifiable credential data according to the identity file of the authorized party, and if the verification is passed, the verifiable credential data is confirmed to be legal and stored.

In a possible implementation manner, the authenticatable credential data is authenticated by the authorized party according to the identity file of the authorized party, and specifically includes:

The authorized party obtains the public key of the authorized party from the identity file of the authorized party, and the public key of the authorized party and the authorized party statement data in the verifiable credential data are used for checking the signature of the authorized party statement data in the verifiable credential data.

The authorizer signs the verifiable credential data by using a private key and sends the signed verifiable credential data to the authorized party;

the authorized party sends an entity identity inquiry request to the registration system;

the registration system returns the identity file of the entity stored in advance to the authorized party;

the authorized party utilizes the identity file of the entity to check the signed verifiable credential data, and if the check is successful, the verifiable credential data is confirmed to be legal;

And the authorized party sends a result of confirming that the verifiable credential data is legal to the registration system for inquiry, and if the registration system inquires that the verifiable credential data is valid, the inquiry result is returned to the authorized party so that the authorized party can store the verifiable credential data.

In a possible implementation manner, before the authorized party sends an identity authorization request to the authorized party according to the statement information of the authorized party, the method further includes:

The authorized Fang Shengcheng second random number; the identity authorization request also comprises the second random number;

The authorizing party sends the verifiable credential data to the authorized party so that the authorized party can store the verifiable credential data, which specifically comprises:

The authorizer generates a third random number, and generates authentication data and encryption data of the verifiable credential data according to the second random number, the third random number and the verifiable credential data; transmitting the identity verification data, the encryption data of the verifiable credential data and the self-saved identity of the authorized party to the authorized party;

The authorized party acquires an identity file of the authorized party from the registration system according to the identity of the authorized party; and verifying the identity verification data according to the identity file of the authorized party, decrypting the encrypted data of the verifiable credential data to obtain the verifiable credential data after verification, and storing the decrypted verifiable credential data.

In a possible implementation manner, the authorizing party generates authentication data and encryption data of the verifiable credential data according to the second random number, the third random number and the verifiable credential data, and specifically includes: the authorizing party encrypts the third random number by using a public key of the authorized party, which is obtained when the authorizing party performs identity verification on the authorized party, so as to obtain encrypted data of the third random number;

The authorizing party signs the third random number by using the private key of the authorizing party stored by the authorizing party to obtain the signature of the third random number;

And the authorizer generates a first session key according to the second random number and the third random number, and encrypts the verifiable credential data by using the first session key to obtain encrypted data of the verifiable credential data.

In a possible implementation manner, the authorized party verifies the identity verification data according to the identity file of the authorized party, and specifically includes:

The authorized party obtains the public key of the authorized party from the identity file of the authorized party, and decrypts the encrypted data of the third random number by using the private key of the authorized party stored by the authorized party to obtain first decrypted data;

The authorized party uses the public key of the authorized party and the first decryption data to check the signature of the third random number.

In a possible implementation manner, the authorized party decrypts the encrypted data of the verifiable credential data to obtain the verifiable credential data, and stores the decrypted verifiable credential data, which specifically includes:

If the signature verification is successful, the authorized party generates a second session key according to the second random number and the first decryption data;

The authorized party uses the second session key to decrypt the encrypted data of the verifiable credential data to obtain the verifiable credential data, extracts the declaration data of the authorized party and the declaration data signature of the authorized party from the verifiable credential data, uses the public key of the authorized party and the extracted declaration data of the authorized party to check the signature of the declaration data of the authorized party, and stores the verifiable credential data if the check passes.

In a possible implementation manner, before the authenticatable credential data is stored by the authorized party, the method further includes:

The authorized party sends the identification of the verifiable credential data in the verifiable credential data to the registration system, and the registration system checks whether the identification of the verifiable credential data is valid or not;

and when the verification result is that the identification of the verifiable credential data is valid and the verification result of the authorized party on the identity verification data is passing, the authorized party stores the verifiable credential data.

In a possible implementation manner, before the authorizer generates verifiable credential data according to the identity authorization request, the method further includes:

and the authorized party performs auditing according to the identity authorization request sent by the authorized party.

In a possible implementation manner, the target party is the authorized party or the authorized party; the method further comprises the steps of:

The target party generates a corresponding identity mark and an identity file, and performs identity registration to the registration system according to the identity mark and the identity file; the identity file comprises a corresponding signature verification public key;

and the registration system carries out auditing on the identity mark and the identity file, and if the identity mark and the identity file pass the auditing, the target party is determined to finish identity registration, and the identity file corresponding to the target party is stored.

In a possible implementation manner, the generating, by the target, a corresponding identity identifier and an identity file includes:

The target party obtains the current time and sets a key pair type, and generates a public key and a private key according to the current time and the key pair type;

carrying out hash operation on the public key to obtain a corresponding hash value, and taking the hash value as an identity of the target party;

And generating an identity file of the target party according to the identity mark and the public key.

In a possible implementation manner, the registering the identity with the registration system according to the identity identifier and the identity file includes: the target party sends the identity mark and the identity file to a registration system;

the registration system performs auditing on the identity mark and the identity file, and the method comprises the following steps:

The registration system determines whether the identity is in the stored identity set, and if not, sends a random identity to the target party.

In a possible implementation manner, after the sending of the random identifier to the target party, the method further includes:

The target receives the random identifier, and signs the random identifier by using the private key to obtain first signature data;

The target party sends the identity file, the random identifier and the first signature data to the registration system;

and the registration system carries out signature verification on the first signature data according to the identity file, and if the signature verification passes, the registration system determines that the target party completes identity registration and stores the identity file corresponding to the target party.

In a possible implementation manner, after the target party generates the identity file, the method further includes: the target party stores the identity file;

After the determining that the target party completes identity registration, the method further comprises the following steps:

The registration system sends the inquiry address of the identity mark to the target party;

and the target updates the identity file according to the query address of the identity mark.

In a possible implementation manner, when the target party is the authorized party, the method further includes:

the authorizer generates authorizer identity data, and signs the identity data by using the private key to obtain second signature data; the identity data of the authorizer is data showing that the authorizer has identity authorization authority;

the authorized party sends the identity file, the identity data and the second signature data to the registration system;

The registration system verifies the second signature data according to the identity file, if the second signature data passes the verification, the identity authorization authority qualification of the authorizer is granted, the identity authorization authority qualification is stored in the identity file stored by the registration system, and the registration state and the identity inquiry address of the authorizer are sent to the authorizer;

and the authorized party updates the identity inquiry address into an identity file stored by the authorized party.

In a possible implementation manner, the method further includes:

the authorized party generates declaration information, and signs a declaration template inquiry address in the declaration information by using the private key to obtain third signature data; the declaration information comprises a declaration template and a declaration template query address;

The authorized party sends the identity file and the statement template query address in the statement information and the third signature data to the registration system;

The registration system verifies the third signature data according to the identity file stored by the registration system, if the third signature data passes the verification, the declaration information is stored in the identity file stored by the registration system, and a new result of the declaration information is returned to the target party;

and the target updates the query address of the statement template into the identity file stored by the target.

In a possible implementation manner, before the authorized party sends the identity authorization request to the authorized party, the method further includes: the authorized party sets a security identifier, and the type of the security identifier is set as plaintext feedback or ciphertext feedback; the identity authorization request also comprises the security identifier;

before the authorizer sends the verifiable credential data to the authorized party, the method further comprises: the authorized party judges the type of the security identifier, and when the type of the security identifier is plaintext return, plaintext data of the verifiable credential data is sent to the authorized party; and when the type of the security identifier is ciphertext feedback, sending ciphertext data of the verifiable credential data to the authorized party.

In a second aspect, an embodiment of the present application provides an apparatus for identity verification, which is applied to an identity authorization blockchain system including an authorizer and an authorized party, where a registration system is deployed in the identity authorization blockchain system; the device comprises:

the authorized party is used for sending a verification request to the verification party, and the verification request comprises the identity of the authorized party;

the verifier is used for generating a random number according to the verification request and returning the random number to the authorized party;

The authorized party is also used for generating a verifiable report according to the random number and the verifiable credential data stored by the authorized party, and sending the verifiable report and the identity of the authorized party stored by the authorized party to the verifier;

The verification party is further configured to obtain an identity file of the authorized party from the registration system by using the identity of the authorized party, verify the verifiable report according to the identity file of the authorized party, and return a verification result to the authorized party.

In a possible implementation manner, the authorized party is specifically configured to

Signing the random number by using a private key of an authorized party stored in the random number to obtain fourth signature data; signing the verifiable credential data by using the private key of the authorized party to obtain fifth signature data;

generating the verifiable report using the random number, the fourth signature data, the verifiable credential data, and the fifth signature data;

The verification party is specifically configured to:

and acquiring the public key of the authorized party from the identity file of the authorized party, and respectively checking the fourth signature data and the fifth signature data by using the public key of the authorized party.

In a possible implementation manner, the verification party is specifically configured to:

Acquiring the random number from the verifiable report, checking the signature of the fourth signature data by using the public key of the authorized party and the random number, and checking the signature by using the public key of the authorized party and the verifiable credential data;

Or alternatively

And verifying the fifth signature data by using the public key of the authorized party and the verifiable credential data, if the verification passes, acquiring the random number from the verifiable report, and verifying the fourth signature data by using the public key of the authorized party and the random number.

In a possible implementation manner, the verifier is further configured to:

acquiring the verifiable credential data from the verifiable report, extracting the identity of the authorizer and the identity of the verifiable credential data from the acquired verifiable credential data, and sending the identity of the authorizer and the identity of the verifiable credential data to the registration system;

The registration system is further configured to: checking whether the identity of the authorized party and the identity of the verifiable credential data are in a valid verifiable credential data list, and returning a valid or invalid query result of the authorized party to the verifier;

the verifier is also configured to: and returning the verification result to the authorized party according to the query result.

In one possible implementation, the identity authorization block chain system is provided with an authorizer; the apparatus further comprises:

The authorized party is used for acquiring the declaration information of the authorized party from the registration system, requesting the authorized party to carry out identity verification on the authorized party according to the identity of the authorized party stored by the authorized party, generating an identity authorization request according to the declaration information of the authorized party when the identity verification result of the authorized party on the authorized party is passed, and sending the identity authorization request to the authorized party;

The authorizer is used for generating verifiable credential data according to the identity authorization request and sending the identification of the verifiable credential data in the verifiable credential data to the registration system;

The registration system is used for updating according to the identification of the verifiable credential data and returning an updating result to the authorized party;

the authorizing party is further configured to send the verifiable credential data to the authorized party for storage by the authorized party.

In a possible implementation manner, the authorized party is specifically configured to:

generating an identity verification request according to the identity of the authorized party, and sending the identity verification request to the authorized party;

The authorizer is specifically configured to:

Generating a first random number and returning the first random number to the authorized party;

The authorized party is also specifically configured to:

signing the first random number according to a private key of an authorized party stored by the self to obtain a first signature result, and sending the first signature result, the first random number and the identity of the authorized party to the authorized party;

the authorizer is also specifically configured to:

And acquiring the identity file of the authorized party from the registration system according to the identity of the authorized party, acquiring the public key of the authorized party from the identity file of the authorized party, and checking the first signature result by using the acquired public key of the authorized party and the first random number.

Acquiring the identity of the authorized party and sending the identity of the authorized party to the registration system;

The registration system is specifically configured to:

And searching a statement template list bound with the authorized party according to the identity of the authorized party, and sending the statement template list to the authorized party.

And selecting a required declaration template from the declaration template list of the authorized party, generating declaration data of the authorized party according to the selected declaration template, and generating the identity authorization request according to the declaration data of the authorized party.

In a possible implementation manner, the authorized party is further configured to generate declaration data of the authorized party according to the declaration information of the authorized party; the identity authorization request comprises declaration data of the authorized party;

The authorizer is specifically configured to:

generating the identification of the verifiable credential data according to a preset rule, and signing the declaration data of the authorized party by using a private key of the authorized party stored by the user to obtain a signature of the declaration data of the authorized party;

generating the verifiable credential data based on the authorized party claim data, the signature of the authorized party claim data, and the identification of the verifiable credential data.

In a possible implementation manner, the authorizer is further configured to:

signing the identification of the verifiable credential data by using the private key of the authorizer to obtain a signature of the verifiable credential data identification;

The signature of the verifiable credential data identification and the identity identification of the authorized party are sent to the registration system;

The registration system is specifically configured to:

and finding a public key of a corresponding authorizing party according to the identity of the authorizing party, and checking the signature of the verifiable credential data identifier by using the public key of the authorizing party and the identifier of the verifiable credential data.

In a possible implementation manner, when the verification result is that the verification result is pass, the registration system is specifically configured to add the identifier of the verifiable credential data to a verifiable credential data list of the authorized party.

In a possible implementation manner, the authorizing party is specifically configured to:

transmitting the verifiable credential data and the identity of the authorizer to the authorized party;

sending a query request to the registration system according to the identification of the verifiable credential data and the identity of the authorizing party;

The registration system is specifically configured to:

Searching whether the identifier of the verifiable credential data of the authorizer exists in a verifiable credential data list of the authorizer according to the identity of the authorizer, if so, indicating that the identifier of the verifiable credential data is valid, and returning a query result and an identity file of the authorizer corresponding to the identity of the authorizer to the authorized party;

The authorized party is also specifically configured to:

And verifying the verifiable credential data according to the identity file of the authorized party, and if the verification is passed, confirming that the verifiable credential data is legal and storing the same.

In a possible implementation manner, the authorized party is specifically configured to: a step of

And acquiring a public key of the authorizer from the identity file of the authorizer, and checking the signature of the authorized party statement data in the verifiable credential data by using the public key of the authorizer and the authorized party statement data in the verifiable credential data.

Signing the verifiable credential data by using a private key, and sending the signed verifiable credential data to the authorized party;

sending an entity identity inquiry request to the registration system;

The registration system is specifically configured to:

Returning the identity file of the pre-stored entity to the authorized party;

The authorized party is also specifically configured to:

verifying the signed verifiable credential data by using the identity file of the entity, and if verification is successful, confirming that the verifiable credential data is legal;

And sending a result of confirming that the verifiable credential data is legal to the registration system for inquiry, and if the registration system inquires that the verifiable credential data is valid, returning the inquiry result to the authorized party so that the authorized party stores the verifiable credential data.

In a possible implementation manner, the authorized party is further configured to:

Generating a second random number; the identity authorization request also comprises the second random number;

The authorizer is specifically for:

generating a third random number, and generating authentication data and encryption data of the verifiable credential data according to the second random number, the third random number and the verifiable credential data; transmitting the identity verification data, the encryption data of the verifiable credential data and the self-saved identity of the authorized party to the authorized party;

The authorized party is further configured to: acquiring an identity file of the authorizing party from the registration system according to the identity of the authorizing party; and verifying the identity verification data according to the identity file of the authorized party, decrypting the encrypted data of the verifiable credential data to obtain the verifiable credential data after verification, and storing the decrypted verifiable credential data.

Encrypting the third random number by using a public key of the authorized party, which is obtained when the authorized party performs identity verification on the authorized party, so as to obtain encrypted data of the third random number;

Signing the third random number by using an authorized party private key stored by the user to obtain a signature of the third random number;

And generating a first session key according to the second random number and the third random number, and encrypting the verifiable credential data by using the first session key to obtain encrypted data of the verifiable credential data.

obtaining a public key of an authorizing party from the identity file of the authorizing party, and decrypting the encrypted data of the third random number by using a private key of the authorized party stored by the authorizing party to obtain first decrypted data;

and signing the signature of the third random number by using the public key of the authorized party and the first decryption data.

if the signature verification is successful, generating a second session key according to the second random number and the first decryption data;

Decrypting the encrypted data of the verifiable credential data by using the second session key to obtain the verifiable credential data, extracting the declaration data of the authorized party and the declaration data signature of the authorized party from the verifiable credential data, checking the signature of the declaration data of the authorized party by using the public key of the authorized party and the extracted declaration data of the authorized party, and if the checking passes, storing the verifiable credential data.

Transmitting the identification of the verifiable credential data in the verifiable credential data to the registration system, and checking whether the identification of the verifiable credential data is valid or not by the registration system;

and when the verification result is that the identification of the verifiable credential data is effective and the verification result of the authorized party on the identity verification data is passing, storing the verifiable credential data.

In a possible implementation manner, the authorizer is further configured to:

And auditing according to the identity authorization request sent by the authorized party.

In a possible implementation manner, the target party is the authorized party or the authorized party; the target party is specifically configured to:

Generating a corresponding identity mark and an identity file, and registering the identity of the registration system according to the identity mark and the identity file; the identity file comprises a corresponding signature verification public key;

The registration system is specifically configured to: and checking the identity mark and the identity file, and if the identity mark and the identity file pass the checking, determining that the target party completes identity registration and storing the identity file corresponding to the target party.

In a possible implementation manner, the target party is specifically configured to:

acquiring current time, setting a key pair type, and generating a public key and a private key according to the current time and the key pair type;

The identity mark and the identity file are sent to a registration system;

the registration system is specifically configured to: and determining whether the identity mark exists in the stored identity mark set, and if not, sending a random mark to the target party.

In a possible implementation manner, the target party is further configured to:

Receiving the random identifier, and signing the random identifier by utilizing the private key to obtain first signature data;

transmitting the identity file and the random identification as well as the first signature data to the registration system;

The registration system is further configured to: and checking the signature of the first signature data according to the identity file, and if the signature passes, determining that the target party completes identity registration and storing the identity file corresponding to the target party.

In a possible implementation manner, the target party is further configured to:

storing the identity file;

the registration system is further configured to: sending the inquiry address of the identity mark to the target party;

the target is also configured to: and updating the identity file according to the query address of the identity mark.

In a possible implementation manner, when the target party is the authorized party, the authorized party is further configured to:

generating identity data of an authorized party, and signing the identity data by utilizing the private key to obtain second signature data; the identity data of the authorizer is data showing that the authorizer has identity authorization authority;

transmitting the identity file and the identity data and the second signature data to the registration system;

the registration system is further configured to: verifying the second signature data according to the identity file, if the second signature data passes the verification, granting the identity authorization authority qualification of the authorizer, storing the identity authorization authority qualification into the identity file stored by the authorizer, and sending the registration state and the identity inquiry address of the authorizer to the authorizer;

The authorizer is further to: and updating the identity inquiry address into the identity file stored by the user.

In a possible implementation manner, the authorizer is further configured to:

Generating declaration information, and signing a declaration template query address in the declaration information by using the private key to obtain third signature data; the declaration information comprises a declaration template and a declaration template query address;

Sending the declaration template query address in the identity file and the declaration information and the third signature data to the registration system;

The registration system is further configured to: verifying the third signature data according to the identity file stored by the target party, if the third signature data passes the verification, storing the declaration information in the identity file stored by the target party, and returning a new result of the declaration information to the target party;

The target is also configured to: and updating the query address of the statement template into the identity file stored by the query address.

Setting a security identifier, and setting the type of the security identifier as plaintext feedback or ciphertext feedback; the identity authorization request also comprises the security identifier;

judging the type of the security identifier, and when the type of the security identifier is plaintext return, transmitting plaintext data of the verifiable credential data to the authorized party; and when the type of the security identifier is ciphertext feedback, sending ciphertext data of the verifiable credential data to the authorized party.

From this, the embodiment of the application has the following beneficial effects:

According to the technical scheme, the identity authorization block chain system for identity verification comprises a registered authorized party and a verifier, and the registration system is deployed in the identity authorization block chain system; after the authorized party sends the verification request including the identity of the authorized party to the verifier, the verifier can generate a random number according to the verification request and return the random number to the authorized party. The authorized party can generate a verifiable report according to the random number and the verifiable credential data stored by the authorized party, and send the verifiable report and the identity of the authorized party stored by the authorized party to the verifying party, so that the verifying party can acquire the identity file of the authorized party from the registration system by utilizing the identity of the authorized party, verify the verifiable report according to the identity file of the authorized party, and return a verification result to the authorized party. And based on the decentralization advantage of the blockchain of the registration system and the advantage that the outside cannot be tampered, the accuracy and the reliability of the authentication result of the authorized party can be effectively improved.

Drawings

In order to more clearly illustrate the embodiments of the application or the technical solutions of the prior art, the drawings which are used in the description of the embodiments or the prior art will be briefly described, it being obvious that the drawings in the description below are only some embodiments of the application, and that other drawings can be obtained according to these drawings without inventive faculty for a person skilled in the art.

FIG. 1 is a flow chart of a method for identity verification according to an embodiment of the present application;

FIG. 2 is a flowchart of an identity authorization method according to an embodiment of the present application;

fig. 3 is a signaling interaction example diagram of an identity registration stage according to an embodiment of the present application;

FIG. 4 is a signaling interaction example diagram of identity registration of an authorized party according to an embodiment of the present application;

FIG. 5 is a diagram illustrating signaling interactions of adding declaration templates provided by embodiments of the present application;

fig. 6 is a block diagram of an apparatus for authentication according to an embodiment of the present application.

Detailed Description

Embodiments of the present application are described below with reference to the accompanying drawings.

Currently, a certificate authority for performing identity authorization may be attacked or manipulated maliciously, so that two parties which do not have any association relationship may perform identity authorization, which results in an unreliable identity authorization relationship and thus an unreliable identity verification result of an authorized party, and thus subsequent data processing operation cannot be performed on the authorized party.

Therefore, the embodiment of the application provides an identity verification system, which is based on the decentralization advantage of the blockchain and the advantage that the outside cannot be tampered, and effectively improves the accuracy and reliability of the identity verification result of the authorized party. The identity authorization system provided by the embodiment of the application is described next.

Referring to fig. 1, a flowchart of a method of identity verification provided by an embodiment of the present application is shown, and as shown in fig. 1, the identity authorization blockchain system includes a registered authorized party (Holder), a registration system, and a Verifier. The authorized party may be any type of Entity device (Entity), such as a person, a device, or a virtual website. For example, the authorized party may be a user, a cell phone, an internet of things device, etc. The Verifier (Verifier) refers to an Entity for verifying verifiable credential data (Verifiable Credential, VC for short), and may be any type of Entity device (Entity), be it a person, a device, or a virtual website. For example, the verifier may be a service provider or the like. The identity of the authorized party can be verified by using the verifier and the registration system.

The registration system may be an intelligent contract deployed in an identity authorization blockchain system or other control systems, and it should be noted that, in the subsequent embodiments of the present application, the registration system is described by taking the registration system as an intelligent contract example, and the implementation manner of other control systems may refer to the implementation process of the intelligent contract, and other implementation processes are not described in detail. Intelligent contracts, among other things, refer to a computer protocol that, once formulated and deployed, enables self-execution (self-executing) and self-verification (self-verifying) without human intervention. Smart contracts allow trusted transactions to be made without third parties, which transactions are traceable and irreversible. Through the advantages of automation of intelligent contracts and incapability of being tampered by the outside, the accuracy and reliability of the authentication result of the authorized party are improved.

In the embodiment of the application, the method for carrying out identity verification comprises the following steps:

s101: the authorized party sends an authentication request to the authentication party, wherein the authentication request comprises the identity of the authorized party.

S102: the verifier generates a random number (nonce) from the verification request and returns the random number (nonce) to the authorized party.

S103: the authorized party generates a verifiable report (Verifiable Presentation, abbreviated as VP) from the random number (nonce) and the self-saved verifiable credential data, and sends the verifiable report, the self-saved identity of the authorized party (which may be defined herein as did_h), to the verifier.

Wherein, the verifiable credential data (VC) stored by the authorized party is obtained and stored through the following steps S201-S204, and the specific acquisition process can be seen from the detailed description of the following steps S201-S204.

Specifically, in one possible implementation, the "authenticated party generates an authenticatable report (VP) according to a random number (nonce) and authenticatable credential data (VC) stored in itself" implementation procedure in this step S103 includes the following steps S1031-S1032:

Step S1031: the authorized party signs the random number (nonce) using its own stored private key of the authorized party, resulting in signature data (which is defined herein as fourth signature data). And signs the verifiable credential data (VC) using the private key of the authorized party, resulting in signed data (which is defined herein as fifth signed data).

Step S1032: the authorized party generates a verifiable report using the random number (nonce), the fourth signature data, the verifiable credential data (VC), and the fifth signature data.

S104: the verifier obtains an identity Document (DID Document) of the authorized party from a registration system (namely an intelligent contract) by using the identity (DID_H) of the authorized party, verifies the verifiable report (VP) according to the identity Document (DID Document) of the authorized party, and returns a verification result to the authorized party so as to realize the identity verification of the authorized party.

It should be noted that, in one possible implementation manner, after the verifiable report (VP) is generated through the steps S1031-S1032, the specific implementation process of the verification party in the step M4 for verifying the verifiable report (VP) according to the identity file (DID Document) of the authorized party is as follows: the verifier obtains the public key of the authorized party from the identity Document (DID Document) of the authorized party, and uses the public key of the authorized party to respectively verify the obtained fourth signature data and fifth signature data. The specific signature verification process comprises the following two implementation modes:

One way is that the verifier may first obtain a random number (nonce) from the verifiable report (VP), then sign the fourth signature data using the public key of the authorized party and the random number (nonce), and when the sign passes, sign the fifth signature data using the public key of the authorized party and the verifiable credential data (VC).

Another way is that the verifier may first verify the fifth signature data using the public key of the authorized party and the verifiable credential data (VC), and then when the verification passes, a random number (nonce) may be obtained from the verifiable report (VP) and the fourth signature data may be verified using the public key of the authorized party and the random number (nonce).

It should be noted that, in order to improve accuracy of the authentication result of the authorized party, in executing the step S104, after the authenticatable report (VP) is authenticated by the authenticating party according to the identity file (DID Document) of the authorized party, the following steps (1) - (3) may be executed first, and then a more accurate authentication result may be returned to the authorized party.

Step (1): the verifier acquires verifiable credential data (VC) from the verifiable report (VP), extracts the identity (did_h) of the authorizer and the identity (vc_id) of the verifiable credential data from the acquired verifiable credential data (VC), and then may send the identity (did_h) of the authorizer and the identity (vc_id) of the verifiable credential data to the registration system (i.e., the smart contract) for execution of the subsequent step (2).

Step (2): the registration system (i.e., the smart contract) checks whether the identity (did_h) of the authorized party and the identity (vc_id) of the verifiable credential data are in the list of valid verifiable credential data, and returns a query result to the verifier that the authorized party is valid or invalid, i.e., a query result to the verifier that indicates that the identity (vc_id) of the verifiable credential data of the authorized party is valid or invalid.

Step (3): after receiving a query result returned by the registration system (i.e., the intelligent contract) and indicating that the identifier (vc_id) of the verifiable credential data of the authorized party is valid or invalid, if the identifier (vc_id) of the verifiable credential data of the authorized party is judged to be valid, the verifying party can return a verification result for verifying the verifiable report (VP), namely, pass the verification of the authorized identity, to the authorized party, so as to complete the verification of the VP. However, if it is determined that the identifier (vc_id) of the verifiable credential data of the authorized party is invalid, a verification result for verifying the verifiable report (VP) is not returned to the authorized party, i.e., the authorized identity verification is not passed.

In summary, in the method for identity verification provided in this embodiment, an identity authorization block chain system for identity verification includes a registered authorized party and a verifier, where a registration system is disposed in the identity authorization block chain system; after the authorized party sends the verification request including the identity of the authorized party to the verifier, the verifier can generate a random number according to the verification request and return the random number to the authorized party. The authorized party can generate a verifiable report according to the random number and the verifiable credential data stored by the authorized party, and send the verifiable report and the identity of the authorized party stored by the authorized party to the verifying party, so that the verifying party can acquire the identity file of the authorized party from the registration system by utilizing the identity of the authorized party, verify the verifiable report according to the identity file of the authorized party, and return a verification result to the authorized party. And based on the decentralization advantage of the blockchain of the registration system and the advantage that the outside cannot be tampered, the accuracy and the reliability of the authentication result of the authorized party can be effectively improved.

Next, the embodiment of the present application will describe in detail a process of generating verifiable credential data (VC) corresponding to an authorized party:

In order to generate verifiable credential data (VC) corresponding to an authorized party, identity authorization of the authorized party is achieved. The authorizer is first deployed in an identity authorization blockchain system. Referring to fig. 2, a flowchart of an identity authorization method provided by an embodiment of the present application is shown, and as shown in fig. 2, the identity authorization blockchain system includes a registered authorizer (Issuer), an authorized party (Holder), and a registration system. The authorizer may authorize the authorized party, and the authorizer may be any type of Entity device (Entity), be it a person, a device, or a virtual website. For example, the authorizer may be a service provider or a device manufacturer, etc. Therefore, verifiable credential data (VC) corresponding to the authorized party can be generated based on the decentralization advantage of the blockchain and the advantage that the outside cannot be tampered, and the safety and reliability of identity authorization between the authorized party and the authorized party are effectively improved.

In the embodiment of the application, the method for carrying out the identity authorization of the authorized party comprises the following steps:

S201: the authorized party acquires declaration information of the authorized party from the registration system, requests the authorized party to carry out identity verification on the authorized party according to the identity identification of the authorized party stored by the authorized party, generates an identity authorization request according to the declaration information of the authorized party when the identity verification result of the authorized party on the authorized party is passed, and sends the identity authorization request to the authorized party.

Wherein the declaration information of the authorizer may be used to identify the identity of the authorizer.

For example, for a producer where the authorizer is an authorized party, the identity Claim (Claim) of the authorizer may include the authorizer generating production specification information for the authorized party device, i.e., the identity Claim identifies the identity of the authorizer.

In some possible implementations of the embodiments of the present application, the implementation process of "the authorized party obtains the declaration information of the authorized party from the registration system" in the present step S201 includes the following steps A1-A2:

step A1: the authorized party obtains the identity of the authorized party and sends the identity of the authorized party to the registration system.

It should be noted that, the authorized party typically discloses the corresponding identity identifier (Decentralized Identifier, abbreviated as DID) information of itself through a public channel (such as an official website), which is defined as did_i herein. In order to obtain the declaration information of the authorizer, the authorized party first needs to obtain the identity (did_i) of the authorizer through the above public channel, and then can send the identity (did_i) of the authorizer to the registration system (i.e., the smart contract).

Step A2: the registration system retrieves the list of claim templates bound with the authorizing party according to the identity of the authorizing party and sends the list of claim templates to the authorized party.

After the authorized party sends the identity (did_i) of the authorized party to the registration system (i.e., the smart contract) through step A1, the registration system (i.e., the smart contract) retrieves the statement template list bound with the authorized party according to the identity (did_i) corresponding to the authorized party, and sends the statement template list to the authorized party.

Furthermore, after receiving the declaration template list bound with the authorized party, the authorized party can request the authorized party to verify the authorized party according to the identity (DID_H) of the authorized party stored by the authorized party, and the specific verification process comprises the following steps of:

step B1: the authorized party generates an identity verification request according to the identity of the authorized party and sends the identity verification request to the authorized party.

Step B2: the authorizer generates a first random number and returns the first random number to the authorized party.

After receiving the authentication request sent by the authorized party, the authorized party first generates a first random number (which may be defined herein as r 1), and then returns the first random number (r 1) to the authorized party

Step B3: the authorized party signs the first random number (r 1) according to the private key of the authorized party stored by the authorized party to obtain a first signature result, and sends the first signature result, the first random number and the identity (DID_H) of the authorized party to the authorized party.

Step B4: the authorized party obtains an identity file (DID Document) of the authorized party from a registration system (namely an intelligent contract) according to the identity (DID_H) of the authorized party, and obtains a public key of the authorized party from the identity file (DID Document) of the authorized party, so that the obtained public key of the authorized party and a first random number (r 1) can be used for checking and signing the received first signature result.

Thus, when the authorizer performs signature verification on the received first signature result, the obtained signature verification result indicates that the authentication result of the authorizer passes, an identity authorization request can be generated according to the declaration information of the authorizer, and the identity authorization request can be sent to the authorizer. The specific process of generating the identity authorization request is as follows: the authorized party selects a desired claims template from the list of claims templates for the authorized party, generates claims data (which may be defined herein as class H) for the authorized party based on the selected claims template, and generates an identity authorization request based on the claims data for the authorized party. And sends it to the authorizing party to request an identity authorization for it.

S202: the authorizer generates verifiable credential data according to the identity authorization request and sends the identification of the verifiable credential data in the verifiable credential data to the registration system.

In this embodiment, after receiving the identity authorization request sent by the authorized party, the authorized party may further generate verifiable credential data according to the identity authorization request. The verifiable credential data may be data generated when the authorizer authorizes the authorized party, and may be used to embody the identity authorization of the authorizer to the authorized party. In one possible implementation, the verifiable credential data includes a verifiable credential (Verifiable Credential, VC) or a verifiable credential identification. The verifiable credential may be obtained by the authorizer according to the declaration information of the authorizer, and the verifiable credential identifier may be generated by the authorizer in a preset identifier generation manner (a manner for generating corresponding verifiable credential identifiers for different authorizers) such as a random number generation manner.

The manner in which the verifiable credential is generated is described below.

Specifically, in one possible implementation, after the authorized party obtains the declaration information of the authorized party, the authorized party may generate declaration data of the authorized party according to the declaration information of the authorized party; and, the claims data of the authorized party can be included in the identity authorization request. Thus, a specific implementation of the authorizer to generate verifiable credential data may include the following steps C1-C2:

Step C1: the authorized party generates an identifier capable of verifying the credential data according to a preset rule, and signs the declaration data of the authorized party by using a private key of the authorized party stored by the authorized party to obtain a signature of the declaration data of the authorized party.

Step C2: the authorizer generates the verifiable credential data based on the authorizer claim data, the signature of the authorizer claim data, and the identification of the verifiable credential data.

Specifically, the authorizer may generate a verifiable credential identifier, vc_id, through a preset rule, and sign the self-declaration information included in the identity authorization request sent by the authorizer by using a private key stored by the authorizer itself, to obtain a signature of the authorizer declaration data (defined as sign_class herein). The verifiable credential data may in turn be generated from the authorized party claim data, the signature of the authorized party claim data (sign_clamp), and the identity of the verifiable credential data (vc_id). The verifiable credential (hereinafter referred to as VC) can be obtained by combining and arranging the signature of the declaration data and the verifiable credential identification.

It should be noted that, in practical applications, only the verifiable credential identifier (i.e. vc_id) in the verifiable credential data is generally uploaded to the blockchain smart contract after being signed by the authorized party, so as to execute the subsequent step S103. The VC_ID is contained in the VC data, and the whole VC data is signed by an authorized party and then sent to an authorized party, so that the VC_ID has tamper-proof property and can replace the whole VC data.

It should be noted that, after receiving the identity authorization request sent by the authorized party, the authorized party needs to perform an audit according to the identity authorization request sent by the authorized party before generating verifiable credential data according to the identity authorization request. For example, some personal real-name information or social attribute information of the authorized party, such as name, identification card number, business license and the like, need to be checked to ensure that the authorized party is legal, so that the subsequent identity authorization operation steps can be continued, and the safety and reliability of the identity authorization between the authorized party and the authorized party are further improved.

In particular implementations, the VC is issued by an authorizing party, such as an organization or organization, is an authentication of a statement provided by an authorized party that the authorizing party can use at an associated application such that a service provider other than the authorizing party can verify the VC presented by the authorized party through an API.

The basic composition of VC may include: credential metadata (CREDENTIAL METADATA), claims, evidence (Proofs). CREDENTIAL METADATA are some of the attributes of the VC, such as Issuer, timestamp, etc., and are signed by Issuer. Claims: different CLAIM TYPE may have different fields, as defined by Issuer, and a VC may contain one or a group of clais. Proos is typically a digital signature of Issuers. In addition, each VC may also have a corresponding identification code (Identifier).

For example, the following is an example of a VC:

/>

s203: the registration system updates according to the identification of the verifiable credential data and returns an update result to the authorized party.

The authorization party sends the verifiable credential data to the intelligent contract (i.e. the registration system) to save the verifiable credential data, updates a valid verifiable credential data list of the authorization party, and returns an update result to the authorization party. Because the identifier of the verifiable credential data does not carry the identity information of the authorized party, the identity data of the authorized party can be prevented from being revealed, and the data security is ensured.

In addition, the verifiable credential may also be sent to the smart contract (i.e., the registration system) as verifiable credential data to be saved in the smart contract and to update the valid verifiable credential data list of the authorizer and to return the update result to the authorizer.

It should be noted that, in one possible implementation manner, before the authorizer sends the identifier of the verifiable credential data to the registration system, the authorizer may also use the private key of the authorizer to sign the identifier of the verifiable credential data to obtain a signature of the identifier of the verifiable credential data, so that before executing the "update of the registration system according to the identifier of the verifiable credential data" in step S103, the following steps D1-D2 may be further executed:

step D1: the authorizing party sends the signature capable of verifying the credential data identification and the identity identification of the authorizing party to the registration system.

Step D2: the registration system finds the public key of the corresponding authorizing party according to the identity of the authorizing party, and uses the public key of the authorizing party and the identification of the verifiable credential data to verify the signature of the verifiable credential data identification.

Further, the specific implementation process of the registration system in the step S103 for updating according to the identifier of the verifiable credential data is as follows: when the signature verification result is passed, the registration system adds the identification of the verifiable credential data to the verifiable credential data list of the authorizing party.

S204: the authorizer sends the verifiable credential data to the authorized party for the authorized party to save.

In this embodiment, after generating verifiable credential data according to an identity authorization request, the authorizer may send the verifiable credential data to the authorized party for the authorized party to save, so that identity authorization of the authorized party can be achieved.

It should be noted that, before the authorized party sends the identity authorization request to the authorized party, the authorized party may also set a security identifier, and set the type of the security identifier to be plaintext backhaul or ciphertext backhaul. Meanwhile, the security identifier is set in the identity authorization request, namely the security identifier is also included in the identity authorization request. In this way, before the authenticatable credential data is sent to the authorized party, the authorized party can judge the type of the security identifier first, and when the type of the security identifier is plaintext return, the plaintext data of the authenticatable credential data is sent to the authorized party; and when the type of the security identifier is ciphertext feedback, ciphertext data capable of verifying the credential data is sent to the authorized party. According to the actual situation, the verifiable credential data are sent to the authorized party through the two implementation modes respectively, so that the identity authorization of the authorized party is realized.

In order to facilitate understanding of the technical solution, a specific scenario is taken as an example for illustration, and generally speaking, the use flow of the DIDs technology is as follows:

In the scene, including: an authorized party (Subject/Holder), an authorized party (Issuer), a Verifier (Verifier), and a verifiable data credential registry (Verifiable DATA REGISTRY). The Subject refers to the Entity that resulted in Claims, which is also the Entity that the VC corresponds to. Holder is an authorized party, typically the same Entity as the Subject. Issuer is the Entity (i.e., authorizer) that issues VCs to the Holder, and requires authentication of the Holder submitted Claim for the Subject. Verifiers are entities that authenticate VCs, typically service providers. Verifiable DATA REGISTRY is some database that all entities have access to, such as blockchain, assisted DID generation, registration, VC registration, query, revocation, issuer public key registration, etc.

In this example, subject, issuer and verifiers may register the DID on a smart contract (i.e., a DIDs smart contract) in the identity-authorized blockchain system, respectively. And Issuer may register as an Authority (Authority), i.e., an authorized party. Verifiers may define a self-accepted Claim data structure. The Subject generates a Claim and submits to Issuer certification. Issuer first authenticates the Subject by means of authentication recorded on the DID Document of the Subject. Issuer authenticates Claim again and signs. And then generating the VC, and adding the hash abstract of the VC to a VC list on the blockchain intelligent contract. The Verifier authenticates the Subject identity through the DID Document, and then confirms the validity and effectiveness of the VC through the VC or the VC identifier on the blockchain.

In summary, the identity authorization blockchain system for identity authorization comprises a registered authorized party and an authorized party, and the identity authorization blockchain system is provided with a registration system; the authorized party acquires declaration information of the authorized party from the registration system, requests the authorized party to carry out identity verification on the authorized party according to the identity identification of the authorized party stored by the authorized party, generates an identity authorization request according to the declaration information of the authorized party when the identity verification result of the authorized party on the authorized party is passed, and sends the identity authorization request to the authorized party; the authorizer generates verifiable credential data according to the identity authorization request, and sends the identification of the verifiable credential data to the registration system, so that the registration system updates according to the identification of the verifiable credential data, and returns an updating result to the authorizer; the authorizer may also send the verifiable credential data to the authorized party for preservation by the authorized party. Based on the decentralized advantage of the blockchain and the advantage that the outside cannot be tampered, the security and reliability of identity authorization between the authorized party and the authorized party can be effectively improved, and the credibility of the identity authorization relationship can be further ensured. And solves the problems of the traditional platform account authentication and the third party account authentication.

Next, the embodiment of the present application will be described with respect to two implementations of "the authorizer sends verifiable credential data to the authorized party for the authorized party to save" in step S204:

(1) The authorizer sends the verifiable credential data to the authorized party in the form of plaintext data for storage by the authorized party. Specifically, the following steps E1-E4 can be included:

step E1: the authorizing party sends the verifiable credential data and the identity of the authorizing party to the authorized party.

In this embodiment, if the authorizer determines that the type of the security identifier is plaintext backhaul before sending the verifiable credential data to the authorized party, the verifiable credential data and plaintext data of the identity identifier (did_i) of the authorizer may be sent to the authorized party.

Step E2: and the authorized party sends a query request to the registration system according to the identification of the verifiable credential data and the identity of the authorized party.

In this embodiment, after receiving the verifiable credential data sent by the authorizer and the identity (did_i) of the authorizer, the authorized party may further send a query request to the registration system according to the identifier (vc_id) of the verifiable credential data and the identity (did_i) of the authorizer, to query the validity of the identifier (vc_id) of the verifiable credential data and the identity (did_i) of the authorizer.

Step E3: the registration system searches whether the verifiable credential data list of the authorized party has the identification of the verifiable credential data according to the identity identification of the authorized party, if so, the registration system indicates that the identification of the verifiable credential data is valid, and returns the query result and the identity file of the authorized party corresponding to the identity identification of the authorized party to the authorized party.

Step E4: the authorized party verifies the verifiable credential data according to the identity file of the authorized party, and if the verification is passed, the authorized party confirms that the verifiable credential data is legal and stores the same.

Specifically, the authorized party can obtain the public key of the authorized party from the identity file of the authorized party, the secret cabinet uses the public key of the authorized party and the authorized party declaration data in the verifiable credential data to verify the signature of the authorized party declaration data in the verifiable credential data, and after the verification result shows that the verification credential data passes verification, the verification credential data is confirmed to be legal and stored.

Illustrating: the entity program of the authorized party obtains a public key (pubKey_I) from an identity file of the authorized party, then a signature (sign_clamp_H) of the authorized party declaration data (clamp_H) in the verifiable credential data is checked through a security module (such as a chip or a SIM card of the authorized party), the checked result is returned to the entity program, if the checked result is successful, the entity program can determine the validity of the verifiable credential data, further the verifiable credential data containing an identifier (VC_ID) of the verifiable credential data can be sent to the security module for storage, and then the security module returns the storage result to the entity program.

(2) The authorizer sends the verifiable credential data to the authorized party in the form of ciphertext data for the authorized party to save.

In a first implementation, the specific implementation process that the authorizer sends the verifiable credential data to the authorized party in the form of ciphertext data for the authorized party to save may include the following steps F1-F5:

Step F1: the authorizing party signs the verifiable credential data by using the private key and sends the signed verifiable credential data to the authorized party.

In this embodiment, if the authorizer determines that the type of the security identifier is ciphertext backhaul before sending the verifiable credential data to the authorized party, the authorizer may send the ciphertext data of the verifiable credential data to the authorized party, specifically, the authorizer may first sign (e.g., digitally sign) the verifiable credential data using a private key, and then send the signed verifiable credential data to the authorized party.

Step F2: the authorized party sends an entity identity query request to the registration system.

In this embodiment, after receiving the signed verifiable credential data sent by the authorizing party, the authorized party may further send an entity identity query request to the registration system.

Step F3: the registration system returns the identity file of the pre-stored entity to the authorized party.

Step F4: and the authorized party performs signature verification on the signed verifiable credential data by using the identity file of the entity, and if the signature verification is successful, the verification is confirmed to be legal.

Step F5: and the authorized party sends a result of confirming that the verifiable credential data is legal to the registration system for inquiry, and if the registration system inquires that the verifiable credential data is valid, the inquiry result is returned to the authorized party so that the authorized party stores the verifiable credential data.

In a second implementation, the authorized party pre-generates a second random number and sets the second random number in the identity authorization request, i.e. the second random number is included in the identity authorization request. The specific implementation process of the authorizer transmitting the verifiable credential data to the authorized party in the form of ciphertext data for the authorized party to save may include the following steps G1-G2:

Step G1: the authorizing party generates a third random number, and generates identity verification data and encryption data of the verifiable credential data according to the second random number, the third random number and the verifiable credential data; and then the authentication data, the encryption data of the verifiable credential data and the self-saved authorization party identity ciphertext are returned to the authorized party.

Step G2: the authorized party acquires an identity file of the authorized party from the registration system according to the identity of the authorized party; and verifying the identity verification data according to the identity file of the authorized party, decrypting the encrypted data of the verifiable credential data to obtain the verifiable credential data after verification passes, and storing the decrypted verifiable credential data.

In some possible implementations of the embodiments of the present application, the specific implementation process of the "the authorized party generates the authentication data and the encrypted data of the verifiable credential data according to the second random number and the third random number and the verifiable credential data" in the step G1 includes the following steps H1-H3:

Step H1: and the authorizing party encrypts the third random number by using the public key of the authorized party, which is obtained when the authorizing party performs identity verification on the authorized party, so as to obtain encrypted data of the third random number.

Step H2: the authorizing party signs the third random number by using the private key of the authorizing party stored by the authorizing party, and the signature of the third random number is obtained.

Step H3: the authorizer generates a first session key according to the second random number and the third random number, and encrypts the verifiable credential data by using the first session key to obtain encrypted data of the verifiable credential data.

On the basis, the specific implementation process of verifying the identity verification data according to the identity file of the authorized party in the step G2 comprises the following steps of I1-I2:

Step I1: the authorized party obtains the public key of the authorized party from the identity file of the authorized party, and decrypts the encrypted data of the third random number by using the private key of the authorized party stored by the authorized party to obtain first decrypted data.

It should be noted that, the identity file generally includes a plurality of public keys and corresponding key identifiers, so when the identity file to which the authorizing party belongs includes a plurality of keys, the authorized party needs to search the public key corresponding to the authorizing party through the key identifiers first, and then can decrypt the encrypted data of the third random number by using the private key of the authorized party stored by the authorized party to obtain the first decrypted data.

Step I2: the authorized party signs the signature of the third random number using the public key of the authorized party and the first decrypted data.

On the basis, the specific implementation process that the authorized party in the step G2 decrypts the encrypted data of the verifiable credential data to obtain the verifiable credential data and stores the decrypted verifiable credential data comprises the following steps J1-J2:

step J1: if the verification is successful, the authorized party can generate a second session key according to the second random number and the first decryption data.

Step J2: the authorized party uses the second session key to decrypt the encrypted data of the verifiable credential data to obtain the verifiable credential data, extracts the declaration data of the authorized party and the declaration data signature of the authorized party from the verifiable credential data, uses the public key of the authorized party and the extracted declaration data of the authorized party to check the signature of the declaration data of the authorized party, and if the check passes, saves the verifiable credential data.

Furthermore, an alternative implementation is to improve the security and reliability of identity authorization between the authorizing party and the authorized party. Before the authenticatable credential data is stored by the authorized party, an identifier (vc_id) of the authenticatable credential data in the authenticatable credential data may also be sent to the registration system, so that the registration system checks whether the identifier of the authenticatable credential data is valid, for example, by checking whether a VC list exists, and verifying the validity of the identity identifier (did_i) of the authorized party. And when the verification result is that the identification (DID_I) of the verifiable credential data is valid and the verification result of the authentication data by the authorized party is passed, the authorized party can save the verifiable credential data.

Next, a method for registering an authorized party and an authorized party in the identity authorized blockchain system will be described. In one possible implementation, the authorizing party or the authorized party is taken as an example of a target party.

In this implementation, the target party (specifically, the authorized party or the authorized party) may generate the corresponding identity and the identity file. Wherein the identity can be used to identify the identity of the target party in the identity-authorized blockchain system. The target may also generate a corresponding public-private key pair for verifying the identity of the target by means of signing and verification. The public key generated by the target party can be used as a signature verification public key corresponding to the target party, and the identity file generated by the target party comprises the corresponding signature verification public key and a signature verification mode. When the target party signs through the private key to obtain corresponding signature data, the signature data can be signed through the signature verification public key and the signature verification mode.

In a specific implementation, the identity generated by the target may be a de-centralized identity (Decentralized Identifiers, DID), i.e. identity information autonomously generated and controlled by the Entity (Entity).

The DID contains some fixed fields and a unique random string to point to the determined Entity. The grammar format is as follows: "method-name" wherein method-name is a scheme name and method-specific-ID is an ID number generated based on a scene rule.

For example, the DID for one Entity is:

“DID:bhdc:0d7ef5e3c48123……d10edd982e5b65642af8d2a792964”。

In addition, in order to ensure uniqueness, the DID may be a hash value of a public key held by an entity, and registered and authenticated on the blockchain after generation to ensure uniqueness of each DID.

Decentralizing identity Document (Decentralized Identifiers Document, DID Document):

each DID has a corresponding DID document, i.e., an identity document, which contains more information about the identity of the target party, such as Public Key (Public Key), signature, service (Service), etc. The DID Document may be stored in the user software of the target party or in the device security hardware, or may be stored in a cloud platform specified by the user after being locally encrypted, which is not limited in the present application.

An example of a DID Document is given below:

/>

The "Public Key" field indicates Public Key data held by the DID entity, the "authentication" field is used to indicate a Public Key (which may be referred to in the "Public Key" field or may be added with a new Public Key) that may be used for identity authentication of the DID entity, and the "Service" field identifies Service content that may be provided by the current DID entity externally, for example, as a device manufacturer, and may issue a verifiable credential for a device that is produced by itself (Verifiable Credential).

In order to facilitate understanding of the technical scheme of the present application, the following describes the relationship between DID, DID Document and VC.

The DID documents and the DIDs are in one-to-one relationship, and each DID has a corresponding DID Document record of its public key and authentication mode.

DID Document and VC are not directly related, but an Issuer may need to verify the Entity identity by Document when issuing VC.

The DID and VC are not simple correspondences, the DID is used to describe the activity, and the VC is a proof of some properties of the activity, generally speaking, one DID will have multiple VCs, one VC will at least correspond to one DID, and in special cases, there will be VCs corresponding to multiple DID, such as wedding cards.

Thus, the target party may perform identity registration with the registration system (i.e., the smart contract) based on the identity and the identity file. It should be noted that the identity file includes a corresponding public signature verification key.

Then, the registration system (i.e. intelligent contract) can audit the identity mark and the identity file, if the identity mark and the identity file pass the audit, the target party is determined to finish the identity registration, and the identity file corresponding to the target party is stored.

Specifically, the process of generating the corresponding identity mark and the corresponding identity file by the target party can be as follows: the target may first set the key type (safeType) and obtain the current time (i.e., timeStamp), and then randomly generate a pair of public and private keys (pubKey and privKey) based on the key type (safeType) and the current time (timeStamp). The private key may be stored in the chip after being encrypted, then, the hash operation is performed on the public key to obtain a corresponding hash value, and the hash value is used as an identity (i.e. DID) of the target party, so that an identity Document (DID Document) of the target party may be generated according to the identity and the public key (pubKey). An alternative implementation manner is that after the target party generates the corresponding identity identifier and identity file, the identity identifier and identity file can be stored.

On the basis, the target party can send the obtained identity and the identity file to the registration system so that the registration system can audit the identity and the identity file, namely, the registration system can determine whether the identity exists in the previously stored identity set, and if the identity does not exist, the random identity can be sent to the target party.

Further, after receiving the random identifier, the target party can sign the random identifier by using a private key to obtain first signature data, and send the identity file, the random identifier and the first signature data to the registration system, so that the registration system performs signature verification on the first signature data according to the identity file, and if the signature verification passes, the target party can be determined to complete identity registration, and the identity file corresponding to the target party is stored.

Still further, in an alternative implementation manner, after determining that the target party completes identity registration, the registration system may send the query address of the identity to the target party, so that the target party updates the identity file according to the query address of the identity.

Illustrating: referring to fig. 3, which shows an exemplary diagram of signaling interaction in an identity registration phase provided by an embodiment of the present application, as shown in fig. 3, a DID entity, that is, the above-mentioned target party, may be an authorized party or an authorized party. The DID entity may be a data processing device that may include a security module and a device program that communicate with each other via a hardware interface. The registration procedure of the authorized party (holder) or the authorizing party (issuer) includes:

S501: the device program of the entity may obtain a time stamp (time stamp) and set a key pair type (safeType).

The time stamp is the current time of acquisition.

S502: the device program sends the key pair type and the timestamp to the security module of the entity, requesting the security module to generate an identification (DID).

S503: the security module randomly generates a pair of public and private keys based on the current time (timeStamp) and the key pair type (safeType).

S504: the security module stores the private key, performs hash operation on the public key to obtain a hash value corresponding to the private key, and uses the hash value as an identification (DID) of the target party (i.e., the authorizer (holder) or the authorizer (issuer)).

The security module may encrypt the private key and store the encrypted private key in the chip.

S505: the security module generates an identity file (DID Document) in combination with the preset template and the incoming current time timeStamp.

S506: the security module returns an identity Document (DID Document) to the device program.

S507: the device program sends an identification (DID) and an identity Document (DID Document) to the registration system requesting authentication (i.e., auditing) of the identification and the identity Document.

Wherein the registration system is built based on blockchain intelligence contracts.

S508: the registration system retrieves whether the identification (DID) has been registered (i.e., the registration system needs to determine whether the identification exists in the stored set of identifications), and if not, it indicates that the identification (DID) is available, and S509 is performed.

S509: the registration system sends a random identification (Nonce), such as a random string, to the device program.

S510: the device program requests the security module to sign a random identification, such as a random string.

S511: the security module signs the random identifier (e.g., a random string) according to a predetermined algorithm (e.g., ECDSA, RSA, SM, etc. signature algorithm) using the private key, generating signature data (sign_nonce), which is defined herein as first signature data.

S512: the security module sends the first signature data (sign_nonce) and the identity file (DID Document) to the device program.

S513: the device program transmits an identity Document (DID Document), a random identification (Nonce), and first signature data (sign_nonce) to the registration system, requesting identity identification (DID) registration.

S514: the registration system obtains a public key from an identity Document (DID Document) and signs the first signature data (sgin _nonce). After the verification is passed, the identification (DID) is registered in the registration system, namely, the identification (DID) is stored in an identification set stored in the registration system, namely, an identification file (DID Document) corresponding to the target party is stored.

S515: the registration system returns a registration result and an identity lookup address (uri_did) to the device program.

S516: the device program returns an identity lookup address to the security module.

S517: the security module updates the identity lookup address to an identity Document (DID Document).

Next, in another possible implementation manner, taking the authorizer as the target, an identity registration procedure of the authorizer is described. The method specifically comprises the following steps K1-K4:

Step K1: the authorizing party generates authorizing party identity data, and signs the identity data by using a private key to obtain second signature data; the authorization party identity data refers to data which represents that an authorization party has identity authorization rights.

Step K2: the authorized party sends the identity file and the identity data and the second signature data to the registration system.

Step K3: the registration system verifies the second signature data according to the identity file, if the second signature data passes the verification, the identity authorization authority qualification of the authorizer is granted, the identity authorization authority qualification is stored in the identity file stored by the registration system, and the registration state and the identity inquiry address of the authorizer are sent to the authorizer.

Step K4: and the authorized party updates the identity inquiry address into the identity file stored by the authorized party.

Illustrating: referring to fig. 4, the diagram shows a signaling interaction example diagram of identity registration of an authorized party according to an embodiment of the present application, as shown in fig. 4, the method includes:

s601: the device program sets a issuer identity and generates authorizer identity data (IssuerData).

The authorization party identity data is data which shows that the authorization party has identity authorization authority;

Specifically, the identity of the Issuer may be manually filled in by the user in the device program of the entity object (i.e. the entity object is determined to be an authorized party) and authorization party identity data may be generated, or the identity of the Issuer and verification information may be automatically set by the device program, and for some DID entity objects that provide services to the outside, the Issuer identity may be registered after the DID identity is registered.

S602: the device program of the entity requests the security module to sign the identity data.

S603: the entity's security module signs the identity data (IssuerData) with a private key, resulting in a signature (sign_ IssuerData), which is defined herein as second signature data.

The security module may decrypt the internally stored private key and then use it to generate second signature data (sign_ IssuerData) according to a predetermined algorithm on the identity data (IssuerData).

S604: the security module returns the second signature data (sign_ IssuerData) to the device program.

S605: the device program sends an identity Document (DID Document), identity data IssuerData, second signature data (sign_ IssuerData) to the registration system to request an identity authority registration of the authorizer (Issuer).

S606: the registration system performs signature verification on the second signature data (sign_ IssuerData) according to the public key in the identity file (DID Document), if the signature verification is successful, registers the Issuer identity, namely grants the identity authorization authority qualification thereof, and stores the identity authorization authority qualification into the self-stored identity file (DID Document).

S607: the registration system returns a registration status and an identity lookup address (uri_ issuer) to the device program.

S608: the device program sends an identity lookup address (uri_ issuer) to the security module.

S609: the security module updates the identity lookup address (uri_ issuer) into its own stored identity file (DID Document).

Next, the procedure of adding the declaration template by the authorizer and the authorized party will be described in the embodiment of the present application. Specifically, the method comprises the following steps L1-L4:

Step L1: the authorized party generates declaration information, signs a declaration template inquiry address in the declaration information by using a private key, and obtains third signature data; wherein the declaration information includes a declaration template and a declaration template query address.

Step L2: the authorized party sends the declaration template query address and third signature data in the identity file and the declaration information to the registration system.

Step L3: the registration system verifies the third signature data according to the identity file stored by the registration system, if the third signature data passes the verification, the declaration information is stored in the identity file stored by the registration system, and a new result of the declaration information is returned to the target party.

Step L4: the target updates the declaration template address into the identity file stored by itself.

Illustrating: referring to fig. 5, a diagram illustrating a signaling interaction example of an add declaration (claim) template provided by an embodiment of the present application, as shown in fig. 5, the method includes:

S701: the facility program of the entity generates declaration information, wherein the declaration information includes a declaration template and a declaration template query address (uri_clip).

S702: the facility program requests signing of the declaration template query address (uri_clip) in the declaration information from the entity's security module.

S703: the security module signs the declaration template query address (uri_clamm) with the built-in private key to obtain signature data (sign_uri_clamm), which is defined herein as third signature data.

S704: the security module sends third signature data (sign_uri_class) to the device program.

S705: the device program sends an identity file (DID Document), a declaration template query address (uri_document), and third signature data (sign_uri_document) to the registry system to request a new declaration (Document) template.

S706: the registration system utilizes a public key in an identity file (DID Document) to check signature of third signature data (sign_uri_document), after the signature check is successful, the declaration information of the declaration template query address is added into the self-stored identity file (DID Document), and if the signature check fails, the declaration template query/acquisition address is not added.

S707: the registration system sends the addition result of the declaration template to the device program.

S708: the device program sends a declarative template query address (uri_clip) to the security module.

S709: the security module updates the declaration template query address (uri_document) to the Service domain of the self-stored identity file (DID Document) and returns a new state to the device program.

Referring to fig. 6, the application also provides an apparatus for identity verification, which is applied to an identity authorization blockchain system including an authorized party and a verifier, wherein a registration system is deployed in the identity authorization blockchain system, and the apparatus comprises:

an authorized party 801, configured to send an authentication request to the authenticating party, where the authentication request includes an identity of the authorized party;

A verifier 802 for generating a random number according to the verification request and returning the random number to the authorized party;

the authorized party 801 is further configured to generate a verifiable report according to the random number and verifiable credential data stored in the authorized party 801, and send the verifiable report and an identity of the authorized party stored in the authorized party to the verifier;

The verifier 802 is further configured to obtain, from the registration system 803, an identity file of the authorized party by using the identity of the authorized party, verify the verifiable report according to the identity file of the authorized party, and return a verification result to the authorized party.

In one possible implementation, the authorized party 801 is specifically configured to

The verifier 802 is specifically configured to:

In one possible implementation, the verifier 802 is specifically configured to:

Or alternatively

In one possible implementation, the verifier 802 is further configured to:

The registration system 803 is further configured to: checking whether the identity of the authorized party and the identity of the verifiable credential data are in a valid verifiable credential data list, and returning a valid or invalid query result of the authorized party to the verifier;

the verifier 802 is further configured to: and returning the verification result to the authorized party according to the query result.

The authorized party 801 is configured to obtain declaration information of the authorized party from the registration system, request the authorized party to perform identity verification on the authorized party according to an identity identifier of the authorized party stored in the authorized party, generate an identity authorization request according to the declaration information of the authorized party when the identity verification result of the authorized party on the authorized party is passed, and send the identity authorization request to the authorized party;

a registration system 803, configured to update according to the identifier of the verifiable credential data, and return an update result to the authorized party;

In one possible implementation, the authorized party 801 is specifically configured to:

The authorizer is specifically configured to:

the authorized party 801 is further specifically configured to:

the authorizer is also specifically configured to:

The registration system 803 is specifically configured to:

In a possible implementation manner, the authorized party 801 is further configured to generate declaration data of an authorized party according to declaration information of the authorized party; the identity authorization request comprises declaration data of the authorized party;

The authorizer is specifically configured to:

In one possible implementation, the authorizer is further configured to:

The registration system 803 is specifically configured to:

In one possible implementation, when the verification result is a pass, the registration system 803 is specifically configured to add the identifier of the verifiable credential data to a verifiable credential data list of the authorized party.

In one possible implementation, the authorizer is specifically configured to:

The registration system 803 is specifically configured to:

the authorized party 801 is further specifically configured to:

In one possible implementation, the authorized party 801 is specifically configured to: a step of

In one possible implementation, the authorizer is specifically configured to:

sending an entity identity inquiry request to the registration system;

The registration system 803 is specifically configured to:

Returning the identity file of the pre-stored entity to the authorized party;

the authorized party 801 is further specifically configured to:

In one possible implementation, the authorized party 801 is further configured to:

The authorizer is specifically for:

The authorized party 801 is also configured to: acquiring an identity file of the authorizing party from the registration system according to the identity of the authorizing party; and verifying the identity verification data according to the identity file of the authorized party, decrypting the encrypted data of the verifiable credential data to obtain the verifiable credential data after verification, and storing the decrypted verifiable credential data.

In one possible implementation, the authorizer is specifically configured to:

In one possible implementation, the authorizer is further configured to:

In one possible implementation, the target party is the authorized party or the authorized party 801; the target party is specifically configured to:

the registration system 803 is specifically configured to: and checking the identity mark and the identity file, and if the identity mark and the identity file pass the checking, determining that the target party completes identity registration and storing the identity file corresponding to the target party.

In one possible implementation, the target party is specifically configured to:

The identity mark and the identity file are sent to a registration system;

the registration system 803 is specifically configured to: and determining whether the identity mark exists in the stored identity mark set, and if not, sending a random mark to the target party.

In one possible implementation, the target party is further configured to:

The registration system 803 is further configured to: and checking the signature of the first signature data according to the identity file, and if the signature passes, determining that the target party completes identity registration and storing the identity file corresponding to the target party.

In one possible implementation, the target party is further configured to:

storing the identity file;

the registration system 803 is further configured to: sending the inquiry address of the identity mark to the target party;

In one possible implementation, when the target party is the authorized party, the authorized party is further configured to:

The registration system 803 is further configured to: verifying the second signature data according to the identity file, if the second signature data passes the verification, granting the identity authorization authority qualification of the authorizer, storing the identity authorization authority qualification into the identity file stored by the authorizer, and sending the registration state and the identity inquiry address of the authorizer to the authorizer;

In one possible implementation, the authorizer is further configured to:

The registration system 803 is further configured to: verifying the third signature data according to the identity file stored by the target party, if the third signature data passes the verification, storing the declaration information in the identity file stored by the target party, and returning a new result of the declaration information to the target party;

In summary, in the apparatus for identity verification provided in this embodiment, an identity authorization blockchain system for identity verification includes a registered authorized party and a verifier, where a registration system is disposed in the identity authorization blockchain system; after the authorized party sends the verification request including the identity of the authorized party to the verifier, the verifier can generate a random number according to the verification request and return the random number to the authorized party. The authorized party can generate a verifiable report according to the random number and the verifiable credential data stored by the authorized party, and send the verifiable report and the identity of the authorized party stored by the authorized party to the verifying party, so that the verifying party can acquire the identity file of the authorized party from the registration system by utilizing the identity of the authorized party, verify the verifiable report according to the identity file of the authorized party, and return a verification result to the authorized party. And based on the decentralization advantage of the blockchain of the registration system and the advantage that the outside cannot be tampered, the accuracy and the reliability of the authentication result of the authorized party can be effectively improved.

Further, the embodiment of the application also provides an identity verification device, which comprises: a processor and a memory;

The processor is used for storing the program codes and transmitting the program codes to the processor;

the memory is used to perform any one of the implementation methods of the above-described authentication methods according to instructions in the program code.

Further, the embodiment of the application also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and when the computer program runs on terminal equipment, the terminal equipment is caused to execute any implementation method of the authentication method.

From the above description of embodiments, it will be apparent to those skilled in the art that all or part of the steps of the above described example methods may be implemented in software plus necessary general purpose hardware platforms. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product, which may be stored in a storage medium, such as ROM/RAM, a magnetic disk, an optical disk, etc., including several instructions for causing a computer device (which may be a personal computer, a server, or a network communication device such as a media gateway, etc.) to execute the method described in the embodiments or some parts of the embodiments of the present application.

It should be noted that, in the present description, each embodiment is described in a progressive manner, and each embodiment is mainly described in a different manner from other embodiments, and identical and similar parts between the embodiments are all enough to refer to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant points refer to the description of the method section.

It is further noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. The identity verification method is characterized by being applied to an identity authorization blockchain system comprising an authorized party and a verifier, wherein a registration system is deployed in the identity authorization blockchain system; the method comprises the following steps:

The verification party acquires the identity file of the authorized party from the registration system by utilizing the identity of the authorized party, verifies the verifiable report according to the identity file of the authorized party, and returns a verification result to the authorized party;

after the verification party verifies the verifiable report according to the identity file of the authorized party, before the verification party returns a verification result to the authorized party, the method further comprises the following steps:

2. The method according to claim 1, wherein the authenticatable report is generated by the authorized party from the random number and the authenticatable credential data stored therein, specifically comprising:

3. The method according to claim 2, wherein the signing the fourth signature data and the fifth signature data using the public key of the authorized party, respectively, specifically comprises:

Or alternatively

4. The method of claim 1, wherein an authorizer is deployed in the identity authorization blockchain system; the method further comprises the steps of:

5. The method according to claim 4, wherein the authorized party requests the authorized party to authenticate the authorized party according to the identity of the authorized party stored in the authorized party, specifically comprising:

6. The method according to claim 4, wherein the authorized party obtains the declaration information of the authorized party from the registration system, specifically comprising:

7. The method according to claim 6, wherein the authorized party generates an identity authorization request according to the declaration information of the authorized party, specifically:

8. The method of claim 4, wherein the authorized party, after obtaining the declaration information of the authorized party, further comprises: the authorized party generates declaration data of the authorized party according to the declaration information of the authorized party; the identity authorization request comprises declaration data of the authorized party;

9. The method of claim 8, wherein the authorizing the party before sending the identification of the verifiable credential data to the registration system further comprises:

10. The method according to claim 9, wherein the registration system is updated according to the identity of the verifiable credential data, in particular: when the signature verification result is that the signature passes, the registration system adds the identification of the verifiable credential data to a verifiable credential data list of the authorized party.

11. The method of claim 4, wherein the authorizing party transmitting the verifiable credential data to the authorized party for preservation by the authorized party, comprising:

12. The method of claim 11, wherein the authenticatable credential data is authenticated by the authorized party according to an identity file of the authorized party, specifically comprising:

13. The method of claim 4, wherein the authorizing party transmitting the verifiable credential data to the authorized party for preservation by the authorized party, comprising:

14. The method of claim 4, wherein before the authorized party sends an identity authorization request to the authorized party based on the declaration information of the authorized party, further comprising:

15. The method according to claim 14, wherein the authorizing party generates authentication data and encrypted data of the verifiable credential data from the second and third random numbers, the verifiable credential data, comprising in particular: the authorizing party encrypts the third random number by using a public key of the authorized party, which is obtained when the authorizing party performs identity verification on the authorized party, so as to obtain encrypted data of the third random number;

16. The method according to claim 15, wherein the authenticating the authentication data by the authorized party based on the identity file of the authorized party comprises:

17. The method according to claim 16, wherein the authorized party decrypts the encrypted data of the verifiable credential data to obtain the verifiable credential data, and stores the decrypted verifiable credential data, and specifically comprises:

18. The method of claim 14, wherein prior to the authenticatable credential data being stored by the authorized party, further comprising:

19. The method of claim 4, wherein prior to the authorizer generating verifiable credential data from the identity authorization request, further comprising:

20. The method according to any of claims 4-19, wherein the target party is the authorized party or the authorized party; the method further comprises the steps of:

21. The method of claim 20, wherein the target generates the corresponding identity and identity file, comprising:

22. The method of claim 21, wherein the registering the identity with the registration system based on the identity and the identity file comprises: the target party sends the identity mark and the identity file to a registration system;

23. The method of claim 22, wherein after said transmitting a random identification to said target, said method further comprises:

24. The method of claim 20, wherein after the target generates the identity file, further comprising: the target party stores the identity file;

25. The method of claim 20, wherein when the target party is the authorized party, the method further comprises:

The authorizer generates authorizer identity data, and signs the identity data by using a private key to obtain second signature data; the identity data of the authorizer is data showing that the authorizer has identity authorization authority;

26. The method of claim 25, wherein the method further comprises:

27. The method of claim 4, wherein prior to the authorizing sending the identity authorization request to the authorizing party, the method further comprises: the authorized party sets a security identifier, and the type of the security identifier is set as plaintext feedback or ciphertext feedback; the identity authorization request also comprises the security identifier;

28. The identity verification device is characterized by being applied to an identity authorization blockchain system comprising an authorized party and a verifier, wherein a registration system is deployed in the identity authorization blockchain system; the device comprises:

The verification party is further configured to obtain an identity file of the authorized party from the registration system by using the identity of the authorized party, verify the verifiable report according to the identity file of the authorized party, and return a verification result to the authorized party;

The verifier is also configured to: acquiring the verifiable credential data from the verifiable report, extracting the identity of the authorizer and the identity of the verifiable credential data from the acquired verifiable credential data, and sending the identity of the authorizer and the identity of the verifiable credential data to the registration system;

29. The apparatus of claim 28, wherein the authorized party is configured to sign the random number using a private key of the authorized party stored in the authorized party to obtain fourth signature data; signing the verifiable credential data by using the private key of the authorized party to obtain fifth signature data;

The verification party is specifically configured to:

30. The apparatus of claim 29, wherein the verifier is configured to:

Or alternatively

31. The apparatus of claim 28, wherein an authorizer is deployed in the identity authorization blockchain system; the apparatus further comprises:

32. The apparatus of claim 31, wherein the authorized party is specifically configured to:

The authorizer is specifically configured to:

The authorized party is also specifically configured to:

the authorizer is also specifically configured to:

33. The apparatus of claim 31, wherein the authorized party is specifically configured to:

The registration system is specifically configured to:

34. The apparatus of claim 33, wherein the authorized party is specifically configured to:

35. The apparatus of claim 31, wherein the authorized party is further configured to generate declaration data for the authorized party based on the declaration information for the authorized party; the identity authorization request comprises declaration data of the authorized party;

The authorizer is specifically configured to:

36. The apparatus of claim 35, wherein the authorizer is further to:

The registration system is specifically configured to:

37. The apparatus of claim 36, wherein the registration system is specifically configured to add the identity of the verifiable credential data to a verifiable credential data list of an authorized party when the verification of the signature results in a pass.

38. The apparatus of claim 31, wherein the authorizer is specifically configured to:

The registration system is specifically configured to:

The authorized party is also specifically configured to:

39. The apparatus of claim 38, wherein the authorized party is specifically configured to: and acquiring a public key of the authorizer from the identity file of the authorizer, and checking the signature of the authorized party statement data in the verifiable credential data by using the public key of the authorizer and the authorized party statement data in the verifiable credential data.

40. The apparatus of claim 39, wherein the authorizer is specifically to:

sending an entity identity inquiry request to the registration system;

The registration system is specifically configured to:

Returning the identity file of the pre-stored entity to the authorized party;

The authorized party is also specifically configured to:

41. The apparatus of claim 31, wherein the authorized party is further configured to:

The authorizer is specifically for:

42. The apparatus of claim 41, wherein the authorizer is specifically to:

43. The apparatus of claim 42, wherein the authorized party is specifically configured to:

44. The apparatus of claim 43, wherein the authorized party is specifically configured to:

45. The apparatus of claim 41, wherein the authorized party is further configured to:

46. The apparatus of claim 31, wherein the authorizer is further to:

47. The apparatus of any one of claims 31-46, wherein a target party is the authorized party or the authorized party; the target party is specifically configured to:

48. The apparatus of claim 47, wherein the target party is specifically configured to:

49. The apparatus of claim 48, wherein the target party is specifically configured to:

The identity mark and the identity file are sent to a registration system;

50. The apparatus of claim 49, wherein the target is further configured to:

51. The apparatus of claim 47, wherein the target is further configured to:

storing the identity file;

52. The apparatus of claim 47, wherein when the target party is the authorized party, the authorized party is further configured to:

generating identity data of an authorized party, and signing the identity data by using a private key to obtain second signature data; the identity data of the authorizer is data showing that the authorizer has identity authorization authority;

53. The apparatus of claim 52, wherein the authorizer is further to:

54. The apparatus of claim 31, wherein the authorized party is further configured to:

55. An apparatus for authentication, the apparatus comprising a processor and a memory:

the memory is used for storing program codes and transmitting the program codes to the processor;

the processor is configured to perform the method of any of claims 1-27 according to instructions in the program code.

56. A computer readable storage medium, characterized in that the computer readable storage medium is for storing a computer program for executing the method of any one of claims 1-27.