A cross-domain digital signature method based on attribute encryption and related equipment

Abstract

This application discloses a cross-domain digital signature method and related equipment based on attribute encryption, belonging to the field of digital signatures using blockchain technology. The cross-domain digital signature method is applied to an internal and external cross-domain joint signature system built on a blockchain network. The system includes an identity chain, a consortium chain, a data storage system, and an attribute authorization center cluster. The consortium chain includes proxy nodes and aggregate signature nodes. The system also includes several domain spaces. Proxy nodes on the consortium chain broadcast document joint signature requests across domains, and attribute keys are generated based on the attribute authorization center cluster. These attribute keys are used to encrypt and decrypt symmetric keys, which are then used to encrypt and decrypt the documents to be signed, ensuring secure key transmission. Finally, the joint signatures are aggregated. This application, by using blockchain technology to achieve internal and external cross-domain joint signatures, ensures data security, reliability, and immutability.

Description

Technical Field

[0001] This application belongs to the field of digital signatures in blockchain technology, specifically involving a cross-domain digital signature method based on attribute encryption and related equipment. Background Technology

[0002] The intelligent shared finance platform has already implemented a series of operations, including the issuance and receipt of external legal electronic vouchers, paperless circulation of internal documents, and paper-based archiving of accounting records. However, there is still no unified standard for the joint signing of internal and external collaborative documents, as well as the processing channels. When signing electronic documents, the general reimbursement business line needs to be online. The reimbursement business involves some internal and external documents. Currently, the signing of documents / vouchers between enterprises and external entities requires multiple parties to manually fill out and verify them before they are mailed offline to the enterprise as proof of reimbursement by the business department. Business personnel then process the business by manually scanning documents as reimbursement attachments.

[0003] The aforementioned collaborative document signing method involves manual entry of documents / forms after searching through various business systems. This method is inefficient, prone to data errors, and involves multiple cross-departmental entities, posing risks of sensitive information leakage and theft. Furthermore, it is susceptible to issues such as unauthorized user access and illegal alteration, negatively impacting business data security and subsequent fee settlement processes. Additionally, the reliance on traditional paper-based signing methods makes it prone to proxy signing, scrambling, and arbitrary modification of signed content. This can lead to financial losses due to discrepancies between the signed content and the actual information, making it difficult to pinpoint the responsible party and hindering subsequent accountability. Summary of the Invention

[0004] The purpose of this application is to propose a cross-domain digital signature method, apparatus, computer equipment, and storage medium based on attribute encryption, in order to solve the problems of easy data leakage, easy tampering of document interaction, non-standard signing process, and difficulty in traceability in existing internal and external collaborative document joint signing methods.

[0005] To address the aforementioned technical problems, this application provides a cross-domain digital signature method based on attribute encryption, employing the following technical solution:

[0006] A cross-domain digital signature method based on attribute encryption is proposed. This method is applied to an internal and external cross-domain joint signature system built on a blockchain network. The system includes an identity chain, a consortium chain, a data storage, and an attribute authorization center cluster. The consortium chain includes business nodes, proxy nodes, and aggregate signature nodes. The system also includes several domain spaces, each configured with a matching proxy node on the consortium chain. The cross-domain digital signature method includes:

[0007] Register all joint signatory parties into the internal and external cross-domain joint signatory system and determine the domain space to which each joint signatory party belongs. The joint signatory parties include the joint signatory initiator and the party to be signed.

[0008] Obtain the document joint signing request initiated by the joint signing initiator, determine the party to be signed, and broadcast the document joint signing request across domains through the proxy node of the domain space to which the joint signing initiator belongs, so as to send the document joint signing request to the party to be signed;

[0009] After the party to be signed receives the document signing request, the party to be signed performs authorization verification, which includes cross-domain authorization verification and access permission authentication.

[0010] Once the party to be signed has passed the authorization verification, the encrypted document, which is pre-stored in the data storage, will be sent to the party to be signed. The encrypted document is generated by encrypting the document to be signed using a symmetric key.

[0011] The metadata of the documents to be signed, which are pre-broadcast on the blockchain network, is sent to the parties to be signed. The metadata of the documents to be signed includes attribute ciphertext data generated after attribute encryption of the symmetric key.

[0012] Obtain the attribute key corresponding to the party to be signed from the attribute authorization center cluster, and use the attribute key to decrypt the attribute ciphertext data to obtain the plaintext of the symmetric key;

[0013] The ciphertext of the document is decrypted using a symmetric key to obtain the plaintext of the document to be signed, and the parties to be signed are instructed to sign the document to obtain the joint signature.

[0014] The joint signature is uploaded by the proxy node of the domain space to which the party to be signed belongs, and the joint signature is aggregated by the aggregation signature node to obtain the joint signature result of the document to be signed.

[0015] To address the aforementioned technical problems, this application also provides a cross-domain digital signature device based on attribute encryption, employing the following technical solution:

[0016] A cross-domain digital signature device based on attribute encryption is disclosed. This device is used to run an internal and external cross-domain joint signature system built on a blockchain network. The system includes an identity chain, a consortium chain, a data storage system, and an attribute authorization center cluster. The consortium chain includes business nodes, proxy nodes, and aggregate signature nodes. The system also includes several domain spaces, each configured with a matching proxy node on the consortium chain. The cross-domain digital signature device comprises:

[0017] The joint signature registration module is used to register all joint signature participants to the internal and external cross-domain joint signature system and determine the domain space to which each joint signature participant belongs. The joint signature participants include the joint signature initiator and the party to be signed.

[0018] The cross-domain broadcast module is used to obtain the document joint signing request initiated by the joint signing initiator, determine the party to be signed, and broadcast the document joint signing request across domains through the proxy node of the domain space to which the joint signing initiator belongs, so as to send the document joint signing request to the party to be signed.

[0019] The authorization verification module is used to verify the authorization of the party to be signed after receiving the document signature request. The authorization verification includes cross-domain authorization verification and access permission authentication.

[0020] The encrypted document sending module is used to send the encrypted document data, which is pre-stored in the data storage, to the party to be signed after the party to be signed has passed the authorization verification. The encrypted document data is generated by encrypting the document to be signed using a symmetric key.

[0021] The metadata sending module is used to send the metadata of the documents to be signed, which are pre-broadcast on the blockchain network, to the parties to be signed. The metadata of the documents to be signed includes attribute ciphertext data generated after attribute encryption of the symmetric key.

[0022] The attribute decryption module is used to obtain the attribute key corresponding to the party to be signed from the attribute authorization center cluster, and use the attribute key to decrypt the attribute ciphertext data to obtain the plaintext of the symmetric key.

[0023] The document decryption module is used to decrypt the encrypted document using a symmetric key to obtain the plaintext of the document to be signed, and instructs the parties to sign the document to obtain the joint signature.

[0024] The joint signature module is used to upload joint signatures through the proxy node of the domain space to which the party to be signed belongs, and to aggregate the joint signatures through the aggregation signature node to obtain the joint signature result of the document to be jointly signed.

[0025] To address the aforementioned technical problems, this application also provides a computer device that employs the following technical solution:

[0026] A computer device includes a memory and a processor, the memory storing computer-readable instructions, the processor executing the computer-readable instructions to implement the steps of the attribute-based encryption-based cross-domain digital signature method as described in any of the preceding claims.

[0027] To address the aforementioned technical problems, this application also provides a computer-readable storage medium, employing the technical solution described below:

[0028] A computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of the attribute-based encryption cross-domain digital signature method as described in any one of the preceding descriptions.

[0029] Compared with the prior art, the embodiments of this application have the following main advantages:

[0030] This application discloses a cross-domain digital signature method and related equipment based on attribute encryption, belonging to the field of digital signatures using blockchain technology. The cross-domain digital signature method is applied to an internal and external cross-domain joint signature system built on a blockchain network. The system includes an identity chain, a consortium chain, a data storage system, and an attribute authorization center cluster. The consortium chain includes business nodes, agent nodes, and aggregate signature nodes. The system also includes several domain spaces, each configured with a matching agent node on the consortium chain. This application uses agent nodes on the consortium chain to broadcast joint signature requests across domains and generates attribute keys based on the attribute authorization center cluster. These attribute keys are used to encrypt and decrypt symmetric keys, which in turn are used to encrypt and decrypt documents to be signed, ensuring secure key transmission. Finally, the joint signatures are aggregated using aggregate signatures. This application achieves internal and external cross-domain joint signatures using blockchain technology, ensuring data security, reliability, and immutability. Attached Figure Description

[0031] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 An exemplary system architecture diagram is shown, in which this application can be applied;

[0033] Figure 2 This paper presents a schematic diagram of the internal and external cross-domain joint signature system based on blockchain, as described in this application.

[0034] Figure 3 A flowchart illustrating an embodiment of the attribute-based encryption cross-domain digital signature method according to this application is shown;

[0035] Figure 4 A flowchart illustrating another embodiment of the attribute-based encryption cross-domain digital signature method according to this application is shown.

[0036] Figure 5A schematic diagram of the structure of one embodiment of the cross-domain digital signature device based on attribute encryption according to this application is shown;

[0037] Figure 6 A schematic diagram of the structure of one embodiment of a computer device according to this application is shown. Detailed Implementation

[0038] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0039] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0040] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0041] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0042] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0043] Terminal devices 101, 102, and 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), laptops, and desktop computers, etc.

[0044] Server 105 can be a server that provides various services, such as a backend server that supports the pages displayed on terminal devices 101, 102, and 103. The server can be a standalone server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0045] It should be noted that the cross-domain digital signature method based on attribute encryption provided in this application embodiment is generally executed by the server, and correspondingly, the cross-domain digital signature device based on attribute encryption is generally set in the server.

[0046] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0047] To address the problems of data leakage, document tampering, non-standard signing processes, and difficulty in traceability in existing internal and external collaborative document signing methods, this application discloses a cross-domain digital signature method and related equipment based on attribute encryption. Belonging to the field of digital signatures using blockchain technology, this cross-domain digital signature method is applied to internal and external cross-domain joint signing systems. A schematic diagram of the internal and external cross-domain joint signing system is shown below. Figure 2 As shown, the internal and external cross-domain joint signature system includes an identity chain, a consortium chain, a data storage system, and an attribute authorization center cluster. The consortium chain includes business nodes, agent nodes, and aggregate signature nodes. The internal and external cross-domain joint signature system also includes several domain spaces, each of which is configured with a matching agent node on the consortium chain.

[0048] Identity chain (e.g.) Figure 2Blockchain X shown: This identity chain is a distributed ledger composed of and jointly maintained by the Certificate Authorization Centers (CAs) of each domain. This chain is responsible for managing the behavior of the CAs and storing all registration information (such as temporary certificates) used for cross-domain authentication. This information is embedded into the blockchain as transactions, so that any blockchain node can access it. The main function of this chain is to provide user identity registration and query services.

[0049] Consortium blockchains (such as...) Figure 2 The blockchain Y shown is a distributed ledger maintained by users and agent nodes, allowing nodes to call and instantiate smart contracts. Since this embodiment is primarily applied to cross-domain joint signature solutions within and outside enterprises, the blockchain here is more accurately described as a consortium blockchain. It should be noted that this application is not limited to consortium blockchains and can be extended to private blockchains.

[0050] Data storage: This can be a centralized cloud service provider (CSP) offering ordinary centralized cloud storage services (such as Amazon Web Services, Alibaba Cloud, etc.), or a distributed file storage system (such as IPFS). In the specific embodiments of this application, IPFS is used as an example, but it is not limited to IPFS and can be other data storage systems.

[0051] The attribute authorization center cluster manages the set of attributes and issues attribute private keys to users who meet the access policies. These private keys are sent to relevant nodes (e.g., users, agent nodes, business nodes) via a secure channel. The attribute authorization center cluster typically consists of multiple attribute authorization authorities, which can be independent entities or organizations. Each attribute authorization authority in the cluster manages a specific set of attributes and corresponding authorization policies. The authority verifies the user's attribute claims and generates corresponding attribute authorization information, such as the attribute private key, based on the access policies.

[0052] Certificate Authority (CA): Also known as the key generation center, the CA of each domain is responsible for managing the members of the entire domain, including member registration (such as issuing and distributing public and private key pairs, identity digital certificates, etc.) and tracking malicious members. Each domain is configured with a CA on the identity chain, and the CA of each domain is equivalent to the group administrator of the entire domain.

[0053] Proxy Node: A proxy node can be an edge node or a fog node, acting as a communication bridge between different participants. It mainly provides APIs for verifying signatures, forwarding messages, retrieving transactions, and invoking smart contracts.

[0054] Joint signature aggregation node: This node is one of the organizing nodes in the consortium blockchain. It is responsible for collecting signatures from each user from the proxy nodes of each domain, generating an aggregate signature, and sending it to the data owner or (electronic document) business node.

[0055] In a specific embodiment of this application, before performing cross-domain joint signature verification, the cross-domain joint signature system needs to be initialized and its attribute organization registered. During the initialization of the cross-domain joint signature system, the Certificate Authority (CA) of each domain initializes the system for its respective domain, generating the system's public parameter λ and the domain master's private key (e.g., ...). Figure 2 Private key of enterprise domain M And the private key of the enterprise's external domain N ) and domain master public key (such as Figure 2 Public key of enterprise intradomain M Public key of enterprise external domain N The domain master's private key is used for encryption and signing operations, while the domain master's public key is used for decryption and authentication operations to ensure secure communication and authentication within / between domains.

[0056] During attribute authority registration, each attribute authority in the attribute authority cluster selects two random numbers α and β, which are used as the attribute authority's private key. Generate e(g,g) α and g β The public key used to compute the attribute mechanism is, i.e., the public key of the attribute mechanism is... Here, e is a bilinear mapping, which is a very important cryptographic primitive widely used in many cryptographic systems, such as identity encryption and attribute encryption. It can associate the operations of two different groups, making it possible to design and prove them. g is a generator of the cyclic group G. The role of generator g is mainly reflected in performing various exponential operations, which is the foundation for building public-key cryptography based on the discrete logarithm problem.

[0057] Continue to refer to Figure 3 The diagram shows a flowchart of an embodiment of the attribute-based encryption cross-domain digital signature method according to this application.

[0058] This application discloses a cross-domain digital signature method based on attribute encryption. This method is applied to an internal and external cross-domain joint signature system built on a blockchain network. The system includes an identity chain, a consortium chain, a data storage system, and an attribute authorization center cluster. The consortium chain includes business nodes, proxy nodes, and aggregate signature nodes. The system also includes several domain spaces, each configured with a matching proxy node on the consortium chain. The cross-domain digital signature method includes:

[0059] S201, register all joint signature participants into the internal and external cross-domain joint signature system, and determine the domain space to which each joint signature participant belongs. The joint signature participants include the joint signature initiator and the party to be signed.

[0060] In this embodiment, users (i.e., each participating party in the joint signature process) first apply for public and private key registration with the Certificate Authority (CA) of their respective domain. The CA then generates the private key usk and public key upk for each participating party. Since the identity chain is a distributed ledger, zero-knowledge identity is used to generate zero-knowledge identities for users in order to avoid exposing user information.

[0061] At the same time, the CA center of the user's domain generates an identity tag for the user. i =Hash(ID) i ||GID). Then, the user's identity information (tag) i ID i Add to the domain member list If the user is also one of the signatories for this collaborative signing of electronic documents, then add them to the joint signing group member list. Inside. It should be noted that if the user is not one of the joint signatories, simply adding them to the domain member list is sufficient.

[0062] After a user's identity registration is completed, the identity chain (such as...) Figure 2 The blockchain (X) will establish a credit list database for each domain, storing the credit identifier and credit score of each legitimate user after registration. If a user's credit identifier is "1", it means that the user is in the credit whitelist; if the user's credit identifier is "0", it means that the user is in the credit blacklist, and the credit score will be adjusted according to each joint signature behavior.

[0063] Further reference Figure 4 , Figure 4 The flowchart illustrates another embodiment of the attribute-based encryption-based cross-domain digital signature method according to this application. Prior to the steps of obtaining the document co-signing request initiated by the co-signing initiator and broadcasting the document co-signing request across domains through a proxy node in the domain space to which the co-signing initiator belongs, the method further includes:

[0064] S211, Obtain the symmetric key and key pair of the joint signature initiator;

[0065] S212, obtain the document to be signed uploaded by the joint signing initiator, encrypt the document to be signed using a symmetric key, generate document ciphertext, and store the document ciphertext in the data storage device;

[0066] S213, transmit the public key of the key pair to the attribute authorization center cluster;

[0067] S214, obtain the attribute set of the party to be signed through the attribute authorization center cluster, and generate the attribute key based on the attribute set of the party to be signed and the public key of the key pair;

[0068] S215, use the attribute key to perform attribute encryption on the symmetric key to obtain attribute ciphertext data;

[0069] S216, Perform a hash operation on the documents to be signed to obtain the hash value of the documents to be signed;

[0070] S217, obtain the location index address of the encrypted document on the data storage, and generate the metadata of the document to be jointly signed based on the attribute encrypted data, the hash value of the document to be jointly signed and the location index address. The metadata of the document to be jointly signed also includes the hash value of the identity identifier of the joint signing initiator, the digital signature of the joint signing initiator, the credit score identifier of the joint signing initiator and the timestamp.

[0071] S218 broadcasts the metadata of the documents to be jointly signed on the blockchain network.

[0072] In this embodiment, before joint signing, the document to be signed needs to be encrypted and uploaded. Specifically, the identity chain needs to generate a symmetric key and key pair for the joint signing initiator, which are used for subsequent data encryption and digital signature operations. After the joint signing initiator uploads the document to be signed, the system uses the obtained symmetric key to encrypt the document, generating encrypted document data, and stores the encrypted document data in the data storage. At the same time, the joint signing initiator needs to transmit the public key of the key pair to the attribute authorization center cluster for subsequent generation of attribute keys. The system obtains the attribute set of the party to be signed through the attribute authorization center cluster. These attributes are used to generate attribute keys. The system uses the attribute set of the party to be signed and the public key of the key pair to generate attribute keys. The system uses the generated attribute keys to encrypt the symmetric key, obtaining attribute encrypted data. The system performs a hash operation on the documents to be signed to obtain the hash value of the documents to be signed, and obtains the location index address of the encrypted document in the data storage. It uses the attribute encrypted data, the hash value of the documents to be signed, the location index address, and other relevant information to generate the metadata of the documents to be signed, which also includes the hash value of the identity identifier of the initiator of the joint signing, the digital signature of the initiator of the joint signing, the credit score identifier of the initiator of the joint signing, and the timestamp.

[0073] In one specific embodiment of this application, reference continues to be made to... Figure 2 If user A is the creator of the (electronic document) data, then a symmetric key is generated, and the (electronic document) data is symmetrically encrypted using the symmetric key to produce ciphertext. This ciphertext is then uploaded to the IPFS system, which returns the storage location index address (Hash). ipfsUser A obtains the attribute public key sent by the attribute authorization center cluster and uses this attribute public key symmetric key for attribute encryption. Simultaneously, User A can obtain the metadata of the (electronic document) data. <CT k Hash m Hash ipfs Hash(tag) i / / ID i ), σ, R i T i >, including CT k It is the key ciphertext encrypted with attributes, Hash m It is the hash value obtained after the file data is processed by a hash function (such as SHA-256). ipfs This represents the location index address of the (electronic document) data stored on IPFS, Hash(tag) i / / ID i ) is the hash value of the user's identity, σ is the user's digital signature, and R is the hash value of the user's identity. i It is the user's credit identifier and credit score, T i It's a timestamp.

[0074] User A records the aforementioned metadata on the blockchain. Each block on the chain contains the hash value of the previous block, which can be used to retrieve blocks. Furthermore, the timestamps generated on the chain ensure the timeliness of the blocks; the latest generated block is broadcast on the chain. Receiving nodes verify the correctness according to the consensus algorithm. If correct, the information is passed to other nodes. After a majority of nodes have verified the correctness, the block is added to the blockchain, achieving the function of permanent data storage and sharing.

[0075] Furthermore, after registering all joint signatory parties into the internal and external cross-domain joint signatory system and determining the domain space to which each joint signatory party belongs, the process also includes:

[0076] Apply for and register key pairs with the certificate authority in the identity chain for each joint sign-off participant, and obtain the key pair for each joint sign-off participant;

[0077] The identity of each joint signatory is verified using the first key pair in the key pair of each joint signatory and a preset zero-knowledge authentication algorithm, and the zero-knowledge identity verification result of each joint signatory is obtained.

[0078] The zero-knowledge identity verification results of each co-signing participant are uploaded to the identity chain.

[0079] Zero-Knowledge Proof (ZKP) is a cryptographic protocol used to prove the truth of a statement without revealing any information about that statement to the verifier; that is, it does not disclose any knowledge. In zero-knowledge proof, the prover can prove the correctness of a statement to the verifier, who can only conclude whether it is correct or not, but cannot know the specific content of the statement.

[0080] In this embodiment, the joint signature system requires all participating parties to register their information and determine the domain space to which each party belongs for subsequent identity verification and authorization. Each participating party needs to apply for and register a key pair with a certificate authority for subsequent identity verification and digital signature operations. The system uses the first key pair from each participating party's key pair and a preset zero-knowledge authentication algorithm to verify the identity of each participating party. Through identity verification, the system can obtain the zero-knowledge identity verification result for each participating party, i.e., verify whether the participating party's identity is valid. Finally, the zero-knowledge identity verification result of each participating party is uploaded to the identity chain so that other participating parties can verify the participating party's identity and perform subsequent authorization verification and interactive operations.

[0081] The above steps are key steps in the identity verification and registration process in the joint signature system. These steps ensure the validity of each participant's identity and provide the necessary identity credentials and authorization verification basis for subsequent joint signature operations.

[0082] Furthermore, the step of obtaining the second key pair by performing key transformation on the first key pair includes:

[0083] Once the parties involved in the joint signing have passed the zero-knowledge identity verification, a second random number is generated.

[0084] The second public key is generated based on the first public key and the second random number.

[0085] In this embodiment, after receiving the user's zero-knowledge identity ψ, the identity chain selects a random number γ and generates the user's second public key using the following formula:

[0086] upk ′ =(g usk ) γ

[0087] After generating the user's second public key, it is then submitted to the blockchain for notarization as a transaction. When generating the attribute key for this user, the identity chain stores the two public keys (upk,upk)... ′ The attribute authorization center cluster is used as part of the input to the key generation algorithm to generate attribute keys.

[0088] Further, the key pair includes a first key pair and a second key pair, wherein the second key pair is obtained by performing key transformation on the first key pair. The first key pair includes a first public key and a first private key, and the second key pair includes a second public key and a second private key. The step of transmitting the public key of the key pair to the attribute authorization center cluster includes:

[0089] Transmit the first and second public keys to the attribute authorization center cluster.

[0090] In this embodiment, the key pair consists of a public key and a private key, wherein the first key pair includes a first public key and a first private key, and the second key pair includes a second public key and a second private key. In the step of transmitting the public key of the key pair to the attribute authorization center cluster, it is necessary to transmit the first public key upk and the second public key upk. ′ The data is transmitted to the attribute authorization center cluster, which then obtains the public key information of the joint sign-off participants for subsequent identity verification, permission verification, and attribute key generation.

[0091] By following the steps above, the attribute authorization center cluster can obtain the public key information of the joint signing participants, so as to carry out subsequent identity verification, access control and attribute key generation operations.

[0092] Furthermore, the steps of obtaining the attribute set of the party to be signed through the attribute authorization center cluster, and generating an attribute key based on the attribute set of the party to be signed and the public key of the key pair, include:

[0093] Determine the attribute authority corresponding to each attribute in the attribute set of the party to be signed, wherein the attribute authorization center cluster includes several attribute authorities;

[0094] Generate a first random number for the attribute structure corresponding to each attribute;

[0095] Calculate the first attribute key based on the first public key and the first random number, and calculate the second attribute key based on the second public key and the first random number;

[0096] Combine the first attribute key and the second attribute key to obtain the attribute key.

[0097] In this embodiment, within the attribute authorization center cluster, it is necessary to determine the attribute organization corresponding to each attribute in the attribute set of the party to be signed. An attribute organization can be understood as an institution or organization responsible for managing and maintaining a specific attribute. To generate an attribute key, a random number t needs to be generated for each attribute's corresponding attribute organization. i random number t i It is a randomly generated value used for subsequent attribute key calculations.

[0098] In a specific embodiment of this application, when user B wants to access user A's (electronic document) data across domains, the attribute authorization cluster will receive the user's two public keys (upk,upk) sent by the identity chain. ′ The attribute authorization cluster obtains user B's personal attribute set. Each attribute authority in the cluster selects a random number δ and then calculates the attribute key according to the following formula:

[0099]

[0100] ASK2 = upk ′δ

[0101] In the formula, ASK1 is the first attribute key, ASK2 is the second attribute key, and n is the number of personal attributes in user B's personal attribute set. Combining the first and second attribute keys, we obtain the attribute key ASK = (ASK1, ASK2), and then feed the attribute key ASK and the first public key upk back to user B.

[0102] In a specific embodiment of this application, the CA node of each domain represents the attribute space of its respective domain. Each attribute in Choose a random number t i , t i It is part of generating the attribute private key.

[0103] Furthermore, the attribute key includes an attribute public key and an attribute private key. After the step of combining the first attribute key and the second attribute key to obtain the attribute key, the method further includes:

[0104] Send the attribute public key to the co-signature initiator;

[0105] The symmetric key is encrypted using the attribute public key to obtain attribute ciphertext data.

[0106] In this embodiment, the attribute authorization center cluster needs to send the attribute public key to the joint signature initiator. This allows the initiator to obtain the attribute public key for subsequent attribute data encryption operations. The attribute public key is used to encrypt the symmetric key, resulting in ciphertext attribute data. Only institutions possessing the corresponding attribute private key can decrypt and retrieve the original symmetric key, ensuring the security of the symmetric key.

[0107] S202: Obtain the document joint signing request initiated by the joint signing initiator, determine the party to be signed, and broadcast the document joint signing request across domains through the proxy node of the domain space to which the joint signing initiator belongs, so as to send the document joint signing request to the party to be signed.

[0108] In this embodiment, user A specifies a joint signature request message Msg1. The content of Msg1 is roughly as follows: "The electronic document associated with the on-chain XXX metadata needs to be signed." "All members in the group member list jointly sign," then user A digitally signs the message Msg1 with their private key and broadcasts it across the entire blockchain.

[0109] If all members in the group member list are within the same domain, then the message only needs to be broadcast across the entire network within that domain. If the group member list includes members from other domains (e.g., users B and D in domain N), then the message is sent to the proxy node of the associated domain (e.g., proxy node Alpha in domain M). Proxy node Alpha then broadcasts the joint signature request message Msg1 to domain N. Proxy node Beta in domain N receives the joint signature request message Msg1 and broadcasts it within domain N.

[0110] It should be noted that upon receiving this broadcast message, if the data user (e.g., user C) and the data owner (e.g., user A) belong to the same domain, the data user can use the locally stored public key of user A to verify the digital signature of the information. Otherwise, the data user (e.g., user B) verifies the message through the CA node of their domain (e.g., the CA node of domain N) using the attribute private key and the temporary certificate stored on the identity chain.

[0111] Further, the steps of obtaining the document joint signing request initiated by the joint signing initiator, determining the party to be signed, and broadcasting the document joint signing request across domains through the proxy node of the domain space to which the joint signing initiator belongs, and sending the document joint signing request to the party to be signed, include:

[0112] Analyze the document signature request to determine the signatory party corresponding to the document to be signed;

[0113] Determine whether the party to be signed and the party initiating the joint signature are in the same domain space;

[0114] When the party to be signed and the party initiating the joint signing are in the same domain space, the document joint signing request is broadcast within the domain space of the party initiating the joint signing;

[0115] When the party to be signed and the party initiating the joint signing are not in the same domain space, the document joint signing request is broadcast across domains through the proxy node of the domain space to which the party initiating the joint signing belongs, and the document joint signing request is sent to the party to be signed.

[0116] In this embodiment, after the initiator of the joint signature request initiates the document joint signature request, the request needs to be parsed to determine the signatory corresponding to the document to be jointly signed. This can be done by parsing relevant information in the request, such as the signatory's identifier or other identifying information. After determining the signatory, it is necessary to determine whether the signatory and the initiator of the joint signature are in the same domain space. A domain space refers to a set of entities with the same permissions and access rules. If the signatory and the initiator of the joint signature are in the same domain space, intra-domain broadcasting can be performed. If the signatory and the initiator of the joint signature are in the same domain space, the initiator of the joint signature can directly broadcast the document joint signature request to other nodes in that domain space so that the signatory can receive and process it. If the signatory and the initiator of the joint signature are not in the same domain space, the initiator of the joint signature needs to perform cross-domain broadcasting through a proxy node of its own domain space. The proxy node can forward the document joint signature request to the domain space where the signatory resides so that the signatory can receive and process it.

[0117] Through the above steps, the initiator of the joint signature can send the document joint signature request to the party to be signed, and choose to broadcast within the domain or across domains depending on whether the party to be signed and the initiator of the joint signature are in the same domain space. This ensures that the party to be signed can receive the document joint signature request in a timely manner and carry out subsequent processing.

[0118] S203: After the party to be signed receives the document co-signing request, it performs authorization verification on the party to be signed. The authorization verification includes cross-domain authorization verification and access permission authentication.

[0119] In this embodiment, the party to be signed needs to satisfy the verification of two contracts. The first is a cross-domain permission verification smart contract, which aims to verify the legitimacy of the cross-domain permissions of the party to be signed, that is, to verify whether the identity of the party to be signed can access across domains. The second is an access permission authentication smart contract, which verifies whether the attributes possessed by the party to be signed meet the access policy set by the joint signing initiator.

[0120] Furthermore, after the party to be signed receives the document signature request, the steps for verifying the party's authorization include:

[0121] Obtain smart contracts from the blockchain network, including cross-domain permission verification smart contracts and access permission authentication smart contracts;

[0122] Cross-domain permission verification is performed on the smart contract based on cross-domain permission verification and the preset Proof verification mechanism to verify the cross-domain permissions of the party to be signed.

[0123] Access rights are verified by a smart contract based on access rights authentication and a pre-defined linear secret sharing algorithm.

[0124] In this embodiment, the system needs to acquire smart contracts in the blockchain network, including cross-domain permission verification smart contracts and access permission authentication smart contracts. Based on the cross-domain permission verification smart contract and a preset Proof verification mechanism, the system verifies the cross-domain permissions of the party to be signed. The Proof verification mechanism is an algorithm used to verify evidence, ensuring that the cross-domain permissions of the party to be signed are legal and valid. During the cross-domain permission verification process, the party to be signed needs to provide corresponding evidence to prove that it has the right to access cross-domain resources. Based on the access permission authentication smart contract and a preset linear secret sharing algorithm, the system verifies the access permissions of the party to be signed. The linear secret sharing algorithm is an algorithm used to protect access control information, ensuring that the party to be signed has the necessary access permissions. During the access permission authentication process, the party to be signed needs to provide the corresponding key to prove that it has the necessary access permissions.

[0125] By following the steps above, the party requesting a signature can verify the authorization of the document signing request to ensure its legitimacy. This prevents unauthorized access and tampering, protecting the security and integrity of the data.

[0126] In one specific embodiment of this application, the smart contract verification process for user B's cross-domain permission verification is as follows:

[0127] User B calculates the access authentication key. And valid attribute user keys AUK1 = AK1, AUK2 = (AK2) 1 / usk AUK = (AUK1, AUK2). The user keeps (usk, upk, ATK, AUK) locally as a secret, while sending ATK to the consortium blockchain.

[0128] User B selects two random numbers r1 and r2, and calculates the following parameters:

[0129] h = Hash(CT) k ,r2,T)

[0130]

[0131]

[0132]

[0133] y = r1 + c·usk(mod p)

[0134] In the formula, h represents the current timestamp T, the random number r2, and the ciphertext key CT. k The hash value obtained by performing a hash operation. The result is obtained by exponentially operating on h and user B's private key usk. p1 is the result of exponentially operating on h using the random number r1. p2 is the result of exponentially operating on the authentication token ATK using the random number r1. c is the result of exponentially operating on the access authentication key ATK and user B's private key usk. The result obtained by p1 and p2 is y, which is obtained by multiplying c by the private key usk, then multiplying by the result of the modulo operation on a large prime number p, and adding a random number r1.

[0135] Then User B will prove and Msg = <CT k ,r2,T,ATK> are sent together to the consortium blockchain.

[0136] The consortium blockchain's smart contract verifies the Proof. First, it verifies the validity of the timestamp, specifically whether the consortium blockchain received the Proof within the set maximum delay time (ΔT). If the Proof is received within the maximum delay time ΔT, then the following is calculated based on the Proof and the content in the Msg:

[0137] h = Hash(CT) k ,r2,T)

[0138]

[0139] At the same time, check whether the following two formulas are true:

[0140]

[0141] ATK y =p2·upk c

[0142] If both formulas are true, then the access permission is valid.

[0143] In one specific embodiment of this application, the smart contract verification process for user B's access rights is as follows:

[0144] The tree-structured access strategy is transformed into an LSSS matrix W using the Linear Secret Sharing (LSSS) algorithm. The number of rows in the matrix is ​​the number of leaf nodes in the access control tree, which is also the number of attributes in the access strategy.

[0145] If the user-bound attributes satisfy the access policy, then a vector can be found. (or there exists a vector) ), enabling If it exists, then the verification result of the smart contract is True.

[0146] S204. After the party to be signed passes the authorization verification, the encrypted document, which is pre-stored in the data storage, is sent to the party to be signed. The encrypted document is generated by encrypting the document to be signed using a symmetric key.

[0147] In this embodiment, if both the cross-domain permission verification smart contract and the access permission authentication smart contract verification results are True, it proves that the party to be signed is a legitimate access user, and IPFS then sends the encrypted file data back to the party to be signed. Simultaneously, IPFS generates a re-encryption key based on the True verification result and the public key of the party to be signed, and sends it together with the re-encryption key to the attribute authorization center cluster via a secure channel. This re-encryption key is then used by the attribute authorization center cluster to re-encrypt the attribute private key.

[0148] S205, the metadata of the document to be jointly signed, which is pre-broadcast on the blockchain network, is sent to the party to be signed. The metadata of the document to be jointly signed includes attribute ciphertext data generated after attribute encryption of the symmetric key.

[0149] In this embodiment, after the party to be signed obtains the plaintext of the attribute private key, it searches for the metadata of the document to be co-signed on the blockchain network and extracts the symmetric key ciphertext CT from the metadata storage. k The symmetric key k is then obtained by decrypting the document using the attribute private key. This symmetric key k is then used to decrypt the ciphertext of the document obtained from IPFS, thus obtaining the plaintext of the document to be signed.

[0150] S206. Obtain the attribute key corresponding to the party to be signed from the attribute authorization center cluster, and use the attribute key to decrypt the attribute ciphertext data to obtain the plaintext of the symmetric key.

[0151] In this embodiment, the attribute authorization center cluster re-encrypts the attribute private key using a re-encryption key, and then sends the re-encrypted data to the party to be signed. The party to be signed decrypts the re-encrypted data using its own private key to obtain the plaintext of the attribute private key.

[0152] Further, the steps of obtaining the attribute key corresponding to the party to be signed from the attribute authorization center cluster, and using the attribute key to decrypt the attribute ciphertext data to obtain the plaintext of the symmetric key include:

[0153] Obtain the first public key of the party to be signed, and use the first public key of the party to be signed to re-encrypt the attribute private key to obtain the re-encrypted data;

[0154] The re-encrypted data is sent to the party to be signed, and the re-encrypted data is decrypted using the first private key of the party to be signed to obtain the plaintext of the attribute private key;

[0155] Download the metadata of the documents to be signed from the blockchain network and identify the attribute encrypted data in the metadata of the documents to be signed.

[0156] The attribute ciphertext data is decrypted using the attribute private key to obtain the plaintext of the symmetric key.

[0157] In this embodiment, firstly, the attribute authorization center cluster needs to obtain the first public key of the party to be signed. This public key is used to re-encrypt the attribute private key. The attribute authorization center cluster uses the first public key of the party to be signed to re-encrypt the attribute private key, obtaining re-encrypted data. The attribute authorization center cluster sends the re-encrypted data to the party to be signed, who uses its own first private key to decrypt the re-encrypted data, thus obtaining the plaintext of the attribute private key. Then, the party to be signed needs to download the metadata of the document to be jointly signed from the blockchain network. The metadata of the document to be jointly signed contains attribute ciphertext data, that is, attribute data encrypted using a symmetric key. The party to be signed uses the previously obtained attribute private key to decrypt the attribute ciphertext data, thus obtaining the plaintext of the symmetric key. This ensures the security of the symmetric key and also guarantees that the party to be signed can correctly decrypt the attribute ciphertext data and obtain the original attribute data.

[0158] Through the above steps, the initiator of the joint signature can obtain the attribute key corresponding to the party to be signed, and use the attribute key to decrypt the attribute ciphertext data to obtain the plaintext of the symmetric key. This ensures that the party to be signed can correctly decrypt the attribute ciphertext data and obtain the original attribute data.

[0159] S207. Use the symmetric key to decrypt the encrypted document to obtain the plaintext of the document to be signed, and instruct the parties to sign to sign the document to obtain the joint signature.

[0160] In this embodiment, a symmetric key k is used to decrypt the ciphertext of the document obtained from IPFS, thereby obtaining the plaintext of the document to be co-signed. Then, the party to be signed uses the signing private key SK. i Sign the documents to be signed to obtain the joint signature.

[0161] It should be noted that during the registration of joint signature participants, the CA nodes of each joint signature participant create a blockchain wallet for the user through the identity chain, and generate a private key fragment PSK for the user based on this wallet. i The public key and private key are sent to the user via a secure channel. Upon receiving the private key fragment, the user generates a complete private key, namely the signing private key SK. i The signing private key SK i Used for digital signatures. A user's public key is publicly displayed on the identity chain, while their private key is kept secret. Users can retrieve the public key and user identity information (tag) by traversing the entire identity chain using the public key's identity attributes. i IDi It binds to its public key, generates an identity certificate, and publishes it to the identity chain.

[0162] In one specific embodiment of this application, when the group signature list There are multiple parties to the electronic document to be signed (e.g., user C in domain M, users B and D in domain N, etc.). Each party reviews the content of the electronic document to be signed. After confirming that it is correct, each party digitally signs the document data. For example, when n parties sign, n digital signatures σ will be generated. i {σ1,σ2,...,σ n}

[0163] Each party seeking to sign submits its signed document to the proxy node of its respective domain. For example, user B submits to proxy node Beta in domain N, and the proxy node verifies the signature σ. i If the condition is valid, output True and accept σ. i If the signature is deemed valid, the user's credit score is incremented by 1; otherwise, the output is False, indicating that the signature submitted by the user is invalid, and the user's credit score is decremented by 1. For serious malicious individuals, they can be directly added to the blacklist, or some penalties can be selectively implemented, such as prohibiting the user from participating in joint signing for a period of time, or requiring them to pay more "costs" to participate in joint signing.

[0164] S208: Upload the joint signature through the proxy node of the domain space to which the party to be signed belongs, and aggregate the joint signature through the aggregation signature node to obtain the joint signature result of the document to be jointly signed.

[0165] In this embodiment, to improve signature verification efficiency and reduce signature storage space, the present invention needs to compress multiple jointly signed digital signatures and aggregate them into a final signature. The aggregation method includes two approaches:

[0166] Signature aggregation method 1: When a proxy node in blockchain Y (such as proxy node Beta in domain N) collects all the legitimate digital signatures of signers (such as user B) in its domain, it sends them to the joint signature aggregation node. This node will collect the signatures and aggregate them to generate the final aggregated signature σ.

[0167] Signature aggregation method two: When the proxy nodes in blockchain Y collect all the legitimate digital signatures of signers in their respective domains, they first perform a first-level aggregation to generate a partial aggregated signature σ′. Each proxy node then sends its own partial aggregated signature σ′ to the joint signature aggregation node, which performs a second-level aggregation to generate the final aggregated signature σ.

[0168] After obtaining the joint signature results of the documents to be jointly signed, it is necessary to verify the joint signature results. Specifically, when the data joint signing initiator (such as user A) or business node receives the aggregated signature, it calls the aggregated signature verification contract to verify the validity of the aggregated signature. If the aggregated signature is valid, the signature is accepted, indicating that the electronic document has been successfully jointly signed internally and externally; if invalid, the signature is rejected.

[0169] After the documents have been jointly signed and confirmed to be correct, they are uploaded to IPFS after being symmetrically encrypted. The hash value of its IPFS storage location is obtained, and the hash digest, aggregated signature, and timestamp are packaged and recorded on the blockchain.

[0170] Once a document is successfully signed, the signing aggregation node will generate a key for symmetric encryption, then upload it to IPFS, and its corresponding metadata will be added to the blockchain. If a business node wants to access and retrieve a successfully signed document, it needs to send a data retrieval request, and the document can only be downloaded after the data retrieval request is verified.

[0171] If a business node's attributes pass the permission verification and meet the access policy, it is granted data access permissions. When a business node gains access to data, it can search for and obtain the hash index of the required electronic document on the blockchain, and then retrieve the original complete encrypted file data from the off-chain IPFS. After receiving the message that the user's attributes meet the access policy, the attribute authorization authority distributes an attribute private key to the user. The user uses this key to decrypt the ciphertext of the symmetric key, obtains the symmetric key, and then uses this symmetric key to decrypt the original complete encrypted file data downloaded from IPFS beforehand, thereby obtaining the plaintext document and realizing access and sharing of the document.

[0172] In the above embodiments, this application discloses a cross-domain digital signature method based on attribute encryption, belonging to the field of digital signatures in blockchain technology. The cross-domain digital signature method is applied to an internal and external cross-domain joint signature system, which is built on a blockchain network. The system includes an identity chain, a consortium chain, a data storage system, and an attribute authorization center cluster. The consortium chain includes business nodes, proxy nodes, and aggregate signature nodes. The system also includes several domain spaces, each configured with a matching proxy node on the consortium chain. This application broadcasts document joint signature requests across domains through proxy nodes on the consortium chain and generates attribute keys based on the attribute authorization center cluster. The attribute keys are used to encrypt and decrypt symmetric keys, which are then used to encrypt and decrypt documents to be signed, ensuring secure key transmission. Finally, the joint signatures are aggregated using aggregate signatures. By using blockchain technology to achieve internal and external cross-domain joint signatures, this application ensures data security, reliability, and immutability.

[0173] In this embodiment, the cross-domain digital signature method based on attribute encryption runs on electronic devices (e.g., Figure 1 The server shown can receive instructions or acquire data via wired or wireless connection. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra-wideband) connections, and other currently known or future wireless connection methods.

[0174] The blockchain referred to in this application is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying blockchain platform, a platform product service layer, and an application service layer.

[0175] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware with computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium, and when executed, they can include the processes of the embodiments of the methods described above. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0176] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0177] Further reference Figure 5 As a response to the above Figure 3 The implementation of the method shown in this application provides an embodiment of a cross-domain digital signature device based on attribute encryption. This device embodiment is similar to... Figure 3Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0178] like Figure 5 As shown in this embodiment, the cross-domain digital signature device 500 based on attribute encryption is used to run an internal and external cross-domain joint signature system. This system is built on a blockchain network and includes an identity chain, a consortium chain, a data storage system, and an attribute authorization center cluster. The consortium chain includes business nodes, proxy nodes, and aggregate signature nodes. The system also includes several domain spaces, each configured with a matching proxy node on the consortium chain. The cross-domain digital signature device 500 includes:

[0179] The joint signature registration module 501 is used to register all joint signature participants to the internal and external cross-domain joint signature system and determine the domain space to which each joint signature participant belongs. The joint signature participants include the joint signature initiator and the party to be signed.

[0180] The cross-domain broadcast module 502 is used to obtain the document joint signing request initiated by the joint signing initiator, determine the party to be signed, and broadcast the document joint signing request across domains through the proxy node of the domain space to which the joint signing initiator belongs, so as to send the document joint signing request to the party to be signed.

[0181] The authorization verification module 503 is used to verify the authorization of the party to be signed after receiving the document signature request. The authorization verification includes cross-domain authorization verification and access permission authentication.

[0182] The encrypted document sending module 504 is used to send the encrypted document data stored in the data storage to the party to be signed after the party to be signed has passed the authorization verification. The encrypted document data is the encrypted data generated by encrypting the document to be signed using a symmetric key.

[0183] Metadata sending module 505 is used to send the metadata of the document to be signed, which is pre-broadcast on the blockchain network, to the party to be signed. The metadata of the document to be signed includes attribute ciphertext data generated after attribute encryption of the symmetric key.

[0184] The attribute decryption module 506 is used to obtain the attribute key corresponding to the party to be signed from the attribute authorization center cluster, and use the attribute key to decrypt the attribute ciphertext data to obtain the plaintext of the symmetric key.

[0185] The document decryption module 507 is used to decrypt the document ciphertext using a symmetric key to obtain the plaintext of the document to be signed, and instructs the parties to sign the document to be signed to obtain the joint signature.

[0186] The joint signature module 508 is used to upload joint signatures through the proxy node of the domain space to which the party to be signed belongs, and to aggregate the joint signatures through the aggregation signature node to obtain the joint signature result of the document to be jointly signed.

[0187] Furthermore, the attribute-based cross-domain digital signature device 500 also includes:

[0188] The key acquisition module is used to acquire the symmetric key and key pair of the co-signing initiator;

[0189] The document encryption module is used to obtain the documents to be signed uploaded by the initiator of the joint signing, encrypt the documents to be signed using a symmetric key, generate document ciphertext, and store the document ciphertext in the data storage device;

[0190] The public key transmission module is used to transmit the public key of the key pair to the attribute authorization center cluster;

[0191] The attribute key generation module is used to obtain the attribute set of the party to be signed through the attribute authorization center cluster, and generate an attribute key based on the attribute set of the party to be signed and the public key of the key pair.

[0192] The attribute encryption module is used to encrypt the symmetric key with the attribute key to obtain attribute ciphertext data.

[0193] The hash operation module is used to perform hash operations on the documents to be signed to obtain the hash value of the documents to be signed.

[0194] The metadata generation module is used to obtain the location index address of the encrypted document on the data storage, and generate the metadata of the document to be jointly signed based on the attribute encrypted data, the hash value of the document to be jointly signed and the location index address. The metadata of the document to be jointly signed also includes the hash value of the identity identifier of the joint signing initiator, the digital signature of the joint signing initiator, the credit score identifier of the joint signing initiator and the timestamp.

[0195] The metadata broadcasting module is used to broadcast the metadata of documents to be jointly signed on the blockchain network.

[0196] Furthermore, the key pair includes a first key pair and a second key pair, wherein the second key pair is obtained by performing a key transformation on the first key pair. The first key pair includes a first public key and a first private key, and the second key pair includes a second public key and a second private key. The public key transmission module includes:

[0197] The public key transmission submodule is used to transmit the first and second public keys to the attribute authorization center cluster;

[0198] Furthermore, the attribute key generation module includes:

[0199] The attribute agency determination submodule is used to determine the attribute agency corresponding to each attribute in the attribute set of the party to be signed. The attribute authorization center cluster includes several attribute agencies.

[0200] The first random number generation submodule is used to generate a first random number for the attribute structure corresponding to each attribute.

[0201] The attribute key calculation submodule is used to calculate the first attribute key based on the first public key and the first random number, and to calculate the second attribute key based on the second public key and the first random number.

[0202] The attribute key generation submodule is used to combine the first attribute key and the second attribute key to obtain the attribute key.

[0203] Furthermore, the attribute key includes an attribute public key and an attribute private key, and the public key transmission module also includes:

[0204] The attribute public key sending submodule is used to send the attribute public key to the joint signature initiator;

[0205] The attribute encryption submodule is used to encrypt the symmetric key using the attribute public key to obtain attribute ciphertext data.

[0206] Furthermore, the attribute-based cross-domain digital signature device 500 also includes:

[0207] The key pair acquisition module is used to apply for and register key pairs with the certificate authority in the identity chain of each joint signature participant, and obtain the key pair of each joint signature participant;

[0208] The zero-knowledge verification module is used to verify the identity of each joint signatory using the first key pair in the key pair of each joint signatory and a preset zero-knowledge identity verification algorithm, and to obtain the zero-knowledge identity verification result of each joint signatory.

[0209] The verification result upload module is used to upload the zero-knowledge identity verification result of each joint signatory to the identity chain;

[0210] Furthermore, the attribute-based cross-domain digital signature device 500 also includes:

[0211] The second random number generation module is used to generate a second random number after the joint signatory parties have passed the zero-knowledge identity verification.

[0212] The second public key generation module is used to generate a second public key based on the first public key and the second random number.

[0213] Furthermore, the cross-domain broadcast module 502 includes:

[0214] The "Party to be Signed Determined" submodule is used to parse document signature requests and determine the party to be signed corresponding to the document to be signed.

[0215] The domain space judgment submodule is used to determine whether the party to be signed and the party initiating the joint signature are in the same domain space;

[0216] The intra-domain broadcast submodule is used to broadcast the document co-signing request intra-domain within the domain space of the co-signing initiator when the party to be signed and the co-signing initiator are in the same domain space.

[0217] The cross-domain broadcast submodule is used to broadcast the document joint signing request across domains through the proxy node of the domain space to which the joint signing initiator belongs when the party to be signed and the party initiating the joint signing are not in the same domain space, so as to send the document joint signing request to the party to be signed.

[0218] Furthermore, the authorization verification module 503 includes:

[0219] The smart contract acquisition submodule is used to acquire smart contracts from the blockchain network, including cross-domain permission verification smart contracts and access permission authentication smart contracts.

[0220] The cross-domain permission verification submodule is used to perform cross-domain permission verification on the party to be signed based on the cross-domain permission verification smart contract and the preset Proof verification mechanism.

[0221] The access permission authentication submodule is used to verify the access permissions of the parties to be signed based on the access permission authentication smart contract and the preset linear secret sharing algorithm.

[0222] Furthermore, the attribute decryption module 506 includes:

[0223] The re-encryption submodule is used to obtain the first public key of the party to be signed and to re-encrypt the attribute private key using the first public key of the party to be signed, so as to obtain the re-encrypted data.

[0224] The decryption submodule is used to send the re-encrypted data to the party to be signed, and decrypt the re-encrypted data using the first private key of the party to be signed to obtain the plaintext of the attribute private key;

[0225] The attribute encrypted data identification submodule is used to download the metadata of the documents to be signed from the blockchain network and identify attribute encrypted data in the metadata of the documents to be signed.

[0226] The attribute decryption submodule is used to decrypt attribute ciphertext data using the attribute private key to obtain the plaintext of the symmetric key.

[0227] In the above embodiments, this application discloses a cross-domain digital signature device based on attribute encryption, belonging to the field of digital signatures in blockchain technology. The cross-domain digital signature method is applied to an internal and external cross-domain joint signature system, which is built on a blockchain network. The system includes an identity chain, a consortium chain, a data storage system, and an attribute authorization center cluster. The consortium chain includes business nodes, proxy nodes, and aggregate signature nodes. The system also includes several domain spaces, each configured with a matching proxy node on the consortium chain. This application broadcasts document joint signature requests across domains through proxy nodes on the consortium chain and generates attribute keys based on the attribute authorization center cluster. The attribute keys are used to encrypt and decrypt symmetric keys, which are then used to encrypt and decrypt documents to be signed, ensuring secure key transmission. Finally, the joint signatures are aggregated using aggregate signatures. By using blockchain technology to achieve internal and external cross-domain joint signatures, this application ensures data security, reliability, and immutability.

[0228] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 6 , Figure 6 This is a basic structural block diagram of the computer device in this embodiment.

[0229] The computer device 6 includes a memory 61, a processor 62, and a network interface 63 that are interconnected via a system bus. It should be noted that only the computer device 6 with components 61-63 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0230] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.

[0231] The memory 61 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 61 may be an internal storage unit of the computer device 6, such as the hard disk or memory of the computer device 6. In other embodiments, the memory 61 may also be an external storage device of the computer device 6, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 6. Of course, the memory 61 may include both the internal storage unit and its external storage device of the computer device 6. In this embodiment, the memory 61 is typically used to store the operating system and various application software installed on the computer device 6, such as computer-readable instructions based on attribute encryption cross-domain digital signature methods. In addition, the memory 61 can also be used to temporarily store various types of data that have been output or will be output.

[0232] In some embodiments, the processor 62 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. The processor 62 is typically used to control the overall operation of the computer device 6. In this embodiment, the processor 62 is used to execute computer-readable instructions stored in the memory 61 or to process data, for example, to execute computer-readable instructions of the attribute-based encryption cross-domain digital signature method.

[0233] The network interface 63 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 6 and other electronic devices.

[0234] This application discloses a computer device belonging to the field of digital signatures in blockchain technology. The cross-domain digital signature method is applied to an internal and external cross-domain joint signature system. This system is built on a blockchain network and includes an identity chain, a consortium chain, a data storage system, and an attribute authorization center cluster. The consortium chain includes business nodes, agent nodes, and aggregate signature nodes. The system also includes several domain spaces, each configured with a matching agent node on the consortium chain. This application uses agent nodes on the consortium chain to broadcast joint signature requests across domains and generates attribute keys based on the attribute authorization center cluster. These attribute keys are used to encrypt and decrypt symmetric keys, which in turn are used to encrypt and decrypt the documents to be signed, ensuring secure key transmission. Finally, the joint signatures are aggregated using aggregate signatures. This application achieves internal and external cross-domain joint signatures using blockchain technology, ensuring data security, reliability, and immutability.

[0235] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the attribute-based encryption cross-domain digital signature method described above.

[0236] This application discloses a computer-readable storage medium belonging to the field of digital signatures in blockchain technology. The cross-domain digital signature method is applied to an internal and external cross-domain joint signature system. This system is built on a blockchain network and includes an identity chain, a consortium chain, a data storage system, and an attribute authorization center cluster. The consortium chain includes business nodes, agent nodes, and aggregate signature nodes. The system also includes several domain spaces, each configured with a matching agent node on the consortium chain. This application uses agent nodes on the consortium chain to broadcast joint signature requests across domains and generates attribute keys based on the attribute authorization center cluster. The attribute keys are used to encrypt and decrypt symmetric keys, which are then used to encrypt and decrypt the documents to be signed, ensuring secure key transmission. Finally, the joint signatures are aggregated using aggregate signatures. This application achieves internal and external cross-domain joint signatures using blockchain technology, ensuring data security, reliability, and immutability.

[0237] 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 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 a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0238] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

Claims

1. A cross-domain digital signature method based on attribute encryption, characterized in that, The cross-domain digital signature method is applied to an internal and external cross-domain joint signature system, which is built on a blockchain network. The system includes an identity chain, a consortium chain, a data storage system, and an attribute authorization center cluster. The consortium chain includes business nodes, proxy nodes, and aggregate signature nodes. The system also includes several domain spaces, each configured with a matching proxy node on the consortium chain. The cross-domain digital signature method includes: Register all joint signature participants into the aforementioned internal and external cross-domain joint signature system, and determine the domain space to which each joint signature participant belongs. The joint signature participants include the joint signature initiator and the party to be signed. The document joint signing request initiated by the joint signing initiator is obtained, the party to be signed is determined, and the document joint signing request is broadcast across domains through the proxy node of the domain space to which the joint signing initiator belongs, so as to send the document joint signing request to the party to be signed. After the party to be signed receives the document signing request, the party to be signed performs permission verification, which includes cross-domain permission verification and access permission authentication. Once the party to be signed passes the authorization verification, the encrypted document data stored in the data storage is sent to the party to be signed. The encrypted document data is generated by encrypting the document to be signed using a symmetric key. The metadata of the document to be jointly signed, which is pre-broadcast on the blockchain network, is sent to the party to be signed. The metadata of the document to be jointly signed includes attribute ciphertext data generated after attribute encryption of the symmetric key. Obtain the attribute key corresponding to the party to be signed from the attribute authorization center cluster, and use the attribute key to decrypt the attribute ciphertext data to obtain the plaintext of the symmetric key; The symmetric key is used to decrypt the encrypted document to obtain the plaintext of the document to be jointly signed, and the party to be signed is instructed to sign the document to be jointly signed to obtain the joint signature. The joint signature is uploaded by the proxy node of the domain space to which the party to be signed belongs, and the joint signature is aggregated by the aggregation signature node to obtain the joint signature result of the document to be jointly signed.

2. The cross-domain digital signature method based on attribute encryption as described in claim 1, characterized in that, Before the step of obtaining the document joint signature request initiated by the joint signature initiator and broadcasting the document joint signature request across domains through the proxy node of the domain space to which the joint signature initiator belongs, the method further includes: Obtain the symmetric key and key pair of the initiator of the joint signature; Obtain the document to be jointly signed uploaded by the initiator of the joint signing, encrypt the document to be jointly signed using the symmetric key, generate the document ciphertext, and store the document ciphertext in the data storage. Transmit the public key of the key pair to the attribute authorization center cluster; The attribute set of the party to be signed is obtained through the attribute authorization center cluster, and the attribute key is generated based on the attribute set of the party to be signed and the public key of the key pair; The attribute key is used to encrypt the symmetric key to obtain the attribute ciphertext data. Perform a hash operation on the document to be signed to obtain its hash value; Obtain the location index address of the encrypted document on the data storage, and generate the metadata of the document to be jointly signed based on the attribute encrypted data, the hash value of the document to be jointly signed, and the location index address. The metadata of the document to be jointly signed also includes the hash value of the identity identifier of the joint signing initiator, the digital signature of the joint signing initiator, the credit score identifier of the joint signing initiator, and the timestamp. Broadcast the metadata of the documents to be jointly signed on the blockchain network.

3. The cross-domain digital signature method based on attribute encryption as described in claim 2, characterized in that, The key pair includes a first key pair and a second key pair, wherein the second key pair is obtained by performing a key transformation on the first key pair. The first key pair includes a first public key and a first private key, and the second key pair includes a second public key and a second private key. The step of transmitting the public key of the key pair to the attribute authorization center cluster includes: Transmit the first public key and the second public key to the attribute authorization center cluster; The step of obtaining the attribute set of the party to be signed through the attribute authorization center cluster, and generating the attribute key based on the attribute set of the party to be signed and the public key of the key pair, includes: Determine the attribute authority corresponding to each attribute in the attribute set of the party to be signed, wherein the attribute authorization center cluster includes several attribute authorities; Generate a first random number for the attribute structure corresponding to each attribute; Calculate the first attribute key based on the first public key and the first random number, and calculate the second attribute key based on the second public key and the first random number; The attribute key is obtained by combining the first attribute key and the second attribute key; The attribute key includes an attribute public key and an attribute private key. After the step of combining the first attribute key and the second attribute key to obtain the attribute key, the method further includes: Send the attribute public key to the joint signature initiator; The attribute public key is used to perform attribute encryption on the symmetric key to obtain the attribute ciphertext data.

4. The cross-domain digital signature method based on attribute encryption as described in claim 3, characterized in that, After the steps of registering all joint signatory parties to the internal and external cross-domain joint signatory system and determining the domain space to which each joint signatory party belongs, the method further includes: Apply for and register key pairs with the certificate authority in the identity chain for each of the joint signing participants, and obtain the key pairs for each of the joint signing participants; The identity of each of the joint signing participants is verified using the first key pair in the key pair of each joint signing participant and a preset zero-knowledge authentication algorithm, so as to obtain the zero-knowledge identity verification result of each of the joint signing participants. The zero-knowledge identity verification result of each of the joint signatory parties is uploaded to the identity chain; The step of obtaining the second key pair by performing key transformation on the first key pair includes: Once the joint signatory parties have passed the zero-knowledge identity verification, a second random number is generated; The second public key is generated based on the first public key and the second random number.

5. The cross-domain digital signature method based on attribute encryption as described in claim 1, characterized in that, The steps of obtaining the document joint signing request initiated by the joint signing initiator, determining the party to be signed, and broadcasting the document joint signing request across domains through the proxy node of the domain space to which the joint signing initiator belongs, and sending the document joint signing request to the party to be signed, include: Parse the document signing request to determine the signatory party corresponding to the document to be signed; Determine whether the party to be signed and the party initiating the joint signature are in the same domain space; When the party to be signed and the party initiating the joint signing are in the same domain space, the document joint signing request is broadcast within the domain space to which the party initiating the joint signing belongs. When the party to be signed and the party initiating the joint signing are not in the same domain space, the document joint signing request is broadcast across domains through the proxy node of the domain space to which the party initiating the joint signing belongs, and the document joint signing request is sent to the party to be signed.

6. The cross-domain digital signature method based on attribute encryption as described in claim 1, characterized in that, The step of verifying the authorization of the party to be signed after receiving the document signature request includes: Obtain the smart contract of the blockchain network, wherein the smart contract includes a cross-domain permission verification smart contract and an access permission authentication smart contract; Cross-domain permission verification is performed on the party to be signed based on the cross-domain permission verification smart contract and the preset Proof verification mechanism. Access rights are verified for the party to be signed based on the access rights authentication smart contract and the preset linear secret sharing algorithm.

7. The cross-domain digital signature method based on attribute encryption as described in claim 3, characterized in that, The steps of obtaining the attribute key corresponding to the party to be signed from the attribute authorization center cluster, and using the attribute key to decrypt the attribute ciphertext data to obtain the plaintext of the symmetric key include: Obtain the first public key of the party to be signed, and use the first public key of the party to be signed to re-encrypt the attribute private key to obtain re-encrypted data; The re-encrypted data is sent to the party to be signed, and the re-encrypted data is decrypted using the first private key of the party to be signed to obtain the plaintext of the attribute private key; Download the metadata of the document to be jointly signed from the blockchain network, and identify attribute encrypted data in the metadata of the document to be jointly signed; The attribute ciphertext data is decrypted using the attribute private key to obtain the plaintext of the symmetric key.

8. A cross-domain digital signature device based on attribute encryption, characterized in that, The cross-domain digital signature device is used to run an internal and external cross-domain joint signature system. This system is built on a blockchain network and includes an identity chain, a consortium chain, a data storage system, and an attribute authorization center cluster. The consortium chain includes business nodes, proxy nodes, and aggregate signature nodes. The system also includes several domain spaces, each configured with a matching proxy node on the consortium chain. The cross-domain digital signature device includes: The joint signature registration module is used to register all joint signature participants to the internal and external cross-domain joint signature system and determine the domain space to which each joint signature participant belongs. The joint signature participants include the joint signature initiator and the party to be signed. The cross-domain broadcast module is used to obtain the document joint signing request initiated by the joint signing initiator, determine the party to be signed, and broadcast the document joint signing request across domains through the proxy node of the domain space to which the joint signing initiator belongs, so as to send the document joint signing request to the party to be signed. The permission verification module is used to verify the permissions of the party to be signed after the party to be signed receives the document signing request. The permission verification includes cross-domain permission verification and access permission authentication. The encrypted document sending module is used to send the encrypted document data pre-stored in the data storage to the party to be signed after the party to be signed passes the authorization verification. The encrypted document data is encrypted data generated by encrypting the document to be signed using a symmetric key. The metadata sending module is used to send the metadata of the document to be jointly signed, which is pre-broadcast on the blockchain network, to the party to be signed. The metadata of the document to be jointly signed includes attribute ciphertext data generated after attribute encryption of the symmetric key. The attribute decryption module is used to obtain the attribute key corresponding to the party to be signed from the attribute authorization center cluster, and use the attribute key to decrypt the attribute ciphertext data to obtain the plaintext of the symmetric key; The document decryption module is used to decrypt the document ciphertext using the symmetric key to obtain the plaintext of the document to be jointly signed, and instructs the party to be signed to sign the document to be jointly signed to obtain the joint signature. The joint signature module is used to upload the joint signature through the proxy node of the domain space to which the party to be signed belongs, and to aggregate the joint signature through the aggregation signature node to obtain the joint signature result of the document to be jointly signed.

9. A computer device, characterized in that, The method includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the cross-domain digital signature method based on attribute encryption as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the cross-domain digital signature method based on attribute encryption as described in any one of claims 1 to 7.

Images