CN115459901B

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

Info

Publication number: CN115459901B
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: 2025-06-06
Anticipated expiration: 2042-07-27
Also published as: CN115459901A

Abstract

The invention discloses a block chain multi-chain and attribute encryption-based building networking data management method, which comprises the steps of constructing a block chain network and a IPFS private network by utilizing a gateway and a cloud server of a building networking cluster, and calling a multi-chain dividing algorithm 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 adopts different storage methods aiming at different types of data, thereby effectively reducing the storage requirement of the block chain and realizing the reliable storage of the data under the chain by IPFS.

Description

Building networking data management method based on blockchain multi-chain and attribute encryption

Technical Field

The invention relates to the technical field of blockchains, in particular to a building networking data management method based on blockchain multi-chain and attribute encryption.

Background

Blockchains are a distributed ledger technique that de-signals and de-centers, and once data is uploaded to the blockchain through the verification of the blockchain node, it is permanently stored and cannot be tampered with. Due to the characteristics of decentralization storage, non-falsification of data and the like, the blockchain can effectively solve the problems of single-point failure and third-party data trust, and ensure the safety and reliability of data. Once the concept of the blockchain is proposed, the blockchain is widely applied to various fields, and research students at home and abroad have made more researches on the application of the blockchain in the scene of the Internet of things of the building, so that the trusted storage of data is realized, and the equipment management of the Internet of things and the operation and maintenance management of the building are realized by utilizing the intelligent contracts of the blockchain.

Along with the continuous development of the internet of things technology, the number of internet of things devices in the internet of things is gradually increased, and the data acquisition amount is continuously increased. Because of the characteristics of full storage and log type recording mode of the blockchain, the data of the blockchain nodes can be accumulated continuously along with time, and the existing research scheme faces the storage performance challenges of the blockchain; in addition, the above studies store the collected data in plain text on the blockchain, lacking privacy protection means.

Aiming at the problems, the patent with the application publication number of CN111914269A discloses a data security sharing method and system in a blockchain and cloud storage environment, original data is stored in an under-chain cloud environment, and only corresponding metadata is stored on a chain, so that the storage pressure of the blockchain is reduced, and the data security sharing is realized based on an attribute encryption scheme. However, the under-chain centralized cloud storage mode has single-point fault hidden trouble, and if a cloud server fails, the normal operation of the whole system can be influenced, so that the data reliability is poor. For this reason, the patent with application publication number CN114065261a discloses a distributed trusted data sharing platform, method and system based on blockchain, and utilizes IPFS to realize the under-chain distributed trusted data storage.

However, the above-mentioned existing method reduces the storage pressure of the blockchain by adopting a cooperative storage mode of the uplink and the downlink of the chain and realizes the secure sharing of data based on an encryption algorithm, but still faces a plurality of challenges. Meanwhile, the continuous expansion of the size of the building networking requires the block chain network to have higher request concurrency processing capacity, and the nodes are required to spend computing resources for serializing and processing blocks containing batch transactions due to the inherent serialization account book writing operation characteristics of the block chain data structure, so that the throughput performance of the traditional single-chain-based data management method is difficult to meet the concurrency processing requirement of the building networking scene. On the other hand, when the data privacy is protected by using the attribute encryption scheme, the data management method based on the block chain is partly used for selecting to store the access control strategy on the block chain in a plaintext form, and the explicit storage of the strategy causes the hidden danger of revealing the strategy attribute and the user information.

In general, the Internet of things equipment in the Internet of things scene of the building has the characteristics of high deployment density, large sampling data volume and the like, if the data is directly stored on the blockchain, the storage performance of the blockchain network can be greatly challenged, and meanwhile, the problem of data privacy leakage can be caused by a data plaintext storage mode because of the public and transparent characteristics of the blockchain. The prior art designs a corresponding link-up-link-down collaborative storage scheme and an attribute encryption scheme to solve the problems, but because the problems commonly adopt a single blockchain for data management, the throughput performance of the blockchain is difficult to meet the concurrent processing requirement of a building networking scene; in addition, when the prior art utilizes an attribute encryption scheme to protect data privacy, an access control strategy is explicitly stored on a blockchain in a plaintext form, and the strategy attribute and the user information have hidden dangers of being revealed.

Therefore, how to provide a data management method for the Internet of things of a building, which reduces the storage pressure of the nodes of the blockchain, improves the concurrency processing capability of the blockchain network, and realizes the safe sharing of data on the premise of implicitly recording the access control strategy on the chain becomes a urgent problem to be solved.

Disclosure of Invention

Aiming at the problems of poor concurrent processing capability and easy leakage of strategies and user information in the prior art of blockchain network storage, the invention provides a blockchain-based multi-chain and attribute-encryption-based building networking data management method, which comprises the following steps:

Constructing a blockchain network and IPFS private networks by utilizing a gateway and a cloud server of a building networking cluster, calling a multi-chain dividing algorithm to divide the blockchain network into a plurality of sub-chains, and storing the corresponding relation between each sub-chain and each intelligent subsystem of the building networking;

an access strategy setting step of calling an ABE initialization algorithm by a key generating mechanism to generate an ABE master key and an ABE public key, setting different access strategies and symmetric keys for different data in the 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 LSSS strategy vectors according to the private value and the access strategies;

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 a data type by calling access policy storage contracts of each sub-chain;

The data storage step comprises the steps of obtaining data in the Internet of things of the building, encrypting the data to obtain ciphertext data, and storing the ciphertext data by adopting a collaborative storage or on-chain storage method according to the data type to obtain a storage record;

Initiating a data access request, obtaining 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 verification is passed;

And a data decryption step, namely calling an ABE decryption algorithm to decrypt the encryption key according to an ABE private key generated by a key generation mechanism by a user, obtaining a symmetric key, decrypting ciphertext data in the storage record by using the symmetric key, and carrying out integrity check on the decrypted data, wherein the data which can be normally used is obtained after verification.

The building networking data management method comprises the steps of dividing the blockchain network into a plurality of sub-chains according to the number of the intelligent sub-systems, the number of devices in each intelligent sub-system and the number of sub-chains to be divided, writing the corresponding relation between the sub-chains and the intelligent sub-systems into configuration files, and storing the configuration files into a gateway and a server.

The building networking data management method, wherein the access policy setting step comprises the following steps:

The initialization step is that a security parameter is randomly generated by initializing a key generation mechanism, and an ABE initialization algorithm is called according to the security parameter to generate the ABE master key and the ABE public key;

the symmetric key generation step, namely classifying data in the Internet of things according to the data type, the position of equipment, the attribution party of the equipment and the affiliated intelligent subsystem as classification conditions, and setting a corresponding access strategy and a symmetric key corresponding to the access strategy for the classified data according to the classification conditions;

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;

And the LSSS policy vector obtaining step is to construct a random vector according to the privacy value, and multiply the LSSS matrix with the random vector to obtain the LSSS policy vector.

The building networking data management method further comprises the following steps:

and the ABE private key obtaining step is that when the user performs first registration, a registration request is initiated to a key generation mechanism, and the key generation mechanism generates the 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 time stamp, registration time and an administrator signature.

The building networking data management method, wherein the ABE private key obtaining step comprises the following steps:

An administrator signature verification step, namely obtaining and verifying an administrator signature after analyzing the registration request through the key generation mechanism;

If the verification is passed, loading the locally stored ABE master 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 returning the ABE private key, namely returning the ABE private key to the user initiating the registration request through a secure channel.

The building networking data management method, wherein the data storage step comprises the following steps:

the data encryption step is that data in the Internet of things of the building are obtained through a data gateway and a server, and encrypted through a symmetric key to obtain ciphertext data;

and the storage step is to judge the sub-chain to which the data belongs by analyzing the configuration file and store the ciphertext data according to a method of storing or cooperatively storing the data on the data type selection chain.

The building networking data management method, wherein the storing step comprises the following steps:

A storage record constructing step, namely calling IPFS an interface to store the ciphertext data into the IPFS private network and acquiring a returned IPFS storage address, and constructing a storage record according to the IPFS storage address and an original data hash value if a collaborative storage method is adopted, and storing the ciphertext data into a corresponding sub-chain if a chain storage method is adopted, and constructing the storage record according to the ciphertext data and the original data hash value;

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

The building networking data management method comprises the step of initiating a data access request to a background server of a building networking system through a terminal, wherein 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 networking data management method, wherein the data request step further comprises the steps of;

An access strategy acquisition step, namely acquiring an access strategy and a private value hash corresponding to data to be requested through a storage record acquisition contract;

And in the permission verification step, a verification private value is obtained according to the user attribute hash set, the LSSS matrix and the LSSS policy vector, the hash value of the verification private value is compared with the private value hash, and if the comparison result is consistent, the user attribute hash set meets the access policy and returns a storage record corresponding to the data to be requested and an encryption key.

The building networking data management method, wherein the data decryption step comprises the following steps:

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 ciphertext data in the storage record by using the symmetric key;

and an integrity checking step, namely 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, completing the data.

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

1. Aiming at the problem of the block chain storage performance faced by the existing building networking data management method, the invention comprehensively adopts two modes of on-chain storage and collaborative storage. For data with small volume and non-fixed data generation frequency and need to be processed piece by piece, the data can be stored in a block chain in an on-chain storage mode. The data with large volume, fixed data generation frequency and batch processing can be stored in a distributed IPFS network under the chain in a collaborative storage mode, and corresponding metadata is stored only in the blockchain, so that the storage requirement of the blockchain is effectively reduced, and the IPFS is utilized to realize the reliable storage of the data under the chain;

2. Aiming at the problem of low concurrency of a blockchain network in the prior art, the invention designs a multi-chain partitioning algorithm by considering that the number of devices of each intelligent subsystem in the building networking is in positive correlation with the number of data generation and the number of blockchain transactions, and the data of the subsystems are partitioned into different subchains for maintenance according to the distribution condition of the number of the devices, so that the blockchain transactions required to be processed by each subchain tend to be consistent. The storage or inquiry request initiated to the blockchain network is forwarded to a specific subchain in the network for processing, and the calculation pressure caused by processing the high concurrency request can be more evenly unloaded to the nodes of each subchain, so that the calculation resources of each node are fully utilized, and the concurrency processing capacity of the blockchain network is improved;

3. Aiming at the unsafe problem of the access control strategy recording mode faced by the prior art when attribute encryption and blockchain are combined, the invention stores the access control strategy and strategy attribute on the blockchain in the form of matrix and hash value (instead of explicit attribute value) respectively by utilizing an intelligent contract and a linear secret sharing scheme (namely LSSS) on the basis of the prior art, and judges the user access authority in the matrix operation mode, thereby realizing the safe recording and effective verification of the access control strategy. Meanwhile, the invention combines the attribute encryption and the linear secret sharing scheme, so that the technical scheme of the invention has the characteristics of fine granularity access control, one-to-many data security sharing, policy security recording and the like.

Drawings

FIG. 1 is a schematic diagram of steps of a method for managing data of a building networking based on blockchain multi-chain and attribute encryption according to an embodiment of the present application;

FIG. 2 is a schematic flow chart of a method for managing data of a building networking based on blockchain multi-chain and attribute encryption according to an embodiment of the present application;

FIG. 3 is a block chain and IPFS based architecture diagram of a data management system for Internet of things of a building in accordance with an embodiment of the present application;

FIG. 4 is a flowchart of a multi-chain partitioning algorithm according to an embodiment of the present application;

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

Fig. 6 is a schematic flow chart of a key generation mechanism for generating an ABE private key of an entity according to an embodiment of the present application;

FIG. 7 is a flowchart illustrating two data storage methods according to an embodiment of the present application;

FIG. 8 is a schematic flow chart of verifying user access rights according to an embodiment of the present application;

FIG. 9 is a schematic diagram of a block chain based multi-chain and attribute encryption method for managing building access data according to an embodiment of the present application;

fig. 10 is a flow chart of a building entrance guard traffic data management method based on blockchain multi-chain and attribute encryption according to an embodiment of the present application.

Detailed Description

The present application will be described and illustrated with reference to the accompanying drawings and examples in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application. All other embodiments, which can be made by a person of ordinary skill in the art based on the embodiments provided by the present application without making any inventive effort, are intended to fall within the scope of the present application.

It is apparent that the drawings in the following description are only some examples or embodiments of the present application, and it is possible for those of ordinary skill in the art to apply the present application to other similar situations according to these drawings without inventive effort. Moreover, it should be appreciated that while such a development effort might be complex and lengthy, it would nevertheless be a routine undertaking of design, fabrication, or manufacture for those of ordinary skill having the benefit of this disclosure, and thus should not be construed as having the benefit of this disclosure.

Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application. The appearances of such phrases 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 those of ordinary skill in the art that the described embodiments of the application can be combined with other embodiments without conflict.

Unless defined otherwise, technical or scientific terms used herein should be given the ordinary meaning as understood by one of ordinary skill in the art to which this application belongs. The terms "a," "an," "the," and similar referents in the context of the application are not to be construed as limiting the quantity, but rather as singular or plural. The terms "comprises," "comprising," "includes," "including," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or modules (elements) is not limited to only those steps or elements but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. The terms "connected," "coupled," and the like in connection with the present application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The term "plurality" as used herein means two or more. "and/or" describes the association relationship of the association object, and indicates that three relationships may exist, for example, "a and/or B" may indicate that a exists alone, a and B exist simultaneously, and B exists alone. The character "/" generally indicates that the context-dependent object is an "or" relationship. The terms "first," "second," "third," and the like, as used herein, are merely distinguishing between similar objects and not representing a particular ordering of objects.

The present invention will be described in detail below with reference to the embodiments shown in the drawings, but it should be understood that the embodiments are not limited to the present invention, and functional, method, or structural equivalents and alternatives according to the embodiments are within the scope of protection of the present invention by those skilled in the art.

Embodiment one:

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

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

S1, constructing a blockchain network and IPFS private networks by utilizing a gateway and a cloud server of a building networking cluster, calling a multi-chain dividing algorithm to divide the blockchain network into a plurality of sub-chains, and storing the corresponding relation between each sub-chain and each intelligent subsystem of the building networking;

The step S1 specifically comprises dividing the blockchain network into a plurality of sub-chains according to the number of the intelligent sub-systems, the number of devices in each intelligent sub-system and the number of sub-chains to be divided, writing the corresponding relation between the sub-chains and the intelligent sub-systems into configuration files, and storing the configuration files into a gateway and a server.

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

Further, the step S2 specifically includes the following:

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 master key and the ABE public key;

Step S22, classifying the data in the Internet of things of the building according to the data type, the position of the equipment, the attribution party of the equipment and the affiliated intelligent subsystem as classification conditions, and setting a corresponding access strategy and a symmetric key corresponding to the access strategy for the classified data according to the classification conditions;

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;

And step S24, constructing a random vector according to the privacy value, and multiplying the LSSS matrix by the random vector to obtain the LSSS policy vector.

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 the user performs first registration, a registration request is initiated to a key generation mechanism, and 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 time stamp, registration time and an administrator signature.

Further, step S4 specifically includes the following;

step S41, after the key generation mechanism analyzes the registration request, an administrator signature is obtained and checked;

and step S43, returning the ABE private key to the user initiating the registration request through a secure channel.

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

Further, the step S5 specifically includes the following:

step S51, data in the Internet of things of the building are obtained through a data gateway and a server, and encrypted through a symmetric key to obtain ciphertext data;

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

Specifically, step S52 includes;

Step S521, if a collaborative storage method is adopted, calling IPFS an interface to store the ciphertext data into the IPFS private network, acquiring a returned IPFS storage address, and constructing a storage record according to the IPFS storage address and an original data hash value;

and step S522, calling a data storage contract of a 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 verification is passed;

Further, step S6 further includes:

Step S61, a data access request is initiated to a background server of the building networking system through the terminal, wherein 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, obtaining access strategies and private value hashes corresponding to data to be requested through a storage record obtaining contract;

And step 63, obtaining a verification private value according to the user attribute hash set, the LSSS matrix and the LSSS policy vector, comparing the hash value of the verification private value with the private value hash, and if the comparison result is consistent, the user attribute hash set meets the access policy and returns a storage record corresponding to the data to be requested and an encryption key.

And S7, according to an ABE private key generated by a key generation mechanism, invoking an ABE decryption algorithm to decrypt the encryption key to obtain a symmetric key, decrypting ciphertext data in the storage record by using the symmetric key, and carrying out integrity check on the decrypted data, wherein after the verification is passed, data which can be normally used is obtained.

Further, the step S7 specifically includes the following:

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 ciphertext data in the storage record by using the symmetric key;

and S72, 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, completing the data.

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

The application provides a data management method of a building networking based on block chain multi-chain and attribute encryption, which aims to reduce the storage pressure of block chain nodes, improve the concurrency 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, a blockchain multi-chain network environment and an interstar file system (namely IPFS) environment are deployed, a plurality of data gateways and cloud servers of a building networking cluster are used as nodes of a blockchain network, a multi-chain dividing algorithm is called to divide the blockchain network into a plurality of sub-chains, the corresponding relation between the sub-chains and an intelligent sub-system is written into a configuration file and stored in the gateway and the server locally, and then the cloud server is used as the nodes to construct IPFS private network.

Specifically, in the step S1, the blockchain multi-chain network is a network environment constructed by a plurality of blockchains that can independently run, and is constructed by using HYPERLEDGER FABRIC in the present application.

Specifically, in the step S1, IPFS is a distributed file storage system, and the IPFS node is formed by a server. The data gateway periodically collects the equipment data, encrypts the data to be stored outside the chain according to a hybrid storage mechanism and stores IPFS, and stores the returned IPFS address into the corresponding sub-chain. IPFS is used for storing the data of the Internet of things equipment generated in the scene of the Internet of things of the building, so that the storage and bandwidth pressure of the blockchain network are reduced.

Specifically, in the step S1, the internet of things of the building includes, but is not limited to, various intelligent subsystems formed by devices such as lighting, monitoring, entrance guard, environmental monitoring, etc. in the building. The intelligent subsystem includes, but is not limited to, a video monitoring system, a fire protection system, a building control system, an environment monitoring system, and/or an access 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 the constituent nodes of the blockchain multi-chain network; the data gateway is responsible for collecting 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 IPFS (collaborative storage) or a corresponding sub-chain (on-chain storage) according to a hybrid storage mechanism;

The gateway/server serving as the blockchain node can be added into one or more sub-chains of the multi-chain network as a blockchain node, comprehensive consideration is needed according to scene requirements and calculation and storage resources of the gateway/server, the server is added into each sub-chain as the blockchain node due to sufficient resources of the server, all data of the blockchain multi-chain network are stored, a IPFS private network is formed by the server and other server nodes, and the server is also responsible for receiving and responding to data requests of users.

Specifically, in the step S1, the building networking cluster refers to a cluster formed by one or more buildings and parks. The building network comprises a plurality of intelligent subsystems, and the quantity of equipment and the quantity of acquired data in the subsystems are greatly different according to different building types;

because the quantity distribution and sampling frequency of the Internet of things equipment in the building in each intelligent subsystem are different, the random sub-chain division mode is easy to cause uneven load of the sub-chains, and the calculation cost of each edge node is difficult to effectively reduce. To this end, a multi-chain partitioning algorithm is proposed herein, taking the number of devices and the amount of data generated for each subsystem in the building network as a criterion for load balancing per sub-chain. The specific dividing steps are as follows:

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

Step1, input the number of intelligent subsystems N, the number of devices per subsystem C _i (i=1, 2,..n), and the number of sub-chains to be partitioned N (N < N).

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

Step2, calculating an optimal average avg= (C ₁+C₂+…+C_N)/n after sub-chain division, and if C _i > avg, dividing the intelligent subsystem System _i into one sub-chain for management.

Step3, sub-chain partitioning the remaining intelligent subsystems such that variance σ₂＝(chain_C₁-avg)₂+(chain_C₂-avg)₂+…+(chain_C_n-avg)₂ is minimized, wherein chain_c _i represents the total number of devices contained within the sub-chain.

Specifically, in Step3, the chain_c _i is the sum of the numbers of the subsystem devices added to the sub-chain.

It should be added that, in view of the availability of the system, the numerous devices within the intelligent subsystem are considered as a whole, and only allowed to be divided into the same sub-chain, i.e. one intelligent subsystem cannot be commonly maintained by multiple sub-chains.

It should be noted that, because the number of devices, the data amount and the blockchain transaction number are in positive correlation, if the variance σ2 after division is minimum, the number of devices maintained by each subchain tends to be consistent, so that the transaction processing pressure of each subchain link point is effectively balanced.

Step4, outputting the number n of sub-chains after division and the intelligent subsystem set contained in each sub-chain.

It should be noted that after the multi-link is divided, the data storage or data acquisition request initiated to the multi-link network is finally unloaded to a specific sub-link, the request is processed only by the node of the sub-link, and the other nodes do not need to consume computing resources. Therefore, the data management method provided by the application has better concurrent processing performance.

Specifically, in step S1, the content of the configuration file record includes, but is not limited to, the number of sub-chains, node information of each blockchain, the correspondence between sub-chains and the intelligent subsystem, the data type and the storage mode thereof.

The node information includes, but is not limited to, a node number, a belonging blockchain, a node IP address, a node communication port number;

the corresponding relation is 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 repair/maintenance information, and equipment manipulation 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 is only accessible to users of the building networking system and is not open to the public.

Including but not limited to, business personnel, 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 may be a local or cloud server.

It should be added that the data gateway and server must meet the memory and hard disk space necessary to deploy HYPERLEDGER FABRIC blockchain and IPFS operating environments, otherwise the blockchain multi-chain network and/or IPFS network will not operate properly.

S2, the key generation mechanism executes initialization operation, randomly generates a security parameter lambda, invokes an ABE initialization algorithm, and generates an ABE master key (namely MK) and an ABE public key (namely PK) according to the lambda.

Specifically, in the 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 acted on by a trusted local server or a cloud server.

Including but not limited to a data gateway, server, and/or user.

Specifically, in the step S2, ABE refers to an attribute-based encryption algorithm, and after the data owner encrypts the data by using the ABE algorithm, only the entity having the specified attribute can decrypt the ciphertext and obtain the original data, which can realize fine-granularity access right control.

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

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

And S3, setting different access strategies P and symmetric keys Key for data in the Internet of things by the data gateway (and/or the server), calling an ABE encryption algorithm according to the public Key PK and the strategy P to encrypt the keys to obtain an encryption Key C, setting a private value S, and generating an LSSS strategy vector rho according to the private value S and the strategy P.

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

The device operation information includes, but is not limited to, whether the device is 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 traffic records;

The device manipulation record refers to an operation log of a user initiating a remote control command to a device, including but not limited to device startup/shutdown and device parameter adjustment.

Specifically, in the step S3, the access policy P indicates an attribute required by the user to access the data, for example, p= (a 1 a 2) v (a 1 a3 a 4), which indicates that the user needs to possess the attributes a1 and a2 or the attributes a1, a3 and a4 to access the data.

Specifically, in step S3, different access policies are set, that is, the data is further classified according to the data type, the location of the device, the home party of the device and/or the intelligent subsystem to which the device belongs, and the corresponding access policies are set for the subdivided data according to the classification conditions, so as to realize fine-granularity access control.

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

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

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

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

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

Specifically, in the step S3, a flow chart 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, wherein M represents the number of the attributes (including repeated attributes) in the policy P, n represents the minimum calculation amount required by the LSSS, and the value of n is calculated by the LSSS matrix construction algorithm.

Specifically, in the Step1, the attribute combination splitting process is as follows, setting a P= (a1A a 2) V (a1A a 3A a 4), splitting to obtain two sub-items Pa= (a1A a 2) and Pb= (a1A a 3A a 4), and meeting any one sub-item, namely meeting the policy P.

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

(1) Any attribute is represented as a single entry matrix M _U = [1], presence matrix M _a represents policy P _a, X _a represents the first column of matrix M _a, and Y _a represents the other columns of matrix M _a except the first column. Matrix M _b is the same.

(2) For any or structure p=p _a∨P_b, policy P can be represented by matrix M _OR shown in equation 1).

(3) For any and structure p=p _a∧P_b, policy P can be represented by matrix M _AND shown in equation 2).

The sub-policies P _a,P_b can be expressed as ([ 1 ]) and ([ 1 ]) according to rule (1), and then calculate a matrix M corresponding to p=p _a∨P_b according to rule (2) and rule (3), the matrix M being 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,) ^T according to the generated privacy value s, wherein r 2-rn are random numbers.

Step3, multiplying the matrix M by the random vector v to obtain the policy vector ρ=m·v= (p 1, p2, pm) ^T of LSSS.

And S4, constructing access policy records by the data gateway (and/or the server) according to the information such as the policy vector rho of the encryption key C, LSSS, the private value hash and the like, then calling access policy storage contracts of all the sub-chains, and storing all the access policy records into the sub-chains corresponding to the accessed data types.

Specifically, in the 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 privacy value hash, a data type, an upload time, and an owner.

TABLE 1

The strategy attribute hash set consists 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, in the present application takes the place of the data gateway and server.

Specifically, in step S4, the data storage contract and other intelligent contracts mentioned later in the application are successfully installed in each sub-chain when initializing the blockchain multi-chain network operation environment, and the entity can call the intelligent contract to execute the corresponding function through the SDK interface provided by the sub-chain, and the mentioned intelligent contracts are similar to the intelligent contracts and are not repeated.

Specifically, in the step S4, the data type is an intelligent subsystem to which the data belongs, such as "access control system data", "monitoring system data", etc., and the local configuration file may be combined to retrieve the sub-chain responsible for the data.

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

It should be noted that, during the storage and subsequent use (i.e. judging the user authority) of the access control policy, the relevant attribute information is always presented in the form of hash value, so as to effectively prevent the leakage of the policy information and the user information.

S5, the user initiates a registration request to the key generation mechanism and receives the 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 the HTTP request, which will not be described in detail later. Information such as IP, port number, communication rule, etc. of the data gateway, server, and key generation mechanism are all shared at the time of initialization.

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

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

Step1, the key generating mechanism receives a registration request initiated by entities such as a user, a gateway and the like.

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

TABLE 2

User ID

User attribute collection

Time stamp

Registration time

Administrator signature

The administrator signature is a signature of the result of splicing the first four fields by using a private key by a system administrator, and a key generation mechanism judges whether a registration request is legal or not through the fields.

It is necessary to supplement that the system administrator identity is generated during initialization and the public key is disclosed, the registration request of the user is required to be sent to the key generation mechanism after the signature is approved by the system administrator in advance, otherwise, the request is regarded as an illegal user request, and the illegal user request is ignored and not processed.

Step2, the key generating mechanism analyzes the registration request, checks the signature of the system administrator, and if the verification is not passed, ignores the registration request of the entity.

Specifically, in Step2, the verification mode refers to that the signature is untagged by using a public key of a system administrator, the untagged 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 failed.

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

Specifically, in Step3, the ABE private key generation algorithm is implemented by calling CPABE the library, taking the master key MK, the public key PK and the user attribute set a as inputs, and outputting the ABE private key of the user, which is used for decrypting the 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 means that the request initiator and the key generation mechanism both generate public-private key pairs 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 by requesting the public key of the initiator, returns the encrypted ABE private key to the requester, and the requester uses the own communication private key to decrypt and obtain the original ABE private key.

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

Specifically, in the step S6, the judging and processing flows of the two storage modes are shown in fig. 7, and the method includes the following steps:

a) Encrypting the data by using the symmetric Key Key;

It should be noted that, because the gateway and the server set multiple access policies and symmetric keys for the data in the 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 mode is described in detail in the foregoing and will not be repeated.

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

Aiming at the problem of the block chain storage performance faced by the existing building networking data management method, the invention comprehensively adopts two modes of on-chain storage and collaborative storage. For data with small volume and non-fixed data generation frequency and need to be processed piece by piece, the data can be stored in a block chain in an on-chain storage mode. The data with large volume, fixed data generation frequency and batch processing can be stored in a distributed IPFS network under the chain in a collaborative storage mode, and corresponding metadata is stored only in the blockchain, so that the storage requirement of the blockchain is effectively reduced, and the IPFS is utilized to realize the reliable storage of the data under the chain;

Specifically, in the step b), the judgment of the data storage method is shown in table 3, and the on-chain storage method is adopted for processing the data such as the equipment management information, the equipment alarm information and the like which are not fixed in data generation frequency and need to be processed piece by piece, and the collaborative storage method is adopted for processing the data such as the equipment operation information, the external environment sampling information and the like which are fixed in data generation frequency and can be processed in batches.

TABLE 3 Table 3

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

d) Adopting a cooperative storage mode, calling IPFS an interface to store ciphertext data into a IPFS network, and acquiring a returned IPFS storage address;

Specifically, in the step d), IPFS interfaces are implemented based on the add command of go-ipfs.

Specifically, in the step d), the IPFS storage address refers to a unique hash value of the returned identification file storage address after storing the encrypted data file in the IPFS private network.

E) Constructing a storage record according to IPFS storage addresses, original data hash values and other information, and then turning to step g);

specifically, in the step e), the data structure of the storage record is shown in table 4, which includes but is not limited to storage mode, ciphertext data, IPFS storage addresses, data types, original data hash values, and storage time.

TABLE 4 Table 4

Storage mode

Ciphertext data

IPFS memory addresses

Data type

Raw data hash value

Storage time

It should be noted that if the storage mode is "store-on-chain", the field "IPFS storage address" is empty, whereas if the storage mode is "store-in-coordination", the field "ciphertext data" is empty.

F) Storing ciphertext data into a sub-chain by adopting a 'store on chain' mode, and constructing a storage record according to information such as ciphertext data, an original data hash value and the like;

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

Specifically, in step g), the target sub-chain refers to a sub-chain responsible for maintaining the intelligent sub-system to which the data belongs, and the corresponding relationship between the intelligent sub-system and the sub-chain can be resolved in the local configuration file.

It should be noted that, for example, the data processed by the collaborative storage method, such as the device running information and the external environment sampling information, the gateway sets the collection frequency and periodically collects the data in batches, the data collected in batches can be stored in a unified way under the chain in a file form by using IPFS, and only the corresponding data storage record is needed to be stored on the chain, so as to obviously reduce the storage occupation of the data to the blockchain, while for the data such as the device management information and the device alarm information, the generation frequency is not fixed (possibly several seconds and several minutes), in order to ensure the data processing efficiency and the availability, the data needs to be processed and stored one by one when being generated, and under the condition, the storage occupation of the storage on the chain to the blockchain is similar to the collaborative storage mode, but the storage and the use efficiency are higher, so the application adopts the on-chain storage method to process the data.

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

Specifically, in the 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 hash set of user attributes, a data type to be requested, a data query condition, a request time, and a time stamp.

TABLE 5

User ID

User attribute hash set

Data type to be requested

Data query conditions

Request time

Time stamp

The user attribute hash set is similar to the strategy attribute hash set and is composed 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, which may be a time range, a location, a device type, and/or a device number.

And 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 belongs according to the data type, and calls the storage record of the target sub-chain to acquire the contract.

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

It should be noted that the data type and the data type are two different classification manners of the data. The data type is used for judging the affiliated intelligent subsystem and is used for dividing and positioning sub-chains, 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.

And S9, acquiring access rights of the user by the storage record, namely verifying whether the attribute hash set of the user meets the LSSS access policy or not, and returning the corresponding storage record and the encryption key C to the server after the verification is passed.

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

step1, storing and recording an LSSS access policy rho, a policy attribute hash set and a privacy hash corresponding to the acquisition request data in the acquisition contract.

Step2, selecting a row matched with the LSSS matrix M to form a new matrix M _P according to the attribute hash set of the user, and calculating a vector f so that f.m _P = (1, 0,..0).

Specifically, in Step2, the line matching manner is to calculate an intersection of the user attribute hash set and the policy attribute hash set, and one or more line vectors corresponding to the intersection are the matched lines.

Specifically, in Step2, the matrix M _P is a mapping of the user attribute set, and the hash values of a1 and a2 are matched with the matrix M on the assumption that the user attribute set is (a 1a 2), and the first three rows of the matrix M constructed in Step1 in Step 3 of the present application are matched to form a matrix M _P,M_P according to a matching rule, which is represented as follows:

Step3, selecting components corresponding to the matrix M _P in the LSSS policy vector rho to form a new vector rho ', and multiplying the vector f by rho ' to obtain a privacy value s '.

Step4, comparing the hash value of s' with the hash of the private value stored in the chain, and if the hash value is consistent with the hash value of the private value, enabling the attribute hash set representing the user to meet the access policy P and have the access right of the requested data.

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

Specifically, in step S9, the corresponding storage records refer to all storage records in the destination sub-ledger consistent with the data type in the data access request.

And S10, the server judges a storage method according to the data type, if the storage method is 'on-chain storage', the storage record is ciphertext data, if the storage method is 'collaborative storage', the storage address IPFS in the storage record is analyzed and acquired, the ciphertext data is acquired 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 the step S10, the ciphertext data is obtained by a get command of go-ipfs.

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

Specifically, in the step S11, the ABE decryption algorithm is implemented by calling CPABE library, and takes the public Key PK, the ABE private Key and the encryption Key C as input, and outputs the original symmetric Key.

Specifically, in the step S11, the ciphertext data decryption process is implemented by calling the library functions such as aes and des, and the library functions are required to be consistent with the symmetric encryption algorithm.

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

In order to improve the data access efficiency, the user stores the secret Key in the local after decrypting the symmetric secret Key, when the user accesses the data again, the user compares the obtained secret Key with the locally stored secret Key, if the comparison result is consistent, the locally stored symmetric secret Key is directly used for decrypting the ciphertext data, and the ABE decryption process is skipped.

For a further understanding of the present application, more specific examples are set forth below. The following application embodiments are examples of a building entrance guard traffic data management method based on blockchain multi-chain and attribute encryption, fig. 9 is a schematic diagram of a model of a building entrance guard traffic data management method based on blockchain multi-chain and attribute encryption provided by the embodiment of the application, and fig. 10 is a flow diagram of a building entrance guard traffic data management method based on blockchain multi-chain and attribute encryption provided by the embodiment of the application. The method comprises the steps of deploying a blockchain running environment in a data gateway and a server, executing a multi-Chain division algorithm to construct 3 sub-chains, dividing related data of an access control system into sub-chains chain_A for management according to the algorithm, storing related configuration information of a multi-Chain network in the gateway and the server, deploying and running IPFS private networks in the server, storing ciphertext data and obtaining ciphertext data content according to IPFS storage addresses, initializing a key generation mechanism, generating an ABE master key and an ABE public key, and disclosing the public key. The embodiment of the application comprises the following steps:

S1, setting an access strategy P= ('System administrator' property personnel '(' enterprise administrator 'building 14')) for access data by a data gateway, generating a symmetric Key Key locally, calling an ABE encryption algorithm according to a public Key PK and a strategy P to encrypt the Key to obtain an encryption Key C, setting a privacy value S as 2, and generating an LSSS strategy vector rho according to the privacy value S and the strategy P.

Specifically, in the step S1, the access policy P means that only a system administrator, a property, and an enterprise administrator working in the 14 th floor have access to the data.

S2, the data gateway constructs an access policy record according to the information such as the policy vector rho of the encryption key C, LSSS, the private value hash and the like, analyzes the local configuration file, judges the sub-Chain to which the data type belongs as Chain_A, calls an access policy storage contract of the Chain_A, and stores the access policy record into the Chain_A.

And S3, an administrator User1 of the 14 th floor enterprise initiates a registration request to the key generation mechanism and receives the returned ABE private key.

S4, the data gateway calls a data acquisition interface to acquire access control traffic data from an access control system of the office building 14 building.

Specifically, in the step S4, the collected gate access data includes, but is not limited to, a personnel number, a name, an in-out direction, an opening mode, and a passage time.

And S5, the data gateway judges that the data type is 'external environment sampling information', adopts a collaborative storage method, encrypts access control passing data by utilizing a symmetric Key Key, and then calls IPFS interface to upload ciphertext access control passing data to IPFS private network to obtain a storage address returned by IPFS.

And S6, the data gateway constructs a storage record according to the IPFS storage address, the hash value of the original access control traffic data and other information, analyzes the local configuration file, judges the sub-Chain to which the access control system data belongs as the chain_A according to the data type, calls the data storage contract of the chain_A, and uploads the storage record into the sub-Chain chain_A.

S7, the User1 initiates a 14-floor access control access data access request to a background server of the building networking system through the terminal.

And S8, the server analyzes the data access request of the User1, acquires the data type to be requested and the attribute hash set A= { role= 'hash (enterprise manager)', location= 'hash (14 building)',. The local configuration file, judges the sub-Chain to be chain_A according to the data type, and then invokes the storage record of the sub-Chain chain_A to acquire a contract.

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

Specifically, in the step S8, the attribute hash set a includes two parts, namely, an attribute name set { role, location, & gt} and an attribute value hash set { hash (enterprise administrator), hash (building 14) }.

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

And S9, the storage record acquires access rights of the User1 of the verification User in the contract, namely, whether the attribute hash set meets the LSSS access policy is verified, and the corresponding storage record and the encryption key C are returned to the background server after verification.

It should be noted that, because the gate access 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.

And S10, the background server judges that the storage method is collaborative storage according to the data type 'external environment sampling information', analyzes IPFS storage addresses in the storage records, acquires ciphertext access data from the IPFS private network, and returns an encryption key C, the ciphertext access data and an original access data hash value to the User1.

S11, a User1 calls an ABE decryption algorithm to decrypt the encryption Key C by means of an ABE private Key, decrypts ciphertext data after obtaining an original Key Key, verifies the integrity of decrypted data according to the hash value of the original access control traffic data, and after verification, the User can use the data to analyze the attendance of the enterprise personnel man-month, assist in predicting enterprise economy and the like.

Specifically, in step S11, the integrity check refers to that the sha256 () function is called to perform hash operation on the decrypted data, and the operation result is compared with the hash value stored in the chain, if the operation result is consistent with the hash value, it indicates that the ciphertext data is complete, and the data content is not tampered.

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

(1) Aiming at the problem of the block chain storage performance faced by the existing building networking data management method, the invention comprehensively adopts two modes of on-chain storage and collaborative storage. For data with small volume and non-fixed data generation frequency and need to be processed piece by piece, the data can be stored in a block chain in an on-chain storage mode. And for data with large volume, fixed data generation frequency and batch processing, a collaborative storage mode can be adopted to store the data into a distributed IPFS network under a chain, and corresponding metadata is stored only in a blockchain, so that the storage requirement of the blockchain is effectively reduced, and the reliable storage of the data under the chain is realized by utilizing IPFS.

(2) Aiming at the problem of low concurrency of a blockchain network in the prior art, the invention designs a multi-chain partitioning algorithm by considering that the number of devices of each intelligent subsystem in the building networking is in positive correlation with the number of data generation and the number of blockchain transactions, and the data of the subsystems are partitioned into different subchains for maintenance according to the distribution condition of the number of the devices, so that the blockchain transactions required to be processed by each subchain tend to be consistent. The storage or inquiry request initiated to the blockchain network can be forwarded to a specific subchain in the network for processing, and the calculation pressure caused by processing the high concurrency request can be more evenly unloaded to the nodes of each subchain, so that the calculation resources of each node are fully utilized, and the concurrency processing capacity of the blockchain network is improved.

(3) Aiming at the unsafe problem of the access control strategy recording mode faced by the prior art when attribute encryption and blockchain are combined, the invention stores the access control strategy and strategy attribute on the blockchain in the form of matrix and hash value (instead of explicit attribute value) respectively by utilizing an intelligent contract and a linear secret sharing scheme (namely LSSS) on the basis of the prior art, and judges the user access authority in the matrix operation mode, thereby realizing the safe recording and effective verification of the access control strategy. Meanwhile, the invention combines the attribute encryption with the linear secret sharing scheme, so that the designed technical scheme has the characteristics of fine granularity access control, one-to-many data security sharing, policy security recording and the like.

The technical features of the above-described embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above-described embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

The above examples illustrate only a few embodiments of the application, which are described in detail and are not to be construed as limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of protection of the present application is to be determined by the appended claims.

Claims

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

2. The method according to claim 1, wherein the network constructing step includes dividing the blockchain network into a plurality of sub-chains according to the number of the intelligent sub-systems, the number of devices in each intelligent sub-system and the number of sub-chains to be divided, writing the corresponding relation between the sub-chains and the intelligent sub-systems into configuration files, and storing the configuration files into a gateway and a server.

3. The method for managing data of the internet of things of claim 1, wherein the access policy setting step includes:

4. The method of building networking data management according to claim 1, further comprising:

5. The method for managing data of internet of things of claim 4, wherein the ABE private key obtaining step includes:

6. The method of building networking data management according to claim 2, wherein the data storage step comprises:

7. The method of claim 6, wherein the storing step comprises:

8. The method according to claim 1, wherein the data requesting step includes initiating a data access request to a background server of the building networking system through the terminal, the contents of the data access request including 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.

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

10. The method for managing data of the internet of things of claim 9, wherein the data decrypting step includes: