Cross-chain request and response method based on re-encryption, multi-blockchain system

Abstract

This invention belongs to the technical field of blockchain information management, and discloses a cross-chain request and response method based on re-encryption, and a multi-blockchain system. Different users in the blockchain each maintain their corresponding Bloom filter and LSSS information. A requesting user b on blockchain B sends an access request to an authorized user a on blockchain A. Authorized user a receives the access request and verifies its necessary attributes through the Bloom filter. After successful verification, it uses the re-encryption key RK. ab The ciphertext C of authorized user a is re-encrypted to obtain the re-encrypted ciphertext C. * And send it to blockchain B, requesting user b to retrieve the re-encrypted ciphertext from blockchain B, when it has a PK that matches the common public key. b When the paired user private key and its attributes satisfy the access control policy of authorized user a, the ciphertext C can be decrypted. * The plaintext in the code. Through the above methods, this invention can achieve a balance between cross-chain access processing speed and security.

Description

Technical Field

[0001] This invention belongs to the technical field of blockchain information management, and more specifically, relates to a cross-chain request and response method based on re-encryption, and a multi-blockchain system. Background Technology

[0002] With the continuous advancement of informatization in the construction industry, various building information systems (such as building project supervision systems, building information modeling (BIM) systems, building project operation and maintenance management systems (O&M systems), and building Internet of Things (IoT) systems) are increasingly becoming important tools for project management, data analysis, and decision support. These systems are often distributed across different blockchains and involve a large amount of sensitive data, such as project approvals, construction management, energy efficiency monitoring, and equipment maintenance. This data needs to be shared and interacted between different systems.

[0003] However, existing information systems face a series of challenges in cross-domain data sharing, especially in terms of data security and access speed. If more complex encryption and decryption methods are used to improve data security, access speed will be limited. On the other hand, if simple encryption and decryption methods are used, access speed can be improved, but data security will be reduced.

[0004] Therefore, there is an urgent need to provide a cross-chain access solution that can balance data security and access speed for users. Summary of the Invention

[0005] In view of the above-mentioned defects or improvement needs of the existing technology, the present invention provides a cross-chain request and response method based on re-encryption and a multi-blockchain system, the purpose of which is to provide users with a cross-chain access solution while taking into account data security and access speed during cross-chain access.

[0006] To achieve the above objectives, the present invention is proposed.

[0007] According to a first aspect of the present invention, a cross-chain request-response method based on re-encryption is provided, wherein different users in the blockchain each maintain their corresponding Bloom filter and LSSS information; the LSSS information corresponding to a user includes an access control matrix M and a mapping function obtained by transforming the user's access control policy using LSSS encryption technology. The requesting user whose attributes satisfy the access control policy of the authorized user has the right to access the authorized user. The access control policy has one or more sub-policies with OR gate logical relationships. Different attributes in each sub-policy form an access control tree through AND gate logical relationships and OR gate logical relationships. The Bloom filter corresponding to the user records the necessary attributes in each of its sub-policies. The necessary attributes in the sub-policy are the attributes that are necessary conditions for satisfying the sub-policy. The request-response method includes:

[0008] S11. Receive the access request from user b located on another blockchain B;

[0009] S12. Validate the necessary attributes of the requesting user b using the Bloom filter corresponding to the authorized user a. If the validation passes, proceed to S13; otherwise, proceed to S14.

[0010] S13, PK the public key of blockchain B. B The LSSS information of authorized user a and the public key PK of the blockchain A where authorized user a resides. A and the private key SK of authorized user a a Input the blockchain smart contract to generate a re-encryption key RK ab Using the re-encryption key RK ab The ciphertext C of authorized user a is re-encrypted to obtain the re-encrypted ciphertext C. * And send it to blockchain B; authorize user a's encrypted C is the public key PK used by blockchain A. A The plaintext U is obtained by encrypting the plaintext U using the authorized attribute set S, which consists of all attributes in the access control policy of authorized user a; and has the same public key PK. B A user with a paired private key whose attributes satisfy the access control policy of authorized user a can decrypt ciphertext C. * plaintext U in the text;

[0011] S14. End the processing response to the access request from user b.

[0012] According to a second aspect of the present invention, a cross-chain request method based on re-encryption is provided, comprising:

[0013] S21. Request user b to send an access request to authorized user a on blockchain A and obtain the re-encrypted ciphertext C in response to the access request. * The re-encrypted ciphertext C * This is the re-encrypted ciphertext generated by the authorizing end through executing the request-response method as described in Example 1;

[0014] S22, By requesting user b's private key SK b And LSSS decryption technology for the re-encrypted ciphertext C * Decrypt the code to obtain the plaintext.

[0015] According to a third aspect of the present invention, a multi-blockchain system based on re-encryption is provided, wherein when a requesting user b on blockchain B needs to access the data of an authorized user a on blockchain A, the requesting end executes the cross-chain request method described above and the authorized end executes the request response method described above.

[0016] The requesting side includes blockchain B and requesting user b, while the authorizing side includes blockchain A and authorizing user a.

[0017] In summary, compared with the prior art, the technical solutions conceived in this invention have the following main advantages:

[0018] This invention employs a dual-stage filtering process for requesting users. The first stage involves a Bloom filter to preliminarily verify the necessary attributes of the requesting user. Since the Bloom filter maintained by the authorized user records the necessary attributes required to satisfy the access control policy, if the necessary attributes of the requesting user are recorded in the Bloom filter maintained by the authorized user, it indicates that the requesting user may satisfy the access control policy. If the necessary attributes of the requesting user are not found in the Bloom filter maintained by the authorized user, it indicates that the requesting user cannot satisfy the access control policy, and access can be directly denied. Therefore, only after passing the verification of the Bloom filter can the requesting user proceed to the second stage of filtering for further verification. The second stage of filtering involves encrypting the ciphertext using a re-encryption key. At this stage, it is necessary to verify whether the attributes of the requesting user satisfy the access control policy of the authorized user. Only users whose attributes satisfy the access control policy of the authorized user can pass the second stage of filtering and obtain the decryption key to decrypt the original plaintext. Thus, because the computational load of the first layer of filtering is relatively small, the verification speed is significantly faster than LSSS verification and public-private key decryption. Based on the first layer of filtering, rapid coarse screening can be performed, helping to filter out a large number of invalid requests. Only requests that pass the first layer of filtering can enter the second, more complex filtering verification. Compared to performing complex verification on all accesses, the dual filtering mechanism of this invention can improve the overall cross-chain access speed. Furthermore, this invention uses a re-encryption method, which can transform ciphertext encrypted with one public key into ciphertext encrypted with another public key without exposing plaintext information. Therefore, it can convert encrypted information from heterogeneous encryption standard systems, enabling cross-domain sharing of ciphertext information and effectively ensuring data security. In summary, this invention achieves a balance between cross-chain access processing speed and security. Attached Figure Description

[0019] Figure 1 This is a flowchart of the steps of a cross-chain request-response method based on re-encryption in one embodiment of the present invention.

[0020] Figure 2 This is a schematic diagram illustrating the process of performing dual authentication on a requesting user in one embodiment of the present invention.

[0021] Figure 3 This is a schematic diagram illustrating information processing for cross-chain access between an authorized user and a requesting user in one embodiment of the present invention.

[0022] Figure 4 This is a flowchart of the steps of a cross-chain request method based on re-encryption in one embodiment of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0024] Example 1

[0025] This invention discloses a cross-chain request-response method based on re-encryption. This invention involves multiple blockchains, each managing one or more engineering information systems, with different blockchains managing different engineering information systems. Information domain encryption methods are defined according to the actual connection between the engineering information systems and the blockchains, forming a blockchain secure information domain. In this invention, to enable better information interoperability between different blockchain information domains, broadcast encryption technology can be used to optimize the efficiency of group message transmission between different blockchain secure information domains. Combined with proxy re-encryption technology, different blockchain secure information domains form an interoperable domain with a unified communication standard during data encryption transmission.

[0026] Each blockchain security information domain within the interoperability domain is used to perform data sharing and access for different engineering projects, and all blockchain security information domains can share and access data in parallel. For example, an engineering project monitoring system can create a blockchain network based on Hyperledger Fabric, adding all users of the engineering project monitoring system to a key generation group. Within this group, the group public key for the blockchain security information domain and the user's private key are generated. Each user is assigned specific permissions based on their role in the project.

[0027] For example, an engineering information system includes:

[0028] The project supervision system stores and manages project supervision data;

[0029] Building Information Modeling (BIM) systems store and manage BIM data for engineering projects;

[0030] The building project operation and maintenance management system stores and manages data during the building's operation phase;

[0031] The IoT system for building projects stores and manages data from IoT devices within the building project.

[0032] Each user on the chain has corresponding identity attribute information. The attributes in the identity attribute information may include, for example, the affiliated unit, the personnel identity, the responsible project, the function, etc. For example, the identity attribute information = { "Affiliated unit: Construction unit", "Personnel identity: Project manager", "Project: Phase I, Section 3 of a certain city", "Function: Project management"}.

[0033] When a user initiates an access request, in addition to identity attribute information, they also need to carry operation attribute information. This operation attribute information tells the other party what kind of operation the user needs to perform. Attributes in the operation attribute information can include, for example, tasks, time limits, resources, authorized operations, etc. For example, operation attribute information = {"Task: Track progress", "Time limit: 2001 / 01 / 01-2011 / 01 / 01", "Resource: Administrative forms", "Authorized operation: Approval}; indicating that the purpose of the requesting user's access is to approve administrative forms submitted by authorized users during the period from 2001 / 01 / 01 to 2011 / 01 / 01.

[0034] In this invention, different users each maintain two types of tools: the first is a Bloom filter, and the second is LSSS (Linear Secret Sharing Scheme) information, including the access control matrix M and mapping function obtained by transforming the user's access control policy using LSSS encryption technology. .

[0035] Each user has their own corresponding access control policy, used to determine the attributes of the requesting user. Only when the requesting user's attributes meet the access control policy of the authorized user can LSSSS decryption be performed and access permissions granted. Since the interoperability domain involves a large number of users, different policies are generally used for different types of user access. Multiple different policies are integrated to obtain an integrated access control policy P, which contains one or more sub-policies. Access permissions are granted as long as the requesting user's attributes meet any one of these sub-policies. To implement the LSSS transformation of the access control policy, the attribute requirements in access control policy P need to be constructed into an access control tree using AND and OR operations. Then, LSSS encryption technology is used to convert this tree into an access control matrix M and a mapping function. The authorized user's private key contains a hidden secret number 's'. Authorized users can recover 's' through calculation, while unauthorized users cannot. For example, the access control tree corresponding to access control policy P can be represented as P = First Sub-policy OR Second Sub-policy OR Third Sub-policy OR ..., where First Sub-policy = Construction Unit AND Project Manager AND Phase I, Section 3, City AND Project Management AND (Specify Plan OR Assign Task OR Track Progress) AND 2001 / 01 / 01-2011 / 01 / 01 AND (Account OR Technical Solution OR Design Drawings OR Model Files OR Administrative Forms) AND (View OR Enter OR Approve OR Initiate Document OR Manage). In this embodiment, the necessary attribute parameters in each sub-strategy include: affiliated unit, personnel identity, project, function, and timeliness. In specific operation, any combination of the above necessary attribute parameters can be selected as the necessary attributes for inserting into the Bloom filter. All necessary attributes in each sub-strategy are inserted into the Bloom filter. For example, if affiliated unit and personnel identity are selected as the necessary attributes for inserting into the Bloom filter, all affiliated units and personnel identities in each sub-strategy are inserted into the Bloom filter. The requesting user's affiliated unit and personnel identity must be able to find corresponding records in the Bloom filter in order to pass the Bloom filter.

[0036] Bloom filters enable efficient insertion and retrieval. Essentially, they are bit arrays. The principle is to map the original data through multiple hash functions to obtain hash codes, and then use these hash codes as indices to mark the corresponding bits in the bit array as 1. To check if a Bloom filter has recorded certain data, the data is also mapped through multiple hash functions to obtain hash codes. Then, using these hash codes as indices, the corresponding bits are checked to see if they are all marked as 1. If not, the Bloom filter definitely hasn't recorded the data; if so, it likely has. In this invention, necessary attributes from each sub-policy of the access control policy are selected and inserted into the Bloom filter. Each user records the necessary attributes from each sub-policy of their access control policy through their corresponding Bloom filter. A requesting user who passes the Bloom filter's verification indicates they may satisfy the access control policy; if they fail, the requesting user is unlikely to satisfy the access control policy.

[0037] like Figure 1 The diagram shows a flowchart of the steps of a cross-chain request-response method based on re-encryption according to an embodiment of the present invention. Figure 2 The diagram shown illustrates a process of performing dual authentication on a requesting user according to an embodiment of the present invention. Figure 3 The diagram shown is a schematic diagram of information processing for cross-chain access between authorized users and requesting users in one embodiment of the present invention.

[0038] The following provides a detailed explanation of each step.

[0039] S11. Receive the access request from user b located on another blockchain B.

[0040] Specifically, the access request from user b carries user b's attribute information, including identity attribute information and operation attribute information. Authorized user a can know what user needs to perform what operation based on the attribute information carried in the access request.

[0041] S12. Validate the necessary attributes of the requesting user b using the Bloom filter corresponding to the authorized user a. If the validation passes, proceed to S13; otherwise, proceed to S14.

[0042] Specifically, since the Bloom filter maintained by authorized user a records the necessary attributes required to satisfy the access control policy, and only the necessary attributes of requesting user b are recorded in the Bloom filter maintained by authorized user a, it means that requesting user b may satisfy the access control policy. If the necessary attributes of requesting user b cannot be found in the Bloom filter maintained by authorized user a, it means that requesting user b cannot satisfy the access control policy, and in this case, access can be directly denied.

[0043] In this invention, a Bloom filter is used for initial verification, enabling rapid coarse screening. Only after passing the Bloom filter verification can the next step be performed for further verification. This improves cross-chain access speed.

[0044] S13, PK the public key of blockchain B. B The LSSS information of authorized user a and the public key PK of the blockchain A where authorized user a resides. A and the private key SK of authorized user a a Input the blockchain smart contract to generate a re-encryption key RK ab Using the re-encryption key RK ab The ciphertext C of authorized user a is re-encrypted to obtain the re-encrypted ciphertext C. * And send it to blockchain B; authorize user a's encrypted C is the public key PK used by blockchain A. A The plaintext U is obtained by encrypting the plaintext U using the authorized attribute set S, which consists of all attributes in the access control policy of authorized user a; and has the same public key PK. B A user with a paired private key whose attributes satisfy the access control policy of authorized user a can decrypt ciphertext C. * The plaintext U in the text.

[0045] Specifically, when building a blockchain, standard encryption algorithms can be used to generate a common public key (PK) and a user private key (SK) for the corresponding blockchain, with different users having different private keys. In one embodiment, to facilitate better information exchange, all blockchains capable of cross-chain information exchange constitute an interoperability domain. Each blockchain in the interoperability domain uses a bilinear pairing-based encryption algorithm to generate a common public key and a user private key for the corresponding blockchain, thereby ensuring that the ciphertext mathematical structures within the interoperability domain are mutually compatible.

[0046] In one embodiment, the blockchains in the interoperability domain exchange information through a proxy server. In S13, blockchain A re-encrypts the key RK. ab The encrypted text C is sent to the proxy server, which then uses the re-encryption key RK. ab Re-encrypt the ciphertext C to obtain the re-encrypted ciphertext C. * And then sent to blockchain B. Specifically, after requesting user b passes the Bloom Filter verification, authorized user a sends the ciphertext C to the proxy server, and the proxy server uses the re-encryption key RK. ab Re-encrypt ciphertext C into ciphertext C of field B. * And re-encrypt the C * The encrypted message U is sent to user b in domain B who requested it, and simultaneously recorded on the blockchain. This embodiment uses a cloud proxy for re-encryption of the ciphertext, which can offload some of the complex computational processes, reduce the computational load on the blockchain and business systems, and thus improve the overall system performance.

[0047] In this invention, the plaintext U is encrypted using two methods:

[0048] The first layer of encryption forms ciphertext C: using the public key PK common to blockchain A. A The plaintext U is encrypted using the authorized attribute set S to generate ciphertext C;

[0049] The second encryption forms ciphertext C. * : Universal public key PK based on blockchain B B LSSS information of authorized user a, and the general public key PK of blockchain A. A and the private key SK of authorized user a a Generate re-encryption key RK ab Using RK ab Encrypt the ciphertext C again.

[0050] The above encryption process uses the public key PK of blockchain A to encrypt the plaintext. A And the authorized attribute set S, therefore, if ciphertext decryption is required, the ciphertext decryption key used must contain the same key as the general public key PK. A Paired user private key SKa And the authorized attribute set S. Therefore, during re-encryption, the re-encryption key used carries the same key as the general public key PK. A Paired user private key SK a And it uses the common public key PK of blockchain B. B And the LSSS information of authorized user a, as long as the requesting user can provide the common public key PK. B Paired user private key SK b Furthermore, since its attributes satisfy the access control policy corresponding to the LSSS information, it is possible to construct a re-encrypted ciphertext C. * The key for decryption and the key for further decryption of ciphertext C are obtained, i.e., as long as the requesting user can provide a key that matches the general public key PK. B Paired user private key SK b Furthermore, if its attributes satisfy the access control policy corresponding to the LSSS information, it can be obtained from the ciphertext C. * The plaintext U is decrypted from the Chinese character set.

[0051] In other words, when a user requests access, the necessary attribute hash value is calculated and a Bloom filter is checked to see if a corresponding hash exists. If not, access is directly denied; if the Bloom filter verification passes, the proxy server returns a re-encrypted ciphertext C to the requesting user. * Users need to decrypt based on their private key's SK and LSSS policies. If the attributes do not meet the threshold decryption conditions, decryption will fail.

[0052] S14. End the response to the access request from user b.

[0053] In one embodiment, the LSSS-based access control policy is stored on the blockchain. The access control policy supports multiple attribute thresholds to ensure that only users who meet the policy conditions can decrypt data. Changes to user attributes in the access control policy are broadcast through blockchain transactions to ensure the dynamism and verifiability of access control.

[0054] In one embodiment, a decentralized key management approach is adopted, in which the generation, distribution, and updating of user keys are recorded on the blockchain; the generation, storage, and use of re-encryption keys are managed by smart contracts, supporting access traceability and permission revocation.

[0055] In one embodiment, the Bloom Filter is stored on the blockchain and its bit array state is maintained; whenever the user attribute set changes, the Bloom Filter is updated synchronously to ensure the accuracy of its filtering function; when the proxy server performs access control, it prioritizes querying the Bloom Filter to improve system processing efficiency.

[0056] Example 2

[0057] This invention also provides a cross-chain request method based on re-encryption, such as... Figure 2 The diagram shows a flowchart of a cross-chain request method based on re-encryption according to an embodiment of the present invention. The steps are described below.

[0058] S21. Request user b to send an access request to authorized user a on blockchain A and obtain the re-encrypted ciphertext C in response to the access request. * ; Re-encrypt ciphertext C * The re-encrypted ciphertext generated by the authorized end through the request-response method of Example 1.

[0059] Specifically, user b sends an access request to authorized user a on blockchain A, providing authorized user a with the necessary attributes of user b. Authorized user a verifies the request using a Bloom filter. If the verification passes, the ciphertext C is re-encrypted. * Send to blockchain B.

[0060] S22, By requesting user b's private key SK b And LSSS decryption technology to re-encrypt ciphertext C * Decrypt the code to obtain the plaintext.

[0061] First, user b on blockchain B sends an access request to authorized user a on blockchain A.

[0062] Secondly, authorized user a on blockchain A performs preliminary verification of the requesting user through a Bloom filter, and after successful verification, sends the re-encrypted ciphertext to blockchain B.

[0063] Finally, user b on blockchain B decrypts the re-encrypted ciphertext to obtain the plaintext.

[0064] As described in Example 1, the ciphertext C is re-encrypted. * This is formed by double encryption of the plaintext. The first encryption uses the common public key PK of blockchain A. A And the authorized attribute set S, therefore, if it is necessary to decrypt the ciphertext C, the decryption key used must contain the same key as the general public key PK. A Paired user private key SK a The outer encryption layer carries a key that matches the common public key (PK). A Paired user private key SK a And it uses the common public key PK of blockchain B. B And the LSSS information of authorized user a, as long as the requesting user can provide the common public key PK. B Paired user private key SK b Furthermore, since its attributes satisfy the access control policy corresponding to the LSSS information, it is possible to construct a re-encrypted ciphertext C.* The key for decryption and the key for further decryption of ciphertext C are obtained, i.e., as long as the requesting user can provide a key that matches the general public key PK. B Paired user private key SK b Furthermore, if its attributes satisfy the access control policy corresponding to the LSSS information, it can be obtained from the ciphertext C. * The plaintext U is decrypted from the plaintext C. In short, user b obtains the ciphertext C. * User b uses personal private key SK b Attempt to decrypt the ciphertext. Check each attribute component of user B against user a's access control policy. If the number of matches exceeds the LSSS threshold, the secret value s can be calculated and restored. User B uses SK. b Calculate the decryption factor with the secret value S Using a decryption factor, the ciphertext C can be calculated. * Restore to plain text.

[0065] In one embodiment, to reduce the computational burden on the blockchain, user b is requested to retrieve the re-encrypted ciphertext C from blockchain B. * Decryption is performed by the requesting user b on their local server.

[0066] In general, this invention performs dual filtering for requesting users. The first layer of filtering uses a Bloom filter to preliminarily verify the necessary attributes of the requesting user. Since the Bloom filter maintained by the authorized user records the necessary attributes required to satisfy the access control policy, if the necessary attributes of the requesting user are recorded in the Bloom filter maintained by the authorized user, it means that the requesting user may satisfy the access control policy. If the necessary attributes of the requesting user are not found in the Bloom filter maintained by the authorized user, it means that the requesting user cannot satisfy the access control policy, and access can be directly denied. Therefore, only after passing the verification of the Bloom filter can the requesting user proceed to the second layer of filtering for further verification. The second layer of filtering involves encrypting the ciphertext using a re-encryption key. At this point, it is necessary to verify whether the attributes of the requesting user satisfy the access control policy of the authorized user. Only users whose attributes satisfy the access control policy of the authorized user can pass the second layer of filtering and obtain the decryption key to decrypt the original plaintext. Thus, because the hash function calculation of the first-level filtering query operation is significantly more time-efficient than asymmetric encryption and decryption calculations, with a smaller computational load, the verification speed is significantly faster than the decryption and restoration process of LSSS and asymmetric encryption and decryption. LSSS and asymmetric encryption have strict decryption conditions, and content verification requires number theory operations. The time for asymmetric encryption and decryption number theory operations is at least a thousand times longer than the time for a fixed number of hash calculations. Based on the first-level filtering, a fast coarse screening can be performed, helping to filter out a large number of invalid requests. Only requests that pass the first-level filtering can enter the second, more complex filtering verification, thereby improving the speed of cross-chain access. Moreover, this invention uses a re-encryption method, which can transform ciphertext encrypted with one public key into ciphertext encrypted with another public key without exposing plaintext information. Therefore, it can convert encrypted information from heterogeneous encryption standard systems, enabling cross-domain information sharing of ciphertext and effectively ensuring data security. In summary, this invention can achieve a balance between cross-chain access processing speed and security.

[0067] Example 3

[0068] The present invention also provides a multi-blockchain system based on re-encryption, comprising multiple blockchains capable of data sharing. When a requesting user b on blockchain B needs to access the data of an authorized user a on blockchain A, the requesting end executes the cross-chain request method as described in Embodiment 2, and the authorizing end executes the request response method as described in Embodiment 1. The requesting end includes blockchain B and requesting user b, and the authorizing end includes blockchain A and authorizing user a.

[0069] Understandably, when a user needs to initiate an access request, they act as the requesting user; when a user needs to be accessed, they act as the authorizing user. The specific process of cross-chain information exchange between the requesting user and the authorizing user can be found in the above description and will not be repeated here.

[0070] The following provides a specific encryption method, which includes the specific process of the bilinear pairing encryption algorithm and the LSSS algorithm.

[0071] Initialization: Select generation parameters G is a cyclic group of prime order p, and g are generators of G, G, and G, respectively. T Let e ​​be the target group, and let G×G and G be the target group. T A bilinear pair mapping relationship between them, where f is the target group G. T The mapping function to the cyclic group G, where the master private key parameter α is from Z. p A random number Z is randomly selected from the given data. p It is the integer field of p.

[0072] Blockchain A generates a universal public key PK A and user private key SK a The process is as follows.

[0073] The blockchain randomly selects parameters {w, h} from the cyclic group G, and all attribute elements of blockchain A. For attribute x∈A, construct a mapping function D such that D x ∈G;

[0074] Blockchain A generates a universal public key. .

[0075] When generating user A's private key:

[0076] The manual input access policy is S, and the authorization attributes in the access policy are connected by AND and OR logic. The LSSS technique is used to transform the access policy S into an LSSS access structure (M, ρ), where M is an L×N matrix, and ρ... i Let M be the i-th row vector of M. i Mapping to properties;

[0077] Construct column vectors ,in For any i∈[1,L], construct λ i =M i *v; To facilitate calculation, construct the index attribute set of matrix M. ;

[0078] From Z p Randomly select β i Construct user a's private key SK a ,have:

[0079]

[0080]

[0081] in, Refers to the index attribute set Other attributes included besides the current row's attributes.

[0082] Blockchain B generates a universal public key PK B and user private key SK b The process is as follows.

[0083] To simplify computation, blockchain starts from Z p Randomly select γ∈Z p Construct a universal public key:

[0084]

[0085] User private key SK b =γ.

[0086] User A generates a re-encryption key RK ab The process is as follows.

[0087] Enter the general public key PK A PK B and user a's private key SK a For user b who meets the access policy, a column vector can be constructed. ,in, For any i∈[1,L], construct When user b's attributes meet the access control policy set by user a, there exists Make:

[0088]

[0089] From Z p Random selection Generate a re-encryption key:

[0090]

[0091] Encrypting plaintext U yields ciphertext C:

[0092] Input plaintext U, user a inputs the authorization attribute set S and the universal public key PK. A From target group G T Randomly select η from Z p The ciphertext obtained by randomly selecting τ in the middle is:

[0093]

[0094] Re-encrypt the ciphertext C to obtain the re-encrypted ciphertext C. * The process is as follows.

[0095] Input ciphertext C and re-encryption key RKab ,structure

[0096]

[0097] For user a with access permissions, when attribute set A s When the access control policy is satisfied, there exists Make:

[0098]

[0099] Can be constructed

[0100]

[0101] structure

[0102]

[0103] Re-encryption yields ciphertext C * :

[0104]

[0105] User b uses private key SK b Decrypting Ciphertext C * The process is as follows.

[0106] Input ciphertext C * and user private key SK b ,structure

[0107]

[0108] It can be calculated

[0109]

[0110]

[0111] Thus, the plaintext U is restored.

[0112]

[0113] The ultimate physical meaning is that ciphertext C can be used. * The components and user private key SK b Restore plaintext U.

[0114] In this scheme, user a can also use the private key SK. a Directly decrypt its ciphertext:

[0115] Input ciphertext C and user private key SK a Known

[0116]

[0117] For user a with access permissions, when attribute set A s When the access control policy is satisfied, there exists Make:

[0118]

[0119] It can be constructed as follows:

[0120]

[0121] Constructing intermediate values:

[0122]

[0123] It can be calculated that:

[0124]

[0125] The following can be deciphered from the original text:

[0126]

[0127] The final physical meaning is that user a can use the components of ciphertext C and the user's private key SK. a The plaintext U is calculated and restored from each component.

[0128] It should be noted that the above specific encryption method is only one specific embodiment, but is not limited thereto.

[0129] In summary, this invention employs a re-encryption method, which can transform ciphertext encrypted with one public key into ciphertext encrypted with another public key without exposing plaintext information. Therefore, it can convert encrypted information from heterogeneous encryption standard systems, enabling cross-domain sharing of ciphertext while ensuring security. Furthermore, this invention utilizes a dual-filter access control mechanism. The first layer of filtering improves the speed of authorization verification, quickly filtering out the vast majority of invalid requests. The second layer of filtering provides fine-grained access control, requiring verification before decryption, thus ensuring system security. This combination of dual filtering achieves a balance between processing speed and security.

[0130] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. It should be noted that the terms "in one embodiment," "for example," and "again" are intended to illustrate the present invention and are not intended to limit the present invention.

[0131] The above embodiments merely illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention.

Claims

1. A cross-chain request-response method based on re-encryption, characterized in that, In the blockchain, each user maintains their own Bloom filter and LSSS information. The LSSS information for each user includes the access control matrix M and mapping function obtained by transforming the user's access control policy using LSSS encryption technology. Users whose attributes satisfy the access control policy of the authorized user have access to the authorized user. The access control policy has one or more sub-policies with OR gate logic relationships. Different attributes in each sub-policy form an access control tree through AND gate logic relationships and OR gate logic relationships. The Bloom filter corresponding to the user records the necessary attributes in each of its sub-policies. The necessary attributes in the sub-policy are the attributes that serve as necessary conditions for satisfying the sub-policy. The request-response method includes: S11. Receive the access request from user b located on another blockchain B; S12. Validate the necessary attributes of the requesting user b using the Bloom filter corresponding to the authorized user a. If the validation passes, proceed to S13; otherwise, proceed to S14. S13, PK the public key of blockchain B. B The LSSS information of authorized user a and the public key PK of the blockchain A where authorized user a resides. A and the private key SK of authorized user a a Input the blockchain smart contract to generate a re-encryption key RK ab Using the re-encryption key RK ab The ciphertext C of authorized user a is re-encrypted to obtain the re-encrypted ciphertext C. * And send it to blockchain B; authorize user a's encrypted C is the public key PK used by blockchain A. A The plaintext U is obtained by encrypting the plaintext U using the authorized attribute set S, which consists of all attributes in the access control policy of authorized user a; and has the same public key PK. B A user with a paired private key whose attributes satisfy the access control policy of authorized user a can decrypt ciphertext C. * plaintext U in the text; S14. End the processing response to the access request from user b.

2. The request-response method as described in claim 1, characterized in that, All blockchains capable of cross-chain information exchange constitute an interoperability domain. Each blockchain in the interoperability domain uses a bilinear pairing-based cryptographic algorithm to generate a common public key and a user private key for the corresponding blockchain.

3. The request-response method as described in claim 1, characterized in that, The attributes requested by the user include attributes that represent identity information and attributes that represent the purpose of access.

4. The request-response method as described in claim 1, characterized in that, All blockchains capable of cross-chain information exchange constitute an interoperability domain. The blockchains within this domain exchange information through a proxy server. In S13, blockchain A re-encrypts the key RK. ab The encrypted text C is sent to the proxy server, which then uses the re-encryption key RK. ab Re-encrypt the ciphertext C to obtain the re-encrypted ciphertext C. * And send it to blockchain B.

5. A cross-chain request method based on re-encryption, characterized in that, include: S21. Request user b to send an access request to authorized user a on blockchain A and obtain the re-encrypted ciphertext C in response to the access request. * The re-encrypted ciphertext C * The re-encrypted ciphertext generated by the authorizing end through executing the request-response method as described in any one of claims 1 to 4; S22, By requesting user b's private key SK b And LSSS decryption technology for the re-encrypted ciphertext C * Decrypt the code to obtain the plaintext.

6. The request method as described in claim 5, characterized in that, In S22, user b is requested to retrieve the re-encrypted ciphertext C from blockchain B. * Decryption is performed by the requesting user b on their local server.

7. A multi-blockchain system based on re-encryption, comprising multiple blockchains capable of data sharing, characterized in that, When user b on blockchain B needs to access data of authorized user a on blockchain A, the requesting end executes the cross-chain request method as described in claim 5 or 6, and the authorizing end executes the request response method as described in any one of claims 1 to 4. The requesting side includes blockchain B and requesting user b, while the authorizing side includes blockchain A and authorizing user a.

8. The multi-blockchain system as described in claim 7, characterized in that, Different blockchains are used to manage data from different engineering information systems, which include: The project supervision system stores and manages project supervision data; Building Information Modeling (BIM) systems store and manage BIM data for engineering projects; The building project operation and maintenance management system stores and manages data during the building's operation phase; The IoT system for building projects stores and manages data from IoT devices within the building project.

Images