Building Internet of Things data management method based on blockchain multi-chain and attribute encryption

Abstract

The present invention discloses a method for managing building Internet of Things data based on blockchain multi-chain and attribute encryption. The method comprises: using the gateway and cloud server of the building Internet of Things cluster to construct a blockchain network and an IPFS private network, and calling a multi-chain partitioning algorithm to divide the blockchain network into multiple sub-chains. The multi-chain partitioning algorithm designed by the present invention divides the subsystem data into different sub-chains for maintenance according to the distribution of the number of devices, so that the computing pressure brought by processing high concurrent requests can be unloaded to the nodes of each sub-chain more evenly, thereby making full use of the computing resources of each node and improving the concurrent processing capability of the blockchain network; the method also comprehensively adopts on-chain storage and collaborative storage, adopts different storage methods for different types of data, thereby effectively reducing the storage demand of the blockchain, and using IPFS to realize reliable storage of off-chain data.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a building Internet of Things data management method based on blockchain multi-chain and attribute encryption. Background Art

[0002] Blockchain is a trustless and decentralized distributed ledger technology. Once the data is verified by the blockchain nodes and uploaded to the blockchain, it will be permanently stored and cannot be tampered with. Due to its decentralized storage and data immutability, blockchain can effectively solve single point failure and third-party data trust issues, ensuring data security and reliability. Once the concept of blockchain was proposed, it has been widely used in many fields. At the same time, domestic and foreign researchers have done a lot of research on the application of blockchain in building IoT scenarios, realizing trusted data storage, and using blockchain smart contracts to achieve IoT device management and building operation and maintenance management.

[0003] With the continuous development of IoT technology, the number of IoT devices in building IoT is gradually increasing, and the amount of data collected is increasing. However, due to the characteristics of blockchain's full storage and log-type recording method, the data of blockchain nodes will continue to accumulate over time, and the existing research schemes face the challenge of blockchain storage performance; in addition, the above research stores the collected data in plain text on the blockchain, lacking privacy protection measures.

[0004] In response to the above problems, the patent application publication number CN111914269A discloses a method and system for secure data sharing in a blockchain and cloud storage environment, which stores the original data in an off-chain cloud environment and only stores the corresponding metadata on the chain, thereby reducing the storage pressure of the blockchain and realizing secure data sharing based on the attribute encryption scheme. However, its off-chain centralized cloud storage method has a single point failure risk. If a cloud server fails, it will affect the normal operation of the entire system, and the data reliability is poor. To this end, the patent application publication number CN114065261A discloses a distributed trusted data sharing platform, method and system based on blockchain, and uses IPFS to realize off-chain distributed trusted data storage.

[0005] However, although the above existing methods use the on-chain and off-chain collaborative storage method to reduce the storage pressure of the blockchain and realize data security sharing based on encryption algorithms, they still face many challenges. On the one hand, the existing methods generally use a single blockchain for data management. The transaction request initiated to the blockchain network needs to be processed by all blockchain nodes to reach a consensus on the data content in the transaction and achieve consistent storage; at the same time, the continuous expansion of the scale of the building Internet of Things requires the blockchain network to have a higher request concurrent processing capability. Due to the inherent serialized ledger writing operation characteristics of the blockchain data structure, all nodes need to spend computing resources to serialize the blocks containing batch transactions, which leads to the throughput performance of the existing single-chain-based data management methods being difficult to meet the concurrent processing requirements of the building Internet of Things scenario. On the other hand, some blockchain-based data management methods choose to store access control policies in plain text on the blockchain when using attribute encryption schemes to protect data privacy. The explicit storage of policies makes the policy attributes and user information leaked.

[0006] In general, IoT devices in building IoT scenarios have the characteristics of high deployment density and large amount of sampled data. If the data is directly stored on the blockchain, it will bring great challenges to the storage performance of the blockchain network; at the same time, due to the open and transparent characteristics of the blockchain, the data plaintext storage method will cause data privacy leakage. The existing technology has designed corresponding on-chain and off-chain collaborative storage solutions and attribute encryption solutions to solve the above problems, but because they generally use a single blockchain for data management, the throughput performance of the blockchain is difficult to meet the concurrent processing requirements of the building IoT scenario; in addition, when the existing technology uses attribute encryption solutions to protect data privacy, the access control policy is explicitly stored in plaintext on the blockchain, and there is a risk of leakage of policy attributes and user information.

[0007] Based on this, how to propose a building Internet of Things data management method to reduce the storage pressure of blockchain nodes, improve the concurrent processing capability of blockchain networks, and realize data security sharing under the premise of implicitly recording access control policies on the chain has become an urgent problem that needs to be solved. Summary of the invention

[0008] In view of the problems of poor concurrent processing capability and easy leakage of strategies and user information in the blockchain network storage in the above-mentioned prior art, the present invention proposes a building Internet of Things data management method based on blockchain multi-chain and attribute encryption, including:

[0009] Network construction steps: Use the gateway and cloud server of the building IoT cluster to build a blockchain network and an IPFS private network, and call the multi-chain partitioning algorithm to divide the blockchain network into multiple sub-chains, and store the corresponding relationship between each sub-chain and each intelligent subsystem of the building IoT;

[0010] Access strategy setting step: using the key generation mechanism to call the ABE initialization algorithm to generate the ABE master key and the ABE public key, setting different access strategies and symmetric keys for different data in the building Internet of Things, calling the ABE encryption algorithm according to the ABE public key and the access strategy to encrypt the symmetric key to obtain an encryption key, and setting a private value, and generating an LSSS strategy vector according to the private value and the access strategy;

[0011] Access policy storage step: construct access policy records for different data according to the encryption key, LSSS policy vector and private value hash, and store each access policy record in the subchain corresponding to the data type by calling the access policy storage contract of each subchain;

[0012] Data storage step: obtaining data in the building Internet of Things and encrypting it to obtain ciphertext data, and storing the ciphertext data using a collaborative storage or on-chain storage method according to the data type to obtain a storage record;

[0013] Data request step: Initiate a data access request, obtain the user attribute hash set and the data type of the requested data by parsing the data access request, determine the subchain to which the requested data belongs according to the data type, and call the storage record acquisition contract of the subchain, verify whether the user attribute hash set meets the access policy through the storage record acquisition contract, and return the corresponding storage record and encryption key after verification;

[0014] Data decryption step: according to the ABE private key generated by the user through the key generation mechanism, call the ABE decryption algorithm to decrypt the encryption key, obtain the symmetric key, use the symmetric key to decrypt the ciphertext data in the storage record, and perform integrity check on the decrypted data. After the check passes, the data that can be used normally is obtained.

[0015] The above-mentioned building Internet of Things data management method, wherein the network construction step includes: dividing the blockchain network into multiple sub-chains according to the number of the intelligent subsystems, the number of devices in each intelligent subsystem, and the number of sub-chains to be divided, and writing the correspondence between the sub-chains and the intelligent subsystems into a configuration file, and storing the configuration file in the gateway and the server.

[0016] In the above-mentioned building Internet of Things data management method, the access policy setting step includes:

[0017] Initialization step: randomly generating a security parameter by initializing the key generation mechanism, and calling the ABE initialization algorithm according to the security parameter to generate the ABE master key and the ABE public key;

[0018] Symmetric key generation step: classify the data in the building Internet of Things according to the data type, device location, device owner and intelligent subsystem as classification conditions, and set corresponding access policies and symmetric keys corresponding to the access policies for the classified data according to the classification conditions;

[0019] LSSS matrix generation step: split the attribute combination of the access policy into multiple sub-items that can satisfy the access policy, and call the LSSS matrix construction algorithm to generate the LSSS matrix;

[0020] LSSS strategy vector acquisition step: construct a random vector according to the private value, and multiply the LSSS matrix and the random vector to obtain the LSSS strategy vector.

[0021] The above-mentioned building Internet of Things data management method further includes:

[0022] Steps for obtaining the ABE private key: When a user registers for the first time, a registration request is initiated to a key generation agency, and the key generation agency generates an ABE private key based on the registration request and returns it to the user. The content of the registration request includes but is not limited to user ID, user attribute set, timestamp, registration time and administrator signature.

[0023] In the above-mentioned building Internet of Things data management method, the ABE private key acquisition step includes:

[0024] Administrator signature verification step: after parsing the registration request through the key generation mechanism, obtaining and verifying the administrator signature;

[0025] ABE private key generation step: if the verification fails, the user's registration request is ignored; if the verification passes, the ABE master key and ABE public key stored locally are loaded through the key generation mechanism, combined with the user attribute set, and the ABE private key generation algorithm is called to generate an ABE private key for the user;

[0026] ABE private key return step: return the ABE private key to the user who initiated the registration request through a secure channel.

[0027] In the above-mentioned building Internet of Things data management method, the data storage step comprises:

[0028] Data encryption step: obtaining data in the building Internet of Things through a data gateway and a server, encrypting the data through a symmetric key, and obtaining ciphertext data;

[0029] Storage step: By parsing the configuration file, determine the subchain to which the data belongs and select on-chain storage or collaborative storage to store the encrypted data according to the data type.

[0030] In the above-mentioned building Internet of Things data management method, the storage step includes:

[0031] Storage record construction step: if the collaborative storage method is adopted, the IPFS interface is called to store the ciphertext data into the IPFS private network, and the returned IPFS storage address is obtained, and the storage record is constructed according to the IPFS storage address and the hash value of the original data; if the on-chain storage method is adopted, the ciphertext data is stored in the corresponding subchain, and the storage record is constructed according to the ciphertext data and the hash value of the original data;

[0032] Storage record uploading step: calling the data storage contract of the subchain to which the data belongs, and uploading the storage record to the subchain.

[0033] The above-mentioned building Internet of Things data management method, wherein the data request step includes: initiating a data access request to the background server of the building Internet of Things system through the terminal, and the content of the data access request includes but is not limited to user ID, user attribute hash set, data type to be requested, data query conditions, request time and timestamp.

[0034] In the above-mentioned building Internet of Things data management method, the data request step further comprises:

[0035] Access policy acquisition step: obtain the access policy and private value hash corresponding to the data to be requested through the storage record acquisition contract;

[0036] Authority verification step: obtain the verification private value according to the user attribute hash set, LSSS matrix and LSSS policy vector, compare the hash value of the verification private value with the hash of the private value, if the comparison result is consistent, the user attribute hash set satisfies the access policy, and returns the storage record and encryption key corresponding to the requested data.

[0037] In the above-mentioned building Internet of Things data management method, the data decryption step includes:

[0038] Decryption step: decrypting the encryption key by using the ABE decryption algorithm according to the ABE public key and the ABE private key to obtain a symmetric key, and using the symmetric key to decrypt the ciphertext data in the storage record;

[0039] Integrity verification step: perform a hash operation on the decrypted data to obtain the hash value of the decrypted data, and compare it with the hash value of the original data stored on the chain. If the comparison results are consistent, the data is complete.

[0040] Compared with the prior art, the advantages and positive effects of the present invention are:

[0041] 1. In response to the blockchain storage performance issues faced by existing building IoT data management methods, the present invention adopts a combination of on-chain storage and collaborative storage. For data with small volume, irregular data generation frequency, and need to be processed one by one, the on-chain storage method can be used to store it in the blockchain. For data with large volume, fixed data generation frequency, and batch processing, the collaborative storage method can be used to store it in the distributed IPFS network off-chain, and only the corresponding metadata is stored in the blockchain, thereby effectively reducing the storage requirements of the blockchain, and using IPFS to achieve reliable storage of off-chain data;

[0042] 2. In view of the low concurrency problem of blockchain networks faced by existing technologies, and considering that the number of devices in each intelligent subsystem in the building Internet of Things is positively correlated with the amount of data generated and the number of blockchain transactions, the present invention designs a multi-chain partitioning algorithm to divide the subsystem data into different sub-chains for maintenance according to the distribution of the number of devices, so that the blockchain transactions to be processed by each sub-chain tend to be consistent. Storage or query requests initiated to the blockchain network will be forwarded to a specific sub-chain in the network for processing. The computing pressure brought by processing high-concurrency requests can be unloaded to the nodes of each sub-chain more evenly, thereby making full use of the computing resources of each node and improving the concurrent processing capability of the blockchain network;

[0043] 3. Aiming at the insecure access control policy recording method problem faced by the prior art when combining attribute encryption with blockchain, the present invention, based on the prior art, uses smart contracts and linear secret sharing schemes (i.e., LSSS) to store access control policies and policy attributes in the form of matrices and hash values ​​(rather than explicit attribute values) on the blockchain, and determines user access rights through matrix operations, thereby achieving secure recording and effective verification of access control policies. At the same time, the present invention combines attribute encryption with linear secret sharing schemes, so that the technical solution of the present invention can have the characteristics of fine-grained access control, "one-to-many" data security sharing, and policy security recording. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 A schematic diagram of the steps of the building Internet of Things data management method based on blockchain multi-chain and attribute encryption provided in an embodiment of the present application;

[0045] Figure 2 A schematic diagram of a method for managing building Internet of Things data based on blockchain multi-chain and attribute encryption provided in an embodiment of the present application;

[0046] Figure 3 An architecture diagram of a building IoT data management system based on blockchain and IPFS provided in an embodiment of the present application;

[0047] Figure 4A schematic diagram of the flow of the multi-chain partitioning algorithm provided in the embodiment of the present application;

[0048] Figure 5 A schematic diagram of the LSSS strategy vector construction process provided in an embodiment of the present application;

[0049] Figure 6 A schematic diagram of a process for a key generation mechanism provided in an embodiment of the present application to generate an entity ABE private key;

[0050] Figure 7 A flowchart of judging and processing two data storage methods provided in an embodiment of the present application;

[0051] Figure 8 A schematic diagram of a process for verifying user access rights provided in an embodiment of the present application;

[0052] Fig. 9 A schematic diagram of a model of a building access control data management method based on blockchain multi-chain and attribute encryption provided in an embodiment of the present application;

[0053] Fig.10 A flowchart of a building access control data management method based on blockchain multi-chain and attribute encryption provided in an embodiment of the present application. DETAILED DESCRIPTION

[0054] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is described and illustrated below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments provided in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0055] Obviously, the drawings described below are only some examples or embodiments of the present application. For ordinary technicians in this field, the present application can also be applied to other similar scenarios based on these drawings without creative work. In addition, it can also be understood that although the efforts made in this development process may be complicated and lengthy, for ordinary technicians in this field related to the content disclosed in this application, some changes in design, manufacturing or production based on the technical content disclosed in this application are just conventional technical means, and should not be understood as insufficient content disclosed in this application.

[0056] Reference to "embodiments" in this application means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those of ordinary skill in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0057] Unless otherwise defined, the technical terms or scientific terms involved in this application should be understood by people with ordinary skills in the technical field to which this application belongs. The words "one", "a", "a", "the" and the like involved in this application do not indicate a quantitative limitation, and may represent the singular or plural. The terms "include", "comprise", "have" and any of their variations involved in this application are intended to cover non-exclusive inclusions; for example, a process, method, system, product or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units that are not listed, or may also include other steps or units inherent to these processes, methods, products or devices. The words "connect", "connected", "coupled" and the like involved in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The "multiple" involved in this application refers to two or more. "And / or" describes the association relationship of associated objects, indicating that there may be three relationships, for example, "A and / or B" can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the objects before and after are in an "or" relationship. The terms "first", "second", "third", etc. involved in this application are only used to distinguish similar objects and do not represent a specific ordering of the objects.

[0058] The present invention is described in detail below in conjunction with the various embodiments shown in the accompanying drawings, but it should be noted that these embodiments are not limitations of the present invention, and any equivalent transformations or substitutions in functions, methods, or structures made by ordinary technicians in the field based on these embodiments are all within the scope of protection of the present invention.

[0059] Embodiment 1:

[0060] Figure 1 A schematic diagram of the steps of a building IoT data management method based on blockchain multi-chain and attribute encryption provided in an embodiment of the present application. Figure 1 As shown, this embodiment discloses a specific implementation method of a building Internet of Things data management method based on blockchain multi-chain and attribute encryption (hereinafter referred to as the "method").

[0061] Specifically, the method disclosed in this embodiment mainly includes the following steps:

[0062] Step S1: Use the gateway and cloud server of the building IoT cluster to build a blockchain network and an IPFS private network, and call the multi-chain partitioning algorithm to divide the blockchain network into multiple sub-chains, and store the corresponding relationship between each sub-chain and each intelligent subsystem of the building IoT;

[0063] Among them, step S1 specifically includes: dividing the blockchain network into multiple sub-chains according to the number of the intelligent subsystems, the number of devices in each intelligent subsystem, and the number of sub-chains to be divided, and writing the correspondence between the sub-chains and the intelligent subsystems into a configuration file, and storing the configuration file in the gateway and the server.

[0064] Step S2: using the key generation mechanism to call the ABE initialization algorithm to generate an ABE master key and an ABE public key, setting different access policies and symmetric keys for different data in the building Internet of Things, calling the ABE encryption algorithm according to the ABE public key and the access policy to encrypt the symmetric key to obtain an encryption key, and setting a private value, and generating an LSSS policy vector according to the private value and the access policy;

[0065] Furthermore, step S2 specifically includes the following contents:

[0066] Step S21: randomly generate a security parameter by initializing the key generation mechanism, and call the ABE initialization algorithm according to the security parameter to generate the ABE master key and the ABE public key;

[0067] Step S22: classify the data in the building Internet of Things according to the data type, the location of the device, the device owner and the intelligent subsystem to which it belongs as classification conditions, and set the corresponding access policy and the symmetric key corresponding to the access policy for the classified data according to the classification conditions;

[0068] Step S23: splitting the attribute combination of the access policy into multiple sub-items that can satisfy the access policy, and calling the LSSS matrix construction algorithm to generate the LSSS matrix;

[0069] Step S24: construct a random vector according to the private value, and multiply the LSSS matrix and the random vector to obtain the LSSS strategy vector.

[0070] Step S3: construct access policy records for different data according to the encryption key, LSSS policy vector and private value hash, and store each access policy record in the subchain corresponding to the data type by calling the access policy storage contract of each subchain;

[0071] Step S4: When the user registers for the first time, a registration request is initiated to the key generation agency. The key generation agency generates an ABE private key based on the registration request and returns it to the user. The content of the registration request includes but is not limited to the user ID, user attribute set, timestamp, registration time and administrator signature.

[0072] Further, step S4 specifically includes the following contents:

[0073] Step S41: After parsing the registration request through the key generation mechanism, the administrator signature is obtained and verified;

[0074] Step S42: If the verification fails, the user's registration request is ignored; if the verification passes, the ABE master key and ABE public key stored locally are loaded through the key generation mechanism, and the ABE private key generation algorithm is called to generate an ABE private key for the user in combination with the user attribute set;

[0075] Step S43: Return the ABE private key to the user who initiated the registration request through a secure channel.

[0076] Step S5: Acquire and encrypt data in the building Internet of Things to obtain ciphertext data, and store the ciphertext data using a collaborative storage or on-chain storage method according to the data type to obtain a storage record;

[0077] Furthermore, step S5 specifically includes the following contents:

[0078] Step S51: obtaining data in the building Internet of Things through a data gateway and a server, and encrypting the data through a symmetric key to obtain ciphertext data;

[0079] Step S52: By parsing the configuration file, determine the subchain to which the data belongs and select on-chain storage or collaborative storage method to store the encrypted data according to the data type.

[0080] Specifically, step S52 includes:

[0081] Step S521: If the collaborative storage method is adopted, the IPFS interface is called to store the ciphertext data into the IPFS private network, and the returned IPFS storage address is obtained, and a storage record is constructed according to the IPFS storage address and the hash value of the original data; if the on-chain storage method is adopted, the ciphertext data is stored in the corresponding subchain, and a storage record is constructed according to the ciphertext data and the hash value of the original data;

[0082] Step S522: Call the data storage contract of the subchain to which the data belongs, and upload the storage record to the subchain.

[0083] Step S6: Initiate a data access request, obtain the user attribute hash set and the data type of the requested data by parsing the data access request, determine the subchain to which the requested data belongs according to the data type, and call the storage record acquisition contract of the subchain, verify whether the user attribute hash set meets the access policy through the storage record acquisition contract, and return the corresponding storage record and encryption key after verification;

[0084] Furthermore, step S6 also includes:

[0085] Step S61: Initiate a data access request to the backend server of the building Internet of Things system through the terminal, wherein the content of the data access request includes but is not limited to the user ID, user attribute hash set, data type to be requested, data query conditions, request time and timestamp.

[0086] Step S62: Obtain the access policy and private value hash corresponding to the data to be requested through the storage record acquisition contract;

[0087] Step S63: Obtain a verification private value according to the user attribute hash set, LSSS matrix and LSSS policy vector, and compare the hash value of the verification private value with the hash of the private value. If the comparison result is consistent, the user attribute hash set satisfies the access policy, and returns the storage record and encryption key corresponding to the requested data.

[0088] Step S7: According to the ABE private key generated by the user through the key generation mechanism, the ABE decryption algorithm is called to decrypt the encryption key to obtain the symmetric key, the symmetric key is used to decrypt the ciphertext data in the storage record, and the decrypted data is integrity checked. After the check passes, the data that can be used normally is obtained.

[0089] Furthermore, step S7 specifically includes the following contents:

[0090] Step S71: decrypting the encryption key by using the ABE decryption algorithm according to the ABE public key and the ABE private key to obtain a symmetric key, and using the symmetric key to decrypt the ciphertext data in the storage record;

[0091] Step S72: Perform a hash operation on the decrypted data to obtain the hash value of the decrypted data, and compare it with the hash value of the original data stored on the chain. If the comparison results are consistent, the data is complete.

[0092] Please refer to the following Figure 2 , Figure 3 The specific application process of this method is as follows:

[0093] This application provides a method for building IoT data management based on blockchain multi-chain and attribute encryption, which aims to reduce the storage pressure of blockchain nodes, improve the concurrent processing capability of blockchain networks, and realize data security sharing under the premise of implicitly recording access control policies on the chain. The flowchart of this method is as follows Figure 2 As shown, the specific steps include:

[0094] Step S1: Deploy the blockchain multi-chain network environment and the Interstellar File System (IPFS) environment, use multiple data gateways and cloud servers of the building IoT cluster as nodes of the blockchain network, call the multi-chain partitioning algorithm to divide the blockchain network into multiple sub-chains, write the correspondence between the sub-chains and the intelligent subsystems into the configuration file and store it locally on the gateway and server, and then use the cloud server as a node to build an IPFS private network.

[0095] Specifically, in step S1, the blockchain multi-chain network is a network environment constructed by multiple blockchains that can run independently, and Hyperledger Fabric is used to construct it in the application of the present invention.

[0096] Specifically, in step S1, IPFS is a distributed file storage system, and IPFS nodes are composed of servers. Data is stored in the form of files, and a unique hash value is generated through the file content to identify the file; after the data gateway regularly collects device data, it encrypts the data to be stored outside the chain according to the hybrid storage mechanism and stores it in IPFS, and stores the returned IPFS address in the corresponding subchain. IPFS is used to store IoT device data generated by building IoT scenarios, thereby reducing the storage and bandwidth pressure of the blockchain network.

[0097] Specifically, in step S1, the building Internet of Things includes but is not limited to various intelligent subsystems composed of equipment such as internal building lighting, monitoring, access control, and environmental monitoring. The intelligent subsystems include but are not limited to video monitoring systems, fire protection systems, building control systems, environmental monitoring systems, and / or access control systems.

[0098] It should be noted that each data gateway corresponds to one or more subsystems, and the gateway and the server together serve as nodes in the blockchain multi-chain network; the data gateway is responsible for collecting the equipment data (equipment operation information, external environment sampling information, fault alarm information, etc.) generated by the corresponding subsystem, and storing the data in IPFS (collaborative storage) or the corresponding subchain (on-chain storage) according to the hybrid storage mechanism;

[0099] The gateway / server acting as a blockchain node can be added to one or more sub-chains of the multi-chain network as a blockchain node, which needs to be considered comprehensively based on the scenario requirements and the computing and storage resources of the gateway / server. Since the server resources are sufficient, the server is added to each sub-chain as a blockchain node, storing all the data of the blockchain multi-chain network, and forming an IPFS private network with other server nodes. The server is also responsible for receiving and responding to user data requests.

[0100] Specifically, in step S1, the building Internet of Things cluster refers to a cluster consisting of one or more buildings or parks. The building Internet of Things includes multiple intelligent subsystems, and the number of devices in the subsystem and the amount of collected data vary greatly depending on the type of building;

[0101] Since the number distribution and sampling frequency of IoT devices in each intelligent subsystem in the building are different, the random sub-chain division method is likely to cause unbalanced load of the sub-chain, and it is difficult to effectively reduce the computing overhead of each edge node. To this end, this paper proposes a multi-chain division algorithm, which uses the number of devices and the amount of data generated in each subsystem in the building Internet of Things as the standard for load balancing of each sub-chain. The specific division steps are as follows:

[0102] Specifically, in step S1, the flowchart of the multi-chain partitioning algorithm is as follows: Figure 4 As shown, it includes the following steps:

[0103] Step 1: Input the number of intelligent subsystems N and the number of devices in each subsystem C i (i=1,2,…,N), and the number of subchains to be divided n(n <N)。

[0104] Specifically, in the step Step 1, the number of sub-chains n is set by the administrator of the blockchain network during initialization.

[0105] Step 2: Calculate the optimal mean value avg after sub-chain division = (C 1 +C 2 +…+C N ) / n, if C i >avg will be the intelligent subsystem System i It is divided into a separate sub-chain for management.

[0106] Step 3: Divide the remaining intelligent subsystems into sub-chains so that the variance σ 2 =(chain_C 1 -avg) 2 +(chain_C 2 -avg) 2 +…+(chain_C n -avg)2 Minimum, where chain_C i Indicates the total number of devices included in the subchain.

[0107] Specifically, in the step Step3, chain_C i That is, the cumulative number of subsystem devices added to the subchain.

[0108] It should be noted that, considering the system availability, the numerous devices within the intelligent subsystem are regarded as a whole and are only allowed to be divided into the same sub-chain, that is, an intelligent subsystem cannot be maintained by multiple sub-chains.

[0109] It should be noted that since the number of devices is positively correlated with the amount of data and the number of blockchain transactions, if the variance σ2 is minimized after division, it means that the number of devices maintained by each sub-chain tends to be consistent, thereby effectively balancing the transaction processing pressure of each sub-chain node.

[0110] Step 4: Output the number of sub-chains n after division and the set of intelligent subsystems contained in each sub-chain.

[0111] It should be noted that after the multi-chain division is completed, the data storage or data acquisition request initiated to the multi-chain network will eventually be unloaded to a specific sub-chain, and only the nodes of the sub-chain will process the request, and other nodes do not need to consume computing resources; at the same time, in this application, the computing pressure brought by processing high-concurrency requests can be unloaded to the nodes of each sub-chain more evenly, and the computing resources of each node can be fully and effectively utilized. Therefore, the data management method provided by this application can have good concurrent processing performance.

[0112] Specifically, in step S1, the content recorded in the configuration file includes but is not limited to: the number of sub-chains, the node information of each blockchain, the correspondence between the sub-chain and the intelligent subsystem, the data type and its storage method.

[0113] The node information includes but is not limited to the node number, the blockchain to which it belongs, the node IP address, and the node communication port number;

[0114] The corresponding relationship refers to the set of intelligent subsystems maintained by a subchain;

[0115] The data types include but are not limited to equipment operation information, external environment sampling information, equipment alarm information, equipment repair / maintenance information, and equipment control records;

[0116] The storage methods include on-chain storage and collaborative storage. The storage process will be described in step S6.

[0117] Specifically, in step S1, the IPFS private network means that the network can only be accessed by users of the building Internet of Things system and is not open to the public.

[0118] The users include but are not limited to enterprise employees, property personnel, operation and maintenance engineers and / or system administrators.

[0119] It should be noted that the data gateway here is only an abstract concept. It can be an actual gateway or a local or cloud server.

[0120] It should be noted that the data gateway and server must meet the memory and hard disk space required for deploying the Hyperledger Fabric blockchain and IPFS operating environment, otherwise the blockchain multi-chain network and / or IPFS network will not be able to operate normally.

[0121] S2: The key generation mechanism performs an initialization operation, randomly generates a security parameter λ, and calls the ABE initialization algorithm to generate the ABE master key (MK) and ABE public key (PK) according to λ.

[0122] Specifically, in step S2, the key generation agency is responsible for responding to the entity registration request and generating a private key for it. The key generation agency can be a trusted local server or cloud server.

[0123] The entities include, but are not limited to, data gateways, servers and / or users.

[0124] Specifically, in step S2, ABE refers to an attribute-based encryption algorithm. After the data owner encrypts the data using the ABE algorithm, only entities with specified attributes can decrypt the ciphertext and obtain the original data. This method can achieve fine-grained access control.

[0125] Specifically, in step S2, the ABE initialization algorithm is implemented by calling the CPABE library, inputting a random number λ, and outputting an ABE master key and an ABE public key.

[0126] It should be noted that the ABE master key is stored locally in the key generation agency and is used to generate the ABE private key for the entity; the ABE public key is publicly used for data encryption; and the ABE private key is stored locally in the entity and is used for data decryption.

[0127] S3: The data gateway (and / or server) sets different access policies P and symmetric keys Key for the data in the building Internet of Things, calls the ABE encryption algorithm according to the public key PK and policy P to encrypt the Key to obtain the encryption key C, sets the private value s, and generates the LSSS policy vector ρ according to the private value s and policy P.

[0128] Specifically, in step S3, the data in the building Internet of Things includes equipment monitoring data and equipment management information. The equipment monitoring data includes but is not limited to equipment operation information, external environment sampling information, and equipment alarm information, and the equipment management information includes but is not limited to equipment repair / maintenance information and equipment operation records.

[0129] The device operation information includes but is not limited to whether the device is turned on and the current parameters of the device;

[0130] The external environment sampling information includes but is not limited to indoor temperature and humidity, vehicle entry and exit records, and access control records;

[0131] The device control record refers to the operation log of the user initiating remote control commands to the device, including but not limited to device startup / shutdown and device parameter adjustment.

[0132] Specifically, in step S3, the access policy P represents the attributes required for the user to access the data, for example, P=(a1∧a2)∨(a1∧a3∧a4), which means that the user must have attributes a1, a2 or attributes a1, a3, a4 to access the data.

[0133] Specifically, in step S3, setting different access strategies means further classifying the data according to its data type, device location, device owner and / or intelligent subsystem, and setting corresponding access strategies for the segmented data according to the classification conditions to achieve fine-grained access control.

[0134] It should be noted that there is a one-to-one correspondence between access policies and symmetric keys, and data with different access policies have different symmetric keys for encryption and decryption.

[0135] Specifically, in step S3, the symmetric key can be generated by library functions such as aes and des. The implementation method of encrypting and decrypting data using the symmetric key is similar, which will not be repeated hereafter.

[0136] Specifically, in step S3, the ABE encryption algorithm is implemented by calling the CPABE library, taking the public key PK, the symmetric key Key and the access policy P as input, and outputting the encrypted symmetric key C.

[0137] Specifically, in step S3, the private value may be any real number, which is specified by the data gateway.

[0138] Specifically, in step S3, LSSS is a linear secret sharing scheme, which is more flexible in expressing access policies, can express any access policy, and has a flexible access structure.

[0139] Specifically, in step S3, the flowchart of the construction process of the LSSS strategy vector is as follows: Figure 5 As shown, the specific steps include:

[0140] Step 1: Split the attribute combination of access policy P into multiple sub-items that can satisfy the policy, and call the LSSS matrix construction algorithm to generate the matrix M mxn , where m represents the number of attributes in strategy P (including repeated attributes), n represents the minimum amount of calculation required by LSSS, and the value of n is calculated by the LSSS matrix construction algorithm.

[0141] Specifically, in the step Step 1, the attribute combination splitting process is as follows: suppose P = (a1∧a2)∨(a1∧a3∧a4), after splitting, two sub-items Pa = (a1∧a2), Pb = (a1∧a3∧a4) can be obtained. Satisfying any sub-item means satisfying the strategy P.

[0142] Specifically, in the step Step1, the LSSS matrix is ​​composed of the matrix M OR , and the matrix M AND The matrix construction rules are as follows:

[0143] (1) Any attribute is represented by a single-entry matrix M U =[1], there exists a matrix M a Represents strategy P a , use X a Represents the matrix M a The first column, Y a Represents the matrix M a Remove the first column from the rest of the columns. The matrix M b Same reason.

[0144] (2) For any or structure P = P a ∨P b , we can use the matrix M shown in formula 1) OR To represent the strategy P.

[0145]

[0146] (3) For any AND structure P = P a ∧P b , we can use the matrix M shown in formula 2) AND To represent the strategy P.

[0147]

[0148] According to rule (1), sub-strategy P a , P b can be expressed as ([1]∧[1]) and ([1]∧[1]∧[1]), respectively. Then, P=P is calculated according to rules (2) and (3). a ∨Pb The corresponding matrix M is shown below. The five rows of matrix M represent the calculation components of attributes a1, a2, a1, a3, and a4 respectively (attribute a1 corresponds to two rows of calculation components).

[0149]

[0150] Step 2: Based on the generated private value s, construct a random vector v = (s, r2, r3, ..., rn) T , where r2~rn are all random numbers.

[0151] Step 3: Multiply the matrix M and the random vector v to obtain the LSSS strategy vector ρ = M v = (p1, p2, ..., pm) T .

[0152] S4: The data gateway (and / or server) constructs an access policy record based on the encryption key C, LSSS policy vector ρ, private value hash and other information, and then calls the access policy storage contract of each subchain to store each access policy record in the subchain corresponding to the type of data being accessed.

[0153] Specifically, in step S4, the data structure of the access policy record is as shown in Table 1, including but not limited to encryption key, LSSS policy vector, LSSS matrix M, policy attribute hash set, private value hash, data type, upload time, and owner.

[0154] Table 1

[0155]

[0156] The policy attribute hash set is composed of multiple pairs of attribute names and attribute value hashes, and each pair of attributes corresponds to a row vector of the matrix M;

[0157] The owner is the entity that sets the access policy and uploads the record, and in this application refers to the data gateway and server.

[0158] Specifically, in step S4, the data storage contract and other smart contracts mentioned later in this application have been successfully installed in each sub-chain when the blockchain multi-chain network operating environment is initialized. The entity can call the smart contract through the SDK interface provided by the sub-chain to perform the corresponding function; the smart contracts mentioned later are similar to them and will not be repeated here.

[0159] Specifically, in step S4, the data type refers to the intelligent subsystem to which the data belongs, such as "access control system data", "monitoring system data", etc., and the subchain responsible for the data can be retrieved in combination with the local configuration file.

[0160] It should be noted that steps S3 and S4 in this application are only executed when the owner defines or modifies the access policy P for a certain type of data.

[0161] It should be noted that during the storage and subsequent use of access control policies (i.e., determining user permissions), the relevant attribute information is always presented in the form of hash values, thereby effectively preventing the leakage of policy information and user information.

[0162] S5: The user initiates a registration request to the key generation agency and receives the ABE private key returned by the key generation agency.

[0163] It should be noted that in this application, communication requests between entities are transmitted through HTTP requests, which will not be repeated in the following text. The IP, port number, communication rules and other information of the data gateway, server and key generation agency are shared during initialization.

[0164] It should be noted that step S5 is only performed when the entity registers for the first time.

[0165] Specifically, in step S5, the flow chart of the generation process of the ABE private key is as follows: Figure 6 As shown, the specific steps include:

[0166] Step 1: The key generation agency receives a registration request initiated by a user, gateway or other entity.

[0167] Specifically, in the step Step 1, the data structure of the registration request is as shown in Table 2, including but not limited to user ID, user attribute set, timestamp, registration time, and administrator signature.

[0168] Table 2

[0169] User ID User attribute collection Timestamp Registration Time Administrator Signature

[0170] The administrator signature refers to the signature of the system administrator using the private key on the result of splicing the first four fields. The key generation agency uses this field to determine whether the registration request is legal.

[0171] It should be noted that the system administrator identity is generated during initialization and its public key is public; the user's registration request needs to be approved and signed by the system administrator before being sent to the key generation agency, otherwise it will be regarded as an illegal user request and will be ignored.

[0172] Step 2: The key generation agency parses the registration request and verifies the signature of the system administrator. If the verification fails, the registration request of the entity is ignored.

[0173] Specifically, in the step Step 2, the verification method refers to using the public key of the system administrator to decrypt the signature, and comparing the decryption result with the string spliced ​​by the first four fields of Table 2. If they are equal, it means that the verification is passed, otherwise it means that the verification fails.

[0174] Step 3: If the verification passes, the key generation agency loads the locally stored master key MK and public key PK, combines the entity's attribute set A, and calls the ABE private key generation algorithm to generate an ABE private key for the entity.

[0175] Specifically, in the step Step 3, the ABE private key generation algorithm is implemented by calling the CPABE library, taking the master key MK, the public key PK and the user attribute set A as input, and outputting the user's ABE private key, which is used to decrypt data.

[0176] Step 4: The key generation agency returns the generated ABE private key to the request initiator through a secure channel.

[0177] Specifically, in the step Step 4, the secure channel means that the request initiator and the key generation agency both generate a public-private key pair for communication in advance and verify the authenticity of the public keys of both parties; then the key generation agency encrypts the ABE private key by the public key of the request initiator, and returns the encrypted ABE private key to the requester, and the requester uses its own communication private key to decrypt and obtain the original ABE private key.

[0178] S6: The data gateway and server obtain the device monitoring data and device management information from the device side and the user side respectively, and use the collaborative storage method or the on-chain storage method to store the data according to the data type.

[0179] Specifically, in step S6, the judgment and processing flow of the two storage methods are as follows: Figure 7 As shown, the following steps are included:

[0180] a) Encrypt data using the symmetric key Key;

[0181] It should be noted that since the gateway and server have set multiple access policies and symmetric keys for the data in the building Internet of Things, before encrypting the data, the gateway and server need to first load the corresponding symmetric key locally according to the classification of the data. The classification method has been described in detail in the previous article and will not be repeated here.

[0182] b) Parse the local configuration file to determine the subchain to which the data belongs and the corresponding storage method;

[0183] In response to the blockchain storage performance issues faced by existing building IoT data management methods, the present invention adopts a combination of on-chain storage and collaborative storage. For data with small volume, irregular data generation frequency, and need to be processed one by one, the on-chain storage method can be used to store it in the blockchain. For data with large volume, fixed data generation frequency, and batch processing, the collaborative storage method can be used to store it in the distributed IPFS network off-chain, and only the corresponding metadata is stored in the blockchain, thereby effectively reducing the storage requirements of the blockchain, and using IPFS to achieve reliable storage of off-chain data;

[0184] Specifically, in the step b), the judgment basis of the data storage method is as shown in Table 3. For data such as equipment management information and equipment alarm information whose data generation frequency is not fixed and needs to be processed one by one, the on-chain storage method is used for processing; for data such as equipment operation information and external environment sampling information whose data generation frequency is fixed and can be processed in batches, the collaborative storage method is used for processing.

[0185] Table 3

[0186]

[0187] c) Determine whether the storage method is "on-chain storage", if so, proceed to step f), otherwise proceed to step d);

[0188] d) Use the "collaborative storage method" to call the IPFS interface to store the ciphertext data into the IPFS network and obtain the returned IPFS storage address;

[0189] Specifically, in step d), the IPFS interface is implemented based on the add command of go-ipfs.

[0190] Specifically, in step d), the IPFS storage address refers to the unique hash value identifying the file storage address returned after the encrypted data file is stored in the IPFS private network.

[0191] e) Construct a storage record based on the IPFS storage address, original data hash value and other information, and then proceed to step g);

[0192] Specifically, in the step e), the data structure of the storage record is as shown in Table 4, including but not limited to storage method, ciphertext data, IPFS storage address, data type, original data hash value, and storage time.

[0193] Table 4

[0194] Storage Ciphertext data IPFS storage address Data Types Original data hash value Storage time

[0195] It should be noted that if the storage method is "on-chain storage", the field "IPFS storage address" is empty; conversely, if the storage method is "collaborative storage", the field "ciphertext data" is empty.

[0196] f) Using the “on-chain storage” method, the encrypted data is stored in the sub-chain, and the storage record is constructed based on the encrypted data, the hash value of the original data and other information;

[0197] g) Call the data storage contract of the destination subchain, upload the storage record to the destination subchain, and the process ends.

[0198] Specifically, in step g), the target subchain refers to the subchain responsible for maintaining the intelligent subsystem to which the data belongs, and the corresponding relationship between the intelligent subsystem and the subchain can be parsed in the local configuration file.

[0199] It should be noted that for data such as equipment operation information and external environment sampling information that are processed using the collaborative storage method, the gateway will set a collection frequency and regularly collect the above data in batches. The batch-collected data can be stored in a unified manner off-chain in the form of files using IPFS, and the chain only needs to store the corresponding data storage records, thereby significantly reducing the storage occupancy of the blockchain by the above data; and for data such as equipment management information and equipment alarm information, the generation frequency is not fixed (may be several seconds or minutes). In order to ensure data processing efficiency and availability, it is necessary to process and store them one by one when the data is generated. Under the above conditions, the storage occupancy of the blockchain by on-chain storage is similar to that of the collaborative storage method, but the storage and use efficiency is higher. Therefore, this application adopts the on-chain storage method to process these data.

[0200] S7: The user initiates a data access request to the backend server of the building Internet of Things system through a terminal. Specifically, in step S7, the terminal includes but is not limited to a PC, a mobile phone, and a tablet.

[0201] Specifically, in step S7, the data structure of the data access request is as shown in Table 5, including but not limited to user ID, user attribute hash set, data type to be requested, data query condition, request time, and timestamp.

[0202] Table 5

[0203] User ID User attribute hash collection The type of data to be requested Data query conditions Request time Timestamp

[0204] The user attribute hash set is similar to the policy attribute hash set, and is composed of multiple pairs of attribute names and attribute value hashes of users;

[0205] The data query condition is used to further determine the data content requested by the user. The field may be a time range, location, device type and / or device number.

[0206] S8: The server parses the user’s data access request, obtains the user attribute hash set and the data type to be requested, then parses the local configuration file, determines the subchain to which the data belongs based on the data type, and calls the storage record of the target subchain to obtain the contract.

[0207] Specifically, in step S8, the input parameters of the storage record acquisition contract include but are not limited to user ID, user attribute hash set, data type, and data query conditions.

[0208] It should be noted that data type and data type are two different ways of classifying data. Data type is used to determine the intelligent subsystem to which it belongs, and is used to divide and locate subchains, including but not limited to access control system data, monitoring system data, and energy system data; while data type is used to determine the storage method of data, including but not limited to equipment operation information, external environment sampling information, equipment alarm information, and equipment management information.

[0209] S9: The storage record obtains the user’s access rights within the contract, that is, verifies whether the user’s attribute hash set satisfies the LSSS access policy. After the verification, the corresponding storage record and encryption key C are returned to the server.

[0210] Specifically, in step S9, the flowchart of the verification process of the user access rights is as follows: Figure 8 As shown, the specific steps include:

[0211] Step 1: The storage record obtains the LSSS access policy ρ, policy attribute hash set and private value hash corresponding to the request data within the contract.

[0212] Step 2: Select the matching rows of LSSS matrix M according to the user's attribute hash set to form a new matrix M P , calculate the vector f such that f·M P =(1,0,...0).

[0213] Specifically, in the step Step 2, the row matching method is to calculate the intersection of the user attribute hash set and the policy attribute hash set, and one or more row vectors corresponding to the intersection are the matched rows.

[0214] Specifically, in the step Step2, the matrix M P It is a mapping of the user attribute set. Assuming that the user attribute set is (a1∧a2), the hash values ​​of a1 and a2 are matched with the matrix M. According to the matching rule, the first three rows of the matrix M constructed in step Step1 in S3 of this application are matched to form the matrix M. P , M P As shown below:

[0215]

[0216] Step 3: Select the LSSS strategy vector ρ and the matrix M P The corresponding components form a new vector ρ'. Multiplying the vector f and ρ' gives the private value s'.

[0217] Step 4: Compare the hash value of s' with the private value hash stored on the chain. If they are consistent, it means that the user's attribute hash set satisfies the access policy P and has access rights to the requested data.

[0218] It should be noted that since the data on the blockchain can be accessed by all internal nodes, in order to prevent the leakage of private values, only the private value hash is stored on the chain. After the private value s' is obtained, the hash is compared to determine whether the user meets the access policy P.

[0219] Specifically, in step S9, the corresponding storage records refer to all storage records in the destination subchain account book that are consistent with the data type in the data access request.

[0220] S10: The server determines the storage method based on the data type. If it is "on-chain storage", it means that the storage record is ciphertext data. If it is "collaborative storage", it parses and obtains the IPFS storage address in the storage record, obtains the ciphertext data from the IPFS private network, and returns the encryption key C, ciphertext data, and original data hash value to the user.

[0221] Specifically, in step S10, the ciphertext data is obtained through the get command of go-ipfs.

[0222] S11: The user uses his own ABE private key to call the ABE decryption algorithm to decrypt the encryption key C, obtains the original symmetric key Key, decrypts the ciphertext data, and verifies the integrity of the decrypted data based on the hash value of the original data. After the verification is passed, the user can use the data normally.

[0223] Specifically, in step S11, the ABE decryption algorithm is implemented by calling the CPABE library, taking the public key PK, the ABE private key and the encryption key C as input, and outputting the original symmetric key Key.

[0224] Specifically, in step S11, the ciphertext data decryption process is implemented by calling library functions such as aes and des, and the library functions must be consistent with those used in the symmetric encryption algorithm.

[0225] Specifically, in step S11, the integrity check refers to performing a hash operation on the decrypted data and comparing the hash operation result with the hash value of the original number stored on the chain. If they are consistent, it means that the ciphertext data returned by the server is complete, that is, the data content has not been tampered with.

[0226] It should be noted that in order to improve the efficiency of data access, the user will store the key locally after decrypting the symmetric key. When the user accesses the data again, the user will compare the obtained key with the locally stored key. If the comparison result is consistent, the ciphertext data will be directly decrypted using the locally stored symmetric key, skipping the ABE decryption process.

[0227] In order to further understand the content of the present invention, a more specific embodiment is given below. The following application embodiment is an example of a building access control data management method based on blockchain multi-chain and attribute encryption. Fig. 9 A schematic diagram of a model of a building access control data management method based on blockchain multi-chain and attribute encryption provided in an embodiment of the present application, Fig.10 A flow chart of a building access control data management method based on blockchain multi-chain and attribute encryption provided in an embodiment of the present application. Among them, the blockchain operating environment has been deployed inside the data gateway and the server, and the multi-chain partitioning algorithm is executed to construct 3 sub-chains. The relevant data of the access control system is divided into the sub-chain Chain_A for management according to the algorithm; the relevant configuration information of the multi-chain network has been saved inside the gateway and the server; the IPFS private network has been deployed and run in the server, which can store ciphertext data and obtain the ciphertext data content according to the IPFS storage address; the key generation mechanism has performed the initialization operation, generated the ABE master key, the ABE public key, and made the public key public. The embodiment of the present application includes the following steps:

[0228] S1: The data gateway sets an access policy P = ('system administrator' ∨ 'property staff' ∨ ('enterprise administrator' ∧ '14th floor')) for the access control data, generates a symmetric key Key locally, calls the ABE encryption algorithm based on the public key PK and policy P to encrypt the Key to obtain the encryption key C, sets the private value s to 2, and generates the LSSS policy vector ρ based on the private value s and policy P.

[0229] Specifically, in step S1, the meaning of the access policy P is that only the system administrator, the property manager, and the enterprise administrator working on the 14th floor have the right to access the data.

[0230] S2: The data gateway constructs an access policy record based on the encryption key C, LSSS policy vector ρ, private value hash and other information, parses the local configuration file, determines that the subchain to which the data belongs is Chain_A according to the data type, calls the access policy storage contract of Chain_A, and stores the access policy record in Chain_A.

[0231] S3: User1, the administrator of the 14th floor enterprise, initiates a registration request to the key generation agency and receives the returned ABE private key.

[0232] S4: The data gateway calls the data collection interface to collect access control data from the access control system on the 14th floor of the office building.

[0233] Specifically, in step S4, the access control data collected includes but is not limited to the following fields: personnel number, name, entry and exit direction, opening method, and access time.

[0234] S5: The data gateway determines that the data type is "external environment sampling information", adopts a collaborative storage method, uses the symmetric key Key to encrypt the access control data, and then calls the IPFS interface to upload the encrypted access control data to the IPFS private network, and obtains the storage address returned by IPFS.

[0235] S6: The data gateway constructs a storage record based on the IPFS storage address, the hash value of the original access control data, and other information, parses the local configuration file, determines that the subchain is Chain_A based on the data type "access control system data", calls the data storage contract of Chain_A, and uploads the storage record to the subchain Chain_A.

[0236] S7: User User1 initiates an access request for the access control data of the 14th floor to the background server of the building Internet of Things system through the terminal.

[0237] S8: The server parses the data access request of user User1, obtains the data type to be requested and the attribute hash set A = {role = 'hash(Enterprise Administrator)', location = 'hash(14th Floor)', ...} of user User1, parses the local configuration file, determines that the subchain to which it belongs is Chain_A according to the data type, and then calls the storage record of subchain Chain_A to obtain the contract.

[0238] Specifically, in step S8, the type of data to be requested is "access control system data".

[0239] Specifically, in step S8, the attribute hash set A includes two parts: an attribute name set {role, location, ...} and an attribute value hash set {hash(enterprise administrator), hash(14th floor), ...}.

[0240] Specifically, in step S8, the parameters passed into the storage record acquisition contract include user ID "User1", attribute hash set A, data type "access control system data", data query condition "location = '14L', dataContent = 'access record'", etc.

[0241] S9: The storage record obtains the access rights of the internal verification user User1 of the contract, that is, verifies whether its attribute hash set satisfies the LSSS access policy. After the verification is passed, the corresponding storage record and encryption key C are returned to the background server.

[0242] It should be noted that since the access control pass data is stored in a collaborative storage manner, the field "ciphertext data" in the storage record is empty, and the field "IPFS storage address" records the storage location of the data.

[0243] S10: The background server determines that the storage method is "collaborative storage" according to the data type "external environment sampling information", parses and obtains the IPFS storage address in the storage record, obtains the encrypted access control data from the IPFS private network, and returns the encryption key C, the encrypted access control data, and the hash value of the original access control data to user User1.

[0244] S11: User User1 uses the ABE private key to call the ABE decryption algorithm to decrypt the encryption key C, obtains the original key Key, decrypts the ciphertext data, and verifies the integrity of the decrypted data based on the hash value of the original access control data. After the verification is passed, the user can use the above data to analyze the monthly attendance of corporate employees and assist in predicting the company's economy.

[0245] Specifically, in step S11, the integrity check refers to calling the sha256() function to perform a hash operation on the decrypted data, and comparing the operation result with the hash value stored on the chain. If they are consistent, it means that the ciphertext data is complete and the data content has not been tampered with.

[0246] In summary, the beneficial effects of the present invention are:

[0247] (1) In view of the blockchain storage performance problem faced by the existing building IoT data management methods, the present invention adopts two methods: on-chain storage and collaborative storage. For data with small volume, irregular data generation frequency, and need to be processed one by one, the on-chain storage method can be used to store it in the blockchain. For data with large volume, fixed data generation frequency, and batch processing, the collaborative storage method can be used to store it in the distributed IPFS network off-chain, and only the corresponding metadata is stored in the blockchain, thereby effectively reducing the storage requirements of the blockchain and using IPFS to achieve reliable storage of off-chain data.

[0248] (2) In view of the low concurrency problem of blockchain networks faced by the existing technologies, and considering that the number of devices in each intelligent subsystem in the building Internet of Things is positively correlated with the amount of data generated and the number of blockchain transactions, the present invention designs a multi-chain partitioning algorithm to divide the subsystem data into different sub-chains for maintenance according to the distribution of the number of devices, so that the blockchain transactions to be processed by each sub-chain tend to be consistent. Storage or query requests initiated to the blockchain network will be forwarded to a specific sub-chain in the network for processing. The computing pressure brought by processing high-concurrency requests can be unloaded to the nodes of each sub-chain more evenly, thereby making full use of the computing resources of each node and improving the concurrent processing capability of the blockchain network.

[0249] (3) In view of the insecure access control policy recording method faced by the prior art when combining attribute encryption with blockchain, the present invention, based on the prior art, uses smart contracts and linear secret sharing schemes (i.e., LSSS) to store access control policies and policy attributes in the form of matrices and hash values ​​(rather than explicit attribute values) on the blockchain, and determines user access rights through matrix operations, thereby achieving secure recording and effective verification of access control policies. At the same time, the present invention combines attribute encryption with linear secret sharing schemes, so that the conceived technical solution can have the characteristics of fine-grained access control, "one-to-many" data security sharing, and policy security recording.

[0250] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0251] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. Building IoT data management method based on blockchain multi-chain and attribute encryption, It is characterized in that include: Network construction steps: Use the gateway and cloud server of the building IoT cluster to build a blockchain network and an IPFS private network, and call the multi-chain partitioning algorithm to divide the blockchain network into multiple sub-chains, and store the corresponding relationship between each sub-chain and each intelligent subsystem of the building IoT; Access strategy setting step: using the key generation mechanism to call the ABE initialization algorithm to generate the ABE master key and the ABE public key, setting different access strategies and symmetric keys for different data in the building Internet of Things, calling the ABE encryption algorithm according to the ABE public key and the access strategy to encrypt the symmetric key to obtain an encryption key, and setting a private value, and generating an LSSS strategy vector according to the private value and the access strategy; Access policy storage step: construct access policy records for different data according to the encryption key, LSSS policy vector and private value hash, and store each access policy record in the subchain corresponding to the data type by calling the access policy storage contract of each subchain; Data storage step: obtaining data in the building Internet of Things and encrypting it to obtain ciphertext data, and storing the ciphertext data using a collaborative storage or on-chain storage method according to the data type to obtain a storage record; Data request step: Initiate a data access request, obtain the user attribute hash set and the data type of the requested data by parsing the data access request, determine the subchain to which the requested data belongs according to the data type, and call the storage record acquisition contract of the subchain, verify whether the user attribute hash set meets the access policy through the storage record acquisition contract, and return the corresponding storage record and encryption key after verification; Data decryption step: according to the ABE private key generated by the user through the key generation mechanism, call the ABE decryption algorithm to decrypt the encryption key, obtain the symmetric key, use the symmetric key to decrypt the ciphertext data in the storage record, and perform integrity check on the decrypted data. After the check passes, the data that can be used normally is obtained.

2. The building Internet of Things data management method according to claim 1, It is characterized in that The network construction step includes: dividing the blockchain network into multiple sub-chains according to the number of the intelligent subsystems, the number of devices in each intelligent subsystem, and the number of sub-chains to be divided, and writing the correspondence between the sub-chains and the intelligent subsystems into a configuration file, and storing the configuration file in the gateway and the server.

3. The building Internet of Things data management method according to claim 1, It is characterized in that The access policy setting step includes: Initialization step: randomly generating a security parameter by initializing the key generation mechanism, and calling the ABE initialization algorithm according to the security parameter to generate the ABE master key and the ABE public key; Symmetric key generation step: classify the data in the building Internet of Things according to the data type, device location, device owner and intelligent subsystem as classification conditions, and set corresponding access policies and symmetric keys corresponding to the access policies for the classified data according to the classification conditions; LSSS matrix generation step: split the attribute combination of the access policy into multiple sub-items that can satisfy the access policy, and call the LSSS matrix construction algorithm to generate the LSSS matrix; LSSS strategy vector acquisition step: construct a random vector according to the private value, and multiply the LSSS matrix and the random vector to obtain the LSSS strategy vector.

4. The building Internet of Things data management method according to claim 1, It is characterized in that Also includes: Steps for obtaining the ABE private key: When a user registers for the first time, a registration request is initiated to a key generation agency, and the key generation agency generates an ABE private key based on the registration request and returns it to the user. The content of the registration request includes but is not limited to user ID, user attribute set, timestamp, registration time and administrator signature.

5. The building Internet of Things data management method according to claim 4, It is characterized in that The ABE private key acquisition step includes: Administrator signature verification step: after parsing the registration request through the key generation mechanism, obtaining and verifying the administrator signature; ABE private key generation step: if the verification fails, the user's registration request is ignored; if the verification passes, the ABE master key and ABE public key stored locally are loaded through the key generation mechanism, combined with the user attribute set, and the ABE private key generation algorithm is called to generate an ABE private key for the user; ABE private key return step: return the ABE private key to the user who initiated the registration request through a secure channel.

6. The building Internet of Things data management method according to claim 2, It is characterized in that The data storage step comprises: Data encryption step: obtaining data in the building Internet of Things through a data gateway and a server, encrypting the data through a symmetric key, and obtaining ciphertext data; Storage step: By parsing the configuration file, determine the subchain to which the data belongs and select on-chain storage or collaborative storage to store the encrypted data according to the data type.

7. The building Internet of Things data management method according to claim 6, It is characterized in that The storing step comprises: Storage record construction step: if the collaborative storage method is adopted, the IPFS interface is called to store the ciphertext data into the IPFS private network, and the returned IPFS storage address is obtained, and the storage record is constructed according to the IPFS storage address and the hash value of the original data; if the on-chain storage method is adopted, the ciphertext data is stored in the corresponding subchain, and the storage record is constructed according to the ciphertext data and the hash value of the original data; Storage record uploading step: calling the data storage contract of the subchain to which the data belongs, and uploading the storage record to the subchain.

8. The building Internet of Things data management method according to claim 1, It is characterized in that The data request step includes: initiating a data access request to the background server of the building Internet of Things system through the terminal, and the content of the data access request includes the user ID, the user attribute hash set, the type of data to be requested, the data query condition, the request time and the timestamp.

9. The building Internet of Things data management method according to claim 8, It is characterized in that The data request step further includes: Access policy acquisition step: obtain the access policy and private value hash corresponding to the data to be requested through the storage record acquisition contract; Authority verification step: obtain the verification private value according to the user attribute hash set, LSSS matrix and LSSS policy vector, compare the hash value of the verification private value with the hash of the private value, if the comparison result is consistent, the user attribute hash set satisfies the access policy, and returns the storage record and encryption key corresponding to the requested data.

10. The building Internet of Things data management method according to claim 9, It is characterized in that The data decryption step comprises: Decryption step: decrypting the encryption key by using the ABE decryption algorithm according to the ABE public key and the ABE private key to obtain a symmetric key, and using the symmetric key to decrypt the ciphertext data in the storage record; Integrity verification step: perform a hash operation on the decrypted data to obtain the hash value of the decrypted data, and compare it with the hash value of the original data stored on the chain. If the comparison results are consistent, the data is complete.

Images