DID-based electronic contract signing method, device, equipment and medium

Abstract

The application relates to a DID-based electronic contract signing method, device and equipment and a storage medium. The method comprises the following steps: obtaining a distributed digital identity (DID) identifier and a corresponding DID document of a user; submitting an authentication request to a certificate issuing agency through the user terminal; obtaining verifiable credentials and digital certificates submitted by the user when signing a contract, and verifying the validity and relevance of the verifiable credentials and the digital certificates; after the verification is passed, receiving a contract signing signature generated by a private key corresponding to the DID identifier, and verifying the legality of the contract signing signature by using the digital certificate; and in response to the fact that the contract signing signature passes the legality verification, storing a contract signing result to a block chain.

Description

Technical Field

[0001] This application relates to the field of electronic contract signing technology, and in particular to a DID-based electronic contract signing method, apparatus, device and storage medium. Background Technology

[0002] Decentralized Identity (DID) is a new digital identity standard based on cryptography and blockchain technology. Its core advantage lies in enabling users to have autonomous control over their identity information, completely eliminating dependence on centralized institutions. Coupled with cutting-edge cryptographic technologies such as zero-knowledge proofs, it can efficiently prove specific user attributes without disclosing original information, providing robust technical support for privacy protection. Digital certificates, as legally recognized identity credentials, must be issued by compliant third-party Certificate Authorities (CAs). This is a core prerequisite for meeting the requirements of the Electronic Signature Law and ensuring the legal validity of electronic signatures.

[0003] In view of this, in order to balance the needs of subscriber privacy and security, signature anti-forgery requirements and the legal compliance of electronic contracts, it is essential to build an electronic contract platform that integrates the dual technological advantages of DID and digital certificates. Summary of the Invention

[0004] In view of the above, this application provides a method, apparatus, device and storage medium for signing electronic contracts based on DID, the purpose of which is to solve the above-mentioned technical problems.

[0005] In a first aspect, this application provides a DID-based electronic contract signing method, the method comprising: Obtain the user's Distributed Digital Identity (DID) identifier and the corresponding DID document; The user terminal submits an authentication request to the certificate authority; the authentication request enables the certificate authority to complete identity verification based on the authentication request and issue a verifiable credential and digital certificate bound to the DID identifier to the user. Obtain the verifiable credentials and digital certificate submitted by the user when signing the contract, and verify the validity and relevance of the verifiable credentials and digital certificate; After successful verification, the contract signing signature generated by the private key corresponding to the DID identifier is received, and the legality of the contract signing signature is verified using the digital certificate. In response to the legality verification of the contract signature, the contract signing result is stored in the blockchain.

[0006] In some embodiments, obtaining the user's distributed digital identity (DID) identifier and the corresponding DID document includes: An encryption key pair is generated locally on the user's computer via the user terminal, and the user's DID identifier is generated based on the public key in the key pair; The user terminal generates a DID document based on the DID identifier and the public key, and signs the DID document using the private key in the key pair; Perform a hash operation on the signed DID document to obtain the document hash value; The registration transaction, which includes the DID identifier and the document hash value, is submitted to the blockchain network to complete the on-chain registration of the DID identifier.

[0007] In some embodiments, generating an encryption key pair locally on the user's computer via a user terminal includes: The trusted execution environment within the user terminal is invoked, and the encryption key pair is generated within the trusted execution environment. The step of signing the DID document using the private key from the key pair includes: Within the trusted execution environment, a hash calculation is performed on the data to be signed in the DID document to obtain a digest to be signed; Within the trusted execution environment, the private key is used to perform a signature operation on the digest to be signed, generating a signature value; The signature value is used to sign the DID document.

[0008] In some embodiments, the authentication request includes the DID identifier, proof of control, and identity verification materials; the certificate authority completes identity verification based on the authentication request and issues a verifiable credential and digital certificate bound to the DID identifier to the user, including: The authenticity of the user's identity and qualification materials and the proof of control shall be verified. In response to the successful authenticity verification, a verifiable credential based on the user's DID identifier is constructed. The digital certificate is issued to the user, and the extended fields of the digital certificate include the user's DID identifier and the corresponding verifiable credential identifier; Calculate the certificate hash value of the digital certificate and populate it into the extended field of the verifiable credential; The private key is used to sign the bound verifiable credential, and the hash value of the signed verifiable credential and the certificate hash value are stored in the blockchain network.

[0009] In some embodiments, storing the hash value of the signed verifiable credential and the certificate hash value in the blockchain network includes: Construct a binding and storage transaction; the binding and storage transaction includes the user's DID identifier, the hash value of the signed verifiable credential, the certificate hash value, and the issuance timestamp and serial number of the digital certificate; Within a preset time period after the digital certificate is issued, the binding and storage transaction will be submitted to the blockchain network.

[0010] In some embodiments, obtaining the verifiable credentials and digital certificate submitted by the user at the time of signing the contract, and verifying the validity and relevance of the verifiable credentials and digital certificate, includes: The issuer of the verifiable credential can verify the validity of the credential signature through the contract signing platform; Verify whether the user DID associated with the verifiable credential is consistent with the DID bound to the currently signed user on the platform; Verify whether the certificate hash value bound in the extended field of the verifiable credential matches the hash value of the digital certificate provided by the signed user; Query the storage status of the verifiable credential in the blockchain network to confirm that the verifiable credential is valid.

[0011] In some embodiments, before obtaining the verifiable credentials and digital certificate submitted by the user at the time of signing the contract, the method further includes a step of binding the user to the contract signing platform: Submit the DID identifier and the digital certificate to the contract signing platform; The validity of the digital certificate is verified through the contract signing platform, and it is also verified whether the extended field of the digital certificate contains the DID identifier. The contract signing platform generates a random challenge string and sends it to the user terminal. The user terminal then signs the challenge string using the private key corresponding to the DID identifier and verifies the signature. After successful verification, a binding relationship is established between the user account, the DID identifier, and the digital certificate within the contract signing platform.

[0012] Secondly, this application provides a DID-based electronic contract signing device, which includes: The acquisition module is used to acquire the user's Distributed Digital Identity (DID) identifier and the corresponding DID document; The authentication module is used to submit an authentication request to the certificate authority through the user terminal; the authentication request is used to enable the certificate authority to complete identity verification based on the authentication request and issue a verifiable credential and digital certificate bound to the DID identifier for the user. The first verification module is used to obtain the verifiable credentials and digital certificate submitted by the user when signing the contract, and to verify the validity and relevance of the verifiable credentials and digital certificate. The second verification module is used to receive the contract signing signature generated by the private key corresponding to the DID identifier after the verification is passed, and to use the digital certificate to verify the legality of the contract signing signature. A storage module is used to store the contract signing result to the blockchain in response to the contract signing signature passing the legality verification.

[0013] Thirdly, this application provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the steps of the DID-based electronic contract signing method described in any embodiment of the first aspect.

[0014] Fourthly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the DID-based electronic contract signing method as described in any embodiment of the first aspect.

[0015] The technical solutions provided in this application have the following advantages compared with the prior art: (1) Decentralized identity anti-counterfeiting: Identity verification is achieved based on DID, eliminating the strong dependence on centralized contract platforms and preventing identity counterfeiting from the root; (2) Privacy and compliance are balanced: Verifiable credentials (VC) carry qualifications and are verified through cryptographic signatures. Sensitive information is stored in hash form and supports selective disclosure, avoiding the risk of information leakage caused by third-party contract platforms holding a large amount of sensitive information; (3) Full-chain traceability and non-repudiation of behavior: Identity confirmation, dual certificate issuance, and contract signing are stored on the blockchain to form a complete evidence chain; (4) Cross-platform mutual recognition and reuse: After each contract platform accesses the DID service platform, DID+VC+digital certificate can be reused to avoid repeated identity verification and solve the pain point of non-mutual recognition of signing results. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating a preferred embodiment of the DID-based electronic contract signing method of this application; Figure 2 This is a schematic diagram of a preferred embodiment of the DID-based electronic contract signing device of this application; Figure 3 This is a schematic diagram of a preferred embodiment of the electronic device of this application; The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0020] It should be noted that the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined as "first" or "second" may explicitly or implicitly include at least that feature. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0021] The current operational model of electronic contract platforms presents significant risks of centralization: the platform relies on its own account system to provide services throughout the entire process, digital certificates must be obtained from CAs through the platform, and subscriber keys are held in escrow by the platform, giving the platform absolute control over data processing. Furthermore, different CAs require users to perform repetitive identity authentication, making the process cumbersome for users.

[0022] Because electronic contract platforms have absolute control over identity information, there may be issues of "collecting beyond the scope and using it illegally." For example, identity data may be used for marketing, data trading, and other value-added services without user authorization, violating the principle of "minimum necessity and explicit authorization" in the Personal Information Protection Law. Once an electronic contract platform is attacked by hackers, suffers system vulnerabilities, or has internal data leaks, it will lead to large-scale leakage of user information, triggering a chain of risks such as fraud and identity theft. It may even lead to subscribers questioning the platform's neutrality, resulting in disputes such as "identity forgery and signature repudiation" that cannot be resolved quickly.

[0023] DID uses blockchain technology to build an immutable identity system, ensuring the trustworthiness of contract signatories from the source. Based on DID's verifiable credential VC, signatories do not need to provide complete identity data to the electronic contract platform, but only need to prove to the verifier that "specific conditions are met". The signatories' identity information and keys are stored locally on the user's device (such as in a DID wallet), rather than on a centralized server, reducing the risk of "data leakage".

[0024] Reference Figure 1 The diagram shown is a flowchart illustrating an embodiment of the DID-based electronic contract signing method of this application. The method is executed by an electronic device, which can be implemented by a software system and / or a hardware system. The DID-based electronic contract signing method includes: Step 101: Obtain the user's Distributed Digital Identity (DID) identifier and the corresponding DID document.

[0025] Distributed Digital Identity (DID) is a new digital identity standard based on cryptography and blockchain technology. Its core is that the identity identifier (DID) is generated and controlled by the user himself, without relying on a centralized identity provider.

[0026] A DID identifier is a unique string that points to a specific DID document. A DID document is a document that contains information associated with a DID identifier. A DID document may include a public key used for authentication, a service endpoint, and other metadata describing the controller of that DID.

[0027] A user's Distributed Digital Identity (DID) and its corresponding DID document can be generated through a user terminal. A user terminal is a local computing device used by the user to perform operations, such as a personal computer, smartphone, or dedicated hardware wallet.

[0028] In some embodiments, obtaining the user's distributed digital identity (DID) identifier and the corresponding DID document may include the following operations: S11, an encryption key pair is generated locally on the user's computer via the user terminal, and the user's DID identifier is generated based on the public key in the key pair.

[0029] An encryption key pair refers to the private and public keys generated in pairs in an asymmetric encryption algorithm.

[0030] A DID (Distributed Digital Identity) is a globally unique string identifier generated according to a specific DID methodology specification, used to point to a specific distributed digital identity. DIDs can be generated based on parameters such as public keys.

[0031] In some embodiments, a user can run an offline client application on a user terminal, which calls a local cryptography library to generate a set of key pairs for asymmetric encryption algorithms in the memory of the user terminal.

[0032] In some embodiments, generating an encryption key pair locally on the user's computer via a user terminal includes the following operations: S111, invoke the trusted execution environment in the user terminal, and generate the encryption key pair in the trusted execution environment.

[0033] A Trusted Execution Environment (TEE) is a secure region located within the main processor, isolated from the device's regular operating system. A TEE ensures the confidentiality and integrity of code and data loaded within it, protecting operations even if the operating system is attacked or compromised. For example, ARM TrustZone technology or Intel SGX technology can create TEEs on user terminals such as smartphones or CPUs.

[0034] An encryption key pair is a private key and a public key generated in pairs in an asymmetric encryption algorithm. The private key is used for signing or decryption, while the public key can be publicly distributed for signature verification or encryption.

[0035] In some embodiments, a client application running on a user terminal's conventional operating system (such as a DID wallet) can initiate a request to a trusted execution environment (TEA) supported by the user terminal hardware and underlying firmware through a predefined, secure API. This request instructs the TEA to perform a key generation task. Upon receiving the request, the TEA, within its isolated secure area, invokes its built-in cryptographic algorithm library to generate an encrypted key pair within the environment.

[0036] S112, within the trusted execution environment, perform hash calculation on the data to be signed in the DID document to obtain the digest to be signed.

[0037] Data to be signed refers to the original information content that needs to be digitally signed. For example, a DID document that needs to be signed, or a specific part that needs to have its signature calculated.

[0038] The hash digest to be signed refers to the fixed-length hash value obtained after hashing the data to be signed.

[0039] In some embodiments, when a DID document needs to be signed, the DID document data to be signed (i.e., the data to be signed) can be transmitted to the Trusted Execution Environment (TEE) through a secure channel. Alternatively, in some embodiments, the DID document itself is assembled and generated within the TEE. Secure code running within the TEE calls its protected cryptographic function library to perform a specified cryptographic hash function (such as the SM3 algorithm) operation on the data to be signed. For example, the hash function performs multiple rounds of compression and processing on the input data to obtain the digest to be signed.

[0040] S113, within the trusted execution environment, the private key is used to perform a signature operation on the digest to be signed to generate a signature value.

[0041] Signature computation is an asymmetric cryptographic algorithm that uses a private key and specific input data (which can be a digest of the data) to generate a unique digital signature that can be verified using the corresponding public key. A signature value is the specific result data generated after a signature operation. It is cryptographic evidence that proves the private key holder has approved specific data.

[0042] S114, Sign the DID document with the signature value.

[0043] In some embodiments, after the signature value is generated within the trusted execution environment, it can be associated with and encapsulated with the original DID document. For example, the signature value can be added as a separate attribute to the JSON structure of the DID document, or the signature value can be separated from the DID document but associated with it by reference.

[0044] S12, the user terminal generates a DID document based on the DID identifier and the public key, and signs the DID document using the private key in the key pair.

[0045] A signature is a unique string of data values ​​that is bound to both the data and the private key, obtained by using a digital signature algorithm to process specific data (or its hash value) with a private key. Signatures are used to prove the integrity and origin of data.

[0046] In some embodiments, a client application on a user terminal can construct a DID document according to a predefined data structure template. The constructed DID document includes an identifier field where the DID identifier is filled in, and a verification method field where the generated public key information is filled in. Then, a digital signature algorithm is applied to the entire content of the DID document (or its hash value) using the private key to generate a digital signature. The digital signature is then appended to the DID document to form the signed DID document.

[0047] S13, perform a hash operation on the signed DID document to obtain the document hash value.

[0048] In some embodiments, after the DID document is generated and signed, a cryptographic hash function can be invoked through an application on the user terminal, using the DID document as input for hash calculation.

[0049] S14, submit the registration transaction, which includes the DID identifier and the document hash value, to the blockchain network to complete the on-chain registration of the DID identifier.

[0050] A registration transaction refers to a data record intended to invoke the function of a specific smart contract on the blockchain, which contains data that needs to be written to the blockchain.

[0051] On-chain registration refers to the process of permanently and immutably recording specific information (such as the binding relationship between a DID identifier and its document hash) on the blockchain ledger by submitting and successfully executing a transaction to the blockchain network.

[0052] Step 102: Submit an authentication request to the certificate authority through the user terminal; the authentication request is used to enable the certificate authority to complete identity verification based on the authentication request and issue a verifiable credential and digital certificate bound to the DID identifier for the user.

[0053] An authentication request is an application initiated by a user to have a certificate authority verify their identity and control. In some embodiments, authentication request materials may include DID-related materials, proof of control, identity verification materials, a statement of business requirements, and certificate request documents.

[0054] Certificate Authorities (CAs) are typically trusted, legally qualified third-party entities responsible for verifying the identity of entities (such as individuals or businesses) and issuing digital certificates to them.

[0055] Identity verification is the process by which a certificate authority reviews the materials submitted by an applicant to confirm that the applicant's identity is genuine and legitimate and that the applicant has control over the applied DID.

[0056] Verifiable credentials are digital credentials issued by an issuer concerning one or more subjects. They contain a statement, issuer information, subject identifier (such as DID), and the issuer's cryptographic signature, enabling any verifier to independently verify their authenticity and integrity.

[0057] A digital certificate is an electronic document issued by a certificate authority (CA) that binds a public key to identity information. For example, an X.509 digital certificate may contain the certificate holder's identity information, public key, CA information, validity period, and the CA's digital signature.

[0058] For example, the application materials included in the certification request may be as shown in Table 1 below.

[0059] Table 1. Application materials for submitting dual certificates In some embodiments, the authentication request includes the DID identifier, proof of control, and identity verification materials; the certificate authority completes identity verification based on the authentication request and issues a verifiable credential and digital certificate bound to the DID identifier to the user, including: S21, verify the authenticity of the user's identity and qualification materials and the control certificate.

[0060] Authenticity verification refers to the process by which a certificate authority reviews the materials submitted by a user to confirm that the materials themselves are authentic, valid, and unaltered, and that the applicant is indeed the subject claimed in the materials and possesses the corresponding DID control. User identity verification materials are documents or information that prove the user's identity. Proof of control is cryptographic evidence that the user possesses the DID's private key.

[0061] In some embodiments, upon receiving an authentication request, the Certificate Authority (CA) can verify the user's identity and qualifications. For example, the CA compares the user's submitted identity information (such as name, ID number, and enterprise unified credit code) with official authoritative data sources (such as the Ministry of Public Security's population information database and the State Administration for Industry and Commerce's enterprise information database), and uses technologies such as liveness detection to ensure the operator is a real person. The CA also verifies the proof of control. Using the public key obtained from the blockchain or DID resolver, corresponding to the DID identifier submitted by the user, the CA performs a signature verification operation on the proof of control (i.e., the user's signature on the challenge string). If the signature verification passes, it proves that the user indeed possesses the private key for the DID.

[0062] S22, in response to the successful authenticity verification, construct a verifiable credential based on the user's DID identifier.

[0063] In a verifiable credential, the subject refers to the object described by that credential. For example, the subject could be a user's DID identifier.

[0064] In some embodiments, after the Certificate Authority (CA) verifies and confirms the authenticity of the user's identity documents and proof of control, it can create a structured digital document according to the data format specification for verifiable credentials. The "Issuer" field is set to the CA's own identifier (which could be the CA's DID). The "Subject" field is set to the DID identifier submitted by the user in the authentication request, indicating verified control. The "Declaration" field contains a declaration of user attributes generated based on the verified identity documents. Additionally, metadata such as the credential's unique identifier, issuance date, and validity period can be set to obtain a verifiable credential.

[0065] S23, issue the digital certificate for the user, wherein the extended fields of the digital certificate include the user's DID identifier and the corresponding verifiable credential identifier.

[0066] Extended fields are fields defined in addition to basic fields to carry extra information. Extended fields can contain various custom information.

[0067] S24, calculate the certificate hash value of the digital certificate and fill it into the extended field of the verifiable credential.

[0068] A certificate hash value is a fixed-length digest value obtained by performing a cryptographic hash function on a complete, issued digital certificate file.

[0069] Extended fields of a verifiable credential are fields in the data structure of a verifiable credential used to store additional information beyond the standard model definition.

[0070] S25, use the private key to sign the bound verifiable credential, and store the hash value of the signed verifiable credential and the certificate hash value in the blockchain network.

[0071] The verifiable credential after binding refers to the verifiable credential that has been filled with associated information such as the certificate hash value of the digital certificate.

[0072] A signed verifiable credential refers to a complete and verifiable credential formed by digitally signing the entire contents (or its hash value) of the "bound verifiable credential" using the issuer's (certificate authority's) private key and appending the signature result to the credential.

[0073] In some embodiments, storing the hash value of the signed verifiable credential and the certificate hash value in the blockchain network includes: constructing a binding and storage transaction; the binding and storage transaction includes the user's DID identifier, the hash value of the signed verifiable credential, the certificate hash value, and the issuance timestamp and serial number of the digital certificate; and submitting the binding and storage transaction to the blockchain network within a preset time after the digital certificate is issued.

[0074] Binding and storage transactions refer to blockchain transactions in a specific format. Their purpose is to call a function of a smart contract on the blockchain to record interrelated data (such as hash values ​​and identifiers associated with user DID, verifiable credentials, and digital certificates) as a whole on the blockchain.

[0075] The issuance timestamp of a digital certificate refers to the point in time that the certificate authority records inside the certificate when it issues the digital certificate, and is used to identify the effective date of the certificate.

[0076] A digital certificate's serial number is a unique identifier assigned to each digital certificate by the certificate authority. A preset time refers to a pre-defined time window.

[0077] Step 103: Obtain the verifiable credentials and digital certificate submitted by the user when signing the contract, and verify the validity and relevance of the verifiable credentials and digital certificate.

[0078] Validity refers to the fact that verifiable credentials and digital certificates are authentic, complete, and within their validity period. For verifiable credentials, validity means that the issuer's signature is correct and the credential content has not been tampered with. For digital certificates, validity means that they were issued by a trusted CA, the certificate chain is complete, and they have not expired or been revoked.

[0079] Relevance refers to the binding relationship between the verifiable credentials submitted by the user, the digital certificate, and the DID identifier bound to the user on the contract platform. For example, verifying whether the DID declared in the verifiable credentials is consistent with the DID used by the user on the current contract platform; and verifying whether the hash field value recorded in the verifiable credentials matches the actual hash value of the digital certificate submitted by the user.

[0080] In some embodiments, obtaining the verifiable credentials and digital certificate submitted by the user at the time of signing the contract, and verifying the validity and relevance of the verifiable credentials and digital certificate, includes the following operations: S31, verify the validity of the signature of the verifiable credential issued by the contract signing platform.

[0081] Contract signing platforms are centralized or distributed application systems that provide electronic contract creation, signing, management, and storage services.

[0082] The issuer of a verifiable credential refers to the entity that issues and digitally signs the verifiable credential.

[0083] In some embodiments, after receiving a verifiable credential submitted by a user upon signing the contract, the contract signing platform can extract the issuer's identification information from the data structure of the verifiable credential, and use the issuer's public key to perform a signature verification operation on the declaration portion of the verifiable credential and the accompanying verifiable credential signature. If the verification passes, it proves that the signature was indeed generated by the claimed issuer's private key, and that the content of the verifiable credential has not been tampered with since signing, thereby verifying the validity of the issuer's verifiable credential signature.

[0084] S32, verify whether the user DID identifier associated in the verifiable credential is consistent with the DID identifier bound to the current contracted user on the platform.

[0085] The user DID identifier associated with a verifiable credential refers to the field value in the data structure of the verifiable credential used to identify the subject described by the credential.

[0086] The DID identifier that a currently signed user binds to the platform refers to the DID identifier that the user provides when registering an account or binding their identity on the contract signing platform, and which is then verified by the platform and associated with their platform account.

[0087] In some embodiments, the contract signing platform can parse the user's DID identifier associated with the verifiable credentials submitted by the user and whose signature has been verified. Simultaneously, the contract signing platform retrieves the DID identifier of the currently signing user bound to the platform from its own user database or session information; that is, the pre-bound DID string corresponding to the user account that initiated the signing operation. The contract signing platform can perform a precise comparison of these two strings. If the two strings are completely identical, the verification passes, indicating that the user has submitted verifiable credentials to prove their qualifications, ensuring the consistency of identity.

[0088] S33, verify whether the certificate hash value bound in the extended field of the verifiable credential matches the hash value of the digital certificate provided by the contracted user; The certificate hash value bound within the extended fields of a verifiable credential refers to the hash value stored in the extended fields of the verifiable credential.

[0089] The digital certificate provided by the signing user is submitted along with the verifiable credentials when signing the contract.

[0090] In some embodiments, the contract signing platform can read the certificate hash value bound to the extended field in the verifiable credential, denoted as H1, from the extended field location specified in the verifiable credential submitted by the user. Simultaneously, the contract signing platform recalculates the hash value of the original digital certificate file submitted by the user in the same signing request, using the same hash algorithm as when it was issued by the CA, denoted as H2. The contract signing platform then compares H1 and H2; if H1 and H2 are exactly equal, the verification is successful.

[0091] S34, query the storage status of the verifiable credential in the blockchain network to confirm that the verifiable credential is in a valid state.

[0092] The storage status of a verifiable credential refers to the status information recorded on the blockchain network, including whether the hash value of the credential has been stored, the storage time, the associated transaction hash (TXID), and possible status identifiers.

[0093] In some embodiments, before obtaining the verifiable credentials and digital certificate submitted by the user at the time of signing the contract, the method further includes a step of binding the user to the contract signing platform: S41, Submit the DID identifier and the digital certificate to the contract signing platform; S42, verify the validity of the digital certificate through the contract signing platform, and verify whether the extended field of the digital certificate contains the DID identifier; The validity of a digital certificate refers to whether the digital certificate itself is authentic, complete, and usable within its validity period.

[0094] Validation can include verifying whether the certificate issuer's signature is correct, whether the certificate chain is complete and traceable to a trusted root certificate, whether the certificate is within its validity period (not expired), and whether the certificate has been revoked by the issuer.

[0095] S43, a random challenge string is generated through the contract signing platform and sent to the user terminal. The user terminal signs the challenge string using the private key corresponding to the DID identifier and verifies the signature.

[0096] The random challenge string is an unpredictable random data string temporarily generated by the verifier to prevent replay attacks and serve as a temporary credential to prove control of the private key.

[0097] Verification can be achieved by using a public key paired with the signing private key to verify the original data and the received signature value, in order to confirm whether the signature was legally generated by the private key.

[0098] S44. After successful verification, a binding relationship is established between the user account, the DID identifier, and the digital certificate within the contract signing platform.

[0099] A user account is a unique identifier for a user in the contract signing platform system. It may include a username, email address, mobile phone number, etc., and is used for logging in and identifying the user.

[0100] Binding relationship refers to the association relationship obtained by linking different data entities (user accounts, DID identifiers, digital certificates) in the backend database of the contract signing platform through the recording of association fields.

[0101] Step 104: After successful verification, receive the contract signing signature generated by the private key corresponding to the DID identifier, and use the digital certificate to verify the legality of the contract signing signature.

[0102] A contract signature is a unique string of data calculated by applying a digital signature algorithm to an electronic contract document (or its hash value) using the signer's private key.

[0103] Legality verification refers to using the public key carried in a digital certificate to verify whether the contract signature was signed by the holder of the private key corresponding to the certificate, thereby confirming the legality of the signing behavior from a cryptographic and legal perspective.

[0104] After successful verification, users can use their locally stored private key, corresponding to the DID identifier bound to the platform, to calculate the content of the electronic contract to be signed (which can be the hash value of the contract) and generate a digital signature, i.e., the contract signing signature. Users can send this signature to the electronic contract platform, which will then perform a legality verification upon receiving it.

[0105] Step 105: In response to the legality verification of the contract signing signature, the contract signing result is stored in the blockchain.

[0106] A contract signing result is a digital record of the contract signing act and key evidence. For example, a contract signing result may include the hash value of the signed electronic contract document, the generated contract signature, the hash value or serial number of the digital certificate used for signing, the signer's DID identifier, the corresponding verifiable credential hash, a timestamp, and descriptive information about the signing event itself.

[0107] Once the contract signature passes legality verification, the electronic contract platform can trigger on-chain notarization. For example, a transaction can be constructed that invokes a smart contract for notarization on the blockchain, submitting the contract signing result data as a parameter. Nodes in the blockchain network reach a consensus on the transaction and package it onto the chain. After a successful transaction, a unique transaction hash and corresponding block are generated.

[0108] Reference Figure 2 The diagram shown is a functional module schematic of the DID-based electronic contract signing device 100 of this application.

[0109] The DID-based electronic contract signing device 100 described in this application is installed in an electronic device. Depending on its functions, the DID-based electronic contract signing device 100 includes an acquisition module 110, an authentication module 120, a first verification module 130, a second verification module 140, and a storage module 150. These modules, also referred to as units, are a series of computer program segments that can be executed by the processor of an electronic device and perform a fixed function, and are stored in the memory of the electronic device.

[0110] In this embodiment, the functions of each module / unit are as follows: Module 110 is used to obtain the user's distributed digital identity (DID) identifier and the corresponding DID document; The authentication module 120 is used to submit an authentication request to the certificate authority through the user terminal; the authentication request is used to enable the certificate authority to complete identity verification based on the authentication request and issue a verifiable credential and digital certificate bound to the DID identifier for the user. The first verification module 130 is used to obtain the verifiable credentials and digital certificate submitted by the user when signing the contract, and to verify the validity and relevance of the verifiable credentials and digital certificate. The second verification module 140 is used to receive the contract signing signature generated by the private key corresponding to the DID identifier after the verification is passed, and to use the digital certificate to verify the legality of the contract signing signature. Storage module 150 is used to store the contract signing result to the blockchain in response to the contract signing signature passing the legality verification.

[0111] The specific implementation of the DID-based electronic contract signing device in this application is largely the same as the specific implementation of the DID-based electronic contract signing method described above, and will not be repeated here.

[0112] Reference Figure 3 The diagram shown is a schematic representation of a preferred embodiment of the electronic device of this application.

[0113] The electronic device includes a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114. Memory 113 is used to store computer programs, such as DID-based electronic contract signing programs; In some embodiments, the processor 111 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 111 can be used to control the overall operation of the electronic device, such as performing data interaction or communication-related control and processing. In this embodiment, the processor 111 is used to run program code stored in the memory 113 or process data.

[0114] The communication interface 112 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The communication interface 112 may also be used to establish a communication connection between the electronic device and other electronic devices.

[0115] The memory 113 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 113 may be an internal storage unit of the electronic device, such as the hard disk or memory of the electronic device. In other embodiments, the memory 113 may also be an external storage device of the electronic device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. of the electronic device. Of course, the memory 113 may include both internal storage units and external storage devices of the electronic device. In this embodiment, the memory 113 can be used to store the operating system and various computer programs installed on the electronic device, such as the program code of a DID-based electronic contract signing program. In addition, the memory 113 can also be used to temporarily store various types of data that have been output or will be output.

[0116] Figure 3 Only an electronic device with components 111-114 is shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0117] In this embodiment of the application, when the processor 111 executes the program stored in the memory 113, it implements the DID-based electronic contract signing method provided in any of the foregoing method embodiments, including: Obtain the user's Distributed Digital Identity (DID) identifier and the corresponding DID document; The user terminal submits an authentication request to the certificate authority; the authentication request enables the certificate authority to complete identity verification based on the authentication request and issue a verifiable credential and digital certificate bound to the DID identifier to the user. Obtain the verifiable credentials and digital certificate submitted by the user when signing the contract, and verify the validity and relevance of the verifiable credentials and digital certificate; After successful verification, the contract signing signature generated by the private key corresponding to the DID identifier is received, and the legality of the contract signing signature is verified using the digital certificate. In response to the legality verification of the contract signature, the contract signing result is stored in the blockchain.

[0118] For a detailed explanation of the above steps, please refer to the above. Figure 1 A flowchart illustrating an embodiment of a DID-based electronic contract signing method.

[0119] Furthermore, this application also proposes a computer-readable storage medium that is both non-volatile and volatile. This computer-readable storage medium is any one or any combination of several of the following: hard disk, multimedia card, SD card, flash memory card, SMC, read-only memory (ROM), erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), USB memory, etc. The computer-readable storage medium includes a data storage area and a program storage area. The program storage area stores a DID-based electronic contract signing program, which, when executed by a processor, performs the following operations: Obtain the user's Distributed Digital Identity (DID) identifier and the corresponding DID document; The user terminal submits an authentication request to the certificate authority; the authentication request enables the certificate authority to complete identity verification based on the authentication request and issue a verifiable credential and digital certificate bound to the DID identifier to the user. Obtain the verifiable credentials and digital certificate submitted by the user when signing the contract, and verify the validity and relevance of the verifiable credentials and digital certificate; After successful verification, the contract signing signature generated by the private key corresponding to the DID identifier is received, and the legality of the contract signing signature is verified using the digital certificate. In response to the legality verification of the contract signature, the contract signing result is stored in the blockchain.

[0120] The specific implementation of the computer-readable storage medium in this application is largely the same as the specific implementation of the DID-based electronic contract signing method described above, and will not be repeated here.

[0121] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, apparatus, article, or method. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0122] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware simulation platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in the storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0123] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for signing electronic contracts based on DID, characterized in that, The method includes: Obtain the user's Distributed Digital Identity (DID) identifier and the corresponding DID document; The user terminal submits an authentication request to the Certificate Authority (CA); the authentication request enables the CA to complete identity verification based on the authentication request and issue a verifiable credential and a digital certificate bound to the user's DID identifier; the extended fields of the digital certificate include the user's DID identifier and the corresponding verifiable credential identifier; the certificate hash value of the digital certificate is calculated and filled into the extended fields of the verifiable credential; the bound verifiable credential is signed using the CA's private key, and the hash value of the signed verifiable credential and the certificate hash value are stored in the blockchain network; Obtain the verifiable credentials and digital certificate submitted by the user at the time of signing the contract, and verify the validity and relevance of the verifiable credentials and digital certificate; the verification includes: verifying whether the certificate hash value bound in the extended field of the verifiable credentials matches the hash value of the digital certificate provided by the signing user; After successful verification, the contract signing signature generated by the private key corresponding to the DID identifier is received, and the legality of the contract signing signature is verified using the digital certificate. In response to the legality verification of the contract signature, the contract signing result is stored in the blockchain.

2. The DID-based electronic contract signing method as described in claim 1, characterized in that, The process of obtaining the user's distributed digital identity (DID) identifier and corresponding DID document includes: An encryption key pair is generated locally on the user's computer via the user terminal, and the user's DID identifier is generated based on the public key in the key pair; The user terminal generates a DID document based on the DID identifier and the public key, and signs the DID document using the private key in the key pair; Perform a hash operation on the signed DID document to obtain the document hash value; The registration transaction, which includes the DID identifier and the document hash value, is submitted to the blockchain network to complete the on-chain registration of the DID identifier.

3. The DID-based electronic contract signing method as described in claim 2, characterized in that, The step of generating an encryption key pair locally on the user's computer via the user terminal includes: The trusted execution environment within the user terminal is invoked, and the encryption key pair is generated within the trusted execution environment. The step of signing the DID document using the private key from the key pair includes: Within the trusted execution environment, a hash calculation is performed on the data to be signed in the DID document to obtain a digest to be signed; Within the trusted execution environment, the private key is used to perform a signature operation on the digest to be signed, generating a signature value; The signature value is used to sign the DID document.

4. The DID-based electronic contract signing method as described in claim 3, characterized in that, The authentication request includes the DID identifier, proof of control, and identity verification materials; the certificate authority completes identity verification based on the authentication request and issues a verifiable credential and digital certificate bound to the DID identifier to the user, including: The authenticity of the user's identity and qualification materials and the proof of control shall be verified. In response to the successful authenticity verification, a verifiable credential based on the user's DID identifier is constructed. Issue the digital certificate to the user.

5. The DID-based electronic contract signing method as described in claim 1, characterized in that, The step of storing the hash value of the signed verifiable credential and the certificate hash value in the blockchain network includes: Construct a binding and storage transaction; the binding and storage transaction includes the user's DID identifier, the hash value of the signed verifiable credential, the certificate hash value, and the issuance timestamp and serial number of the digital certificate; Within a preset time period after the digital certificate is issued, the binding and storage transaction will be submitted to the blockchain network.

6. The DID-based electronic contract signing method as described in claim 1, characterized in that, The step of obtaining the verifiable credentials and digital certificate submitted by the user at the time of signing the contract, and verifying the validity and relevance of the verifiable credentials and digital certificate, includes: The issuer of the verifiable credential can verify the validity of the credential signature through the contract signing platform; Verify whether the user DID associated with the verifiable credential is consistent with the DID bound to the currently signed user on the platform; Query the storage status of the verifiable credential in the blockchain network to confirm that the verifiable credential is valid.

7. The DID-based electronic contract signing method as described in claim 6, characterized in that, Before obtaining the verifiable credentials and digital certificate submitted by the user at the time of signing the contract, the method also includes a step of binding the user to the contract signing platform: Submit the DID identifier and the digital certificate to the contract signing platform; The validity of the digital certificate is verified through the contract signing platform, and it is also verified whether the extended field of the digital certificate contains the DID identifier. The contract signing platform generates a random challenge string and sends it to the user terminal. The user terminal then signs the challenge string using the private key corresponding to the DID identifier and verifies the signature. After successful verification, a binding relationship is established between the user account, the DID identifier, and the digital certificate within the contract signing platform.

8. A DID-based electronic contract signing device, characterized in that, The device includes: The acquisition module is used to acquire the user's Distributed Digital Identity (DID) identifier and the corresponding DID document; An authentication module is used to submit an authentication request to a certificate authority through the user terminal; the authentication request enables the certificate authority to complete identity verification based on the authentication request, and issue a verifiable credential and a digital certificate bound to the user's DID identifier; the extended fields of the digital certificate include the user's DID identifier and the corresponding verifiable credential identifier; the certificate hash value of the digital certificate is calculated and filled into the extended fields of the verifiable credential; the bound verifiable credential is signed using the certificate authority's private key, and the hash value of the signed verifiable credential and the certificate hash value are stored in the blockchain network; The first verification module is used to obtain the verifiable credentials and digital certificate submitted by the user when signing the contract, and to verify the validity and relevance of the verifiable credentials and digital certificate; the verification includes: verifying whether the certificate hash value bound in the extended field of the verifiable credentials matches the hash value of the digital certificate provided by the signing user. The second verification module is used to receive the contract signing signature generated by the private key corresponding to the DID identifier after the verification is passed, and to use the digital certificate to verify the legality of the contract signing signature. A storage module is used to store the contract signing result to the blockchain in response to the contract signing signature passing the legality verification.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the DID-based electronic contract signing method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the DID-based electronic contract signing method as described in any one of claims 1 to 7.

Images