CN113111325B - Method for constructing identity chain - Google Patents

Method for constructing identity chain Download PDF

Info

Publication number
CN113111325B
CN113111325B CN202110433733.4A CN202110433733A CN113111325B CN 113111325 B CN113111325 B CN 113111325B CN 202110433733 A CN202110433733 A CN 202110433733A CN 113111325 B CN113111325 B CN 113111325B
Authority
CN
China
Prior art keywords
user
attribute
identity
template
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110433733.4A
Other languages
Chinese (zh)
Other versions
CN113111325A (en
Inventor
白健
杨任轶
薛锋
安红章
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Electronic Technology Cyber Security Co Ltd
Original Assignee
China Electronic Technology Cyber Security Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Electronic Technology Cyber Security Co Ltd filed Critical China Electronic Technology Cyber Security Co Ltd
Priority to CN202110433733.4A priority Critical patent/CN113111325B/en
Publication of CN113111325A publication Critical patent/CN113111325A/en
Application granted granted Critical
Publication of CN113111325B publication Critical patent/CN113111325B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Telephonic Communication Services (AREA)

Abstract

The invention provides a method for constructing an identity chain, which comprises the following steps: stage one: registration of attribute providers and dependents; and a second stage: creating an attribute template; and a third stage: importing user attribute identity information; and a fourth stage: establishing a trust list; and a fifth stage: and (4) user attribute identity authentication. The invention realizes that the attribute identity information of the user is completely managed and controlled by the user independently, and realizes the cross-platform and cross-system cross-domain identity authentication of the user.

Description

Method for constructing identity chain
Technical Field
The invention relates to the technical field of block chains and digital identity information, in particular to a method for constructing an identity chain.
Background
At present, the block chain technology develops landing of a plurality of application exploration and application scenes in the fields of finance, industry, internet, agriculture, energy industry and the like, and the development of the block chain technology and the landing of the application are mature day by day.
In the current internet, due to the characteristics of complexity, variability, dispersion and the like of digital identity information of a user, the user cannot manage the digital identity information of the user. Meanwhile, the problem of cross-domain identity authentication of a user between a multi-system architecture and an application platform cannot be realized.
Disclosure of Invention
The invention aims to provide a method for constructing an identity chain, so as to solve the problems of the traditional digital identity information.
The invention provides a method for constructing an identity chain, which comprises the following steps:
stage one: registration of attribute providers and dependents;
and a second stage: creating an attribute template;
and a third stage: importing user attribute identity information;
and a fourth stage: establishing a trust list;
and a fifth stage: and (4) user attribute identity authentication.
Further, the registration of the attribute provider and the relying party at stage one comprises the following steps:
step 1.1, an attribute provider and a relying party initiate a registration request by submitting a role identifier AppID, a unified social credit code, an organization name, a legal identity card and an organization registration address to a system;
step 1.2, the identity chain utilizes the SDKs of the attribute provider and the depended party to generate an AppID, a public key PK and a private key SK for the attribute provider and the depended party, and utilizes the generated private key SK to digitally sign the AppID, the organization name, the legal identity card, the organization registration address and the public key PK to generate signature information SIG ();
step 1.3, the attribute provider and the relying party initiate a cochain request by the agency name, the unified social credit code, the AppID, the public key PK, the legal identity card, the agency registration address and the signature information SIG ();
step 1.4, verifying signature information SIG () by an identity chain and judging whether AppID is unique, if the signature information is verified to be correct and the AppID is unique, chaining and storing registration information of an attribute provider and a relying party, and returning block data; otherwise, rejecting the registration application.
Further, the creation of the attribute template in phase two includes the following steps:
step 2.1, the attribute provider calls an attribute template creating interface, and the AppID and the private key SK of the attribute provider are transmitted to the attribute provider according to the attribute template creating interfaceIDPTemplate ID, template type, template name, template fields { att1, att2.. atti }, version number, and state identification; memory attributeAppID of provider is AppIDIDP；
Step 2.2, the identity chain utilizes the SDK of the attribute provider to apply to the incoming AppIDPPrivate key SKIDPThe signature information SIG is generated by digitally signing the template ID, the template type, the template name, the template field { att1, att2.. atti }, the version number and the state identifierIDP()；
Step 2.3, the attribute provider calls the attribute template uplink request interface to applyIDPTemplate ID, template type, template name, template fields { att1, att2.. atti }, version number, state identification, and signature information SIGIDP() Uplink storage;
step 2.4, verifying signature information SIG by identity chainIDP() Judging whether the ID of the attribute template is unique, if the signature information is verified to be correct and the ID of the attribute template is unique, successfully creating the attribute template, and returning block data; otherwise, the attribute template creation fails.
Further, the importing of the user attribute identity information in stage three includes the following steps:
step 3.1, the attribute provider calls an attribute identity information import interface to applyIDPPrivate key SKIDPWriting the identity card number hash value of the user, the mobile phone number, the user global identity primary key Uid, the user attribute identity primary key UserID, the template ID, the Merkle root, the template fields { att1, att2.. atti }, the version number, the timestamp and the effective identifier, the user public key PK and the extension field into an identity chain;
step 3.2, the identity chain utilizes the SDK of the attribute provider to write in the AppIDPCarrying out digital signature on the ID card number hash value of the user, the mobile phone number, the user global identity primary key Uid, the user attribute identity primary key UserID, the template ID, the Merkle root, the template fields { att1, att2.. atti }, the version number, the timestamp and the effective identifier to generate signature information SIGIDP()；
Step 3.3, the attribute provider calls the attribute identity uplink request interface to applyIDPHash value of user identification card number, mobile phone number, user global identity key Uid and user attribute identityA primary key UserID, a template ID, a Merkle root, a template field { att1, att2.. atti }, a version number, a timestamp and a valid identifier, and signature information SIGIDP() Performing uplink storage;
step 3.4, verifying signature information SIG by identity chainIDP() And determine AppIDPIf the signature information is correct and App is verifiedIDPIf the attribute identity information is unique, the attribute identity information is successfully imported, and block data is returned; otherwise, the import of the attribute identity information fails.
Further, the creation of the trust list in stage four includes the following steps:
step 4.1, the relying party calls a trust list creating request in the system, and the AppID of the relying party and the private key SK of the relying party are usedRPAnd AppIDPUploading the list; recording the AppID of the dependent party as AppIDRP；
Step 4.2, the identity chain utilizes the dependent party's SDK to the uploaded AppIDRP、AppIDPDigitally signing the list and the timestamp to generate signature information SIGRP()；
Step 4.3, the relying party calls the uplink request interface to apply the AppIDRP、AppIDPList and signature information SIGRP() Uplink storage;
step 4.4, the identity chain verifies the signature information SIGRP() If the signature information is correct, the AppID is verifiedRPAnd AppIDPThe list is associated and block data is returned.
In one embodiment, the user attribute authentication at stage five comprises the following steps:
step 5.1, the relying party requests the user to authorize a user global identity primary key Uid, a user attribute identity primary key UserID, an attribute template field { att1, att2.. atti } and an attribute template field { attm.. attn } to be verified through a front end, and the front end forwards the request to the user;
step 5.2, the user authorizes the user global identity primary key Uid, the user attribute identity primary key UserID and the attribute template field { attmuserDigitally signing the above information to generate signature information SIGuser()；
Step 5.3, the user carries out Hash operation on the fields which are not verified in the attribute template through the front end, submits the plaintext of the fields which need to be verified, sorts all the field information according to the original field arrangement rule after submission, and simultaneously the front end forwards a request of authorization content;
step 5.4, after receiving the request transmitted from the front end, the relying party firstly obtains the public key PK of the user on the identity chain according to the user global identity main key UiduserAnd returning the public key information of the user to the relying party SDK, wherein the relying party SDK utilizes the public key PK of the useruserSignature information SIG generated for useruser() Verifying;
step 5.5, after the verification is passed, the dependence party SDK calculates Merkle roots of all attribute fields in all attribute templates, and signs the user global identity main key Uid, the template ID, the user attribute identity main key UserID, the Merkle roots and the timestamp by using the private key SK of the dependence party SDK to obtain signature information SIGRP()；
Step 5.6, the relying party calls the interface of the identity chain to apply the AppIDRPUser global identity primary key Uid, template ID, user attribute identity primary key UserID, Merkle root and signature information SIGRPr() Making an uplink request with the timestamp;
step 5.7, the identity chain stores the data information in an uplink mode, and the following operations are executed at the same time:
1) acquiring user information according to the Uid;
2) according to AppIDRPAcquiring information of a relying party;
3) verifying the correctness of the signature information;
4) verifying a trust list of relying parties;
5) verifying the correctness of the template;
6) verifying the correctness of the Merkle root;
7) recording the authentication behavior;
8) block data is returned.
In one embodiment, the user attribute authentication at stage five comprises the following steps:
step 5.1, the relying party requests the user to authorize a user global identity primary key Uid, a user attribute identity primary key UserID, an attribute template field { att1, att2.. atti } and an attribute template field { attm.. attn } to be verified through a front end, and the front end forwards the request to the user;
step 5.2, the front end executes real-name authentication service for the user, the user is required to transmit four identity factors including an identity card number, a mobile phone number, a verification code and face information into the user, the front end completes real-name authentication of the user identity information based on the four identity factors, and after the authentication is successful, the authentication result is synchronously notified to the user and a relying party;
step 5.3, the user sends a user global identity primary key Uid, a user attribute identity primary key UserID, an attribute template field { att1, att2.. atti } and an attribute template field to be verified { attm.. attn } to the front end, the field which is not verified in the front end attribute template carries out hash operation, and the field plaintext to be verified is submitted;
step 5.4, the front end forwards authorization request information { a user global identity primary key Uid, a user attribute identity primary key UserID, and current all attribute template field information { hash (att1).. attm.. attn.. hash { atti } } };
step 5.5, the relying party calls the SDK to apply the AppIDRPCarrying out a cochain request on a user global identity primary key Uid, a template ID, a user attribute identity primary key UserID, a template ID, a timeStamp and current all attribute template field information { hash (att1).. attm.. attn.. hash { atti };
step 5.6, the relying party calculates all current attribute template field information { hash (att1).. attm.. attn.. hash { atti } submitted by the user uplink to obtain a Merkle root, and meanwhile, the relying party utilizes a private key SK of the relying party to carry out AppID information on the uplinkRPCarrying out digital signature on the user global identity main key Uid, the user attribute identity main key UserID, the template ID, the Merkle root and the timeStamp to obtain signature information SIGRP()；
Step 5.7, the relying party calls the interface of the identity chain to apply the AppIDRPAll usersA bureau identity primary key Uid, a user attribute identity primary key UserID, a template ID, a Merkle root and signature information SIGRPr() Making an uplink request with the timestamp;
step 5.8, the identity chain stores the data information in an uplink mode, and meanwhile the following operations are executed:
1) acquiring user information according to the Uid;
2) according to AppIDRPAcquiring information of a relying party;
3) verifying the correctness of the signature information;
4) verifying a trust list of relying parties;
5) verifying the correctness of the template;
6) verifying the correctness of the Merkle root;
7) recording the authentication behavior;
8) block data is returned.
In summary, due to the adoption of the technical scheme, the invention has the beneficial effects that:
(1) the attribute identity information of the user is completely managed and controlled by the user independently;
(2) the cross-platform and cross-system cross-domain identity authentication of the user is realized;
(3) the attribute identity information is stored based on the Merkle tree, so that the attribute identity information of the user can not be tampered and integrity verification is guaranteed.
(4) The identity chain provides corresponding SDKs for the attribute provider and the relying party, so that the attribute provider and the relying party can be conveniently and quickly accessed;
(5) the operator is used for auditing and verifying the organization access, so that the controllability and the supervision capability of the identity chain on the attribute provider and the relying party are provided.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present invention, and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained according to the drawings without inventive efforts.
Fig. 1 is a system architecture diagram of a method for constructing an identity chain according to an embodiment of the present invention.
Fig. 2 is a flow diagram of the registration of an attribute provider and a relying party in an embodiment of the invention.
FIG. 3 is a flow chart of the creation of an attribute template according to an embodiment of the present invention.
Fig. 4 is a flowchart of importing user attribute identity information according to an embodiment of the present invention.
FIG. 5 is a flow diagram of the creation of a trust list of an embodiment of the present invention.
Fig. 6 is a flowchart of a first embodiment of user attribute authentication according to the present invention.
Fig. 7 is a flowchart of a second embodiment of user attribute authentication according to the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. The components of embodiments of the present invention generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations.
Thus, the following detailed description of the embodiments of the present invention, presented in the figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of selected embodiments of the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Examples
Based on the current status of identity management and identity authentication, and oriented to the application requirements of electronic identity information management, authentication use and the like, the invention constructs a unified identity chain based on the block chain technology, and various identity attribute providers and dependents are jointly accessed into the identity chain, wherein the attribute provider imports user identity attribute information, and the dependents can finish the authentication of user identities through the user identity information recorded on the identity chain. Meanwhile, the user can realize the management and application of personal digital identity through the identity chain. The identity chain provides important credible support for identity authentication. As shown in fig. 1, the identity chain system architecture of this embodiment encapsulates an attribute provider SDK and a relying party SDK, and the identity chain service mainly provides identity registration and identity authentication for the outside through the SDK. The method for constructing an identity chain implemented in this embodiment includes five stages: registering an attribute provider and a relying party, creating an attribute template, importing user attribute identity information, creating a trust list and authenticating a user attribute identity.
As shown in fig. 2, stage one: registration of an attribute provider (identity management system) and a relying party (identity authentication system)
Step 1.1, an attribute provider and a relying party initiate a registration request by submitting information such as a role identifier (AppID), a unified social credit code, an organization name, a legal identity card, an organization registration address and the like to a system;
step 1.2, the identity chain utilizes the SDKs of the attribute provider and the depended party to generate an AppID, a public key PK and a private key SK for the attribute provider and the depended party, and utilizes the generated private key SK to digitally sign information such as the AppID, an organization name, a legal identity card, an organization registration address, the public key PK and the like, so as to generate signature information SIG ();
step 1.3, the attribute provider and the relying party initiate a cochain request by the agency name, the unified social credit code, the AppID, the public key PK, the legal identity card, the agency registration address and the signature information SIG ();
step 1.4, verifying signature information SIG () by an identity chain and judging whether AppID is unique, if the signature information is verified to be correct and the AppID is unique, chaining and storing registration information of an attribute provider and a relying party, and returning block data; otherwise, rejecting the registration application.
As shown in fig. 3, stage two: creation of an Attribute template
Step 2.1, the attribute provider calls an attribute template creating interface, and the attribute template creating interface is transmitted into the attribute provider according to the attribute template creating interfaceAppID and private key SK of attribute providerIDPInformation such as template ID, template type, template name, template field { att1, att2.. atti }, version number and state identification; recording AppID of attribute provider as AppIDIDP；
Step 2.2, the identity chain utilizes the SDK of the attribute provider to apply to the incoming AppIDPPrivate key SKIDPThe signature information SIG is generated by digitally signing information such as template ID, template type, template name, template fields { att1, att2.. atti }, version number and state identificationIDP()；
Step 2.3, the attribute provider calls the attribute template uplink request interface to applyIDPTemplate ID, template type, template name, template fields { att1, att2.. atti }, version number, state identification, and signature information SIGIDP() Uplink storage;
step 2.4, verifying signature information SIG by identity chainIDP() Judging whether the ID of the attribute template is unique, if the signature information is verified to be correct and the ID of the attribute template is unique, successfully creating the attribute template, and returning block data; otherwise, the attribute template creation fails.
As shown in fig. 4, stage three: import of user attribute identity information
Step 3.1, the attribute provider calls an attribute identity information import interface to applyIDPPrivate key SKIDPWriting information such as the identity card number hash value of the user, the mobile phone number, the user global identity primary key Uid, the user attribute identity primary key UserID, the template ID, the Merkle root, the template fields { att1, att2.. atti }, the version number, the timestamp and the effective identifier, the user public key PK, the extension field and the like into an identity chain, wherein the rest of the information is necessary to be filled except the user public key PK and the extension field;
step 3.2, the identity chain utilizes the SDK of the attribute provider to write in the AppIDPCarrying out digital signature on information such as the ID card number hash value of the user, the mobile phone number, the user global identity primary key Uid, the user attribute identity primary key UserID, the template ID, the Merkle root, the template fields { att1, att2.. atti }, the version number, the timestamp and the effective identifier, and generating a signatureInformation SIGIDP()；
Step 3.3, the attribute provider calls the attribute identity uplink request interface to applyIDPInformation such as the ID card number hash value of the user, the mobile phone number, the user global identity primary key Uid, the user attribute identity primary key UserID, the template ID, the Merkle root, the template fields { att1, att2.. atti }, the version number, the timestamp and the effective identifier, and signature information SIGIDP() Performing uplink storage;
step 3.4, verifying signature information SIG by identity chainIDP() And determine AppIDPIf the signature information is correct and App is verifiedIDPIf the attribute identity information is unique, the attribute identity information is successfully imported, and block data is returned; otherwise, the import of the attribute identity information fails.
As shown in fig. 5, stage four: trust list creation
Step 4.1, the relying party calls a trust list creating request in the system, and the AppID of the relying party and the private key SK of the relying party are usedRPAnd AppIDPUploading information such as lists and the like; recording the AppID of the dependent party as AppIDRP；
Step 4.2, the identity chain utilizes the dependent party's SDK to the uploaded AppIDRP、AppIDPDigitally signing the list and timestamp information to generate signature information SIGRP()；
Step 4.3, the relying party calls the uplink request interface to apply the AppIDRP、AppIDPList and signature information SIGRP() Uplink storage;
step 4.4, the identity chain verifies the signature information SIGRP() If the signature information is correct, the AppID is verifiedRPAnd AppIDPThe list is associated and block data is returned.
And a fifth stage: user attribute identity authentication
This stage five of the example provides two embodiments:
as shown in fig. 6, in the first embodiment:
step 5.1, the relying party requests the user to authorize a user global identity primary key Uid, a user attribute identity primary key UserID, an attribute template field { att1, att2.. atti } and an attribute template field { attm.. attn } to be verified through a front end, and the front end forwards the request to the user;
step 5.2, the user authorizes information such as a user global identity primary key Uid, a user attribute identity primary key UserID, an attribute template field needing to be verified and the like, and utilizes a self private key SKuserDigitally signing the above information to generate signature information SIGuser()；
Step 5.3, the user carries out Hash operation on the fields which are not verified in the attribute template through the front end, submits the plaintext of the fields which need to be verified, sorts all the field information according to the original field arrangement rule after submission, and simultaneously the front end forwards a request of authorization content;
step 5.4, after receiving the request transmitted from the front end, the relying party firstly obtains the public key PK of the user on the identity chain according to the user global identity main key UiduserAnd returning the public key information of the user to the relying party SDK, wherein the relying party SDK utilizes the public key PK of the useruserSignature information SIG generated for useruser() Verifying;
step 5.5, after the verification is passed, the dependence party SDK calculates Merkle roots of all attribute fields in all attribute templates, and signs information such as a user global identity main key Uid, a template ID, a user attribute identity main key UserID, the Merkle roots and a timestamp by using a private key SK of the dependence party SDK to obtain signature information SIGRP()；
Step 5.6, the relying party calls the interface of the identity chain to apply the AppIDRPUser global identity primary key Uid, template ID, user attribute identity primary key UserID, Merkle root and signature information SIGRPr() Making an uplink request with the timestamp;
step 5.7, the identity chain stores the data information in an uplink mode, and the following operations are executed at the same time:
1) acquiring user information according to the Uid;
2) according to AppIDRPAcquiring information of a relying party;
3) verifying the correctness of the signature information;
4) verifying a trust list of relying parties;
5) verifying the correctness of the template;
6) verifying the correctness of the Merkle root;
7) recording the authentication behavior;
8) block data is returned.
As shown in fig. 7, embodiment two:
step 5.1, the relying party requests the user to authorize a user global identity primary key Uid, a user attribute identity primary key UserID, an attribute template field { att1, att2.. atti } and an attribute template field { attm.. attn } to be verified through a front end, and the front end forwards the request to the user;
step 5.2, the front end executes real-name authentication service for the user, the user is required to transmit four identity factors including an identity card number, a mobile phone number, a verification code and face information into the user, the front end completes real-name authentication for the identity information of the user based on the four identity factors, and after the authentication is successful, the authentication result is synchronously notified to the user and a relying party;
step 5.3, the user sends related information such as a user global identity primary key Uid, a user attribute identity primary key UserID, attribute template fields { att1, att2.. atti } and attribute template fields { attm.. attn } to be verified to the front end, hash operation is carried out on fields which are not verified in the attribute template of the front end, and plaintext of the fields to be verified is submitted;
step 5.4, the front end forwards authorization request information { a user global identity primary key Uid, a user attribute identity primary key UserID, and current all attribute template field information { hash (att1).. attm.. attn.. hash { atti } } };
step 5.5, the relying party calls the SDK to apply the AppIDRPCarrying out a cochain request on a user global identity primary key Uid, a template ID, a user attribute identity primary key UserID, a template ID, a timeStamp and current all attribute template field information { hash (att1).. attm.. attn.. hash { atti };
step 5.6, the relying party calculates all current attribute template field information { hash (att1).. attm.. attn.. hash { atti } submitted by the user uplink to obtain a Merkle root, and meanwhile, the relying party calculates all current attribute template field information { hash (att1).. attm.. attn.. hash { atti }, and simultaneously obtains the Merkle rootRelying party utilizes its own private key SK to AppID of uplink informationRPCarrying out digital signature on the user global identity main key Uid, the user attribute identity main key UserID, the template ID, the Merkle root and the timeStamp to obtain signature information SIGRP()；
Step 5.7, the relying party calls the interface of the identity chain to apply the AppIDRPUser global identity primary key Uid, user attribute identity primary key UserID, template ID, Merkle root and signature information SIGRPr() Making an uplink request with the timestamp;
step 5.8, the identity chain stores the data information in an uplink mode, and meanwhile the following operations are executed:
1) acquiring user information according to the Uid;
2) according to AppIDRPAcquiring information of a relying party;
3) verifying the correctness of the signature information;
4) verifying a trust list of relying parties;
5) verifying the correctness of the template;
6) verifying the correctness of the Merkle root;
7) recording the authentication behavior;
8) block data is returned.
According to the method, the identity chain constructs an identity alliance consisting of the user attribute identity provider, the relying party and the user in a mode based on the alliance chain. In the identity alliance, an attribute provider and a relying party need to submit corresponding qualification information before accessing the identity alliance, an operator in an identity chain system can check the qualification information submitted by the attribute provider and the relying party, and after the checking is passed, the digital identity information of a user is imported by the attribute provider. The relying party consists of various service systems and application platforms and is used for realizing the authentication of the attribute identity information provided by the attribute provider. In the distributed account book of the identity chain, the encrypted attribute identity information of the user and the Merkle root of all the identity information of the user are stored, wherein the integrity check of the identity information of the user can be realized through the Merkle root. Meanwhile, a trust list established between an attribute provider and a relying party is stored in an account book of an identity chain, and the establishment and storage of the trust list provide queriable trust rules and authentication specifications for cross-domain identity authentication of a user.
In addition, all attribute identity information of the user in the identity chain is stored in a Merkle tree mode, and the SHA256 algorithm and the data structure in the Merkle tree ensure that the attribute identity information of the user cannot be tampered and integrity is verified, so that privacy protection of the attribute identity information of the user is realized, and leakage of the private attribute identity information of the user is avoided. In the invention, corresponding public and private key information is generated for the user according to the standard elliptic curve SM2p256v1, wherein the SM2 algorithm (GM/T0003) is used as a digital signature algorithm in the identity chain system platform, thereby not only improving the speed of signature and signature verification, but also ensuring the legitimate rights and interests of the user.
So far, the method for constructing the identity chain has the following beneficial effects:
(1) the attribute identity information of the user is completely managed and controlled by the user independently;
(2) the cross-platform and cross-system cross-domain identity authentication of the user is realized;
(3) the attribute identity information is stored based on the Merkle tree, so that the attribute identity information of the user can not be tampered and integrity verification is guaranteed.
(4) The identity chain provides corresponding SDKs for the attribute provider and the relying party, so that the attribute provider and the relying party can be conveniently and quickly accessed;
(5) the operator is used for auditing and verifying the organization access, so that the controllability and the supervision capability of the identity chain on the attribute provider and the relying party are provided.
The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims (6)

1. A method for constructing an identity chain, comprising:
stage one: registration of attribute providers and dependents;
and a second stage: creating an attribute template;
and a third stage: importing user attribute identity information;
and a fourth stage: establishing a trust list;
and a fifth stage: user attribute identity authentication;
phase one the registration of the attribute provider and the relying party comprises the steps of:
step 1.1, an attribute provider and a relying party initiate a registration request by submitting a role identifier AppID, a unified social credit code, an organization name, a legal identity card and an organization registration address to a system;
step 1.2, the identity chain utilizes the SDKs of the attribute provider and the depended party to generate an AppID, a public key PK and a private key SK for the attribute provider and the depended party, and utilizes the generated private key SK to digitally sign the AppID, the organization name, the legal identity card, the organization registration address and the public key PK to generate signature information SIG ();
step 1.3, the attribute provider and the relying party initiate a cochain request by the agency name, the unified social credit code, the AppID, the public key PK, the legal identity card, the agency registration address and the signature information SIG ();
step 1.4, verifying signature information SIG () by an identity chain and judging whether AppID is unique, if the signature information is verified to be correct and the AppID is unique, chaining and storing registration information of an attribute provider and a relying party, and returning block data; otherwise, rejecting the registration application.
2. The method for constructing the identity chain according to claim 1, wherein the creation of the attribute template at stage two comprises the following steps:
step 2.1, the attribute provider calls an attribute template creating interface, and the AppID and the private key SK of the attribute provider are transmitted to the attribute provider according to the attribute template creating interfaceIDPTemplate ID, template type, template name, template fields { att1, att2.. atti }, version number, and state identification; note the bookAppID of attribute provider is AppIDIDP；
Step 2.2, the identity chain utilizes the SDK of the attribute provider to apply to the incoming AppIDPPrivate key SKIDPThe signature information SIG is generated by digitally signing the template ID, the template type, the template name, the template field { att1, att2.. atti }, the version number and the state identifierIDP()；
Step 2.3, the attribute provider calls the attribute template uplink request interface to applyIDPTemplate ID, template type, template name, template fields { att1, att2.. atti }, version number, state identification, and signature information SIGIDP() Uplink storage;
step 2.4, verifying signature information SIG by identity chainIDP() Judging whether the ID of the attribute template is unique, if the signature information is verified to be correct and the ID of the attribute template is unique, successfully creating the attribute template, and returning block data; otherwise, the attribute template creation fails.
3. The method for constructing the identity chain according to claim 2, wherein the importing of the user attribute identity information in stage three comprises the following steps:
step 3.1, the attribute provider calls an attribute identity information import interface to applyIDPPrivate key SKIDPWriting the identity card number hash value of the user, the mobile phone number, the user global identity primary key Uid, the user attribute identity primary key UserID, the template ID, the Merkle root, the template fields { att1, att2.. atti }, the version number, the timestamp and the effective identifier, the user public key PK and the extension field into an identity chain;
step 3.2, the identity chain utilizes the SDK of the attribute provider to write in the AppIDPCarrying out digital signature on the ID card number hash value of the user, the mobile phone number, the user global identity primary key Uid, the user attribute identity primary key UserID, the template ID, the Merkle root, the template fields { att1, att2.. atti }, the version number, the timestamp and the effective identifier to generate signature information SIGIDP()；
Step 3.3, the attribute provider calls the attribute identity uplink request interface to applyIDPThe system comprises a user identity card number hash value, a mobile phone number, a user global identity primary key Uid, a user attribute identity primary key UserID, a template ID, a Merkle root, template fields { att1, att2.. atti }, a version number, a timestamp and a valid identifier and signature information SIGIDP() Performing uplink storage;
step 3.4, verifying signature information SIG by identity chainIDP() And determine AppIDPIf the signature information is correct and App is verifiedIDPIf the attribute identity information is unique, the attribute identity information is successfully imported, and block data is returned; otherwise, the import of the attribute identity information fails.
4. The method for building the identity chain according to claim 3, wherein the creation of the trust list in stage four comprises the following steps:
step 4.1, the relying party calls a trust list creating request in the system, and the AppID of the relying party and the private key SK of the relying party are usedRPAnd AppIDPUploading the list; recording the AppID of the dependent party as AppIDRP；
Step 4.2, the identity chain utilizes the dependent party's SDK to the uploaded AppIDRP、AppIDPDigitally signing the list and the timestamp to generate signature information SIGRP()；
Step 4.3, the relying party calls the uplink request interface to apply the AppIDRP、AppIDPList and signature information SIGRP() Uplink storage;
step 4.4, the identity chain verifies the signature information SIGRP() If the signature information is correct, the AppID is verifiedRPAnd AppIDPThe list is associated and block data is returned.
5. The method for building the identity chain according to claim 4, wherein the user attribute identity authentication in stage five comprises the following steps:
step 5.1, the relying party requests the user to authorize a user global identity primary key Uid, a user attribute identity primary key UserID, an attribute template field { att1, att2.. atti } and an attribute template field { attm.. attn } to be verified through a front end, and the front end forwards the request to the user;
step 5.2, the user authorizes the user global identity primary key Uid, the user attribute identity primary key UserID and the attribute template field { attmuserDigitally signing the above information to generate signature information SIGuser()；
Step 5.3, the user carries out Hash operation on the fields which are not verified in the attribute template through the front end, submits the plaintext of the fields which need to be verified, sorts all the field information according to the original field arrangement rule after submission, and simultaneously the front end forwards a request of authorization content;
step 5.4, after receiving the request transmitted from the front end, the relying party firstly obtains the public key PK of the user on the identity chain according to the user global identity main key UiduserAnd returning the public key information of the user to the relying party SDK, wherein the relying party SDK utilizes the public key PK of the useruserSignature information SIG generated for useruser() Verifying;
step 5.5, after the verification is passed, the dependence party SDK calculates Merkle roots of all attribute fields in all attribute templates, and signs the user global identity main key Uid, the template ID, the user attribute identity main key UserID, the Merkle roots and the timestamp by using the private key SK of the dependence party SDK to obtain signature information SIGRP()；
Step 5.6, the relying party calls the interface of the identity chain to apply the AppIDRPUser global identity primary key Uid, template ID, user attribute identity primary key UserID, Merkle root and signature information SIGRPr() Making an uplink request with the timestamp;
step 5.7, the identity chain stores the data information in an uplink mode, and the following operations are executed at the same time:
1) acquiring user information according to the Uid;
2) according to AppIDRPAcquiring information of a relying party;
3) verifying the correctness of the signature information;
4) verifying a trust list of relying parties;
5) verifying the correctness of the template;
6) verifying the correctness of the Merkle root;
7) recording the authentication behavior;
8) block data is returned.
6. The method for building the identity chain according to claim 4, wherein the user attribute identity authentication in stage five comprises the following steps:
step 5.1, the relying party requests the user to authorize a user global identity primary key Uid, a user attribute identity primary key UserID, an attribute template field { att1, att2.. atti } and an attribute template field { attm.. attn } to be verified through a front end, and the front end forwards the request to the user;
step 5.2, the front end executes real-name authentication service for the user, the user is required to transmit four identity factors including an identity card number, a mobile phone number, a verification code and face information into the user, the front end completes real-name authentication of the user identity information based on the four identity factors, and after the authentication is successful, the authentication result is synchronously notified to the user and a relying party;
step 5.3, the user sends a user global identity primary key Uid, a user attribute identity primary key UserID, an attribute template field { att1, att2.. atti } and an attribute template field to be verified { attm.. attn } to the front end, the field which is not verified in the front end attribute template carries out hash operation, and the field plaintext to be verified is submitted;
step 5.4, the front end forwards authorization request information { a user global identity primary key Uid, a user attribute identity primary key UserID, and current all attribute template field information { hash (att1).. attm.. attn.. hash { atti } } };
step 5.5, the relying party calls the SDK to apply the AppIDRPCarrying out a cochain request on a user global identity primary key Uid, a template ID, a user attribute identity primary key UserID, a timeStamp and current all attribute template field information { hash (att1).. attm.. attn.. hash { atti };
step 5.6, the relying party calculates all current attribute template field information { hash (att1).. attm.. attn.. hash { atti } submitted by the user uplink to obtainTo the Merkle root, the relying party uses its own private key SK to apply the UpID to the uplink informationRPCarrying out digital signature on the user global identity main key Uid, the user attribute identity main key UserID, the template ID, the Merkle root and the timeStamp to obtain signature information SIGRP()；
Step 5.7, the relying party calls the interface of the identity chain to apply the AppIDRPUser global identity primary key Uid, user attribute identity primary key UserID, template ID, Merkle root and signature information SIGRPr() Making an uplink request with the timestamp;
step 5.8, the identity chain stores the data information in an uplink mode, and meanwhile the following operations are executed:
1) acquiring user information according to the Uid;
2) according to AppIDRPAcquiring information of a relying party;
3) verifying the correctness of the signature information;
4) verifying a trust list of relying parties;
5) verifying the correctness of the template;
6) verifying the correctness of the Merkle root;
7) recording the authentication behavior;
8) block data is returned.
CN202110433733.4A 2021-04-21 2021-04-21 Method for constructing identity chain Active CN113111325B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110433733.4A CN113111325B (en) 2021-04-21 2021-04-21 Method for constructing identity chain

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110433733.4A CN113111325B (en) 2021-04-21 2021-04-21 Method for constructing identity chain

Publications (2)

Publication Number Publication Date
CN113111325A CN113111325A (en) 2021-07-13
CN113111325B true CN113111325B (en) 2022-04-19

Family

ID=76719273

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110433733.4A Active CN113111325B (en) 2021-04-21 2021-04-21 Method for constructing identity chain

Country Status (1)

Country Link
CN (1) CN113111325B (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108270780A (en) * 2018-01-08 2018-07-10 中国电子科技集团公司第三十研究所 A kind of heterogeneous network environment multicenter digital identity management method
CN110941668A (en) * 2019-11-08 2020-03-31 中国电子科技网络信息安全有限公司 Block chain-based unified identity management and authentication method

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170302663A1 (en) * 2016-04-14 2017-10-19 Cisco Technology, Inc. BLOCK CHAIN BASED IoT DEVICE IDENTITY VERIFICATION AND ANOMALY DETECTION
US10528551B2 (en) * 2017-09-29 2020-01-07 Oracle International Corporation System and method for providing a representational state transfer proxy service for a blockchain cloud service
CN109858270A (en) * 2019-02-22 2019-06-07 江苏金智教育信息股份有限公司 A kind of construction method and system of decentralization digital identity
CN110581860B (en) * 2019-09-19 2022-08-26 腾讯科技（深圳）有限公司 Identity authentication method, device, storage medium and equipment based on block chain
CN111046352B (en) * 2019-12-13 2021-05-18 浙江师范大学 Identity information security authorization system and method based on block chain

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108270780A (en) * 2018-01-08 2018-07-10 中国电子科技集团公司第三十研究所 A kind of heterogeneous network environment multicenter digital identity management method
CN110941668A (en) * 2019-11-08 2020-03-31 中国电子科技网络信息安全有限公司 Block chain-based unified identity management and authentication method

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
《A Unified Trust Service Scheme for Heterogeneous Identity Alliance》;董贵山等;《2020 International Conference on Networking and Network Applications (NaNA)》;20210219;第167-173页 *
《Trust Enhancement Scheme for Cross Domain Authentication of PKI System》;白健等;《2019 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery (CyberC)》;20201002;第103-110页 *
《基于区块链的异构身份联盟与监管体系架构和关键机制》;董贵山等;《通信技术》;20200229;第53卷(第2期);第3-4节，以及附图2-3 *
《基于区块链的身份管理认证研究》;董贵山等;《计算机科学》;20181130;第45卷(第11期);正文第3-4节，以及附图9-11 *

Also Published As

Publication number Publication date
CN113111325A (en) 2021-07-13

Similar Documents

Publication Publication Date Title
US11784791B2 (en) Verifying an identity based on multiple distributed data sources using a blockchain to safeguard the identity
CN108898389B (en) Content verification method and device based on block chain and electronic equipment
US20220058655A1 (en) Authentication system
US11121873B2 (en) System and method for hardening security between web services using protected forwarded access tokens
CN110569658B (en) User information processing method and device based on blockchain network, electronic equipment and storage medium
US11757640B2 (en) Non-fungible token authentication
CN112671720B (en) Token construction method, device and equipment for cloud platform resource access control
CN102202306B (en) Mobile security authentication terminal and method
CN105812350B (en) Cross-platform single sign-on system
CN110213223A (en) Business management method, device, system, computer equipment and storage medium
CN111404695B (en) Token request verification method and device
CN114168915A (en) Block chain digital identity generation and verification method
CN112148280B (en) Block chain-based data evidence storage service templated development method
CN108900311A (en) A kind of no certificate bluetooth key endorsement method and system
CN114003925A (en) Signature combined online declaration method and system based on block chain
CN114365134A (en) Secure identity card using unclonable functions
CN111949958A (en) Authorization authentication method and device in Oauth protocol
EP3799683B1 (en) Methods and devices for generating and verifying passwords
CN116886357A (en) Distributed digital identity authentication method, device and medium for mobile platform
CN113111325B (en) Method for constructing identity chain
CN113779637B (en) Attribute data processing method, attribute data processing device, attribute data processing equipment and attribute data processing medium
CN114066708A (en) Traceable picture authorization method and device
CN111049808A (en) Real-name authentication method and device
CN109309917A (en) EID digital identification authentication method and system based on mobile terminal software code module
CN115499247B (en) Zero-knowledge proof-based attribute certificate verification method and device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant