On-chain digital identity privacy protection scheme based on decentralized identifier

Abstract

The invention relates to a decentralized identifier-based on-chain digital identity privacy protection scheme, which specifically comprises the following steps of: selectively revealing declaration based on a BLS signature and a Merkle hash tree for a low privacy scene: replacing a declaration set structure with the hash tree by a publisher, and aggregating the signature by a user; according to the selective disclosure declaration based on BBS + signature for a high privacy scene, a publisher can blindly sign a user certificate, and a user can realize zero-knowledge proof so as to hide attributes; according to the extension layer design based on the universal parser, original direct interaction between the universal parser and a decentralized account book is converted into indirect interaction to process DID document data. The method has the advantage of high time overhead in a low-privacy-degree scene, a certain balance between privacy and time overhead is achieved in a high-privacy-degree scene, meanwhile, privacy during DID document analysis is enhanced, and the association problem in the DID analysis process is relieved.

Description

Technical Field

[0001] The present invention relates to the field of blockchain privacy protection, and in particular to digital identity privacy protection, and specifically to an on-chain digital identity privacy protection solution based on a decentralized identifier. Background Art

[0002] In order to solve the problem that traditional centralized identity authentication systems are usually based on trusted third parties, this dependency makes them vulnerable to single points of failure. The decentralized identifiers represented by blockchain as the underlying foundation, developed by the Decentralized Identity Foundation and the World Wide Web Consortium, came into being, also known as DID, which enables users to fully control and manage their own network identities without relying on any centralized organization, but this will cause privacy issues related to user data. First, the current research based on similar DID structures has good performance in dealing with single scenarios, but lacks flexibility in designing to deal with complex distributed scenarios. There is a problem that the time overhead increases linearly or exponentially when the identity information that needs to be verified increases in large quantities. Secondly, some DID-based solutions have good time performance advantages but do not consider attribute hiding to achieve privacy protection. A very small number of DID-based solutions consider privacy protection design but have large time overhead. Finally, for DID-based solutions, it is necessary to consider the privacy and security issues of DID universal resolvers. In the distributed scenario of the industrial Internet, how to achieve complex identity interactions while protecting the privacy of identity data of different groups or individuals is one of the current challenges.

[0003] There is a certain foundation for digital identity research at present. Bai et al. proposed a decentralized identity authentication system Health-zklDM for medical services. The researchers used zkSNRAK technology to generate and verify identity information, making the system have high throughput and low execution time, but when dealing with a large amount of attribute information, the system computing and storage overhead grows linearly. Zheng et al. proposed a medical insurance claims solution based on zero-knowledge proof, blockchain and smart contracts, which has an acceptable time overhead, but as the identity information increases, the time overhead grows exponentially. The system model framework of the above work is similar to the DID architecture. The DID-based solutions include: Fotiou et al. proposed a self-sovereign and decentralized naming scheme based on DID for information-centric network architecture, which enables content items to be self-verified; Li et al. proposed a smart tourism identity authentication service based on blockchain and DID, which has high authentication efficiency but does not consider attribute privacy protection; Xiong et al. proposed a large-scale decentralized identity management scheme for the Internet of Things based on DID and blockchain. The researchers mainly focused on improving efficiency but did not consider privacy protection; Yin et al. proposed a new type of distributed identity based on DID and blockchain, which achieved the establishment of a self-sovereign identity that provides privacy protection through a designed credential model and a created system proof system. However, due to its tree-structured proof system, the credential weights need to be sorted when verifying the credential, which increases additional time overhead. It is worth noting that these DID-based solutions do not take into account the privacy issues of the DID universal resolver. In the DID service, the main task of the universal resolver is to receive DID requests and return DID documents from the blockchain network specified in the request. As a single entry point for the service, it connects different service providers and distributed ledgers, that is, the universal resolver can associate DID requests with DID documents during the DID resolution process. The adversary can observe the DID resolution process through the universal resolver to collect a large amount of data to associate DIDs and DID documents, and then infer the user's sensitive data. Summary of the invention

[0004] The purpose of the present invention is to propose an on-chain digital identity privacy protection scheme based on decentralized identifiers to achieve different degrees of privacy protection to meet the needs of scenarios with different privacy requirements, and to achieve a certain balance between privacy protection effect and overhead.

[0005] The object of the present invention is achieved in this way:

[0006] A flexible selective disclosure method is proposed to achieve different degrees of privacy protection. For the disclosure of partial statements in low-privacy scenarios, selective disclosure is performed based on BLS signatures and Merkle hash trees to achieve weak privacy protection of the undisclosed parts, in which efficient on-chain authentication is achieved by aggregating signatures of multiple parties. For the disclosure of partial privacy statement equality in high-privacy scenarios, zero-knowledge selective disclosure is achieved based on BBS+signatures, and strong privacy protection is achieved by constructing zero-knowledge proofs. This includes not only allowing the verifier to verify the selectively disclosed statement, but also allowing the publisher to blindly sign the statement to be hidden. An extension layer design that can be used with a universal resolver is proposed based on the parsing mechanism of the existing DID universal resolver. This structural design is based on Intel's trusted execution environment and ORAM implementation, which enhances the privacy when parsing DID documents, thereby enhancing the privacy of users' digital identities.

[0007] The specific method is as follows:

[0008] An on-chain digital identity privacy protection scheme based on decentralized identifiers includes the following steps:

[0009] Step 1: System initialization completes DID registration for each entity;

[0010] Step 2: Choose different disclosure statement methods based on scenario requirements;

[0011] Step 3: For scenarios with low privacy requirements, choose the selective disclosure statement method based on BLS signature and Merkle hash tree, which includes three steps: issuing VC, constructing VP and verifying VP;

[0012] Step 4: For scenarios with high privacy requirements, choose the zero-knowledge selective disclosure statement method based on BBS+signature, which is also divided into three steps: publishing VC, constructing VP, and verifying VP;

[0013] Step 5: When parsing DID documents, the original direct interaction between the universal parser and the decentralized ledger is transformed into an indirect interaction to process the DID document data flow through the designed extension layer based on the universal parser.

[0014] Furthermore, in step 1, the system first initializes various parameters required for generating signatures. The registration of each entity DID is that each participant creates and submits the DID and the corresponding DID document to the DID registry through the existing mature framework technology. The DID document is a JSON document associated with each DID, which contains information such as verification public key, service endpoint, etc., which are securely stored on the distributed ledger. The DID document includes but is not limited to the public key, and the addition, deletion, modification and query of the DID are implemented using the existing mature technology framework, where DID addition: This solution uses the user blockchain address as the DID string, and the public and private keys used for creation are self-generated and managed by the user. The user provides the public key and blockchain address to create the DID and DID document; DID deletion and modification: By constructing revocation transactions and update transactions, once the verification nodes reach a consensus, the revocation transaction will be recorded on the chain and the status of the DID document will be marked as revoked, and the record of the update transaction will cause the updated version of the DID document to be retrieved through the DID query; DID query: Through the DID universal parser, according to the DID query the registry in the distributed ledger, find the corresponding record and parse and return the corresponding DID document.

[0015] Furthermore, when issuing VC in step 3, the publisher constructs a Merkle hash tree of the user's statement set or the statement set provided by the user and calculates the root hash of the tree. The attributes represented by each statement correspond to the leaf nodes in the Merkle hash tree, and the core content is as follows:

[0016] leaves←SHA256(Json.parse(S))

[0017] Tree = new MerkleTree(leaves)

[0018] V root =Tree.getRoot()

[0019] The publisher signs the root hash value using the private key of the BLS signature. The core content is as follows:

[0020] σ←BLS.sin(sk i ,V root )

[0021] The root hash represents the credential fingerprint, allowing validity checks to be performed on the claims in the credential.

[0022] Furthermore, when constructing VP in step 3, the user can selectively disclose the statement after receiving the publisher's VC. The disclosure statement, the proof of calculating the root hash, and the publisher's signature must be combined into VP and sent to the verifier. Assume that the Merkle hash tree has two leaf nodes, namely attribute a and attribute n. At this time, the user wants to disclose attribute a and hide attribute n, so the path proof of calculating the root hash should include attribute a, the hash function Hash() used in the calculation, and the hash value Hn corresponding to attribute n. When the verifier receives it, the Merkle hash tree can be reconstructed through the proof and compared with the corresponding root hash V in the user's DID document. root For comparison, the content is as follows:

[0023]

[0024] If they are equal, it means that the declaration corresponding to the attribute is valid, which means that the user has achieved revealing only attribute a.

[0025] Furthermore, when verifying the VP in step 3, after the verifier receives the VP sent by the user, it obtains the publisher's DID document and the user's DID document through the DID universal resolver, and obtains the publisher's public key to form a public key list and a corresponding root hash list. σ Adjust the root hash list. Verification is mainly divided into two parts: verifying the path proof and verifying the signature. Verifying the path proof is to calculate whether the user's Merkle hash tree based on the path conforms to the Merkle hash tree constructed by the publisher.

[0026] Furthermore, the user-blind specific attribute information when publishing the VC in step 4 is as follows:

[0027] blindM←Hash(message)

[0028] Then create an attribute set C containing blindM, receive the random number SignNonce used by the publisher for blind signature, and use the publisher's public key to create a blind signature context, the content of which is as follows:

[0029] (blindClaims,BlindFactor)←newContext(linkSecret,pk,SignNonce)

[0030] Send the attribute set C and the blind signature context blindClaims to the publisher, who performs the blind signature. The content is as follows:

[0031] VC←blindSign(C,blindClaims,sk,pk,SignNonce)

[0032] The VC is then sent back to the user, who unblinds the original signature for verification, as follows:

[0033] sign←unblind(pk,VC,BlindFactor)

[0034] verify(sign,pk)

[0035] Then the VC phase is completed.

[0036] Furthermore, when constructing and verifying VP in step 4, the verifier knows the VC structure in advance, that is, the verifier only knows the corresponding relationship between the position of the credential and the declaration, but does not know the attribute content corresponding to the specific declaration, where PR1 indicates that the user needs to disclose the first declared attribute in VC_A, PR2 indicates that the user's VC_B comes from publisher B, and PR3 indicates that the user provides a zero-knowledge proof that the second declared attribute of VC_A is equal to the third declared attribute of VC_B. The proof information PM1 and PM2 contain the disclosed declared attribute information and the hidden declared attribute information. The verifier first calculates a random number to limit the user from forging the proof, and the content is as follows:

[0037] VerNonce←random()

[0038] Then PR1, 2, and 3 are sent to the user. The user constructs VP. The user generates a blinding factor and uses the attribute set C and the blinding factor sameBlind to construct the proof information PM1 and PM2 and the signature commitment. The content is as follows:

[0039] sameBlind←random()

[0040] pok1←CommitSign(PR1,PM1,σ A )

[0041] pok2←CommitSign(PR2,PM2,σ B )

[0042] Then generate a challenge and construct a proof, as follows:

[0043] challenge←createChallenge(pok1,pok2,VerNonce)

[0044] proof i ←generateSignPok(pok i ,challenge)i∈[1,2]

[0045] The user sends VP to the verifier, and the verifier calculates the challenge and verifies it based on the proof. The content is as follows:

[0046] VerChallenge←createChallenge(pok1,pok2,VerNonce)

[0047] Result i ←verify(proof i ,VerChallenge)i∈[1,2]

[0048] Thus, the user completes a signed proof of knowledge and proof of equality of the commitment value created during the VC issuance phase.

[0049] Furthermore, the extension layer design in step 5 includes a total of four functional modules, namely, a connection module, a cache module, a temporary DID generation module, and a document request proxy module. Among them, the connection module replaces the client session processing of the HTTP server of the original general resolver by using the connection manager in the enclave. That is, the DID requester can directly establish a secure session with the extension layer part. The DID request is directly passed to the extension layer through this module for subsequent processing, and is returned to the requester when the corresponding DID document is retrieved; the cache module replaces the DID cache of the general resolver with a DID document cache based on ORAM to mitigate the existing memory access mode side channel attack of SGX. ORAM makes access to a specific DID cache index no different from access to other indexes. An attacker who observes the memory access mode executed by the extension layer cannot establish a link between the DID request and the specific DID document cache entry. The DID document cache resides in the EPC specific page of the enclave, which is essentially a database of key-value pairs; the temporary DID generation module generates and maintains a temporary DID list for each DID request, and provides the temporary DID to the resolver part in the general resolver. The random number generation module uses SGX's sgx_read_rand() random number generation function. The generation module also maintains a temporary DID to DID lookup table shared with the document request proxy module. The generation module queues the DID pair for DID document extraction. The document request proxy module cancels the queue after the DID document extraction is completed; the document request proxy module intercepts the temporary DID document request format DRF sent by the driver to the server, that is, the temporary DID DRF. Replace the temporary DID with the real DID. In order to forward and correctly handle the temporary DIDDRF, two basic adjustments need to be made to the driver: First, the DRF needs to explicitly carry the DID method information in the request, which makes it easier to identify which blockchain network a specific DRF was originally used for. Second, the target address needs to be changed in the driver to point to the document request proxy. In this way, the proxy module can intercept the request, replace the temporary DID with the real DID, and retrieve the DID document.

[0050] Furthermore, the data processing flow of the extension layer in step 5 can be summarized as follows: the first step is that before establishing a secure connection, the DID query agent initially verifies the extension layer in the DID resolver infrastructure of the server. By calling a specific SGXAPI function, the remote identity authentication mechanism provided by Intel is used to verify whether an enclave is a real SGXenclave, and confirm whether the code and data it runs are secure and untampered. Subsequently, the query agent sends the DID URL to the extension layer through a secure channel. The second step is whether the cache hits. If the cache hits, the corresponding DID document is returned to the requester. If the cache does not hit, a temporary DID is generated for the given DID through the temporary DID generation module. The temporary DID is a DID with the same format that is randomly generated according to the specific length and format of the real DID. The third step is that the extension layer sends the generated temporary DID to the universal resolver, and the driver in the universal resolver uses the temporary DID to generate the corresponding temporary DIDDRF. The fourth step is to send DRF to the document request proxy module in the extension layer. The temporary DID DRF is replaced with the real DRF through the document request proxy module, and then sent to the blockchain to query the corresponding DID document. The fifth step is that the document request proxy saves the queried DID document to the cache, and then returns it to the requester through a secure channel. The core process steps include the following:

[0051] DID,DIDMethod←parse(DIDURL)

[0052] tempDID←generate(DIDMethod)

[0053] tempDIDDRF←DIDDriver.generate(tempDID)

[0054] DIDDRF←replace(DID,tempDIDDRF)

[0055] Thus, the extension layer completes the DID document request processing.

[0056] The positive effects of the present invention are:

[0057] The present invention proposes a flexible selective disclosure statement method by combining multiple signature technologies, thereby achieving different degrees of privacy protection to meet the needs of scenarios with different privacy requirements. For large traffic environments with low privacy requirements, communication storage overhead is reduced by aggregated signatures. For scenarios with high privacy requirements, balanced overhead and zero-knowledge proof with stronger privacy protection effect are provided. The present invention also proposes an extension layer design based on a universal parser implementation, which enhances privacy when parsing DID documents and alleviates association problems in the DID parsing process. This solution achieves a certain balance between privacy and time overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 This is an architecture diagram of an on-chain digital identity privacy protection solution based on decentralized identifiers.

[0059] Figure 2 It is a flow chart of the on-chain digital identity privacy protection solution based on decentralized identifiers.

[0060] Figure 3 This is a flow chart showing the selective disclosure statement method based on BLS signature and Merkle hash tree.

[0061] Figure 4 It is a zero-knowledge selective disclosure statement method based on BBS+signature to publish VC timing diagram.

[0062] Figure 5 It is a zero-knowledge selective disclosure statement method based on BBS+signature to construct and verify the VP timing diagram.

[0063] Figure 6 It is an architectural diagram of the design of the universal parser extension layer. DETAILED DESCRIPTION

[0064] The specific implementation modes of the present invention are further described in detail below with reference to the accompanying drawings.

[0065] like Figure 1 As shown, the present invention first registers DID, and then the user selects different selective disclosure declaration methods according to the scenario requirements to subsequently publish VC, construct VP and verify VP, which specifically includes the following steps:

[0066] Step 1: System initialization completes DID registration for each entity;

[0067] Step 2: Choose different disclosure statement methods based on scenario requirements;

[0068] Step 3: For scenarios with low privacy requirements, choose the selective disclosure statement method based on BLS signature and Merkle hash tree, which includes three steps: issuing VC, constructing VP and verifying VP, such as Figure 3 As shown;

[0069] Step 4: For scenarios with high privacy requirements, choose the zero-knowledge selective disclosure statement method based on BBS+signature, which is also divided into three steps: publishing VC, constructing VP, and verifying VP, such as Figure 4 , 5 As shown;

[0070] Step 5: When parsing DID documents, the original direct interaction between the universal parser and the decentralized ledger is transformed into an indirect interaction to process the DID document data flow through the designed extension layer based on the universal parser.

[0071] Further, each step in step 1 is as follows Figure 2 As shown, first the system initializes various parameters required for generating signatures. The registration of each entity DID is that each participant creates and submits the DID and the corresponding DID document to the DID registry through the existing mature framework technology. The DID document is a JSON document associated with each DID, which contains information such as verification public key and service endpoint, which is securely stored on the distributed ledger. The DID document includes but is not limited to the public key, and the addition, deletion, modification and query of the DID are implemented using the existing mature technology framework, where DID addition: This solution uses the user blockchain address as the DID string, and the public and private keys used for creation are self-generated and managed by the user. The user provides the public key and blockchain address to create the DID and DID document; DID deletion and modification: By constructing revocation transactions and update transactions, once the verification nodes reach a consensus, the revocation transaction will be recorded on the chain and the status of the DID document will be marked as revoked, and the record of the update transaction will cause the updated version of the DID document to be retrieved through the DID query; DID query: Through the DID universal parser, according to the DID query the registry in the distributed ledger, find the corresponding record and parse and return the corresponding DID document.

[0072] Furthermore, when issuing VC in step 3, the publisher constructs a Merkle hash tree of the user's statement set or the statement set provided by the user and calculates the root hash of the tree. The attributes represented by each statement correspond to the leaf nodes in the Merkle hash tree, and the core content is as follows:

[0073] leaves←SHA256(Json.parse(S))

[0074] Tree = new MerkleTree(leaves)

[0075] V root =Tree.getRoot()

[0076] The publisher signs the root hash value using the private key of the BLS signature. The core content is as follows:

[0077] σ←BLS.sin(sk i ,V root )

[0078] The root hash represents the credential fingerprint, allowing validity checks to be performed on the claims in the credential.

[0079] Furthermore, when constructing VP in step 3, the user can selectively disclose the statement after receiving the publisher's VC. The disclosure statement, the proof of calculating the root hash, and the publisher's signature must be combined into VP and sent to the verifier. Assume that the Merkle hash tree has two leaf nodes, namely attribute a and attribute n. At this time, the user wants to disclose attribute a and hide attribute n, so the path proof of calculating the root hash should include attribute a, the hash function Hash() used in the calculation, and the hash value Hn corresponding to attribute n. When the verifier receives it, the Merkle hash tree can be reconstructed through the proof and compared with the corresponding root hash V in the user's DID document. root For comparison, the content is as follows:

[0080]

[0081] If they are equal, it means that the declaration corresponding to the attribute is valid, which means that the user has achieved revealing only attribute a.

[0082] Furthermore, when verifying the VP in step 3, after the verifier receives the VP sent by the user, it obtains the publisher's DID document and the user's DID document through the DID universal resolver, and obtains the publisher's public key to form a public key list and a corresponding root hash list. σ Adjust the root hash list. Verification is mainly divided into two parts: verifying the path proof and verifying the signature. Verifying the path proof is to calculate whether the user's Merkle hash tree based on the path conforms to the Merkle hash tree constructed by the publisher.

[0083] Furthermore, the user-blind specific attribute information when publishing the VC in step 4 is as follows:

[0084] blindM←Hash(message)

[0085] Then create an attribute set C containing blindM, receive the random number SignNonce used by the publisher for blind signature, and use the publisher's public key to create a blind signature context, the content of which is as follows:

[0086] (blindClaims,BlindFactor)←newContext(linkSecret,pk,SignNonce)

[0087] Send the attribute set C and the blind signature context blindClaims to the publisher, who performs the blind signature. The content is as follows:

[0088] VC←blindSign(C,blindClaims,sk,pk,SignNonce)

[0089] The VC is then sent back to the user, who unblinds the original signature for verification, as follows:

[0090] sign←unblind(pk,VC,BlindFactor)

[0091] verify(sign,pk)

[0092] Then the VC phase is completed.

[0093] Furthermore, when constructing and verifying VP in step 4, the verifier knows the VC structure in advance, that is, the verifier only knows the corresponding relationship between the position of the credential and the declaration, but does not know the attribute content corresponding to the specific declaration, where PR1 indicates that the user needs to disclose the first declared attribute in VC_A, PR2 indicates that the user's VC_B comes from publisher B, and PR3 indicates that the user provides a zero-knowledge proof that the second declared attribute of VC_A is equal to the third declared attribute of VC_B. The proof information PM1 and PM2 contain the disclosed declared attribute information and the hidden declared attribute information. The verifier first calculates a random number to limit the user from forging the proof, and the content is as follows:

[0094] VerNonce←random()

[0095] Then PR1, 2, and 3 are sent to the user. The user constructs VP. The user generates a blinding factor and uses the attribute set C and the blinding factor sameBlind to construct the proof information PM1 and PM2 and the signature commitment. The content is as follows:

[0096] sameBlind←random()

[0097] pok1←CommitSign(PR1,PM1,σ A )

[0098] pok2←CommitSign(PR2,PM2,σ B )

[0099] Then generate a challenge and construct a proof, as follows:

[0100] challenge←createChallenge(pok1,pok2,VerNonce)

[0101] proof i ←generateSignPok(pok i ,challenge)i∈[1,2]

[0102] The user sends VP to the verifier, and the verifier calculates the challenge and verifies it based on the proof. The content is as follows:

[0103] VerChallenge←createChallenge(pok1,pok2,VerNonce)

[0104] Result i ←verify(proof i ,VerChallenge)i∈[1,2]

[0105] Thus, the user completes a signed proof of knowledge and proof of equality of the commitment value created during the VC issuance phase.

[0106] Furthermore, the extension layer design in step 5 includes a total of four functional modules, namely, a connection module, a cache module, a temporary DID generation module, and a document request proxy module. Among them, the connection module replaces the client session processing of the HTTP server of the original general resolver by using the connection manager in the enclave. That is, the DID requester can directly establish a secure session with the extension layer part. The DID request is directly passed to the extension layer through this module for subsequent processing, and is returned to the requester when the corresponding DID document is retrieved; the cache module replaces the DID cache of the general resolver with a DID document cache based on ORAM to mitigate the existing memory access mode side channel attack of SGX. ORAM makes access to a specific DID cache index no different from access to other indexes. An attacker who observes the memory access mode executed by the extension layer cannot establish a link between the DID request and the specific DID document cache entry. The DID document cache resides in the EPC specific page of the enclave, which is essentially a database of key-value pairs; the temporary DID generation module generates and maintains a temporary DID list for each DID request, and provides the temporary DID to the resolver part in the general resolver. The random number generation module uses SGX's sgx_read_rand() random number generation function. The generation module also maintains a temporary DID to DID lookup table shared with the document request proxy module. The generation module queues the DID pair for DID document extraction. The document request proxy module cancels the queue after the DID document extraction is completed; the document request proxy module intercepts the temporary DID document request format DRF sent by the driver to the server, that is, the temporary DID DRF. Replace the temporary DID with the real DID. In order to forward and correctly handle the temporary DIDDRF, two basic adjustments need to be made to the driver: First, the DRF needs to explicitly carry the DID method information in the request, which makes it easier to identify which blockchain network a specific DRF was originally used for. Second, the target address needs to be changed in the driver to point to the document request proxy. In this way, the proxy module can intercept the request, replace the temporary DID with the real DID, and retrieve the DID document.

[0107] Furthermore, the data processing flow of the extension layer in step 5 is as follows: Figure 6As shown, it can be summarized as follows: the first step is that before establishing a secure connection, the DID query agent initially verifies the extension layer in the server's DID resolver infrastructure. By calling a specific SGX API function, the remote identity verification mechanism provided by Intel is used to verify whether an enclave is a real SGX enclave, and whether the code and data it runs are secure and untampered. Subsequently, the query agent sends the DID URL to the extension layer through a secure channel. The second step is whether the cache hits. If the cache hits, the corresponding DID document is returned to the requester. If the cache does not hit, a temporary DID is generated for the given DID through the temporary DID generation module, where the temporary DID is a DID that is randomly generated according to the specific length and format of the real DID and has the same format. The third step is that the extension layer sends the generated temporary DID to the universal resolver, and the driver in the universal resolver uses the temporary DID to generate the corresponding temporary DID DRF. The fourth step is to send the DRF to the document request agent module in the extension layer, and replace the temporary DID DRF with the real DRF through the document request agent module, and then send it to the blockchain to query the corresponding DID document. The fifth step is that the document request agent saves the queried DID document to the cache and then returns it to the requester through a secure channel. The core process steps include the following:

[0108] DID,DIDMethod←parse(DIDURL)

[0109] tempDID←generate(DIDMethod)

[0110] tempDIDDRF←DIDDriver.generate(tempDID)

[0111] DIDDRF←replace(DID,tempDIDDRF)

[0112] Thus, the extension layer completes the DID document request processing.

Claims

1. An on-chain digital identity privacy protection scheme based on decentralized identifiers, characterized in that: The method comprises the following steps: Step 1: System initialization completes DID registration for each entity; Step 2: Choose different disclosure statement methods based on scenario requirements; Step 3: For scenarios with low privacy requirements, choose the selective disclosure statement method based on BLS signature and Merkle hash tree, which includes three steps: issuing VC, constructing VP and verifying VP; Step 4: For scenarios with high privacy requirements, choose the zero-knowledge selective disclosure statement method based on BBS+signature, which is also divided into three steps: publishing VC, constructing VP, and verifying VP; Step 5: When parsing DID documents, the original direct interaction between the universal parser and the decentralized ledger is transformed into an indirect interaction to process the DID document data flow through the designed extension layer based on the universal parser.

2. According to the on-chain digital identity privacy protection scheme based on decentralized identifiers as described in claim 1, it is characterized in that: In the step 1, the system first initializes various parameters required for generating signatures. The DID registration of each entity is that each participant creates and submits the DID and the corresponding DID document to the DID registry through the existing mature framework technology. The DID document is a JSON document associated with each DID, which contains information such as verification public key and service endpoint. This information is securely stored on the distributed ledger. The DID document includes but is not limited to the public key. The addition, deletion, modification and query of the DID are implemented using the existing mature technology framework, where DID addition: This solution uses the user blockchain address as the DID string, and the public and private keys used for creation are self-generated and managed by the user; the user provides the public key and blockchain address to create the DID and DID document, DID deletion and modification: By constructing revocation transactions and update transactions, once the verification nodes reach a consensus, the revocation transaction will be recorded on the chain and the status of the DID document will be marked as revoked, and the record of the update transaction will cause the updated version of the DID document to be retrieved through DID query, DID query: Through the DID universal parser, according to the DID query the registry in the distributed ledger, find the corresponding record and parse and return the corresponding DID document.

3. According to the on-chain digital identity privacy protection scheme based on decentralized identifiers as described in claim 1, it is characterized in that: When issuing VC in step 3, the publisher constructs a Merkle hash tree of the user's statement set or the statement set provided by the user and calculates the root hash of the tree; the attribute represented by each statement corresponds to a leaf node in the Merkle hash tree, and the core content is as follows: leaves←SHA256(Json.parse(S)) Tree = new MerkleTree(leaves) V root =Tree.getRoot() The publisher signs the root hash value using the private key of the BLS signature. The core content is as follows: σ←BLS.sin(sk i ,V root ) The root hash represents the credential fingerprint, allowing validity checks to be performed on the claims in the credential.

4. According to the on-chain digital identity privacy protection scheme based on decentralized identifiers as described in claim 1, it is characterized in that: When constructing VP in step 3, after receiving the publisher's VC, the user can selectively disclose the statement, and the disclosure statement, the proof of calculating the root hash, and the publisher's signature must be combined into VP and sent to the verifier; assuming that the Merkle hash tree has two leaf nodes, namely attribute a and attribute n; at this time, the user wants to disclose attribute a and hide attribute n, then the path proof of calculating the root hash should include attribute a, the hash function Hash() used in the calculation, and the hash value Hn corresponding to attribute n; when the verifier receives it, the Merkle hash tree can be reconstructed through the proof and combined with the corresponding root hash V in the user's DID document root For comparison, the content is as follows: If they are equal, it means that the declaration corresponding to the attribute is valid, which means that the user has achieved revealing only attribute a.

5. According to the decentralized identifier-based on-chain digital identity privacy protection scheme described in claim 1, it is characterized in that: When verifying VP in step 3, after receiving the VP sent by the user, the verifier obtains the publisher's DID document and the user's DID document through the DID universal resolver, and obtains the publisher's public key to form a public key list and a corresponding root hash list; according to the signature list newList σ Adjust the root hash list; verification is mainly divided into two parts: verifying the path proof and verifying the signature. Verifying the path proof means calculating whether the user's Merkle hash tree based on the path conforms to the Merkle hash tree constructed by the publisher.

6. According to the decentralized identifier-based on-chain digital identity privacy protection scheme described in claim 1, it is characterized in that: The user-blind specific attribute information when publishing the VC in step 4 is as follows: blindM←Hash(message) Then create an attribute set C containing blindM, receive the random number SignNonce used by the publisher for blind signature, and use the publisher's public key to create a blind signature context, the content of which is as follows: (blindClaims,BlindFactor)←newContext(linkSecret,pk,SignNonce) Send the attribute set C and the blind signature context blindClaims to the publisher, who performs the blind signature. The content is as follows: VC←blindSign(C,blindClaims,sk,pk,SignNonce) The VC is then sent back to the user, who unblinds the original signature for verification, as follows: sign←unblind(pk,VC,BlindFactor) verify(sign,pk) Then the VC phase is completed.

7. According to the decentralized identifier-based on-chain digital identity privacy protection scheme described in claim 1, it is characterized in that: When constructing and verifying VP in step 4, the verifier knows the VC structure in advance, that is, the verifier only knows the corresponding relationship between the position of the credential and the declaration, but does not know the attribute content corresponding to the specific declaration. Among them, PR1 indicates that the user needs to disclose the first declared attribute in VC_A, PR2 indicates that the user's VC_B comes from publisher B, and PR3 indicates that the user provides a zero-knowledge proof that the second declared attribute of VC_A is equal to the third declared attribute of VC_B. The proof information PM1 and PM2 contain the disclosed declared attribute information and the hidden declared attribute information. The verifier first calculates a random number to limit the user from forging the proof. The content is as follows: VerNonce←random() Then PR1, 2, and 3 are sent to the user. The user constructs VP. The user generates a blinding factor and uses the attribute set C and the blinding factor sameBlind to construct the proof information PM1 and PM2 and the signature commitment. The content is as follows: sameBlind←random() pok1←CommitSign(PR1,PM1,σ A ) pok2←CommitSign(PR2, PM2, σ B ) Then generate a challenge and construct a proof, as follows: challenge←createChallenge(pok1,pok2,VerNonce) proof i ←generateSignPok(pok i ,challenge)i∈[1,2] The user sends VP to the verifier, and the verifier calculates the challenge and verifies it based on the proof. The content is as follows: VerChallenge←createChallenge(pok1,pok2,VerNonce) result i ←verify(proof i ,VerChallenge)i∈[1,2] Thus, the user completes a signed proof of knowledge and proof of equality of the commitment value created during the VC issuance phase.

8. According to the decentralized identifier-based on-chain digital identity privacy protection scheme described in claim 1, it is characterized in that: The extension layer design in step 5 includes a total of 4 major functional modules, namely, a connection module, a cache module, a temporary DID generation module, and a document request proxy module; wherein, the connection module replaces the client session processing of the HTTP server of the original general resolver by using the connection manager in the enclave; that is, the DID requester can directly establish a secure session with the extension layer; the DID request is directly passed to the extension layer through this module for subsequent processing, and is returned to the requester when the corresponding DID document is retrieved; the cache module replaces the DID cache of the general resolver with a DID document cache based on ORAM to mitigate the existing memory access mode side channel attack of SGX; ORAM makes access to a specific DID cache index no different from access to other indexes; observe the attack of the memory access mode executed by the extension layer The attacker cannot establish a link between the DID request and the specific DID document cache entry; the DID document cache resides in the EPC specific page of the enclave, which is essentially a database of key-value pairs; the temporary DID generation module generates and maintains a temporary DID list for each DID request, and provides the temporary DID to the parser part in the general parser; the random number is generated using SGX's sgx_read_rand() random number generation function; the generation module also maintains a temporary DID to DID lookup table shared with the document request proxy module; the generation module queues the DID pair for DID document extraction; the document request proxy module cancels the queue after the DID document is extracted; the document request proxy module intercepts the document request format DRF of the temporary DID sent by the driver to the server, that is, the temporary DID DRF; replace the temporary DID with the real DID; in order to forward and correctly handle the temporary DID DRF, two basic adjustments need to be made to the driver: first, the DRF needs to explicitly carry the DID method information in the request, which makes it easier to identify which blockchain network a specific DRF was originally used for; second, the target address needs to be changed in the driver to point to the document request proxy; in this way, the proxy module can intercept the request, replace the temporary DID with the real DID, and retrieve the DID document.

9. According to the decentralized identifier-based on-chain digital identity privacy protection scheme described in claim 1, it is characterized in that: The data processing flow of the extension layer in step 5 can be summarized as follows: the first step is that before establishing a secure connection, the DID query agent initially verifies the extension layer in the DID resolver infrastructure of the server; by calling a specific SGXAPI function, the remote identity verification mechanism provided by Intel is used to verify whether an enclave is a real SGXenclave, and confirm whether the code and data it runs are secure and untampered; then, the query agent sends the DID URL to the extension layer through a secure channel; The second step is to check whether the cache hits. If the cache hits, the corresponding DID document is returned to the requester; if the cache does not hit, a temporary DID is generated for the given DID through the temporary DID generation module; The temporary DID is a DID with the same format as the real DID that is randomly generated according to the specific length and format of the real DID; the third step is that the extension layer sends the generated temporary DID to the universal parser, and the driver in the universal parser uses the temporary DID to generate the corresponding temporary DIDDRF; the fourth step is to send the DRF to the document request agent module in the extension layer, and replace the temporary DID DRF with the real DRF through the document request agent module, and then send it to the blockchain to query the corresponding DID document; the fifth step is that the document request agent saves the queried DID document to the cache, and then returns it to the requester through a secure channel. The core of the process steps includes the following: DID,DID Method←parse(DIDURL) tempDID←generate(DIDMethod) tempDIDDRF←DIDDriver.generate(tempDID) DIDDRF←replace(DID,tempDIDDRF) Thus, the extension layer completes the DID document request processing.

Images