CN115459901A

CN115459901A - Building Internet of things data management method based on block chain multi-chain and attribute encryption

Info

Publication number: CN115459901A
Application number: CN202210893136.4A
Authority: CN
Inventors: 王旭; 郑文虎; 范增良; 牟伟; 华清波; 王金龙; 熊晓芸
Original assignee: Qingdao E Link Information Technology Co ltd
Current assignee: Qingdao E Link Information Technology Co ltd
Priority date: 2022-07-27
Filing date: 2022-07-27
Publication date: 2022-12-09

Abstract

The invention discloses a building Internet of things data management method based on block chain multi-chain and attribute encryption, which comprises the following steps: the method comprises the steps that a block chain network and an IPFS private network are built by utilizing a gateway and a cloud server of a building Internet of things cluster, and a multi-chain division algorithm is called to divide the block chain network into a plurality of sub-chains; the method also comprehensively adopts two modes of on-chain storage and collaborative storage, and different storage methods are adopted for different types of data, so that the storage requirement of the block chain is effectively reduced, and the reliable storage of the data under the chain is realized by utilizing IPFS.

Description

Building Internet of things data management method based on block chain multi-chain and attribute encryption

Technical Field

The invention relates to the technical field of block chains, in particular to a building Internet of things data management method based on block chain multi-chain and attribute encryption.

Background

The blockchain is a distrust-free and centralization-free distributed ledger technology, and once data is uploaded to the blockchain through verification of a blockchain node, the data is permanently stored and cannot be tampered. Due to the characteristics of decentralized storage, data non-falsification and the like, the block chain can effectively solve the problems of single-point failure and third-party data trust, and the safety and reliability of the data are guaranteed. Once the concept of the block chain is provided, the block chain is widely applied to a plurality of fields, and meanwhile, researchers at home and abroad have conducted more researches on the application of the block chain in the scene of the Internet of things of the building, so that the credible storage of data is realized, and the equipment management and the building operation and maintenance management of the Internet of things are realized by using an intelligent contract of the block chain.

With the continuous development of the internet of things technology, the number of internet of things equipment in the building internet of things is gradually increased, and the data acquisition amount is continuously increased. Due to the characteristics of the full storage and log type recording modes of the block chain, data of the block chain link points can be continuously accumulated along with time, and the existing research scheme faces the storage performance challenge of the block chain; in addition, the above studies store the collected data in plaintext form on the blockchain, and lack privacy protection means.

In order to solve the above problems, a patent with application publication number CN111914269a discloses a method and a system for data secure sharing in a block chain and cloud storage environment, where original data is stored in the cloud environment under the chain, and only corresponding metadata is stored on the chain, so as to reduce the storage pressure of the block chain and implement data secure sharing based on an attribute encryption scheme. However, a single-point fault hidden danger exists in a down-link centralized cloud storage mode, if a cloud server fails, the normal operation of the whole system is affected, and the data reliability is poor. Therefore, a patent with application publication number CN114065261a discloses a distributed trusted data sharing platform, method and system based on a block chain, and the distributed trusted data storage under the chain is realized by using IPFS.

However, although the above existing method adopts a chain uplink and downlink cooperative storage manner to reduce the storage pressure of the block chain and implement data security sharing based on an encryption algorithm, many challenges still exist. On one hand, the existing method generally adopts a single blockchain to perform data management, and a transaction request initiated to a blockchain network needs to be processed by all blockchain link points together so as to achieve consensus on data contents in transaction and realize consistent storage; meanwhile, the continuous expansion of the scale of the building internet of things requires that a blockchain network has high request concurrency processing capacity, and due to the inherent serialized account book writing operation characteristic of a blockchain data structure, nodes need to spend computing resources to serialize blocks containing batch transactions, so that the throughput performance of the existing single-chain-based data management method is difficult to meet the concurrency processing requirement of the scene of the building internet of things. On the other hand, in the data management method based on the block chain partially, when the attribute encryption scheme is used for protecting data privacy, the access control policy is selected to be stored on the block chain in a clear text mode, and the policy attribute and the user information are hidden in the leakage due to the explicit storage of the policy.

Generally, the internet of things equipment in the scene of the internet of things of the building has the characteristics of high deployment density, large sampling data volume and the like, and if the data is directly stored in a block chain, great challenges are brought to the storage performance of a block chain network; meanwhile, due to the public and transparent characteristics of the block chain, the data privacy leakage problem can be caused by the data plaintext storage mode. In the prior art, a corresponding chain uplink and downlink collaborative storage scheme and an attribute encryption scheme are designed to solve the problems, but because a single block chain is generally adopted for data management, the throughput performance of the block chain is difficult to meet the concurrent processing requirement of the scene of the building internet of things; in addition, in the prior art, when the attribute encryption scheme is used for protecting data privacy, the access control policy is explicitly stored on the block chain in a plaintext form, and hidden dangers of leakage of policy attributes and user information exist.

Therefore, how to provide a building internet of things data management method, which reduces the storage pressure of the blockchain nodes, improves the concurrent processing capacity of the blockchain network, and realizes data security sharing on the premise of implicitly recording an access control strategy on a chain becomes a problem to be solved urgently.

Disclosure of Invention

Aiming at the problems that the block chain network storage in the prior art is poor in concurrency processing capability and the strategy and the user information are easy to leak, the invention provides a building internet of things data management method based on block chain multi-chain and attribute encryption, which comprises the following steps:

a network construction step: building a block chain network and an IPFS private network by using a gateway and a cloud server of a building Internet of things cluster, calling a multi-chain division algorithm to divide the block chain network into a plurality of sub-chains, and storing the corresponding relation between each sub-chain and each intelligent subsystem of the building Internet of things;

an access policy setting step: calling an ABE initialization algorithm by using a key generation mechanism to generate an ABE main key and an ABE public key, setting different access strategies and symmetric keys for different data in the building Internet of things, calling an ABE encryption algorithm according to the ABE public key and the access strategies to encrypt the symmetric keys to obtain encryption keys, setting a private value, and generating an LSSS policy vector according to the private value and the access strategies;

an access strategy storage step: constructing access policy records for different data according to the encryption key, the LSSS policy vector and the private value hash, and storing each access policy record into a sub-chain corresponding to the data type by calling an access policy storage contract of each sub-chain;

a data storage step: acquiring data in the building Internet of things, encrypting the data to obtain ciphertext data, and storing the ciphertext data by adopting a collaborative storage or chain storage method according to the data type to obtain a storage record;

a data request step: initiating a data access request, acquiring a user attribute hash set and the data type of data to be requested by analyzing the data access request, judging a sub-chain to which the data to be requested belongs according to the data type, calling a storage record of the sub-chain to acquire a contract, verifying whether the user attribute hash set meets the access strategy or not through the storage record acquisition contract, and returning a corresponding storage record and an encryption key after the verification is passed;

