CN115664683A - Cross-domain method based on block chain intelligent contract - Google Patents
Cross-domain method based on block chain intelligent contract Download PDFInfo
- Publication number
- CN115664683A CN115664683A CN202211353171.3A CN202211353171A CN115664683A CN 115664683 A CN115664683 A CN 115664683A CN 202211353171 A CN202211353171 A CN 202211353171A CN 115664683 A CN115664683 A CN 115664683A
- Authority
- CN
- China
- Prior art keywords
- certificate
- identity
- user
- domain
- intelligent contract
- 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.)
- Pending
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The invention discloses a cross-domain method based on a block chain intelligent contract, which comprises the following steps: 1) And (3) constructing a trust union chain and creating a special intelligent contract SC for the issuer issuers. 2) The user generates a self-signed certificate and stores the certificate information in the IPFS, and finally the sender uploads the identity certificate to the intelligent contract. 3) And the verifier acquires the identity certificate and the certificate information and verifies the authenticity of the user. 4) When general cross-domain identity authentication is established, the validity of the intelligent contract address SC _ issuer of the sponsor of the domain where the user to be authenticated is located needs to be inquired in the SC _ Root through the verification process. 5) If the service provider requires to provide the identity attribute information, the Merkle tree is used for carrying out the method of chain uplink and downlink anchoring identity attribute data, and the Merkle root value is verified. The invention takes Root _ SC as a trust anchor, adds a heavy insurance for preventing CA failure, and can directly provide identity attribute authentication service in the cross-domain process.
Description
Technical Field
The invention belongs to the technical field of network communication, and further relates to a cross-domain authentication method based on a block chain intelligent contract in the technical field of identity authentication.
Background
The wide application of the internet in various fields inevitably leads to exponential increase of data interaction demand of a client and a server, and in the existing network environment, in order to meet the demand, an organization or a service provider usually sets an authentication server to realize convenient management of user data. This results in the creation of a large number of relatively independent trust domains, and the user's network services need to be authenticated within the independent trust domain to be accepted or accessed. However, for many resource access and communication requests, a single trust domain where a user is located is difficult to satisfy conditions, and a connection with other trust domains needs to be established, so that wider data support is obtained. This requires providing unique digital identities and cross-domain services for user entities in the network.
Public Key Infrastructure (PKI) is a common deployment of network space that determines the uniqueness, authenticity and legitimacy of entities by maintaining digital certificates, often used in distributed identity management systems that provide digital identities to users. Most of the domain-crossing researches based on the block chain PKI at the present stage still cannot get rid of the influence of the traditional PKI framework, such as single-point failure, complicated certificate life cycle, poor transparency and the like. The cross-domain model based on the block chain mainly uses the CA as a node to build an inter-CA mutual trust relationship formed by alliance chains, so that the authority of the CA is too centralized, and the problem of single-point failure is not thoroughly solved. In addition, the identity of the user is provided by an identity provider in the domain where the user is located, entities in other domains naturally lack trust for the identity, and although the existence of a federation chain can establish contact for identity mutual trust, the trust degree is low, a uniform standard specification is difficult to form, and the security cannot be effectively guaranteed.
Disclosure of Invention
The invention aims to provide a cross-domain authentication method based on a block chain intelligent contract aiming at the problems in the cross-domain identity authentication, so as to provide further security guarantee for CA mutual trust and ensure the reliability and the security of the cross-domain identity authentication.
The idea for realizing the purpose of the invention is as follows: and forming a alliance chain by taking a plurality of prover nodes as main block chain nodes. All users in the system establish and store own identity attributes by taking the users as centers. The prover generates and stores the certificate credential in the smart contract to facilitate the verifier to quickly verify the authenticity of the information. Aiming at the cross-domain problem, the invention uses the trust chain based on the intelligent contract to replace the traditional CA certificate trust chain, solves the CA mutual trust problem, avoids the repeated issuing and verification process of the mutual trust certificate, can improve the efficiency to meet the general cross-domain requirement, and is easy to expand. Moreover, for a special cross-domain scene with more privacy and high security requirements, a method for uplink and downlink anchoring of identity attribute data on a Merkle tree chain is utilized, and the identity attribute authentication service is directly provided while the privacy is protected.
A cross-domain authentication method based on a block chain intelligent contract comprises the following steps.
Step 1, initialization stage: and constructing a trust alliance chain, and creating a special intelligent contract SC for a certifier issuers for signing and issuing user certificates in respective domains and storing certificate certificates.
Step 4, general cross-domain identity authentication: the general cross-domain premise is that the two communicating parties are sufficiently trusted by the provers in the respective domains because of the federation chain, the provers in the two independent trust domains naturally establish a trust relationship.
For example, two users userA in different domains want to establish cross-domain communication with userB in the following procedure.
And 4-1, using the userB as a verifier, needing to check the certificate of the userA and verifying the authenticity of the certificate, wherein the method is consistent with the step 3.
And 4-2, entering the next stage after the verification is passed, and inquiring the validity of the intelligent contract address SC _ issuer of the prover of the domain where the verified user is located in the SC _ Root.
And 4-3, repeating the step 4-1 and the step 4-2 for the reverse authentication from the userB to the userA, thereby realizing the bidirectional authentication.
Step 5, special cross-domain scene operation: users have access to some cross-domain scenarios that require more stringent identity privacy data to be provided.
Step 5-1, the user issues an authentication request to the service provider.
And 5-2, the service provider sends the requirement of the identity attribute needing to be verified to the user.
Step 5-3, the user provides the service provider with a set of identity attributes [ Attr _1, attr_2.., attr _ n ] to be verified, and Hash values and certificate information generated corresponding to other unrelated attributes.
And 5-4, verifying the authenticity of the information, calculating to finally obtain a Merkle root value, and comparing the Merkle root value obtained in the intelligent contract called by the certificate information. And verifying the identity certificate, the method is step 3.
Compared with the prior art, the invention has the following advantages.
First, in the traditional PKI + federation chain mode, the premise of realizing the communication between two entities across domains is that the root CAs in the respective domains of the two parties are trusted, and this trust relationship is based on the federation chain, which is consistent with the general cross-domain scheme expressed by the present invention in the underlying architecture. However, the Root _ SC is added in the scheme of the invention as a trust anchor, and a heavy insurance is added for preventing the CA from doing disorder, so that the scheme is undoubtedly safer compared with the former two schemes.
Second, most of the existing technologies do not consider the situation that the CA in the opposite domain is not trusted or does not exist in any way, that is, the service provider exists independently and does not belong to any specific domain. The problem can be effectively solved by the special cross-domain scheme provided by the invention, the attribute data storage mode based on the Merkle tree can meet the authentication requirement of the service provider, the authenticity of the user identity information is maintained while the privacy is ensured, and only a few times of hash operations for additionally verifying the identity attribute are needed.
Thirdly, the calculation overhead of the PKI cross-domain scheme based on the block chain is mainly embodied in asymmetric encryption and decryption, signature and Hash algorithm. In addition, the invention uses IPFS (interplanetary file system) to store the certificate file, and the user does not need to transmit the complete certificate file (with the size of 2 KB) when communicating with the authentication server. Only ipfsAddr (dozens of bytes) needs to be sent, and communication burden can be effectively reduced.
Drawings
FIG. 1 is a general system model schematic of the present invention.
FIG. 2 is a schematic diagram of the intelligent contract structure of the present invention.
FIG. 3 is a schematic diagram of the identity attribute Merkle of the present invention.
Detailed Description
The present invention will be described in detail below with reference to specific embodiments shown in the drawings.
Fig. 1 is an overall system architecture diagram of the block chain intelligent contract-based cross-domain authentication method of the present invention, and as shown in fig. 1, a system model mainly comprises six entities, namely, a user, a sender, a verifier, an IPFS node, a service provider, and a block chain network. Each part is specifically described below.
1) The user: the certificate holder possesses the identity attribute data and manages the identity attribute by itself. Identity attributes refer to some identity information of a user, such as name, academic calendar, work information, etc., and are referred to herein as attribute sets [ Attr _1, attr_2., attr _ n ].
2) And (3) a sender: and the credible entity has authority, has user data and can carry out reliable endorsement on the identity of the user, such as government, bank, university and company.
3) And (3) verifier: the entity verifying the authenticity of the user identity, and the verifier in the system can be any other user as it does not involve the disclosure of authentic information.
4) IPFS node: IPFS (inter-satellite File System) provides certificate storage service, the storage cost of Ethermen is too high, and certificate files are not recommended to be stored in the IPFS, so that the IPFS is more convenient to use.
5) The service provider: a third party providing network services to a user may have less trust in the prover and may require the user to provide an entity with proof of identity attributes.
6) Block chain network: the invention utilizes an Etherhouse platform, which is the most common platform for using intelligent contracts. The identity certificate is linked up to play a role in preventing tampering, so that a verifier can verify information conveniently.
Fig. 2 is a schematic diagram of an intelligent contract structure, each sub-SC is managed by SC _ Root, and the sub-SC stores therein verifiable identity credential information VC of users in the jurisdiction.
Referring to fig. 1 and fig. 2, the following is a specific implementation process of the cross-domain authentication method of the present invention.
Step 1, initialization phase.
And step 1-1, taking the SC _ Root as a trust anchor, and incorporating the intelligent contract SC addresses owned by the senders of different domains into the trust anchor. It mainly has two modules, respectively valid SC and invalid SC, for storing the corresponding SC address.
Step 1-2, when a new issuers joins the block chain network, the SC _ Root creates an empty contract SC _ n for the new issuers, writes the address of the SC _ n into a valid SC, and finally writes the Ethernet address of the issuers into the empty contract SC _ n, which represents that the ownership of the contract is transferred to the issuers. When an issuer fails or exits the federation chain, the SC that it represents needs to be included in the failed SC.
Each issuer issuers, step 1-3, may have one or more dedicated intelligent contracts SC for issuing user credentials in their respective domains and storing the credential credentials, with contract write operations being performed only by issuers.
And 2, registering the user identity.
Step 2-1, user → issuer: { submit (userInfo) }
The user submits identity information userInfo to the licensor. The identity information is a set of a plurality of identity attributes [ Attr _1, attr_2, attr_3., attr _ n ], wherein the identity attributes required to be verified and audited by different provers are different, and a user submits a corresponding identity attribute set according to the requirements.
Step 2-2, issure → user: { verify (userInfo) }send (contignaddr) }
After the verification of the sender is successful, the address of the CA agent intelligent contract and the address of the root intelligent contract are called and returned to the user.
Step 2-3, user: { generateCert }
The user generates a self-signed certificate Cert and uses the contract address as a certificate issuer. The invention uses self-signed certificate, and for the structure of X.509 digital certificate, the main change lies in the issuer's column: CN = SC _ issue Addr, smart contract address represented by the prover; o = SC _ Root Addr, root smart contract address.
Step 2-4, IFPS: { ipfsAdd (Cert, pk _ u) }
And uploading the certificate file and the user public key to the IPFS node, and returning the ipfsAddr.
Steps 2-5, user → issuer: { generateID (CertHash, ipfsAddr, T) and ipfsAddr }.
Step 2-6, issuer { VC → Smart Contract }
The user generates a unique identity credential ID using the certificate hash value and the ipfs address and a timestamp T (where T ensures the uniqueness of the ID), and the prover writes the verifiable identity credential VC into the smart contract. The VC contains the ID, certHash, ipfsAddr, timetag, and Merkle root.
And step 3, identity authentication.
Step 3-1, verifier → user: { verify request; the random N }
The verifier initiates a verification request to the user and sends the generated random number N to the user.
Step 3-2, user → verifier: { Sign (N), (ipfsAddr, ID) }
The user signs the random number by using a private key of the user, and packs and sends the signature Sign (N), the ipfsAddr and the ID to the verifier.
Step 3-3, verifier \8596IPFS: { getInfo (ipfsAddr) → Cert, pk _ u; verify (Sign (N)) }
And acquiring the user certificate and the public key information from the IPFS through the ipfsAddr, and verifying the signature by using the user public key by the verifier.
Step 3-4, verifier \8596blockchain { get _ VC; if (Verify (CertHash, ipfsAddr, T, ID)) = True }
After the verifier calls the intelligent contract to obtain the identity credential through the contract address existing in the certificate, whether the ID is generated by the certificate hash and the IPFS address needs to be verified so as to ensure the ID authenticity, and the result is True.
Step 3-5, verifier { Verify (VC, cert) → True or False }
And finally, verifying all the obtained information, and comparing the identity certificate VC with the certificate information to prevent the information from being tampered. And if the verification is passed, outputting True, and successfully verifying the identity.
As shown in fig. 1, after the identity authentication of the userA and the userB in their respective domains through the above steps is successful, the following steps are also required for the two users to establish cross-domain communication.
And 4, general cross-domain identity authentication.
Step 4-1, because of the existence of the federation chain, issuer1 and Issuer2 have naturally established a trust relationship. And the userB serves as a verifier for verifying the certificate of the userA, and the method is consistent with the step 3.
And 4-2, entering the next stage after the verification is passed, finding the contract address SC _ issuer where the sender is located and the SC _ Root address where the sender belongs in the item of the issuer of the certificate, searching whether the address of the SC _ issuer exists in the invalid SC in the SC _ Root, and searching the SC _ issuer in the valid SC if the address of the SC _ issuer does not exist in the invalid SC. If so, the identity of userA is valid.
And 4-3, repeating the step 4-1 and the step 4-2 in the reverse authentication from the userB to the userA, thereby realizing the bidirectional authentication.
For special occasions, users access cross-domain situations requiring more strict identity privacy data, such as bank services and other situations involving monetary transactions, which provide a lower authentication acceptance for the identity provided by the prover, i.e. the trust level is not sufficient to offset the potential security risk. This undoubtedly puts higher demands on the privacy and security as well as the authority of the identity authentication.
When a service provided by a service provider is accessed across domains for the first time, it needs to be provided with specific identity attributes. For the user, the identity information is a collection of multiple identity attributes [ Attr _1, attr _2, attr _3,. And Attr _ n ], using a Merkle tree-based attribute data storage approach. The method ensures the consistency of the uplink and downlink information of the block chain, and simultaneously meets the privacy security of the identity attribute.
Step 4, the general cross-domain identity authentication method cannot meet the requirements, and the operation of step 5 needs to be performed.
And 5, performing special cross-domain scene operation.
Fig. 3 is a schematic diagram of identity attribute Merkle, which is a complete Merkle tree composed of a plurality of identity attributes, and Merkle root is added to a certificate credential written in a smart contract during user identity registration. Due to the characteristics of the hash function, anyone cannot directly obtain the identity attribute of the user through the Merkle root value. If the user needs to provide [ Attr _2] to the service provider A on demand when accessing the service provider A, the user sends [ Hash1, hash34] in the locally stored Merkle tree to the service provider together. After the service provider obtains the data, the Hash value of [ Attr _2] is calculated, then the calculation is carried out with [ Hash1, hash34] to finally obtain the Merkle root value, and the Merkle root value is compared with the Merkle root value obtained in the intelligent contract called by the certificate information. If the two are consistent, the authentication of the user is successful, and the user can access the service. The specific process is as follows.
Step 5-1, user → server A: { request (assert) }
The user initiates an authentication request to the service provider a.
Step 5-2, server A → user: { requset (Attr), N, pk _ A }
The service provider A sends a requirement of the required identity attribute to the user, wherein pk _ A is the temporary public key of the service provider A, and N is a random number, and the function is to prevent replay attack.
Step 5-3, user → server A: { Enpk _ A (Attr _2, N, ipfsAddr, ID), [ Hash1, hash34] }
After receiving the reply, the user encrypts the Attr _2 to be verified, the random number N and the certificate information through pk _ A and returns the encrypted result to A. Because of the privacy of identity involved in the transmission, an asymmetric encryption algorithm is used here for security, rather than a signature.
Step 5-4, server A { verify (Attr _ 2) }
And the service provider decrypts the message after receiving the response of the user, and verifies the authenticity of the attribute according to the obtained information under the condition of ensuring the correctness of the random number.
Claims (6)
1. A cross-domain method based on a block chain intelligent contract is characterized by comprising the following specific steps:
step 1, initialization stage: establishing a trust union chain, establishing a special intelligent contract SC for a certifier issuers, and signing and issuing user certificates in respective domains and storing certificate certificates;
step 2, user identity registration: the user sends the identity information to a certificate sender to request authenticity verification; after the certification issuer verifies and verifies, the contract address is returned to the user, the user generates a self-signed certificate and stores the certificate information in the IPFS, and finally, the identity certificate is uploaded to the intelligent contract by the certification issuer;
step 3, identity authentication: the verifier sends a verification request to the user, calls an intelligent contract through a contract address in the certificate to obtain an identity certificate, obtains certificate information from the IPFS and verifies the authenticity of the certificate and the intelligent contract;
step 4, general cross-domain identity authentication: the general cross-domain premise is that two communicating parties are sufficiently trusted to the provers in the respective domains, because of the existence of the federation chain, the provers in two independent trust domains naturally establish a trust relationship, for example, two users userA in different domains need to establish cross-domain communication with userB, and the process is as follows:
step 4-1, the userB is used as a verifier, the certificate of the userA needs to be checked, the authenticity of the certificate is verified, and the method is consistent with the step 3;
step 4-2, entering the next stage after the verification is passed, and inquiring the validity of the intelligent contract address SC _ issuer of the sponsor of the domain where the verified user is located in the SC _ Root;
4-3, repeating the step 4-1 and the step 4-2 for the reverse authentication from the userB to the userA, thereby realizing the bidirectional authentication;
step 5, special cross-domain scene operation: users access some cross-domain scenarios that require more stringent identity privacy data;
step 5-1, the user sends an authentication request to the service provider;
step 5-2, the service provider sends the identity attribute requirement to be verified to the user;
step 5-3, the user provides a set [ Attr _1, attr_2, attr _ n ] of identity attributes needing to be verified to a service provider, and Hash values and certificate information generated corresponding to other irrelevant attributes;
and 5-4, verifying the authenticity of the information, calculating to finally obtain a Merkle root value, comparing the Merkle root value obtained in the intelligent contract called by the certificate information, and verifying the identity certificate, wherein the method is the step 3.
2. The domain crossing method based on the blockchain intelligent contract according to claim 1, wherein the step 1 specifically comprises the following steps:
step 1-1, taking SC _ Root as a trust anchor, and incorporating the intelligent contract SC addresses owned by senders in different domains into the trust anchor, wherein the trust anchor mainly comprises two modules which are respectively an effective SC and a failure SC and are used for storing corresponding SC addresses;
step 1-2, when a new issuers joins the block chain network, the SC _ Root creates an empty contract SC _ n for the issuers, writes the SC _ n address into a valid SC, and finally writes the Ether house address of the issuers into the empty contract SC _ n, which represents that the ownership of the contract is transferred to the issuers, and when the issuers fail or quit the alliance chain, the SCs represented by the issuers need to be brought into the failed SC;
each issuer issuers, step 1-3, may have one or more dedicated intelligent contracts SC for issuing user credentials in their respective domains and storing the credential credentials, with contract write operations being performed only by issuers.
3. The cross-domain method based on the intelligent blockchain contract according to claim 1, wherein the user identity registration in step 2 uses a self-signed certificate, and for the structure of the X.509 digital certificate, the main change lies in the issuer's columns: CN = SC _ issue Addr, the smart contract address represented by the prover; o = SC _ Root Addr, root smart contract address.
4. The cross-domain method based on the blockchain intelligent contract, according to claim 1, wherein in step 3, the verifier obtains the user certificate from the IPFS through the ipfsAddr, and obtains the identity certificate through invoking the intelligent contract at the contract address, and then verifies the authenticity of the information, instead of obtaining the user verification information from the issuer.
5. The block chain intelligent contract-based cross-domain method according to claim 1, wherein in step 4, the cross-domain parties need to verify not only the authenticity of the certificate information but also the validity of the contract address of the prover, and the specific process is as follows:
step 4-1, because of the existence of the alliance chain, the trust relationship is naturally established between the answer 1 and the answer 2, the userB is used as a verifier to verify the certificate of the userA, and the method is consistent with the identity verification step;
step 4-2, entering the next stage after the verification is passed, finding out a contract address SC _ issuer where the sender is located and an SC _ Root address where the sender belongs in a project of a certificate issuer, finding out whether the address of the SC _ issuer exists in a failure SC in the SC _ Root, if not, finding out the SC _ issuer in a valid SC, and if so, indicating that the identity of the useRA is valid;
and 4-3, repeating the step 4-1 and the step 4-2 in the reverse authentication from the userB to the userA, thereby realizing the bidirectional authentication.
6. The method of claim 1, wherein when the service provider requests to verify the identity attribute of the user, the step 5 verifies whether the attribute hash is consistent with the Merkle root stored in the intelligent contract, and it uses the attribute data storage method based on the Merkle tree to ensure the consistency of the information under the blockchain.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211353171.3A CN115664683A (en) | 2022-11-01 | 2022-11-01 | Cross-domain method based on block chain intelligent contract |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211353171.3A CN115664683A (en) | 2022-11-01 | 2022-11-01 | Cross-domain method based on block chain intelligent contract |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115664683A true CN115664683A (en) | 2023-01-31 |
Family
ID=84994669
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211353171.3A Pending CN115664683A (en) | 2022-11-01 | 2022-11-01 | Cross-domain method based on block chain intelligent contract |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115664683A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117951680A (en) * | 2024-03-25 | 2024-04-30 | 信通院(江西)科技创新研究院有限公司 | Software supply chain dynamic tracking method and tracking platform based on block chain |
-
2022
- 2022-11-01 CN CN202211353171.3A patent/CN115664683A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117951680A (en) * | 2024-03-25 | 2024-04-30 | 信通院(江西)科技创新研究院有限公司 | Software supply chain dynamic tracking method and tracking platform based on block chain |
| CN117951680B (en) * | 2024-03-25 | 2024-05-31 | 信通院(江西)科技创新研究院有限公司 | Software supply chain dynamic tracking method and tracking platform based on block chain |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109829326B (en) | Cross-domain authentication and fair audit de-duplication cloud storage system based on block chain | |
| US10554421B2 (en) | Method for superseding log-in of user through PKI-based authentication by using smart contact and blockchain database, and server employing same | |
| CN110138560B (en) | Double-proxy cross-domain authentication method based on identification password and alliance chain | |
| US10659236B2 (en) | Method for superseding log-in of user through PKI-based authentication by using blockchain database of UTXO-based protocol, and server employing same | |
| CN114186248B (en) | Zero-knowledge proof verifiable certificate digital identity management system and method based on block chain intelligent contracts | |
| CN112055025B (en) | Privacy data protection method based on block chain | |
| CN112818368A (en) | Digital certificate authentication method based on block chain intelligent contract | |
| EP3764308A1 (en) | Blockchain-based system, and electronic apparatus and method in the system | |
| CN109327481B (en) | Block chain-based unified online authentication method and system for whole network | |
| CN101938473B (en) | Single-point login system and single-point login method | |
| US20090055916A1 (en) | Secure delegation using public key authentication | |
| CN113507458B (en) | Cross-domain identity authentication method based on block chain | |
| CN113824563B (en) | Cross-domain identity authentication method based on block chain certificate | |
| CN101374159B (en) | Credible control method and system for P2P network | |
| CN110177109B (en) | Double-proxy cross-domain authentication system based on identification password and alliance chain | |
| CN111444492A (en) | Digital identity verification method based on medical block chain | |
| CN113343213A (en) | Multi-CA cross-domain authentication method based on block chain in distributed autonomous network | |
| El-Hajj et al. | Ethereum for secure authentication of iot using pre-shared keys (psks) | |
| CN111901432A (en) | Block chain-based safety data exchange method | |
| Li et al. | A Blockchain‐Based Public Auditing Protocol with Self‐Certified Public Keys for Cloud Data | |
| Gulati et al. | Self-sovereign dynamic digital identities based on blockchain technology | |
| Jia et al. | PROCESS: Privacy-preserving on-chain certificate status service | |
| Zhang et al. | Cross-domain identity authentication scheme based on blockchain and PKI system | |
| CN115664683A (en) | Cross-domain method based on block chain intelligent contract | |
| Kubilay et al. | KORGAN: An efficient PKI architecture based on PBFT through dynamic threshold signatures |
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 |