Electronic document encryption and decryption system and method based on block chain, medium and equipment

Abstract

The invention provides an electronic document encryption and decryption system and method based on a block chain, a medium and equipment, the system comprises a block chain evidence tracing layer, an electronic document security layer and a security access and identity management layer, and the block chain evidence tracing layer is used for tracing an evidence uploaded by data; the electronic document security layer comprises an uploading node processor and a downloading node processor, and is used for encrypting uploaded data by using an uploading data node and decrypting block data by using a downloading data node, and the encryption and decryption processes are processed based on a self-defined ciphertext policy attribute proxy re-encryption mechanism; and the security access and identity management layer is used for verifying the security attribute of the node and performing management. According to the method, while full-link traceability and tampering prevention of the document process are realized, dynamic and fine-grained regulation and control of the access permission of the encrypted document are supported, and authenticity, privacy and controllable sharing of data are comprehensively guaranteed.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to a blockchain-based electronic document encryption and decryption system, method, medium and device. Background Technology

[0002] As a core link in international trade, port shipping logistics involves dozens of stakeholders, including shipping companies, port operators, shipping agents, freight forwarders, warehousing companies, customs brokers, and inland carriers. Under the traditional operating model, all parties rely on paper documents (such as bills of lading, manifests, packing lists, and delivery orders) for information transmission and ownership confirmation, resulting in cumbersome processes, low efficiency, high costs, and a high risk of errors.

[0003] In recent years, although some enterprises have tried to introduce Electronic Data Interchange (EDI) or build their own information systems to improve efficiency, these methods are still weak in terms of trust mechanisms and security. In particular, centralized document platforms not only have the risk of single point of failure, but also raise widespread concerns about data authenticity, integrity and privacy leaks because data is centralized in the management of a single authority. In addition, existing electronic transmission methods, such as FTP (File Transfer Protocol) or HTTPS (Hypertext Transfer Protocol Secure), still have significant shortcomings in terms of anti-tampering, non-repudiation and fine-grained privacy protection. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, the purpose of this application is to provide a blockchain-based electronic document encryption and decryption system, method, medium and device to solve the problems of high risk of centralized storage, easy tampering, weak non-repudiation of traditional protocols and insufficient privacy protection in the prior art.

[0005] Firstly, this application provides a blockchain-based electronic document encryption and decryption system, the system comprising:

[0006] The blockchain consists of a traceability layer, an electronic document security layer, and a secure access and identity management layer.

[0007] The blockchain evidence storage and traceability layer is used to trace the evidence of uploaded data;

[0008] The electronic document security layer includes an upload node processor and a download node processor. The upload node processor is used to encrypt uploaded data using upload data nodes. The download node processor is used to decrypt block data using download data nodes. The encryption and decryption process is based on a custom ciphertext policy attribute proxy re-encryption mechanism. The ciphertext policy attribute proxy re-encryption mechanism includes an encryption phase. During the encryption phase, when the upload node uploads the encrypted electronic document to the storage system, it determines the storage address corresponding to the electronic document and packages it into an index based on the storage address and the encrypted symmetric key. After the upload node uploads the index to the blockchain system, consensus nodes are selected, and the consensus nodes and the upload node perform index consensus to generate a new block containing the encrypted index.

[0009] The secure access and identity management layer is used to verify and manage the security attributes of nodes.

[0010] In some embodiments of the first aspect of this application, the processing based on the custom ciphertext policy attribute proxy re-encryption mechanism further includes: a decryption phase, wherein, during the decryption phase, when a download node is about to download new block data, the user attribute of the current download node is determined, the user attribute includes authorized users and unauthorized users, wherein authorized users decrypt directly, and unauthorized users wait for the new block data to be re-encrypted before decryption.

[0011] In some embodiments of the first aspect of this application, when the uploading node uploads the encrypted electronic document to the storage system, the storage address corresponding to the electronic document is determined, and an index is packaged based on the storage address and the encryption symmetric key, specifically including:

[0012] The storage system includes the IPFS system. The upload node first encrypts the electronic document with a symmetric key. When the encrypted electronic document is stored in the IPFS system, the storage address is determined. The storage address includes the IPFS address hash value.

[0013] The symmetric key is encrypted with attributes to obtain an encrypted symmetric key. The index is obtained by combining the encrypted symmetric key of the electronic document and the IPFS address hash value, wherein the IPFS address hash value is placed in plaintext in the index.

[0014] In some embodiments of the first aspect of this application, after the uploading node uploads the index to the blockchain system, consensus nodes are selected, and the consensus nodes and the uploading node perform index consensus to generate a new block containing the encrypted index, specifically including:

[0015] After the uploading node uploads the index to the blockchain system, consensus nodes are selected. All the consensus nodes have the same sorting of the data stream of the uploading node under the same view.

[0016] The consensus nodes and upload nodes reach an index consensus, which specifically includes a pre-preparation phase, a preparation phase, and a commit phase.

[0017] During the pre-preparation phase, the upload node assigns a corresponding number to each indexed ciphertext fragment and broadcasts and verifies it. The broadcast content includes <<PRE-PREPARE,v,n,d> The verification content includes whether the ciphertext digest and the index ciphertext content are consistent, whether the view number and the ciphertext fragment allocation number are within a preset range, and whether the current node has received other messages containing the same view number and ciphertext fragment allocation number but different index ciphertext content. When the verification is successful, the node enters the preparation stage. The uploading node and the consensus node store the index ciphertext content locally and broadcast it. The broadcast content includes <PREPARE, v, n, d, i>, where v is the view number, n is the ciphertext fragment allocation number, d is the ciphertext digest, CT is the index ciphertext content, and i is the node number.

[0018] During the preparation phase, verification is also performed. The verification includes whether the ciphertext digest is consistent with the ciphertext digest in the pre-preparation phase, whether the view number is consistent, and whether the ciphertext fragment allocation number is within a preset range. After the verification is successful, the current node i writes the broadcast content < PREPARE, v, n, d, i> to the log and completes the preparation phase when it receives 2f preparation messages from different nodes that are consistent with the pre-preparation phase. Here, v is the view number, n is the ciphertext fragment allocation number, d is the ciphertext digest, i is the node number, and f is the number of faulty nodes.

[0019] During the submission phase, all nodes broadcast <COMMIT, v, n, D(CT), i>, where v is the view number, n is the ciphertext fragment allocation number, CT is the index ciphertext content, D(CT) is the hash value of the index ciphertext content, and i is the node number. If the number of reply messages received by the uploading node reaches f+1, it indicates that the consensus is successful. At this time, a new block containing the encrypted index is generated, and f is the number of faulty nodes.

[0020] In some embodiments of the first aspect of this application, when a download node wants to download new block data, it specifically includes:

[0021] The user attributes of the download node are determined based on the attribute set and access results. These user attributes include authorized users, unauthorized users, and data owners.

[0022] When an authorized user downloads data from a new block, they directly decrypt the on-chain index and retrieve and decrypt the data from the storage system.

[0023] The unauthorized user submits an access request to the data owner or authorized administrator. After the request is approved, the data owner or authorized administrator generates a re-encryption key. The re-encryption key is related to the identity attribute of the unauthorized user. The re-encryption key is used to re-encrypt the encryption symmetric key. After the encryption symmetric key is re-encrypted, the unauthorized user decrypts the on-chain index and retrieves and decrypts the data from the IPFS system.

[0024] To achieve the above and other related objectives, a second aspect of this application provides a blockchain-based electronic document encryption method, applied to the upload node processor in the aforementioned blockchain-based electronic document encryption and decryption system. The method includes the following steps:

[0025] First, the electronic document is encrypted with a symmetric key. Then, the encrypted electronic document is uploaded to the IPFS system to obtain the IPFS address hash value of the electronic document. The symmetric key is then encrypted with attributes to obtain an encrypted symmetric key. An index is packaged based on the storage address and the encrypted symmetric key. The index is obtained by combining the encrypted symmetric key of the electronic document and the IPFS address hash value. The IPFS address hash value is placed in plaintext in the index.

[0026] The index is uploaded to the blockchain system, and consensus is reached with consensus nodes to generate a new block. All consensus nodes have the same view and consistent order of the data stream of the uploading node. The consensus process with consensus nodes specifically includes a pre-preparation phase, a preparation phase, and a commit phase. In the pre-preparation phase, a corresponding number is assigned to each ciphertext fragment of the index, and broadcast and verified. The broadcast content includes <<PRE-PREPARE,v,n,d> The verification process includes checking whether the ciphertext digest matches the index ciphertext content, whether the view number and ciphertext fragment allocation number are within a preset range, and whether the current node has received any other messages containing the same view number and ciphertext fragment allocation number but with different index ciphertext content. Once verification is successful, the node enters the preparation phase, where the uploading node and the consensus node store the index ciphertext content locally and broadcast it. The broadcast content includes <PREPARE, v, n, d, i>. During the preparation phase, verification is also performed, checking whether the ciphertext digest matches the ciphertext digest from the pre-preparation phase, whether the view number matches, and whether the ciphertext fragment allocation number is within a preset range. Once verification is successful, the current node i writes the <PREPARE, v, n, d, i> broadcast content to the log and completes the preparation phase when it receives 2f preparation messages from different nodes that are consistent with the pre-preparation phase. During the commit phase, all nodes broadcast <COMMIT, v, n, D>. (CT), i>, if the number of reply messages received by the consensus node reaches f+1, it indicates that the consensus is successful. At this time, a new block containing the encrypted index is generated, where v is the view number, n is the ciphertext fragment allocation number, d is the ciphertext digest, CT is the index ciphertext content, i is the node number, f is the number of faulty nodes, and D (CT) is the hash value of the index ciphertext content.

[0027] To achieve the above and other related objectives, a third aspect of this application provides a blockchain-based electronic document decryption method, applied to the download node processor in the aforementioned blockchain-based electronic document encryption and decryption system. The method includes the following steps:

[0028] The user attributes of the download node are determined based on the attribute set and access results. These user attributes include authorized users, unauthorized users, and data owners.

[0029] When an authorized user downloads data from a new block, they directly decrypt the on-chain index and retrieve and decrypt the data from the IPFS system.

[0030] The unauthorized user submits an access request to the data owner or authorized administrator. After the request is approved, the data owner or authorized administrator generates a re-encryption key. The re-encryption key is related to the identity attribute of the unauthorized user. The re-encryption key is used to re-encrypt the encryption symmetric key. After the encryption symmetric key is re-encrypted, the unauthorized user decrypts the on-chain index and retrieves and decrypts the data from the IPFS system.

[0031] The data in the new block is decrypted using a re-encryption key, which is issued by the data owner or the authorized administrator and is used to convert the original index ciphertext into new ciphertext.

[0032] To achieve the above and other related objectives, a fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the blockchain-based electronic document encryption method and / or the blockchain-based electronic document decryption method described above.

[0033] To achieve the above and other related objectives, a fifth aspect of this application provides a computer program product comprising computer program code that, when executed on a computer, causes the computer to implement the blockchain-based electronic document encryption method and / or the blockchain-based electronic document decryption method described above.

[0034] To achieve the above and other related objectives, a sixth aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory; the processor executes the computer program to implement the blockchain-based electronic document encryption method and / or the blockchain-based electronic document decryption method described above.

[0035] As described above, the blockchain-based electronic document encryption and decryption system, method, medium, and device described in this application have the following beneficial effects:

[0036] 1. Establish a trusted collaborative environment for multiple parties: Blockchain technology provides an immutable record of the entire lifecycle of document data from generation and flow to archiving. Any participant can independently verify the authenticity and flow history of the data, which greatly reduces disputes and verification costs caused by information opacity and distrust.

[0037] 2. Excellent balance between security and privacy: The innovative “attribute encryption + proxy re-encryption + blockchain broadcast” model realizes “on-chain evidence storage and authorized decryption”, which not only utilizes the distributed trust advantage of blockchain, but also ensures the commercial privacy of sensitive data through attribute encryption technology, in line with the requirements of information security strategy.

[0038] 3. Fine-grained access control and dynamic adjustment: It realizes fine-grained control and dynamic adjustment of access permissions for encrypted documents, which solves the problem of inflexible adjustment of permissions in traditional solutions and significantly improves adaptability and practicality.

[0039] 4. Revolutionary improvement in business process efficiency: Taking the "blockchain electronic ticket exchange platform" application as an example, the traditional ticket exchange process, which requires manual processing of each ticket and takes several hours to several days, is compressed into batch processing supported by smart contracts. Hundreds of tickets can be processed in a few minutes, improving efficiency by hundreds of times. Attached Figure Description

[0040] Figure 1 The diagram shown is a schematic representation of the blockchain-based electronic document encryption and decryption system of this application in one embodiment.

[0041] Figure 2 The diagram shows an encryption / decryption process of the blockchain-based electronic document encryption / decryption system of this application in one embodiment;

[0042] Figure 3 The diagram shown is a schematic diagram of new block generation in one embodiment of the blockchain-based electronic document encryption and decryption system of this application;

[0043] Figure 4 The diagram shown is an index consensus diagram of one embodiment of the blockchain-based electronic document encryption and decryption system of this application;

[0044] Figure 5 The diagram shown illustrates the decryption process by an authorized user in one embodiment of the blockchain-based electronic document encryption and decryption system of this application.

[0045] Figure 6 The diagram shown illustrates unauthorized user decryption in one embodiment of the blockchain-based electronic document encryption and decryption system of this application.

[0046] Figure 7 The diagram shown is a structural schematic of the electronic device of this application in one embodiment.

[0047] Component designation explanation 10 Blockchain-based electronic document encryption and decryption system 11 Blockchain Evidence Storage and Traceability Layer 12 Electronic document security layer 13 Secure Access and Identity Management Layer 700 Electronic terminal 701 processor 702 memory 7021 operating system 7022 app 703 Network interface 704 bus system 705 User Interface Detailed Implementation

[0048] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0049] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0050] Furthermore, the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of the various embodiments can be combined with each other, but only on the basis of being achievable by those skilled in the art. If the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed in this application.

[0051] This application proposes a blockchain-based electronic document encryption and decryption system, method, medium, and device, applicable to the transmission of electronic documents in port shipping logistics. This application relies on a consortium blockchain to build a multi-party mutual trust foundation and combines it with multi-authority attribute proxy re-encryption technology. While achieving end-to-end traceability and tamper-proofing of the document process, it supports dynamic and fine-grained control over access permissions to encrypted documents. This improves business collaboration efficiency while comprehensively ensuring the authenticity, privacy, and controllable sharing of data. The technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0052] like Figure 1 As shown, in one embodiment of the invention, the blockchain-based electronic document encryption and decryption system 10 of this application includes:

[0053] The blockchain evidence storage and traceability layer 11, the electronic document security layer 12, and the secure access and identity management layer 13, among which,

[0054] The blockchain evidence storage and traceability layer 11 is used to trace the evidence of uploaded data;

[0055] The electronic document security layer 12 includes an upload node processor and a download node processor. The upload node processor is used to encrypt uploaded data using upload data nodes. The download node processor is used to decrypt block data using download data nodes. The encryption and decryption process is based on a custom ciphertext policy attribute proxy re-encryption mechanism.

[0056] The secure access and identity management layer 13 is used to verify and manage the security attributes of nodes.

[0057] It should be noted that, in this embodiment, the blockchain evidence storage and traceability layer 11 is used to trace the evidence of uploaded data. A permissioned consortium blockchain network based on Hyperledger Fabric is constructed, with the core port and shipping enterprise as the governance node. Each organization runs multiple peer nodes to ensure reliability. Smart contracts such as document issuance contracts, document circulation contracts, and status query contracts are deployed to execute business logic. Hyperledger Fabric is an open-source, enterprise-grade permissioned distributed ledger platform, a framework for building and managing blockchain applications, designed specifically for commercial environments. Fabric transaction process is a multi-party process that ensures consistency and finality. During the transaction, the client constructs and submits a transaction proposal to the designated endorsing node. The endorsing node simulates the execution of chaincode in a sandbox environment, generates read-write sets and responses, and signs the endorsements. After the client collects endorsements that meet the policy, it submits the transaction to the sorting service. The sorting service performs a global sort on all transactions and packages them into blocks, which are then broadcast to all nodes. After receiving the blocks, each node verifies the validity of the transaction endorsements and the consistency of the read-write sets one by one, and finally submits the valid transactions to the ledger and updates the world state.

[0058] Furthermore, in this embodiment, compared to the standard process described above, this application has made key modifications before consensus to address the needs of high concurrency, strong privacy, and multi-attribute control in port and shipping logistics. These modifications will be explained in the section on the electronic document security layer. Further, when the endorsement node simulates the execution of chaincode, it will forcibly verify whether the attribute set mapped by the client certificate that initiated the proposal satisfies the access structure (M, ρ) carried in the proposal, where M is the access matrix and ρ is the attribute mapping function. Simultaneously, a revolutionary modification has been made to the traditional PBFT (Practical Byzantine Fault Tolerance) consensus algorithm, embedding business-based attribute logic into the consensus message propagation path, achieving permission filtering, and reducing communication volume from network-wide broadcasting to only notifying relevant parties, greatly reducing network load. Storing encrypted index ciphertext on the consortium blockchain ensures the immutability and end-to-end traceability of the index data, while preventing data from being directly exposed to the public storage layer.

[0059] Furthermore, in this embodiment, an attribute set and access structure are pre-designed based on a multi-dimensional fine-grained control system. The attribute classification system, based on the characteristics of port logistics business, categorizes attributes into three types: role attributes, environment attributes, and constructs a multi-dimensional attribute space. The dynamic attribute allocation mechanism adopts a hierarchical management approach using attribute agents (AA): the CA (Certificate Authority) acts as the root node, managing the global attribute set; AA1 (role management agent) is responsible for role attributes (e.g., shipper → port_operator); AA2 (permission management agent) is responsible for permission attributes (e.g., view_bill_of_lading); and AA3 (environment management agent) is responsible for environment attributes such as location and time. The advantage lies in achieving separation of responsibilities in attribute management, reducing the single point of failure risk for the CA. This application adopts a hybrid access structure to achieve fine-grained access control, which is jointly defined by the access matrix M and the attribute mapping function ρ. Its design principle is: the attribute combination logic is directly specified by business requirements, and the node attributes are automatically associated through standardized mapping to ensure that the permission rules are accurately matched with the business scenario. Among them, the access matrix M defines the logical conditions for attribute combination and expresses the combination requirements of attribute sets using standard logical operators (AND / OR). For example: M = [shipper AND location=Shanghai] means that the user must simultaneously satisfy the shipper (shipper role) and location=Shanghai (Shanghai port location) attributes; M = [consignee OR customs_agent] means that the user must satisfy either the consignee (consignee role) or the customs_agent (customs broker role) attribute; The attribute mapping function ρ automatically converts the network identifier (IP address) of a node into a predefined set of attributes, realizing seamless association of permissions. For example, the IP address 192.168.1.100 is mapped to the attribute set {role: shipper, location: Shanghai} through the function ρ; The specific conversion logic is: ρ(IP) = {role: [IP's organizational role], location: [IP's port area]}. This mapping is based on the port business's pre-configured attribute database (such as the organizational role table and port area table), ensuring that the IP address and business attributes are automatically and accurately associated without manual intervention.

[0060] Specifically, in this embodiment, for example, an exporter (Shipper A) issues a bill of lading for shipment from Shanghai Port to Los Angeles, setting the following access policy: "The consignee (Consignee B) or the customs broker (CustomsAgent) at Shanghai Port can view this bill of lading." The data owner (Shipper A) will convert this natural language policy into a cryptographically executable access structure and encrypt the data on the blockchain. Only users whose identities match the access policy can obtain the key to view the bill of lading data. At the same time, the data owner (Shipper A) can dynamically adjust the permissions.

[0061] Furthermore, it should be noted that, in this embodiment, the electronic document security layer 12 includes an upload node processor and a download node processor. The upload node processor is used to encrypt the uploaded data using the upload data node; the download node processor is used to decrypt the block data using the download data node. The encryption and decryption process is based on a custom ciphertext policy attribute proxy re-encryption mechanism. The custom ciphertext policy attribute proxy re-encryption mechanism of this application will be described in detail in the subsequent description.

[0062] Furthermore, it should be noted that in this embodiment, the secure access and identity management layer 13 is used to verify and manage the security attributes of nodes. All external access must go through the API gateway and obtain access tokens using the OAuth 2.0 protocol. An SM2 digital certificate identifying each participant is issued. This certificate is used for two-way TLS authentication between the client and the gateway, and between the client and the blockchain node, as well as transaction signing. OAuth 2.0 is an industry-standard authorization protocol and a token mechanism that allows users to grant limited permissions to third-party applications to access specific data on other websites. Within the business system, the OAuth token is mapped and verified with the organizational identity and user identity in the blockchain network to ensure that every API call is backed by a legitimate on-chain entity.

[0063] Furthermore, in one embodiment of the invention, the processing based on the custom ciphertext policy attribute proxy re-encryption mechanism specifically includes:

[0064] The ciphertext policy attribute proxy re-encryption mechanism includes an encryption phase and a decryption phase, wherein,

[0065] During the encryption phase, when the uploading node uploads the encrypted electronic document to the storage system, the storage address corresponding to the electronic document is determined, and an index is packaged based on the storage address and the encrypted symmetric key; and when the uploading node uploads the index to the blockchain system, consensus nodes are selected, and the consensus nodes and the uploading node perform index consensus to generate a new block containing the encrypted index.

[0066] During the decryption phase, when a download node needs to download new block data, the user attributes of the current download node are determined. User attributes include authorized users and unauthorized users. Authorized users decrypt directly, while unauthorized users wait for the new block data to be re-encrypted before decryption.

[0067] It should be noted that, in this embodiment, as Figure 2 As shown, the custom ciphertext policy attribute proxy re-encryption mechanism of this application includes an encryption phase and a decryption phase. The encryption phase includes a double-layer hash protection mechanism and a custom consensus mechanism. Specifically, as follows... Figure 3 As shown, the upload node corresponds to the data owner. When the upload node uploads the encrypted electronic document to the storage system, it determines the storage address corresponding to the electronic document and packages it into an index based on the storage address and the encrypted symmetric key. Then, when the upload node uploads the index to the blockchain system, consensus nodes can be selected, and the consensus nodes and upload nodes can reach an index consensus to generate a new block containing the encrypted index.

[0068] Furthermore, in this embodiment, the decryption stage includes decryption based on the user attributes of the download node. Specifically, when a download node wants to download new block data, it needs to first determine the user attributes of the current download node. Accordingly, the user attributes include authorized users and unauthorized users. For authorized users, decryption can be performed directly, while for unauthorized users, a new permission needs to be granted using a re-encryption key for decryption.

[0069] Furthermore, in one embodiment of the invention, when the uploading node uploads the encrypted electronic document to the storage system, the storage address corresponding to the electronic document is determined, and an index is packaged based on the storage address and the encryption symmetric key, specifically including:

[0070] The storage system includes the IPFS system. The upload node first encrypts the electronic document with a symmetric key. When the encrypted electronic document is stored in the IPFS system, the storage address is determined. The storage address includes the IPFS address hash value.

[0071] The symmetric key is encrypted with attributes to obtain an encrypted symmetric key. The index is obtained by combining the encrypted symmetric key of the electronic document and the IPFS address hash value, wherein the IPFS address hash value is placed in plaintext in the index.

[0072] It should be noted that, in this embodiment, the IPFS (InterPlanetary File System) system, as a high-efficiency storage engine, can support automatic fragmented storage of large electronic document files (maximum single file size 100GB), providing high-throughput data retrieval capabilities and solving the scalability bottleneck of traditional centralized storage. In particular, this application innovatively employs a two-layer hash protection mechanism. Specifically, the electronic document is first encrypted with a symmetric key. When the encrypted electronic document is stored in the IPFS system, the storage address is determined, and correspondingly, the storage address includes the IPFS address hash value. Then, the symmetric key is attribute-encrypted to obtain an encrypted symmetric key. Specifically, a random encrypted symmetric key (E... Key After concatenating the IPFS address hash (Locm) with the IPFS address hash value, an index value (Index = E) is generated using the SM3 hash algorithm. Key ||Locm||SM3(E Key ||Locm), || represents a concatenation operation, where the plaintext of the IPFS address hash value is placed in the index. The core advantage of this mechanism lies in its comparison with traditional single-layer hash schemes (such as directly using E). Key ), can be achieved through a two-layer hash structure (E Key The combination hash with Locm increases the key cracking complexity to the security strength level of the SM3 algorithm. The purpose of using it twice is to improve the security strength level and meet security requirements.

[0073] Furthermore, in this embodiment, this application proposes a collaborative storage architecture of IPFS and blockchain to achieve a balance between security and efficiency. Specifically, the electronic document itself is encrypted and stored on the IPFS network, whose distributed nature ensures high availability and efficient retrieval of the file. At the same time, the encryption key of the file and the IPFS address hash value are encrypted through attribute encryption to form an index ciphertext, which is stored on the consortium blockchain. The two are tightly bound by cryptographic hashes. The index value is generated jointly by the key and the file hash. Data tampering at any layer will lead to hash verification failure. The blockchain ensures the immutability and full traceability of permission policies and access records. IPFS bears the storage pressure of large files, thereby solving the dual problems of low storage efficiency of pure blockchain and insufficient trust of traditional centralized storage while ensuring data sovereignty and privacy.

[0074] Furthermore, in one embodiment of the invention, after the uploading node uploads the index to the blockchain system, consensus nodes are selected, and the consensus nodes and the uploading node perform index consensus to generate a new block containing the encrypted index, specifically including:

[0075] After the uploading node uploads the index to the blockchain system, consensus nodes are selected. All the consensus nodes have the same sorting of the data stream of the uploading node under the same view.

[0076] The consensus nodes and upload nodes reach an index consensus, which specifically includes a pre-preparation phase, a preparation phase, and a commit phase.

[0077] During the pre-preparation phase, the upload node assigns a corresponding number to each indexed ciphertext fragment and broadcasts and verifies it. The broadcast content includes <<PRE-PREPARE,v,n,d> The verification content includes whether the ciphertext digest and the index ciphertext content are consistent, whether the view number and the ciphertext fragment allocation number are within a preset range, and whether the current node has received other messages containing the same view number and ciphertext fragment allocation number but different index ciphertext content. When the verification is successful, the node enters the preparation stage. The uploading node and the consensus node store the index ciphertext content locally and broadcast it. The broadcast content includes <PREPARE, v, n, d, i>, where v is the view number, n is the ciphertext fragment allocation number, d is the ciphertext digest, CT is the index ciphertext content, and i is the node number.

[0078] During the preparation phase, verification is also performed. The verification includes whether the ciphertext digest is consistent with the ciphertext digest in the pre-preparation phase, whether the view number is consistent, and whether the ciphertext fragment allocation number is within a preset range. After the verification is successful, the current node i writes the broadcast content < PREPARE, v, n, d, i> to the log and completes the preparation phase when it receives 2f preparation messages from different nodes that are consistent with the pre-preparation phase. Here, v is the view number, n is the ciphertext fragment allocation number, d is the ciphertext digest, i is the node number, and f is the number of faulty nodes.

[0079] During the submission phase, all nodes broadcast <COMMIT, v, n, D(CT), i>, where v is the view number, n is the ciphertext fragment allocation number, CT is the index ciphertext content, D(CT) is the hash value of the index ciphertext content, and i is the node number. If the number of reply messages received by the uploading node reaches f+1, it indicates that the consensus is successful. At this time, a new block containing the encrypted index is generated, and f is the number of faulty nodes.

[0080] It should be noted that, in this embodiment, after the uploading node uploads the index to the blockchain system, consensus nodes are filtered, and the consensus nodes and uploading nodes perform index consensus, such as... Figure 4As shown, it specifically includes a pre-preparation stage, a preparation stage, and a submission stage. This application focuses on the high-frequency trading scenario of port logistics and deeply optimizes the PBFT (Practical Byzantine Fault Tolerance) consensus mechanism. The consensus efficiency is significantly improved through a three-stage process reconstruction. The consensus mechanism optimization scheme of this application eliminates redundant communication and invalid request processing while retaining the security of PBFT, achieving a performance breakthrough in high-concurrency scenarios. The consensus mechanism comparison is shown in Table 1.

[0081] Table 1. Comparison of Consensus Mechanisms

[0082] Furthermore, the Pre-prepare and Prepare phases ensure that all consensus nodes maintain a consistent order of data streams from the uploading nodes under the same view; the Prepare and Commit phases ensure that the original order remains unchanged after a view switch.

[0083] Specifically, in this embodiment, assuming the total number of nodes is N and the number of faulty nodes is f, where f is less than 1 / 3N, during the pre-preparation phase, the uploading node assigns a number n to each indexed ciphertext fragment and broadcasts it to the blockchain network.<PRE-PREPARE,v,n,d> ,CT>, where v is the view number, n is the ciphertext fragment assignment number, d is the ciphertext digest, and CT is the indexed ciphertext content.

[0084] Further, in this embodiment, after receiving the pre-preparation message, the uploading node and consensus node verify the following: whether the ciphertext digest d is consistent with the content of the index ciphertext content CT; whether the view number is v; whether the ciphertext fragment allocation number n is within the pre-approval range [h, H], where h represents the lower limit of the view number and H represents the upper limit of the view number; and whether the current node has not received other messages containing the same v and n but different CT. If the verification is successful, the node enters the preparation stage. Further, all uploading nodes and consensus nodes store the index ciphertext content CT in their local message logs and broadcast <PREPARE, v, n, d, i> to the blockchain network, where v is the view number, n is the ciphertext fragment allocation number, d is the ciphertext digest, and i is the node number.

[0085] Furthermore, in this embodiment, the preparation phase also includes verification, specifically verifying the following: whether the ciphertext digest d is consistent with the ciphertext digest d in the pre-preparation phase; whether the view number is v; and whether the ciphertext fragment allocation number n is within the range of [h, H], where h represents the lower limit of the view number and H represents the upper limit of the view number. For the upload node or consensus node, the preparation phase is completed when the following conditions are met: the current node i writes the broadcast content <PREPATE, v, n, d, i> into the log and receives 2f preparation messages from different nodes that are consistent with the pre-preparation phase, where v is the view number, n is the ciphertext fragment allocation number, d is the ciphertext digest, i is the node number, and f is the number of faulty nodes.

[0086] Furthermore, in this embodiment, after the above two conditions are met, the submission phase begins. In the submission phase, all nodes broadcast <COMMIT, v, n, D(CT), i> to the blockchain network. Similar to the previous two phases, each consensus node performs a similar verification after receiving the submission message. If 2f+1 verified submission messages are received, a reply (REPLY) message is sent to the uploading node. If the number of reply messages received by the uploading node reaches f+1, it indicates that the index ciphertext content in this round of data sharing has reached a consensus. At this time, a new block containing the encrypted index is generated.

[0087] Furthermore, in this embodiment, after a round of data sharing is completed, the original uploading node no longer generates new candidate blocks and broadcasts them to the network. The consensus node sets a timer to ensure that there is no subsequent data input from the previous round of data sharing. When the timer expires, a view switch is triggered to prevent user nodes from waiting indefinitely for requests, thus delaying the next round of data sharing. The consensus node broadcasts...<VIEW-CHANGE,v+1,m,P,i> Where m is the last index ciphertext number to reach consensus, P is the set of all index ciphertext numbers that have reached the ready state after m, and i is the node number. The active node in the new round of data sharing is elected. When the new active node collects 2f+1 view switching messages, it starts assembling the pre-prepared message set O. It selects the smallest index ciphertext number among the 2f+1 view switching messages as min, and the largest index ciphertext number in P among the 2f+1 view switching messages as max. It assembles the pre-prepared message under view v+1 for each index ciphertext number between min and max, generating the pre-prepared message set O. Subsequently, the new active node assembles the new view message.<NEW-VIEW,v+1,V,O > It is then broadcast to all upload nodes and consensus nodes in the network. Here, V is the set of view switching messages with view number v+1 received by the new data node. After receiving the new view message, the upload node and consensus node verify whether the set of pre-prepared messages O in it is correct. If the verification is successful, the new data node executes the pre-prepared messages in the set of pre-prepared messages O under view v+1.

[0088] Furthermore, in one embodiment of the invention, when a download node needs to download new block data, the specific steps include:

[0089] The user attributes of the download node are determined based on the attribute set and access results. These user attributes include authorized users, unauthorized users, and data owners.

[0090] When an authorized user downloads data from a new block, they directly decrypt the on-chain index and retrieve and decrypt the data from the storage system.

[0091] The unauthorized user submits an access request to the data owner or authorized administrator. After the request is approved, the data owner or authorized administrator generates a re-encryption key. The re-encryption key is related to the identity attribute of the unauthorized user. The re-encryption key is used to re-encrypt the encryption symmetric key. After the encryption symmetric key is re-encrypted, the unauthorized user decrypts the on-chain index and retrieves and decrypts the data from the IPFS system.

[0092] It should be noted that, in this embodiment, there are many nodes in the blockchain. Specifically, the user attributes of the download node are determined based on the attribute set and access results. Accordingly, user attributes include authorized users, unauthorized users, and data owners. For example... Figure 5 As shown, when the authorized user downloads data from a new block, they directly decrypt the on-chain index, retrieve and decrypt the data from the storage system; as... Figure 6 As shown, the unauthorized user submits an access request to the data owner or authorized administrator. After the request is approved, the data owner or authorized administrator generates a re-encryption key. The re-encryption key is related to the identity attributes of the unauthorized user. In this embodiment, the identity attributes include, for example, the identity and level of a port logistics user. The re-encryption key is used to re-encrypt the encryption symmetric key. After the encryption symmetric key is re-encrypted, the unauthorized user decrypts the on-chain index and retrieves and decrypts the data from the IPFS system.

[0093] Specifically, in this embodiment, an unauthorized user submits an access request to the data owner or authorized administrator. After review, the data owner defines a new access policy (M', ρ'), which includes the "new attributes" that the user already possesses or will soon be granted. The proxy node uses a re-encryption key (Rk) to encrypt the original index ciphertext. Convert to new ciphertext This process only changes the access policy corresponding to the ciphertext, without exposing the original data key or modifying the encrypted files stored on IPFS. If the new policy involves attributes that the user did not originally possess, the corresponding attribute authority (AA) will issue the corresponding attribute private key to the user, and the newly generated key will be used to further modify these attributes. The data is submitted to the blockchain for evidence storage, and the user then decrypts it using their updated attribute private key (which now satisfies M'). The key and file locator are obtained, and then the file content is retrieved and decrypted from IPFS. Both ultimately obtain the encrypted content and decrypt it through IPFS.

[0094] Furthermore, in this embodiment, taking the generation of a re-encryption key by an authorized administrator as an example, it is based on the original attribute private key. With the new attribute private key Generate re-encryption key The mathematical expression is ,in, For safety functions, ensure Used only for ciphertext conversion; cannot be derived. Authorized administrators will encrypt the original index. Convert to new ciphertext The conversion logic is as follows: Because the authorized administrator cannot obtain Only holding To completely avoid the risk of key leakage, download nodes use a new attribute private key. Decryption Access permissions are updated in real time.

[0095] This application also provides a blockchain-based electronic document encryption method, applied to the upload node processor in the aforementioned blockchain-based electronic document encryption and decryption system. The method includes the following steps:

[0096] First, the electronic document is encrypted with a symmetric key. Then, the encrypted electronic document is uploaded to the IPFS system to obtain the IPFS address hash value of the electronic document. The symmetric key is then encrypted with attributes to obtain an encrypted symmetric key. An index is packaged based on the storage address and the encrypted symmetric key. The index is obtained by combining the encrypted symmetric key of the electronic document and the IPFS address hash value. The IPFS address hash value is placed in plaintext in the index.

[0097] The index is uploaded to the blockchain system, and consensus is reached with consensus nodes to generate a new block. All consensus nodes have the same view and consistent order of the data stream of the uploading node. The consensus process with consensus nodes specifically includes a pre-preparation phase, a preparation phase, and a commit phase. In the pre-preparation phase, a corresponding number is assigned to each ciphertext fragment of the index, and broadcast and verified. The broadcast content includes <<PRE-PREPARE,v,n,d> The verification process includes checking whether the ciphertext digest matches the index ciphertext content, whether the view number and ciphertext fragment allocation number are within a preset range, and whether the current node has received any other messages containing the same view number and ciphertext fragment allocation number but with different index ciphertext content. Once verification is successful, the node enters the preparation phase, where the uploading node and the consensus node store the index ciphertext content locally and broadcast it. The broadcast content includes <PREPARE, v, n, d, i>. During the preparation phase, verification is also performed, checking whether the ciphertext digest matches the ciphertext digest from the pre-preparation phase, whether the view number matches, and whether the ciphertext fragment allocation number is within a preset range. Once verification is successful, the current node i writes the <PREPARE, v, n, d, i> broadcast content to the log and completes the preparation phase when it receives 2f preparation messages from different nodes that are consistent with the pre-preparation phase. During the commit phase, all nodes broadcast <COMMIT, v, n, D>. (CT), i>, if the number of reply messages received by the consensus node reaches f+1, it indicates that the consensus is successful. At this time, a new block containing the encrypted index is generated, where v is the view number, n is the ciphertext fragment allocation number, d is the ciphertext digest, CT is the index ciphertext content, i is the node number, f is the number of faulty nodes, and D (CT) is the hash value of the index ciphertext content.

[0098] It should be noted that, in this embodiment, since the specific implementation method of this embodiment corresponds to the embodiment in the aforementioned system, the same details will not be repeated here. Those skilled in the art should also understand that the protection scope of the blockchain-based electronic document encryption method described in this application embodiment is not limited to the execution order of the steps listed in this embodiment. Any scheme implemented by adding, subtracting, or replacing steps in the prior art based on the principles of this application is included within the protection scope of this application.

[0099] This application also provides a blockchain-based electronic document decryption method, applied to the download node processor in the aforementioned blockchain-based electronic document encryption and decryption system. The method includes the following steps:

[0100] The user attributes of the download node are determined based on the attribute set and access results. These user attributes include authorized users, unauthorized users, and data owners.

[0101] When an authorized user downloads data from a new block, they directly decrypt the on-chain index and retrieve and decrypt the data from the IPFS system.

[0102] The unauthorized user submits an access request to the data owner or authorized administrator. After the request is approved, the data owner or authorized administrator generates a re-encryption key. The re-encryption key is related to the identity attribute of the unauthorized user. The re-encryption key is used to re-encrypt the encryption symmetric key. After the encryption symmetric key is re-encrypted, the unauthorized user decrypts the on-chain index and retrieves and decrypts the data from the IPFS system.

[0103] It should be noted that, in this embodiment, since the specific implementation method of this embodiment corresponds to the embodiment in the aforementioned system, the same details will not be repeated here. Those skilled in the art should also understand that the protection scope of the blockchain-based electronic document decryption method described in this application embodiment is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, subtracting, or replacing steps in the prior art based on the principles of this application is included within the protection scope of this application.

[0104] It should be understood that the disclosed systems or methods can be implemented in other ways, given the several embodiments provided in this application. For example, the system embodiments described above are merely illustrative. For instance, the division of modules / layers is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or layers may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, modules, or units, and may be electrical, mechanical, or other forms.

[0105] The modules / layers described as separate components may or may not be physically separate. The components shown as modules / layers may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / layers can be selected to achieve the objectives of the embodiments of this application, depending on actual needs. For example, the functional modules / layers in the various embodiments of this application may be integrated into one processing module, or each module / layer may exist physically separately, or two or more modules / layers may be integrated into one module / layer.

[0106] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0107] This application also provides an electronic device, such as... Figure 7 As shown, the electronic device includes a processor and a memory.

[0108] like Figure 7 As shown, the electronic device includes: at least one processor 701, a memory 702, at least one network interface 703, and a user interface 705. The various components in the device are coupled together via a bus system 704. It is understood that the bus system 704 is used to implement communication between these components. In addition to a data bus, the bus system 704 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 7 The general will label all buses as bus systems.

[0109] The user interface 705 may include a monitor, keyboard, mouse, trackball, clicker, button, touchpad, or touch screen.

[0110] It is understood that memory 702 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM) or programmable read-only memory (PROM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable categories of memory.

[0111] In this embodiment, the memory 702 is used to store various types of data to support the operation of the electronic terminal 700. Examples of this data include any executable program for operation on the electronic terminal 700, such as the operating system 7021 and application programs 7022. The operating system 7021 contains various system programs, such as the framework layer, core library layer, and driver layer, for implementing various basic services and handling hardware-based tasks. The application program 7022 may contain various applications, such as a media player and a browser, for implementing various application services. The methods provided in this embodiment can be included in the application program 7022.

[0112] The methods disclosed in the embodiments of this application can be applied to processor 701, or implemented by processor 701. Processor 701 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 701 or by instructions in the form of software. The processor 701 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 701 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. Processor 701 may be a microprocessor or any conventional processor, etc. The steps of the accessory optimization method provided in the embodiments of this application can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.

[0113] In an exemplary embodiment, the electronic terminal 700 may be used by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), or complex programmable logic devices (CPLDs) to execute the aforementioned method.

[0114] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes: computer program code, which, when run on a computer, causes the computer to execute the method of any of the embodiments of the above-described blockchain-based electronic document encryption method and / or the above-described blockchain-based electronic document decryption method.

[0115] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing program code. When the program code is run on a computer, it causes the computer to execute the method of any of the embodiments of the above-described blockchain-based electronic document encryption method and / or the above-described blockchain-based electronic document decryption method.

[0116] The terms “component,” “module,” “system,” etc., used in this specification are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0117] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0118] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0119] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0120] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0121] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0122] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. A computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs (DVDs), or semiconductor media (e.g., solid-state disks (SSDs)).

[0123] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0124] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0125] In summary, this application provides a blockchain-based electronic document encryption and decryption system, method, medium, and device. Utilizing the immutability of blockchain, it achieves full lifecycle traceability and verifiability of document data, fundamentally solving the pain points of data authenticity disputes and information opacity in traditional centralized platforms, significantly reducing trust costs. Furthermore, it innovatively integrates "attribute encryption + proxy re-encryption" technology, combined with the blockchain broadcast mechanism, forming a secure paradigm of "on-chain evidence storage and authorized decryption." This leverages the distributed trust advantages of blockchain while ensuring absolute privacy of sensitive data through fine-grained encryption, strictly preventing the leakage of trade secrets. Taking "blockchain electronic document exchange" as an example, it reduces document processing time from hours or even days to minutes, achieving hundreds of times efficiency improvement and driving revolutionary changes in business processes.

[0126] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A blockchain-based electronic document encryption and decryption system, characterized in that, The system includes: The blockchain consists of a traceability layer, an electronic document security layer, and a secure access and identity management layer. The blockchain evidence storage and traceability layer is used to trace the evidence of uploaded data; The electronic document security layer includes an upload node processor and a download node processor. The upload node processor is used to encrypt uploaded data using upload data nodes. The download node processor is used to decrypt block data using download data nodes. The encryption and decryption process is based on a custom ciphertext policy attribute proxy re-encryption mechanism. The ciphertext policy attribute proxy re-encryption mechanism includes an encryption phase. During the encryption phase, when the upload node uploads the encrypted electronic document to the storage system, it determines the storage address corresponding to the electronic document and packages it into an index based on the storage address and the encrypted symmetric key. After the upload node uploads the index to the blockchain system, consensus nodes are selected, and the consensus nodes and the upload node perform index consensus to generate a new block containing the encrypted index. The secure access and identity management layer is used to verify and manage the security attributes of nodes.

2. The blockchain-based electronic document encryption and decryption system according to claim 1, characterized in that, The processing is based on a custom ciphertext policy attribute proxy re-encryption mechanism, which specifically includes a decryption phase. During the decryption phase, when a download node needs to download new block data, the user attributes of the current download node are determined. The user attributes include authorized users and unauthorized users. Authorized users decrypt directly, while unauthorized users wait for the new block data to be re-encrypted before decryption.

3. The blockchain-based electronic document encryption and decryption system according to claim 1, characterized in that, When an upload node uploads the encrypted electronic document to the storage system, it determines the storage address corresponding to the electronic document and packages it into an index based on the storage address and the encryption symmetric key. Specifically, this includes: The storage system includes the IPFS system. The upload node first encrypts the electronic document with a symmetric key. When the encrypted electronic document is stored in the IPFS system, the storage address is determined. The storage address includes the IPFS address hash value. The symmetric key is encrypted with attributes to obtain an encrypted symmetric key. The index is obtained by combining the encrypted symmetric key of the electronic document and the IPFS address hash value, wherein the IPFS address hash value is placed in plaintext in the index.

4. The blockchain-based electronic document encryption and decryption system according to claim 1, characterized in that, After the uploading node uploads the index to the blockchain system, consensus nodes are selected, and the consensus nodes and uploading nodes reach an index consensus to generate a new block containing the encrypted index. This process includes: After the uploading node uploads the index to the blockchain system, consensus nodes are selected. All the consensus nodes have the same sorting of the data stream of the uploading node under the same view. The consensus nodes and upload nodes reach an index consensus, which specifically includes a pre-preparation phase, a preparation phase, and a commit phase. During the pre-preparation phase, the upload node assigns a corresponding number to each indexed ciphertext fragment and broadcasts and verifies it. The broadcast content includes <<PRE-PREPARE,v,n,d> The verification content includes whether the ciphertext digest and the index ciphertext content are consistent, whether the view number and the ciphertext fragment allocation number are within a preset range, and whether the current node has received other messages containing the same view number and ciphertext fragment allocation number but different index ciphertext content. When the verification is successful, the node enters the preparation stage. The uploading node and the consensus node store the index ciphertext content locally and broadcast it. The broadcast content includes <PREPARE, v, n, d, i>, where v is the view number, n is the ciphertext fragment allocation number, d is the ciphertext digest, CT is the index ciphertext content, and i is the node number. During the preparation phase, verification is also performed. The verification includes whether the ciphertext digest is consistent with the ciphertext digest in the pre-preparation phase, whether the view number is consistent, and whether the ciphertext fragment allocation number is within a preset range. After the verification is successful, the current node i writes the broadcast content < PREPARE, v, n, d, i> into the log and completes the preparation phase when it receives 2f preparation messages from different nodes that are consistent with the pre-preparation phase. Here, v is the view number, n is the ciphertext fragment allocation number, d is the ciphertext digest, i is the node number, and f is the number of faulty nodes. During the submission phase, all nodes broadcast <COMMIT, v, n, D(CT), i>, where v is the view number, n is the ciphertext fragment allocation number, CT is the index ciphertext content, D(CT) is the hash value of the index ciphertext content, and i is the node number. If the number of reply messages received by the uploading node reaches f+1, it indicates that the consensus is successful. At this time, a new block containing the encrypted index is generated, and f is the number of faulty nodes.

5. The blockchain-based electronic document encryption and decryption system according to claim 2, characterized in that, When a download node needs to download new block data, the specific steps include: The user attributes of the download node are determined based on the attribute set and access results. These user attributes include authorized users, unauthorized users, and data owners. When an authorized user downloads data from a new block, they directly decrypt the on-chain index and retrieve and decrypt the data from the storage system. The unauthorized user submits an access request to the data owner or authorized administrator. After the request is approved, the data owner or authorized administrator generates a re-encryption key. The re-encryption key is related to the identity attribute of the unauthorized user. The re-encryption key is used to re-encrypt the encryption symmetric key. After the encryption symmetric key is re-encrypted, the unauthorized user decrypts the on-chain index and retrieves and decrypts the data from the IPFS system.

6. A blockchain-based electronic document encryption method, characterized in that, The method for the upload node processor in the blockchain-based electronic document encryption and decryption system of claim 1 includes the following steps: First, the electronic document is encrypted with a symmetric key. Then, the encrypted electronic document is uploaded to the IPFS system to obtain the IPFS address hash value of the electronic document. The symmetric key is then encrypted with attributes to obtain an encrypted symmetric key. An index is packaged based on the storage address and the encrypted symmetric key. The index is obtained by combining the encrypted symmetric key of the electronic document and the IPFS address hash value. The IPFS address hash value is placed in plaintext in the index. The index is uploaded to the blockchain system, and consensus is reached with consensus nodes to generate a new block. All consensus nodes have the same view and consistent order of the data stream of the uploading node. The consensus process with consensus nodes specifically includes a pre-preparation phase, a preparation phase, and a commit phase. In the pre-preparation phase, a corresponding number is assigned to each ciphertext fragment of the index, and broadcast and verified. The broadcast content includes <<PRE-PREPARE,v,n,d> The verification process includes checking whether the ciphertext digest matches the index ciphertext content, whether the view number and ciphertext fragment allocation number are within a preset range, and whether the current node has received any other messages containing the same view number and ciphertext fragment allocation number but with different index ciphertext content. Once verification is successful, the node enters the preparation phase, where the uploading node and the consensus node store the index ciphertext content locally and broadcast it. The broadcast content includes <PREPARE, v, n, d, i>. During the preparation phase, verification is also performed, checking whether the ciphertext digest matches the ciphertext digest from the pre-preparation phase, whether the view number matches, and whether the ciphertext fragment allocation number is within a preset range. Once verification is successful, the current node i writes the <PREPARE, v, n, d, i> broadcast content to the log and completes the preparation phase when it receives 2f preparation messages from different nodes that are consistent with the pre-preparation phase. During the commit phase, all nodes broadcast <COMMIT, v, n, D>. (CT), i>, if the number of reply messages received by the consensus node reaches f+1, it indicates that the consensus is successful. At this time, a new block containing the encrypted index is generated, where v is the view number, n is the ciphertext fragment allocation number, d is the ciphertext digest, CT is the index ciphertext content, i is the node number, f is the number of faulty nodes, and D (CT) is the hash value of the index ciphertext content.

7. A blockchain-based method for decrypting electronic documents, characterized in that, The method for the download node processor in the blockchain-based electronic document encryption and decryption system of claim 1 includes the following steps: The user attributes of the download node are determined based on the attribute set and access results. These user attributes include authorized users, unauthorized users, and data owners. When an authorized user downloads data from a new block, they directly decrypt the on-chain index and retrieve and decrypt the data from the IPFS system. The unauthorized user submits an access request to the data owner or authorized administrator. After the request is approved, the data owner or authorized administrator generates a re-encryption key. The re-encryption key is related to the identity attribute of the unauthorized user. The re-encryption key is used to re-encrypt the encryption symmetric key. After the encryption symmetric key is re-encrypted, the unauthorized user decrypts the on-chain index and retrieves and decrypts the data from the IPFS system.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the blockchain-based electronic document encryption method as described in claim 6 and / or the blockchain-based electronic document decryption method as described in claim 7.

9. A computer program product, characterized in that, The computer program product includes computer program code, which, when run on a computer, enables the computer to implement the blockchain-based electronic document encryption method as described in claim 6 and / or the blockchain-based electronic document decryption method as described in claim 7.

10. An electronic device, characterized in that, The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory to enable the electronic device to perform the blockchain-based electronic document encryption method as described in claim 6 and / or the blockchain-based electronic document decryption method as described in claim 7.

Images