data decryption: and calling an ABE decryption algorithm to decrypt the encrypted key according to an ABE private key generated by a user through a key generation mechanism to obtain a symmetric key, decrypting the ciphertext data in the storage record by using the symmetric key, performing integrity check on the decrypted data, and obtaining data which can be normally used after the check is passed.

The building Internet of things data management method comprises the following network construction steps: and dividing the block chain network into a plurality of sub chains according to the number of the intelligent subsystems, the number of devices in each intelligent subsystem and the number of the sub chains to be divided, writing the corresponding relation between the sub chains and the intelligent subsystems into a configuration file, and storing the configuration file into a gateway and a server.

The building internet of things data management method comprises the following access policy setting steps:

an initialization step: randomly generating a security parameter by initializing a key generation mechanism, and calling an ABE initialization algorithm according to the security parameter to generate the ABE main key and the ABE public key;

a symmetric key generation step: classifying data in the building Internet of things according to data types, equipment positions, equipment attributions and intelligent sub-systems as classification conditions, and setting corresponding access strategies and symmetric keys corresponding to the access strategies for the classified data according to the classification conditions;

LSSS matrix generation: splitting the attribute combination of the access strategy into a plurality of sub-items which can meet the access strategy, and calling an LSSS matrix construction algorithm to generate an LSSS matrix;

LSSS strategy vector obtaining step: and constructing a random vector according to the private value, and multiplying the LSSS matrix by the random vector to obtain the LSSS strategy vector.

The building internet of things data management method further comprises the following steps:

obtaining an ABE private key: when a user registers for the first time, a registration request is sent to a key generation mechanism, the key generation mechanism generates an ABE private key according to the registration request and returns the ABE private key to the user, wherein the content of the registration request comprises but is not limited to a user ID, a user attribute set, a timestamp, registration time and an administrator signature.

The building internet of things data management method comprises the following steps of:

and (3) verifying the signature of the administrator: after the registration request is analyzed by the key generation mechanism, the signature of the administrator is obtained and verified;

ABE private key generation step: if the verification is not passed, ignoring the registration request of the user; if the verification is passed, loading the locally stored ABE main key and the locally stored ABE public key through a key generation mechanism, and calling an ABE private key generation algorithm to generate an ABE private key for the user by combining a user attribute set;

and an ABE private key returning step: returning the ABE private key to a user initiating a registration request over a secure channel.

The building internet of things data management method comprises the following data storage steps:

data encryption: acquiring 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;

a storage step: and judging the sub-chain to which the data belongs by analyzing the configuration file, and selecting a method for storing on-chain or cooperatively storing according to the data type to store the ciphertext data.

The building Internet of things data management method comprises the following storage steps:

a storage record construction step: if a cooperative storage method is adopted, an IPFS interface is called to store the ciphertext data into the IPFS private network, a 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 method of chain storage is adopted, the ciphertext data is stored into the corresponding sub chain, and a storage record is constructed according to the ciphertext data and the original data hash value;

a storage record uploading step: and calling a data storage contract of the sub-chain to which the data belongs, and uploading the storage record to the sub-chain.

The building internet of things data management method comprises the following data request steps: the method comprises the steps that a data access request is sent to a background server of the building Internet of things system through a terminal, and the content of the data access request comprises but is not limited to a user ID, a user attribute hash set, a data type to be requested, a data query condition, a request time and a time stamp.

The building internet of things data management method comprises the following steps of requesting data;

an access policy acquisition step: acquiring an access strategy and a private value hash corresponding to the data to be requested by a contract through a storage record;

and (3) permission verification step: and obtaining a check private value according to the user attribute hash set, the LSSS matrix and the LSSS strategy vector, comparing the hash value of the check private value with the private value hash, if the comparison result is consistent, the user attribute hash set meets the access strategy, and returning a storage record and an encryption key corresponding to the data to be requested.

The building internet of things data management method comprises the following data decryption steps:

and (3) decryption: decrypting the encryption key through an ABE decryption algorithm according to the ABE public key and the ABE private key to obtain a symmetric key, and decrypting the ciphertext data in the storage record by using the symmetric key;

and (3) integrity checking: and carrying out hash operation on the decrypted data to obtain a hash value of the decrypted data, comparing the hash value with the hash value of the original data stored on the chain, and if the comparison result is consistent, the data is complete.

Compared with the prior art, the invention has the advantages and positive effects that:

1. aiming at the problem of block chain storage performance of the existing building Internet of things data management method, the invention comprehensively adopts two modes of on-chain storage and collaborative storage. For data which is small in size, unfixed in data generation frequency and needs to be processed one by one, an on-chain storage mode can be adopted to store the data in a block chain. For data which is large in size, fixed in data generation frequency and capable of being processed in batches, a collaborative storage mode can be adopted, the data is stored in a distributed IPFS network under a chain, and corresponding metadata is only stored in a block chain, so that the storage requirement of the block chain is effectively reduced, and the reliable storage of the data under the chain is realized by utilizing the IPFS;

2. aiming at the problem of low concurrency of a blockchain network in the prior art, considering that the equipment quantity of each intelligent subsystem in a building internet is in positive correlation with the data generation quantity and the blockchain transaction quantity, the invention designs a multi-chain division algorithm, divides the subsystem data into different sub-chains for maintenance according to the equipment quantity distribution condition, and enables the blockchain transactions required to be processed by each sub-chain to tend to be consistent. Storage or query requests initiated to the blockchain network are forwarded to a specific sub-chain in the network for processing, and the computing pressure brought by processing high concurrent requests can be more evenly unloaded to the nodes of each sub-chain, so that the computing resources of each node are fully utilized, and the concurrent processing capacity of the blockchain network is improved;

3. aiming at the problem that the access control strategy recording mode is unsafe when attribute encryption and a block chain are combined in the prior art, the access control strategy and the strategy attribute are respectively stored on the block chain in the form of a matrix and a hash value (instead of an explicit attribute value) by utilizing an intelligent contract and a linear secret sharing scheme (namely LSSS) on the basis of the prior art, and the access authority of a user is judged through a matrix operation mode, so that the safe recording and the effective verification of the access control strategy are realized. Meanwhile, the invention combines the attribute encryption and the linear secret sharing scheme, so that the technical scheme of the invention can have the characteristics of fine-grained access control, one-to-many data secure sharing, strategy secure recording and the like.

Drawings

Fig. 1 is a schematic step diagram of a building internet of things data management method based on block chain multi-chain and attribute encryption according to an embodiment of the present application;

fig. 2 is a schematic flow chart of a building internet of things data management method based on block chain multi-chain and attribute encryption according to the embodiment of the present application;

fig. 3 is a block chain and IPFS-based architecture diagram of a building internet of things data management system according to an embodiment of the present disclosure;

fig. 4 is a schematic flowchart of a multi-chain division algorithm provided in an embodiment of the present application;

fig. 5 is a schematic diagram of a LSSS policy vector construction process provided in an embodiment of the present application;

fig. 6 is a schematic flowchart of a key generation mechanism generating an entity ABE private key according to an embodiment of the present application;

FIG. 7 is a flowchart illustrating the determination and processing of two data storage methods according to an embodiment of the present disclosure;

FIG. 8 is a schematic flowchart of verifying a user access right according to an embodiment of the present disclosure;

fig. 9 is a schematic model diagram of a building access control traffic data management method based on block chain multi-chain and attribute encryption according to an embodiment of the present application;

fig. 10 is a schematic flow chart of the building access control traffic data management method based on block chain multi-chain and attribute encryption according to the embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of and not restrictive on the broad application. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments provided in the present application without any inventive step are within the scope of protection of the present application.

It is obvious that the drawings in the following description are only examples or embodiments of the present application, and that it is also possible for a person skilled in the art to apply the present application to other similar contexts on the basis of these drawings without inventive effort. Moreover, it should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another.

Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the specification. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is to be expressly and implicitly understood by one of ordinary skill in the art that the embodiments described herein may be combined with other embodiments without conflict.

Unless otherwise defined, technical or scientific terms referred to herein should have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. Reference to "a," "an," "the," and similar words throughout this application are not to be construed as limiting in number, and may refer to the singular or the plural. The present application is directed to the use of the terms "including," "comprising," "having," and any variations thereof, which are intended to cover non-exclusive inclusions; for example, a process, method, system, article, or apparatus that comprises a list of steps or modules (elements) is not limited to the listed steps or elements, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. Reference to "connected," "coupled," and the like in this application is not intended to be limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The term "plurality" as referred to herein means two or more. "and/or" describes the association relationship of the associated object, indicating that there may be three relationships, for example, "a and/or B" may indicate: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. Reference herein to the terms "first," "second," "third," and the like, are merely to distinguish similar objects and do not denote a particular ordering for the objects.

The present invention is described in detail with reference to the embodiments shown in the drawings, but it should be understood that these embodiments are not intended to limit the present invention, and those skilled in the art should understand that functional, methodological, or structural equivalents or substitutions made by these embodiments are within the scope of the present invention.

The first embodiment is as follows:

fig. 1 is a schematic step diagram of a building internet of things data management method based on block chain multi-chain and attribute encryption according to an embodiment of the present application. As shown in fig. 1, this embodiment discloses a specific implementation of a building internet of things data management method (hereinafter referred to as "method") based on block chain multi-chain and attribute encryption.

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

step S1: building a block chain network and an IPFS private network by using a gateway and a cloud server of a building Internet of things cluster, calling a multi-chain division algorithm to divide the block chain network into a plurality of sub-chains, and storing the corresponding relation between each sub-chain and each intelligent subsystem of the building Internet of things;

wherein, step S1 specifically includes: and dividing the block chain network into a plurality of sub chains according to the number of the intelligent subsystems, the number of devices in each intelligent subsystem and the number of the sub chains to be divided, writing the corresponding relation between the sub chains and the intelligent subsystems into a configuration file, and storing the configuration file into a gateway and a server.

Step S2: calling an ABE initialization algorithm by using a key generation mechanism to generate an ABE main key and an ABE public key, setting different access strategies and symmetric keys for different data in the building Internet of things, calling an ABE encryption algorithm according to the ABE public key and the access strategies to encrypt the symmetric keys to obtain encryption keys, setting a private value, and generating an LSSS policy vector according to the private value and the access strategies;

further, step S2 specifically includes the following steps:

step S21: randomly generating a security parameter by initializing a key generation mechanism, and calling an ABE initialization algorithm according to the security parameter to generate the ABE main key and the ABE public key;

step S22: classifying data in the building Internet of things according to data types, equipment positions, equipment affiliations and intelligent subsystems as classification conditions, and setting corresponding access strategies and symmetric keys corresponding to the access strategies for the classified data according to the classification conditions;

step S23: splitting the attribute combination of the access strategy into a plurality of sub-items which can meet the access strategy, and calling an LSSS matrix construction algorithm to generate an LSSS matrix;

step S24: and constructing a random vector according to the private value, and multiplying the LSSS matrix and the random vector to obtain the LSSS strategy vector.

And step S3: constructing access strategy records for different data according to the encryption key, the LSSS strategy vector and the private value hash, and storing each access strategy record into a sub-chain corresponding to the data type by calling an access strategy storage contract of each sub-chain;

and step S4: when a user registers for the first time, a registration request is sent to a key generation mechanism, the key generation mechanism generates an ABE private key according to the registration request and returns the ABE private key to the user, wherein the content of the registration request comprises but is not limited to a user ID, a user attribute set, a timestamp, registration time and an administrator signature.

Further, step S4 specifically includes the following contents;

step S41: after the registration request is analyzed by the key generation mechanism, the signature of the administrator is obtained and verified;

step S42: if the verification is not passed, ignoring the registration request of the user; if the verification is passed, loading the locally stored ABE main key and the locally stored ABE public key through a key generation mechanism, and calling an ABE private key generation algorithm to generate an ABE private key for the user by combining a user attribute set;

step S43: returning the ABE private key to a user initiating a registration request over a secure channel.

Step S5: acquiring data in the building Internet of things, encrypting the data to obtain ciphertext data, and storing the ciphertext data by adopting a cooperative storage method or a chain storage method according to the data type to obtain a storage record;

further, step S5 specifically includes the following steps:

step S51: acquiring 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;

step S52: and judging the sub-chain to which the data belongs by analyzing the configuration file, and selecting a method for storing on-chain or cooperatively storing according to the data type to store the ciphertext data.

Specifically, step S52 includes;

step S521: if a cooperative storage method is adopted, an IPFS interface is called to store the ciphertext data into the IPFS private network, a returned IPFS storage address is obtained, and a storage record is constructed according to the IPFS storage address and the original data hash value; if a chain storage method is adopted, the ciphertext data are stored into the corresponding sub chain, and a storage record is constructed according to the ciphertext data and the original data hash value;

step S522: and calling a data storage contract of the sub-chain to which the data belongs, and uploading the storage record to the sub-chain.

Step S6: initiating a data access request, acquiring a user attribute hash set and a data type of data to be requested by analyzing the data access request, judging a sub-chain to which the data to be requested belongs according to the data type, calling a storage record acquisition contract of the sub-chain, verifying whether the user attribute hash set meets the access strategy or not through the storage record acquisition contract, and returning a corresponding storage record and an encryption key after the verification is passed;

further, step S6 further includes:

step S61: the method comprises the steps that a data access request is sent to a background server of the building Internet of things system through a terminal, and the content of the data access request comprises but is not limited to a user ID, a user attribute hash set, a data type to be requested, a data query condition, a request time and a time stamp.

Step S62: acquiring an access strategy and a private value hash corresponding to the data to be requested by a contract through a storage record;

step S63: and obtaining a check private value according to the user attribute hash set, the LSSS matrix and the LSSS strategy vector, comparing the hash value of the check private value with the private value hash, if the comparison result is consistent, the user attribute hash set meets the access strategy, and returning a storage record and an encryption key corresponding to the data to be requested.

Step S7: and calling an ABE decryption algorithm to decrypt the encrypted key according to an ABE private key generated by a user through a key generation mechanism to obtain a symmetric key, decrypting the ciphertext data in the storage record by using the symmetric key, performing integrity check on the decrypted data, and obtaining data which can be normally used after the check is passed.

Further, step S7 specifically includes the following steps:

step S71: decrypting the encryption key through an ABE decryption algorithm according to the ABE public key and the ABE private key to obtain a symmetric key, and decrypting the ciphertext data in the storage record by using the symmetric key;

step S72: and carrying out hash operation on the decrypted data to obtain a hash value of the decrypted data, comparing the hash value with the hash value of the original data stored on the chain, and if the comparison result is consistent, the data is complete.

Referring to fig. 2 and fig. 3, the following application flow of the method is specifically described:

the application provides a building Internet of things data management method based on block chain multi-chain and attribute encryption, and aims to reduce the storage pressure of block chain nodes, improve the concurrent processing capacity of a block chain network and realize data security sharing on the premise of implicitly recording an access control strategy on a chain. The flow chart of the method is shown in fig. 2, and specifically comprises the following steps:

step S1: the method comprises the steps of deploying a block chain multi-chain network environment and an interplanetary file system (IPFS) environment, using a plurality of data gateways and a cloud server of a building Internet of things cluster as nodes of the block chain network, calling a multi-chain division algorithm to divide the block chain network into a plurality of sub-chains, writing the corresponding relation between the sub-chains and an intelligent subsystem into a configuration file and storing the configuration file to the local of the gateways and the server, and then using the cloud server as the nodes to construct an IPFS private network.

Specifically, in step S1, the blockchain multi-link network is a network environment constructed by a plurality of independently operable blockchains, and is constructed by using a hyper hedger Fabric in the present application.

Specifically, in step S1, the IPFS is a distributed file storage system, and the IPFS nodes are formed by servers. Storing data in a file form, and generating a unique hash value through file content to identify a file; after the data gateway collects the equipment data regularly, the data needing to be stored outside the chain is encrypted according to a mixed storage mechanism and then stored in the IPFS, and the returned IPFS address is stored in the corresponding subchain. The IPFS is used for storing Internet of things equipment data generated in the building Internet of things scene, so that the storage and bandwidth pressure of a block chain network is relieved.

Specifically, in step S1, the building internet of things includes, but is not limited to, various intelligent subsystems formed by devices for building interior lighting, monitoring, entrance guard, environment monitoring, and the like. The intelligent subsystem includes but is not limited to a video monitoring system, a fire fighting system, a building control system, an environment monitoring system and/or an entrance and exit control system.

It should be noted that each data gateway corresponds to one or more subsystems, and the gateway and the server are used together as a constituent node of the block chain multi-link network; the data gateway is responsible for acquiring equipment data (equipment operation information, external environment sampling information, fault alarm information and the like) generated by the corresponding subsystem, and storing the data into an IPFS (cooperative storage) or a corresponding subchain (on-chain storage) according to a hybrid storage mechanism;

the gateway/server serving as the block link node can be added to one or more sub-chains of the multi-chain network as the block link node, and needs to be considered comprehensively according to the scene requirements and the computing and storage resources of the gateway/server; the server is used as a block chain node to be added into each sub-chain as the resource of the server is sufficient, all data of the block chain multi-chain network are stored, and an IPFS private network is formed by the server and other server nodes; the server is also responsible for receiving and responding to data requests of users.

Specifically, in step S1, the building internet of things cluster refers to a cluster formed by one or more buildings and parks. The building Internet of things comprises a plurality of intelligent subsystems, and the number of devices and the data acquisition amount in the subsystems are greatly different according to different building types;

due to the fact that the quantity distribution and sampling frequency of the internet of things equipment in the building in each intelligent subsystem are different, the load of the sub chains is unbalanced easily due to the random sub chain dividing mode, and the calculation cost of each edge node is difficult to reduce effectively. Therefore, a multi-chain division algorithm is provided, and the number of devices and the generated data volume of each subsystem in the building internet of things are used as the standard of load balancing of each sub-chain. The specific division steps are as follows:

specifically, in step S1, a flow diagram of the multi-chain division algorithm is shown in fig. 4, and includes the following steps:

step1: input intelligent subsystemNumber of systems N, number of devices C of each subsystem _i (i =1,2, …, N), and the number of child chains to be divided N (N)<N)。

Specifically, in Step1, the number n of child chains is set by an administrator of the blockchain network at the time of initialization.

Step2: calculating the optimal average value avg = (C) after the subchain is divided ₁ +C ₂ +…+C _N ) N, if C _i >avg then will the intelligent subsystem System _i And the management is carried out by dividing the sub-chains into one sub-chain.

Step3: the remaining intelligent subsystems are sub-divided such that the variance σ is ₂ ＝(chain_C ₁ -avg) ₂ +(chain_C ₂ -avg) ₂ +…+(chain_C _n -avg) ₂ Minimum, where chain _ C _i Indicating the total number of devices contained within the child chain.

Specifically, in Step3, chain _ C _i I.e., the sum of the number of subsystem devices joining the child chain.

It should be added that, in consideration of system availability, the plurality of devices in 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 a plurality of sub-chains.

It should be added that, since the number of devices has a positive correlation with the data volume and the transaction number of the blockchain, if the variance σ 2 after the division is minimum, 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.

Step4: and outputting the number n of the divided sub-chains and an intelligent subsystem set contained in each sub-chain.

It should be added that after the multi-chain division is completed, the data storage or data acquisition request initiated to the multi-chain network is finally unloaded to a specific sub-chain, and only the node of the sub-chain processes the request, while other nodes do not need to consume computing resources; meanwhile, in the application, the computing pressure brought by processing the high concurrent requests can be more evenly unloaded to the nodes of each sub-chain, and the computing resources of each node can be fully and effectively utilized. Therefore, the data management method provided by the application can have better concurrent processing performance.

Specifically, in step S1, the content recorded by the configuration file includes, but is not limited to: the number of the sub chains, the node information of each block chain, the corresponding relation between the sub chains and the intelligent subsystem, the data type and the storage mode of the sub chains and the intelligent subsystem.

The node information comprises but is not limited to a node number, a belonging block chain, a node IP address and a node communication port number;

the corresponding relation refers to an intelligent subsystem set which is responsible for maintenance of a certain sub-chain;

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

the storage mode includes two types of on-chain storage and collaborative storage, and the storage flow will be described in step S6.

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.

Including, but not limited to, enterprise employees, property personnel, operation and maintenance engineers, and/or system administrators.

It should be noted that the data gateway is only an abstract concept, and may be an actual gateway, or a local or cloud server.

It should be noted that the data gateway and the server must satisfy the memory and hard disk space necessary for deploying the hyper-hedgehog Fabric blockchain and the IPFS operating environment, otherwise, the blockchain multi-link network and/or the IPFS network cannot be normally operated.

S2: the key generation mechanism performs initialization operation, randomly generates a security parameter lambda, and calls an ABE initialization algorithm to generate an ABE master key (i.e., MK) and an ABE public key (i.e., PK) according to lambda.

Specifically, in step S2, the key generation mechanism is responsible for responding to the entity registration request and generating a private key for the entity registration request, and the key generation mechanism may be assumed by a trusted local server or a cloud server.

Including but not limited to data gateways, servers, and/or users.

Specifically, in step S2, the ABE refers to an attribute-based encryption algorithm, and after the data owner encrypts the data using the ABE, only the entity having the specified attribute can decrypt the ciphertext and obtain the original data.

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

It should be added that the ABE master key is stored locally in the key generation mechanism and used for generating an ABE private key for the entity; the ABE public key is used for data encryption; the ABE private key is stored locally at the entity for data decryption.

S3: the data gateway (and/or the server) sets different access strategies P and symmetric keys Key for data in the building Internet of things, calls an ABE encryption algorithm to encrypt Key according to a public Key PK and the strategies P to obtain an encryption Key C, sets a secret value s, and generates an LSSS strategy vector rho according to the secret value s and the strategies P.

Specifically, in step S3, the data in the building internet of things includes device monitoring data and device management information. The device monitoring data includes, but is not limited to, device operation information, external environment sampling information, and device alarm information, and the device management information includes, but is not limited to, device repair/maintenance information, and device operation records.

The device operation information includes but is not limited to whether the device is turned on or not, and current parameters of the device;

the external environment sampling information comprises but is not limited to indoor temperature and humidity, vehicle access records and entrance guard passage records;

the device control record refers to an operation log of a user initiating a remote control command to the device, including but not limited to device start/stop and device parameter adjustment.

Specifically, in step S3, the access policy P represents the attribute required by the user to access the data, such as P = (a 1 ^ a 2) (a 1 ^ a3 ^ a 4), which indicates that the user needs to possess the attribute a1, a2 or the attribute a1, a3, a4 to access the data.

Specifically, in step S3, setting different access policies means further classifying the data according to the data type, the location of the device, the device attribution party, and/or the belonging intelligent subsystem, and setting a corresponding access policy for the subdivided data according to the classification condition, so as to implement fine-grained access control.

It should be noted that the access policy and the symmetric key are in a one-to-one correspondence relationship, and data with different access policies has different symmetric keys for encryption and decryption.

Specifically, in step S3, the symmetric key may be generated through aes, des, and other library functions, and the implementation manner of encrypting and decrypting data using the symmetric key is the same, which is not described in detail later.

Specifically, in step S3, the ABE encryption algorithm is implemented by calling a CPABE library, and the public Key PK, the symmetric Key, and the access policy P are used as inputs, and the encrypted symmetric Key C is output.

Specifically, in step S3, the secret value may be any real number and is specified by the data gateway.

Specifically, in step S3, the LSSS is a linear secret sharing scheme, which is more flexible in terms of access policy expression, can express any access policy, and has a flexible access structure.

Specifically, in step S3, a flow diagram of a construction process of the LSSS policy vector is shown in fig. 5, and specifically includes the following steps:

step1: splitting the attribute combination of the access policy P into a plurality of sub-items which can meet the policy, and calling an LSSS matrix construction algorithm to generate a matrix M _mxn Where m represents the number of attributes (including duplicate attributes) within policy P, n represents the minimum amount of computation required for LSSS, and the value of n is computed by the LSSS matrix construction algorithm.

Specifically, in Step1, the attribute combining and splitting process is as follows: let P = (a 1a 2) (^ a3 a 4), after splitting, two sub-items Pa = (a 1a 2), pb = (a 1a 3 a 4) can be obtained, and any sub-item can satisfy the strategy P.

Specifically, in Step1, the LSSS matrix is composed of an or matrix M _OR And matrix M _AND The matrix construction rule is as follows:

(1) Either attribute is represented as a single-order matrix M _U ＝[1]Existence matrix M _a Representation strategy P _a By X _a Representation matrix M _a First row of (A), Y _a Representation matrix M _a The other columns of the first column are removed. Matrix M _b The same is true.

(2) For arbitrary or structure P = P _a ∨P _b The matrix M shown in formula 1) can be used _OR To represent the policy P.

(3) For arbitrary and structure P = P _a ∧P _b The matrix M shown in formula 2) can be used _AND To represent the policy P.

According to rule (1), sub-policy P _a ，P _b Can be respectively represented as ([ 1 ]]∧[1]) And ([ 1 ]]∧[1]∧[1]) Then P = P is calculated from rule (2) and rule (3) _a ∨P _b The corresponding matrix M, which is shown below. The five rows of the matrix M represent the calculated components of the attributes a1, a2, a1, a3, a4, respectively (attribute a1 corresponds to two rows of calculated components).

Step2: constructing a random vector v = (s, r2, r3, …, rn) according to the generated secret value s ^T Wherein r2 to rn are random numbers.

Step3: will matrix MMultiplying the random vector v to obtain the strategy vector rho = M.v = (p 1, p2, …, pm) of LSSS ^T 。

S4: the data gateway (and/or the server) constructs access policy records according to the encryption key C, LSSS policy vector rho, the secret value hash and other information, then calls an access policy storage contract of each sub-chain, and stores each access policy record into the sub-chain corresponding to the accessed data type.

Specifically, in step S4, the data structure of the access policy record is shown in table 1, and includes, but is not limited to, an encryption key, an LSSS policy vector, an LSSS matrix M, a policy attribute hash set, a secret value hash, a data type, an upload time, and an owner.

TABLE 1

The strategy attribute hash set is composed of a plurality of pairs of attribute names and attribute value hashes, and each pair of attributes corresponds to a row vector of the matrix M;

the owner, i.e. the entity that sets the access policy and uploads the record, is referred to in this application as data gateway and server.

Specifically, in step S4, the data storage contract and other intelligent contracts mentioned later in this application have been successfully installed in each child chain when initializing the block chain multi-chain network operating environment, and the entity may invoke the intelligent contract through an SDK interface provided by the child chain to perform a corresponding function; the smart contracts mentioned later are similar to the above and will not be described in detail.

Specifically, in step S4, the data type refers to an intelligent subsystem to which the data belongs, such as "door access system data", "monitoring system data", and the like, and the sub-chain responsible for the data can be retrieved by combining with the local configuration file.

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

It should be added that, in the storage and subsequent use (i.e. determining the user right) of the access control policy, the relevant attribute information is always presented in the form of a hash value, thereby effectively preventing the leakage of the policy information and the user information.

S5: the user initiates a registration request to the key generation mechanism and receives an ABE private key returned by the key generation mechanism.

It should be noted that, in the present application, the communication requests between the entities are all transmitted by means of HTTP requests, and are not described in detail later. Information such as IP, port numbers, communication rules, etc. of the data gateway, server, and key generation mechanism are shared at initialization.

It should be noted that step S5 is only executed when the entity is first registered.

Specifically, in step S5, a flowchart of a generation process of the ABE private key is shown in fig. 6, and specifically includes the following steps:

step1: the key generation mechanism receives a registration request initiated by an entity such as a user, a gateway, etc.

Specifically, in Step1, the data structure of the registration request is shown in table 2, including but not limited to a user ID, a user attribute set, a timestamp, a registration time, and an administrator signature.

TABLE 2

User ID

User attribute collection

Time stamp

Registration time

Administrator signatures

The administrator signature is the signature of the result after the system administrator uses the private key to splice the first four fields, and the key generation mechanism judges whether the registration request is legal or not through the fields.

It should be noted that, the system administrator identity is generated at initialization, and the public key thereof is public; the registration request of the user needs to be approved by a system administrator in advance and then sent to the key generation mechanism, otherwise, the registration request is regarded as an illegal user request and is ignored and not processed.

Step2: the key generation mechanism analyzes the registration request, verifies the signature of the system administrator, and ignores the registration request of the entity if the verification fails.

Specifically, in Step2, the verification mode refers to that the public key of the system administrator is used to perform a signature release operation on the signature, the signature release result is compared with the character strings spliced by the first four fields in table 2, if the result is equal, the verification is passed, otherwise, the verification is not passed.

Step3: if the verification is passed, the key generation mechanism loads the locally stored master key MK and the public key PK, and invokes an ABE private key generation algorithm to generate an ABE private key for the entity by combining the attribute set A of the entity.

Specifically, in Step3, the ABE private key generation algorithm is implemented by calling the CPABE library, and the user ABE private key is output by taking the master key MK, the public key PK and the user attribute set a as input, and the private key is used for decrypting data.

Step4: the key generation mechanism returns the generated ABE private key to the request initiator through a secure channel.

Specifically, in Step4, the secure channel refers to that both the request initiator and the key generation mechanism generate a public-private key pair for communication in advance, and verify the authenticity of the public keys of both parties; and then the key generation mechanism encrypts the ABE private key through the public key of the request initiator, returns the encrypted ABE private key to the request initiator, and decrypts by using the communication private key of the request initiator to obtain the original ABE private key.

S6: the data gateway and the server respectively acquire the equipment monitoring data and the equipment management information from the equipment side and the user side, and perform data storage by adopting a collaborative storage method or a chain storage method according to the data type.

Specifically, in step S6, the flow of determining and processing two storage manners is shown in fig. 7, and includes the following steps:

a) Encrypting the data by using a symmetric Key;

it should be added that, because the gateway and the server set multiple access policies and symmetric keys for data in the building internet of things, before encrypting the data, the gateway and the server need to load the corresponding symmetric keys locally according to the classification of the data, and the classification manner is described in detail in the foregoing, and is not described again.

b) Analyzing a local configuration file, and judging a sub chain to which the data belongs and a corresponding storage method;

aiming at the problem of block chain storage performance of the existing building Internet of things data management method, the invention comprehensively adopts two modes of on-chain storage and collaborative storage. For data which is small in size, unfixed in data generation frequency and needs to be processed one by one, an on-chain storage mode can be adopted to store the data in a block chain. For data which is large in size, fixed in data generation frequency and capable of being processed in batches, a collaborative storage mode can be adopted, the data is stored in a distributed IPFS network under a chain, and corresponding metadata is only stored in a block chain, so that the storage requirement of the block chain is effectively reduced, and the reliable storage of the data under the chain is realized by utilizing the IPFS;

specifically, in the step b), the judgment of the data storage method is based on that as shown in table 3, the data such as the device management information and the device alarm information which are generated by the data and have unfixed frequency and need to be processed one by one are processed by using the on-chain storage method; and processing data such as equipment operation information and external environment sampling information which have fixed data generation frequency and can be processed in batches by adopting a collaborative storage method.

TABLE 3

c) Judging whether the storage method is 'storage on chain', if so, turning to the step f), and otherwise, turning to the step d);

d) Calling an IPFS interface to store ciphertext data into an IPFS network by adopting a 'cooperative storage mode', and acquiring a returned IPFS storage address;

specifically, in the step d), the IPFS interface is implemented based on an add command of go-IPFS.

Specifically, in step d), the storage address of the IPFS refers to a unique hash value that identifies the storage address of the file and is returned after the encrypted data file is stored in the IPFS private network.

e) Constructing a storage record according to information such as IPFS (Internet protocol file system) storage address, original data hash value and the like, and then turning to step g);

specifically, in step e), the data structure of the storage record is shown in table 4, and includes, but is not limited to, a storage mode, ciphertext data, an IPFS storage address, a data type, a hash value of the original data, and a storage time.

TABLE 4

Storage mode

Ciphertext data

IPFS storage address

Data type

Raw data hash value

Storage time

It should be added that, if the storage mode is "store on chain", the field "IPFS storage address" is empty; on the contrary, if the storage mode is 'cooperative storage', the field 'ciphertext data' is empty.

f) Storing the ciphertext data into the subchain in a chain storage mode, and constructing a storage record according to the ciphertext data, the original data hash value and other information;

g) And calling a data storage contract of the target sub-chain, uploading the storage record to the target sub-chain, and ending the process.

Specifically, in the step g), the destination sub-chain is a sub-chain responsible for maintaining the intelligent sub-system to which the data belongs, and the correspondence between the intelligent sub-system and the sub-chain can be analyzed in the local configuration file.

It should be added that, for example, the data processed by the collaborative storage method such as the device operation information, the external environment sampling information, etc. the inside of the gateway may set the collection frequency and periodically collect the data in batches, the data collected in batches may be stored uniformly under the chain in the form of a file by using the IPFS, and only the corresponding data storage records need to be stored on the chain, thereby significantly reducing the storage occupation of the block chain by the data; for data such as equipment management information and equipment alarm information, the generation frequency is not fixed (possibly several seconds and several minutes), and in order to ensure the efficiency and the availability of data processing, the data needs to be processed and stored item by item when being generated.

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

Specifically, in step S7, the data structure of the data access request is shown in table 5, and includes, but is not limited to, a user ID, a user attribute hash set, a data type to be requested, a data query condition, a request time, and a timestamp.

TABLE 5

User ID

User attribute hash sets

Data type to be requested

Data query conditions

Time of request

Time stamp

The user attribute hash set is similar to the strategy attribute hash set and consists of a plurality of pairs of attribute names and attribute value hashes of users;

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

S8: the server analyzes the data access request of the user, acquires the user attribute hash set and the data type to be requested, then analyzes the local configuration file, judges the sub-chain to which the user attribute hash set belongs according to the data type, and calls the storage record of the target sub-chain to acquire the contract.

Specifically, in step S8, the incoming parameters of the storage record acquisition contract include, but are not limited to, a user ID, a user attribute hash set, a data category, and a data query condition.

It should be added that the data type and the data type are two different classification ways for the data. The data type is the judgment of the intelligent subsystem to which the data type belongs, and is used for dividing and positioning the subchains, including but not limited to access control system data, monitoring system data and energy system data; and the data type is used for judging the storage mode of the data, including but not limited to equipment operation information, external environment sampling information, equipment alarm information and equipment management information.

S9: and the storage record obtains the access authority of the user verified in the contract, namely, whether the attribute hash set of the user meets the LSSS access strategy is verified, and the corresponding storage record and the encryption key C are returned to the server after the verification is passed.

Specifically, in step S9, a schematic flow chart of a process of verifying the user access right is shown in fig. 8, and specifically includes the following steps:

step1: and storing, recording and acquiring LSSS access strategy rho, strategy attribute hash set and private value hash corresponding to the request data in the contract.

Step2: selecting the rows matched with the LSSS matrix M according to the attribute hash set of the user to form a new matrix M _P Calculating the vector f such that f.M _P ＝(1,0,...0)。

Specifically, in Step2, a row matching manner is to calculate an 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 row.

Specifically, in Step2, the matrix M _P The method is used for mapping a user attribute set, the attribute set of a user is assumed to be (a 1 ^ a 2), hash values of a1 and a2 are matched with a matrix M, and the first three rows of the matrix M constructed in the Step1 in the application S3 are matched according to a matching rule to form the matrix M _P ，M _P As follows:

step3: selecting a neutralization matrix M in the LSSS policy vector rho _P The corresponding components form a new vector ρ ', and the vector f is multiplied by ρ ' to obtain a secret value s '.

Step4: and comparing the hash value of s' with the hash of the private value stored in the chain, and if the hash values are consistent, the attribute hash set representing the user meets the access policy P and has the access authority of the requested data.

It should be noted that, since data on the blockchain can be accessed by all internal nodes, in order to prevent the leakage of the secret value, only the hash of the secret value is stored on the chain, and after the secret value s' is obtained, the hash is compared to determine whether the user satisfies the access policy P.

Specifically, in step S9, the corresponding storage records are all storage records in the destination sub-chain account book that are consistent with the data type in the data access request.

S10: the server judges a storage method according to the data type, if the storage method is 'chain storage', the storage record is represented as ciphertext data, if the storage method is 'cooperative storage', the IPFS storage address in the storage record is analyzed and obtained, the ciphertext data are obtained from the IPFS private network, and the encryption key C, the ciphertext data and the original data hash value are returned to the user.

Specifically, in step S10, the ciphertext data may be obtained by a get command of go-ipfs.

S11: and the user calls an ABE decryption algorithm to decrypt the encryption Key C by virtue of the own ABE private Key, decrypts the ciphertext data after acquiring the original symmetric Key Key, verifies the integrity of the decrypted data according to the hash value of the original data, and can normally use the data after the verification is passed.

Specifically, in step S11, the ABE decryption algorithm is implemented by calling a CPABE library, and the public Key PK, the ABE private Key, and the encryption Key C are used as inputs, and the original symmetric Key is output.

Specifically, in step S11, the ciphertext data decryption process is implemented by calling the ae library function, the des library function, and the like, and the corresponding library function needs to be used in the symmetric encryption algorithm.

Specifically, in step S11, the integrity check refers to performing hash operation on the decrypted data, and comparing the hash operation result with the hash value of the original number stored in the chain, and if the hash operation result is consistent with the hash value of the original number stored in the chain, the ciphertext data returned by the server is complete, that is, the data content is not tampered.

It should be noted that, in order to improve the access efficiency of data, after decrypting the symmetric Key, the user stores the Key locally, when the subsequent user accesses the data again, the user compares the acquired Key with the locally stored Key first, and if the comparison result is consistent, the user directly decrypts the ciphertext data by using the locally stored symmetric Key, and skips the ABE decryption process.

In order to further understand the present disclosure, more specific examples are given below. The following application embodiments are examples of building access control traffic data management methods based on block chain multi-chain and attribute encryption, fig. 9 is a model schematic diagram of a building access control traffic data management method based on block chain multi-chain and attribute encryption provided by the embodiment of the application, and fig. 10 is a flow schematic diagram of a building access control traffic data management method based on block chain multi-chain and attribute encryption provided by the embodiment of the application. The access control system comprises a data gateway and a server, wherein a block Chain running environment is deployed in the data gateway and the server, a multi-Chain division algorithm is executed to construct 3 sub-chains, and related data of the access control system are divided into the sub-chains Chain _ A to be managed according to the algorithm; the related configuration information of the multi-link network is stored in the gateway and the server; the server is provided with and runs an IPFS private network, and can store ciphertext data and acquire ciphertext data contents according to an IPFS storage address; the key generation mechanism has performed initialization operations, generates an ABE master key, an ABE public key, and publishes the public key. The embodiment of the application comprises the following steps:

s1: the data gateway sets an access strategy P for access control data (a ' system administrator ' V-shaped ' property personnel ' V-shaped (an enterprise administrator ' A '14 building ')), locally generates a symmetric Key Key, calls an ABE encryption algorithm to encrypt the Key according to a public Key PK and a strategy P to obtain an encryption Key C, sets a secret value s to be 2, and generates an LSSS strategy vector rho according to the secret value s and the strategy P.

Specifically, in step S1, the meaning of the access policy P is: only system administrators, property owners, and enterprise administrators working at the 14 th floor have access to the data.

S2: the data gateway constructs an access strategy record according to information such as the encryption key C, LSSS strategy vector rho and private value hash, analyzes a local configuration file, judges the sub-Chain to be Chain _ A according to the data type, calls an access strategy storage contract of Chain _ A, and stores the access strategy record into Chain _ A.

S3: the administrator User1 of the 14-floor enterprise initiates a registration request to the key generation organization and receives the returned ABE private key.

S4: and the data gateway calls a data acquisition interface to acquire access control passing data from an access control system of 14-th building of the office building.

Specifically, in step S4, the acquired entrance guard passing data includes, but is not limited to, the following fields: personnel number, name, access direction, opening mode and transit time.

S5: and the data gateway judges the data type to be external environment sampling information, encrypts the access control passing data by using a symmetric Key Key by adopting a cooperative storage method, then calls an IPFS interface to upload the ciphertext access control passing data to an IPFS private network, and acquires a storage address returned by the IPFS.

S6: the data gateway constructs a storage record according to information such as an IPFS (Internet protocol file system) storage address and an original access control passing data hash value, analyzes a local configuration file, judges that the sub-Chain is Chain _ A according to the data type 'access control system data', calls a data storage contract of Chain _ A, and uploads the storage record to the sub-Chain _ A.

S7: and the User1 initiates an access request of 14-building entrance guard access data to a background server of the building Internet of things system through the terminal.

S8: the server analyzes the data access request of the User1, obtains the data type to be requested and an attribute hash set A = { role = 'hash (enterprise administrator)', location = 'hash (14 th)', } of the User1, analyzes a local configuration file, judges that the sub-Chain to which the server belongs is Chain _ A according to the data type, and then calls a storage record of the sub-Chain _ A to obtain a contract.

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

Specifically, in step S8, the attribute hash set a includes two parts: a set of attribute names { role, location,. } and a set of attribute value hashes { hash (enterprise administrator), hash (14 th floor), }.

Specifically, in the step S8, the parameters of the incoming storage record acquisition contract include a User ID "User1", a property hash set a, a data type "access control system data", a data query condition "location = '14L', a data content = 'access record'," and the like.

S9: and the storage record obtains the access authority of the contract internal verification User1, namely, whether the attribute hash set meets the LSSS access strategy is verified, and the corresponding storage record and the encryption key C are returned to the background server after the verification is passed.

It should be noted that, since the access control passage data is stored in a cooperative storage manner, the field "ciphertext data" in the storage record is null, and the field "IPFS storage address" records the storage location of the data.

S10: the background server judges that the storage method is 'cooperative storage' according to the data type 'external environment sampling information', analyzes and acquires an IPFS storage address in a storage record, acquires ciphertext access control passing data from an IPFS private network, and returns an encryption key C, the ciphertext access control passing data and the original access control passing data hash value to the User1.

S11: the User1 calls an ABE decryption algorithm to decrypt the encryption Key C by means of an ABE private Key, decrypts ciphertext data after acquiring an original Key Key, verifies the integrity of the decrypted data according to the hash value of the original entrance guard passing data, and can use the data to analyze the working and monthly attendance of enterprise personnel and assist in predicting the economy of enterprises and the like after verification.

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 in the chain, where if the operation result is consistent with the hash value stored in the chain, it indicates that the ciphertext data is complete, and the data content is not tampered.

In conclusion, the beneficial effects of the invention are as follows:

(1) Aiming at the problem of block chain storage performance of the existing building Internet of things data management method, the invention comprehensively adopts two modes of on-chain storage and collaborative storage. For data which is small in size, unfixed in data generation frequency and needs to be processed one by one, an on-chain storage mode can be adopted to store the data in a block chain. For data which is large in size, fixed in data generation frequency and capable of being processed in batches, a collaborative storage mode can be adopted, the data is stored in a distributed IPFS network under a chain, and corresponding metadata are stored only in a block chain, so that the storage requirement of the block chain is effectively reduced, and the reliable storage of the data under the chain is realized by utilizing the IPFS.

(2) Aiming at the problem of low concurrency of a blockchain network in the prior art, considering that the equipment quantity of each intelligent subsystem in a building internet is in positive correlation with the data generation quantity and the blockchain transaction quantity, the invention designs a multi-chain division algorithm, divides the subsystem data into different sub-chains for maintenance according to the equipment quantity distribution condition, and enables the blockchain transactions required to be processed by each sub-chain to tend to be consistent. The storage or query request initiated to the block chain network is forwarded to a specific subchain in the network for processing, and the computing pressure brought by processing high concurrent requests can be relatively averagely unloaded to the nodes of each subchain, so that the computing resources of each node are fully utilized, and the concurrent processing capability of the block chain network is improved.

(3) Aiming at the problem that the access control strategy recording mode is unsafe when attribute encryption and a block chain are combined in the prior art, the access control strategy and the strategy attribute are respectively stored on the block chain in the form of a matrix and a hash value (instead of an explicit attribute value) by utilizing an intelligent contract and a linear secret sharing scheme (namely LSSS) on the basis of the prior art, and the access authority of a user is judged through a matrix operation mode, so that the safe recording and the effective verification of the access control strategy are realized. Meanwhile, the invention combines the attribute encryption and the linear secret sharing scheme, so that the conceived technical scheme can have the characteristics of fine-grained access control, one-to-many data security sharing, policy security recording and the like.

The technical features of the embodiments described above may be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the embodiments described above are not described, but should be considered as being within the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. The building Internet of things data management method based on block chain multi-chain and attribute encryption is characterized by comprising the following steps:

an access policy storage step: constructing access policy records for different data according to the encryption key, the LSSS policy vector and the private value hash, and storing each access policy record into a sub-chain corresponding to the data type by calling an access policy storage contract of each sub-chain;

a data request step: initiating a data access request, acquiring a user attribute hash set and a data type of data to be requested by analyzing the data access request, judging a sub-chain to which the data to be requested belongs according to the data type, calling a storage record acquisition contract of the sub-chain, verifying whether the user attribute hash set meets the access strategy or not through the storage record acquisition contract, and returning a corresponding storage record and an encryption key after the verification is passed;

data decryption: and calling an ABE decryption algorithm to decrypt the encryption key according to an ABE private key generated by a user through a key generation mechanism to obtain a symmetric key, decrypting the ciphertext data in the storage record by using the symmetric key, performing integrity check on the decrypted data, and obtaining the data which can be normally used after the integrity check is passed.

2. The building internet of things data management method according to claim 1, wherein the network construction step comprises: and dividing the block chain network into a plurality of sub chains according to the number of the intelligent subsystems, the number of devices in each intelligent subsystem and the number of the sub chains to be divided, writing the corresponding relation between the sub chains and the intelligent subsystems into a configuration file, and storing the configuration file into a gateway and a server.

3. The building internet of things data management method according to claim 1, wherein the access policy setting step comprises:

a symmetric key generation step: classifying data in the building Internet of things according to data types, equipment positions, equipment affiliations and intelligent subsystems as classification conditions, and setting corresponding access strategies and symmetric keys corresponding to the access strategies for the classified data according to the classification conditions;

LSSS matrix generation step: splitting the attribute combination of the access strategy into a plurality of sub-items which can meet the access strategy, and calling an LSSS matrix construction algorithm to generate an LSSS matrix;

LSSS strategy vector obtaining step: and constructing a random vector according to the private value, and multiplying 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, further comprising:

5. The building internet of things data management method of claim 4, wherein the ABE private key obtaining step comprises:

ABE private key generation step: if the verification is not passed, ignoring the registration request of the user; if the verification is passed, loading the locally stored ABE master key and the ABE public key through a key generation mechanism, and calling an ABE private key generation algorithm to generate an ABE private key for the user by combining a user attribute set;

and returning the ABE private key: returning the ABE private key to a user initiating a registration request over a secure channel.

6. The building internet of things data management method according to claim 2, wherein the data storage step comprises the following steps:

a data encryption step: acquiring 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;

7. The building internet of things data management method according to claim 6, wherein the storing step comprises:

8. The building internet of things data management method according to claim 1, wherein the data requesting step comprises: the method comprises the steps that a data access request is sent to a background server of the building Internet of things system through a terminal, and the content of the data access request comprises but is not limited to a user ID, a user attribute hash set, the data type of a request, a data query condition, request time and a time stamp.

9. The building internet of things data management method of claim 8, wherein the data requesting step further comprises:

10. The building internet of things data management method according to claim 9, wherein the data decryption step comprises: