An alliance chain-based internet of things data verifiable access control method

Abstract

A kind of Internet of Things data verifiable access control method based on alliance chain, comprising: constructing alliance chain network, initialization, creating group and deploying smart contract;Alliance chain member node, user, Internet of Things equipment are registered to CA respectively, obtain certificate and related key;Internet of Things equipment accesses Internet of Things platform by MQTT protocol;Internet of Things equipment formulates access control strategy to the monitored data, and sends to alliance chain communication node after using CP-ABE encryption function to data encryption;Communication node saves data ciphertext to Internet of Things platform;User initiates access control request to alliance chain, and alliance chain decides whether to issue Token according to the signature information of user;User initiates request access resource to Internet of Things platform, and Internet of Things platform verifies the legality of Token;Internet of Things platform generates data integrity proof and saves in alliance chain for user verification;When unable to pass user verification, user calls compensation verification contract to apply for compensation verification, and communication node inspects and decides responsible party.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of Internet of Things access control and data integrity verification, and in particular to an Internet of Things data verifiable access control method based on a consortium chain. BACKGROUND

[0002] Massive Internet of Things data increases the storage pressure of terminal devices, and the usual way is that Internet of Things devices access an Internet of Things cloud platform, upload monitored data to the cloud platform for storage, users pay on demand, and remotely manage and maintain data. However, after the device uploads data to the cloud platform, the local backup will be deleted, thereby losing the control right of the monitored data, and there may be problems such as data leakage, data tampering, and fake data of the cloud platform. Therefore, a scheme is needed to ensure the privacy and integrity of the Internet of Things device monitoring data.

[0003] There are currently two main directions of research on access control, one is to research on the basis of traditional access control schemes, such as combining attribute-based access control (ABAC) and role-based access control (RBAC) with a blockchain. However, this way usually has poor data privacy and cannot guarantee data security. The other is to research on the basis of combining a ciphertext policy attribute-based encryption (CP-ABE) scheme with a blockchain. However, this way usually needs a single attribute authorization agency, is not easy to expand, and also has problems such as user identity privacy and low efficiency.

[0004] There are currently two main directions of research on data integrity verification, one is to directly use a hash function to pre-calculate a hash value to perform data integrity verification. However, this way usually has poor completeness, and the complete data needs to be obtained during verification, and cannot achieve lightweight verification. The other is to combine a PDP and a POR with a blockchain. However, this way usually has a large number of modular exponentiation and bilinear operations, and has large time overhead. And cannot prevent malicious attacks of users on the cloud platform. SUMMARY

[0005] In view of the deficiencies of the traditional access control scheme and the data integrity verification scheme mentioned above, the present application proposes a solution, aiming to realize privacy security, fine-grained access control, and data integrity of monitored Internet of Things data. The solution solves the many security and trust problems of centralized management of data by a third-party platform.

[0006] The Internet of Things data verifiable access control method based on a consortium chain of the present application comprises the following steps:

[0007] S1, an administrator registers with a CA, builds a consortium chain network, deploys a smart contract, and initializes the consortium chain;

[0008] S2, the user registers with the CA, generates attribute keys and signature keys;

[0009] S3, the user of the device registers the device and accesses the device;

[0010] S4, define the ciphertext access control policy, obtain the communication node, send the monitoring data ciphertext to the alliance chain, generate metadata, and finally send the monitoring data ciphertext to the IOT platform;

[0011] S5, the user requests access, obtains the policy structure, and generates a signature; the alliance chain verifies the signature, and if it is legal, generates a Token;

[0012] S6, the user uses the Token to access the IOT platform data, the platform administrator verifies, and if the verification is passed, the proof is written into the alliance chain, and the ciphertext is returned to the user;

[0013] S7, the user obtains the data integrity proof from the alliance chain and verifies the proof;

[0014] S8, if the verification is not passed, the user initiates compensation verification to the alliance chain, the alliance chain obtains the proof information, performs verification, and decides the responsible party.

[0015] The specific technical solutions of the application are as follows:

[0016] (1) By applying the CP-ABE of the multi-attribute authorization center in the alliance chain, the performance and security limitations of the traditional single-attribute authorization center are solved, and data security and decentralized fine-grained access control are realized. ABS is introduced in each attribute authorization center, which can complete access policy verification while ensuring the anonymity of user identity attributes, protecting the privacy of user identity attributes;

[0017] (2) The alliance chain is combined with Pedersen commitment for data integrity verification after access control. A large number of modular exponentiation and bilinear pairing operations existing in traditional data integrity verification are abandoned, the metadata is generated by the alliance chain, and the problems of high cost, low efficiency and trust existing in the traditional scheme are solved;

[0018] (3) By using JWT Token as the token after access policy verification for data access, the functions of one-time authorization, multiple verifications and multiple accesses are realized. The token contains the signature information of the authorized user and the metadata for verifying data integrity, which realizes lightweight data integrity verification on the basis of fine-grained access control, and can limit the number of accesses, ensuring the security of data.

[0019] Further, the multi-attribute authorization center distributes attribute keys and signature keys to the alliance chain member nodes and participating users, the former key is used to realize access policy formulation and fine-grained access control, and the latter key is used to protect the identity attribute privacy of the user.

[0020] Further, the Pedersen commitment is an encryption algorithm with strong hiding and binding properties, where the difficulty of hiding values is based on the discrete logarithm problem, and the binding property ensures that the calculated commitment is difficult to calculate under normal calculation. In the actual scheme, two roles of the committer and the verifier are usually included, and the specific commitment steps are as follows:

[0021] S1: initialization: take a large prime number p>2 160 , take any a,b∈Z p and 4a 3 +27b 2 ≠0. Define E p (a,b): y 2 ≡x 3 +ax+b(mod p), all point sets of the equation constitute an elliptic curve. The trusted party selects two points G and Q on the elliptic curve, G is the predetermined generating point of the curve, and Q=kG(k is the private key of the trusted party). Finally, the system parameters (p, a, b, G, Q) are disclosed.

[0022] S2: commitment: the committer randomly selects r,x∈Z p , makes a commitment to x with r, and calculates as follows:

[0023] C=G(x,r)=xG+rQ∈E p (a,b) (4-8)

[0024] S3: open: the committer discloses r and x, and the verifier verifies whether the equation C=xG+rQ is established to open the commitment.

[0025] Further, the JWT Token is in the form of Header.Payload.Signature. (1) Header, usually composed of two parts. alg: indicates the signature algorithm. tye: indicates the Token type; (2) Payload, which contains claims, and the claims are usually the claims about the data of the entity (for example, the user). For example, set the Token expiration time, Token issuer, Token user, issue time, etc. In this scheme, it also contains attribute information of the access user and the accessed device, and metadata information for verifying data integrity, etc. (3) Signature, the process of signing, which is actually signing the header and the content of the payload. Header and Payload are both encoded using Base64, and the encoded Header and Payload are first spliced into a string by a dot (.), and then signed by the signer's secret key secret using the signature algorithm alg specified in the Header, as follows.

[0026] HMACSHA256(base64UrlEncode(Header) + "." + base64UrlEncode(Payload), secret);

[0027] The signature algorithm used in this scheme is RSA, and when the access policy verification is passed, the private key deviceSK of the accessed data device is used to sign the Header and Payload. When performing verification on the Token, the receiver first divides the Token into three parts: Header, Payload and Signature. The verifier obtains the unique identifier deviceID of the accessed device from the Payload, and then obtains the public key devicePK stored when the device accesses, and then performs verification on the Signature, and compares the obtained data with the Header and Payload to verify the validity of the Token.

[0028] The beneficial effects of the present application are that the privacy and security of data and users are guaranteed by combining various cryptography technologies with the alliance chain, and the fine-grained access control of data is realized. Moreover, in the process of guaranteeing fine-grained access control, the integrity of the accessed data can be verified quickly with low overhead. The alliance chain is used as a regulatory party to generate metadata, the commitment value is saved in the alliance chain node by Pedersen commitment and consensus is reached, the interests of end users are guaranteed, the emergence of malicious users is avoided, and the interests of the cloud platform are maintained, thereby ensuring the fairness in the verification process. BRIEF DESCRIPTION OF DRAWINGS

[0029] Figure 1A model diagram of the Internet of Things verifiable access control method of the present application;

[0030] Figure 2 A flowchart of the Internet of Things verifiable access control method of the present application;

[0031] Figure 3 A smart contract design diagram of the Internet of Things verifiable access control method of the present application. DETAILED DESCRIPTION

[0032] The present application is further described below in combination with a specific embodiment of an Internet of Things verifiable access control method based on a consortium chain.

[0033] Embodiments of the present application and examples of implementation processes are described as follows:

[0034] An Internet of Things verifiable access control method based on a consortium chain is shown in the model diagram as Figure 1 The system mainly includes five roles:

[0035] Trusted CA: the certificate authority of the present scheme. That is, the registration authority, responsible for maintaining the consortium chain. Each organization in the network needs to send a CSP (Cryptographic Service Provider) request to the trusted CA before joining the network, and the CA signs a certificate for it. And the user in the scheme also needs to register with the CA, and the certificate issued contains the user's identity information.

[0036] Consortium chain: the consortium chain selected in the present scheme is Hyperledger Fabric, and each member node needs to obtain CA authentication before joining the consortium chain. The consortium chain member nodes are maintained by various attribute authorization centers AA, which are responsible for distributing attribute private keys and signature private keys after the user is registered with the CA. One AA can be responsible for multiple attributes, but each attribute can only be managed by one AA. In addition, the member nodes are also responsible for generating metadata for data integrity verification and consensus among nodes. The information stored in the chain mainly includes access control policy structure, user key information, metadata for data integrity verification and Pedersen commitment value. Hyperledger Fabric realizes access control through smart contracts, and provides contract chain code function API for user calling.

[0037] User: The users of this scheme are divided into visitors and device owners. Visitors obtain authorization by issuing an access request to the consortium chain and performing access policy verification. After obtaining authorization, they can request ciphertext data from the IoT platform and decrypt the ciphertext using attribute keys issued by multiple attribute authorization agencies. Device owners are responsible for managing several IoT devices, formulating access control policies for the data monitored by IoT devices, encrypting shared data, sending ciphertext to the consortium chain, generating metadata for verification, and finally uploading ciphertext to the IoT platform.

[0038] IoT platform: The cloud platform of this scheme. IoT data is massive, and device storage capacity is limited, making it impossible to store all data on the chain. Therefore, the data monitored by devices needs to be encrypted and stored uniformly in the cloud. The IoT platform is responsible for storing and managing all data monitored by IoT devices and returning ciphertext to users according to the permissions included in the user Token after the consortium chain authorizes the Token. If the Token contains metadata for performing data integrity verification, the IoT platform needs to generate data integrity proof according to the metadata information and write it into the consortium chain for user verification.

[0039] IoT device: As the largest component group in IoT, it is used to monitor various types of data. IoT devices usually do not have strong storage and computing capabilities and cannot serve as peer nodes in the consortium chain or store data independently. Therefore, they need to contact the IoT platform and the consortium chain to ensure efficient monitoring. Each IoT device has a unique deviceID for unique identification.

[0040] The basic interaction steps are as follows:

[0041] S1: The administrator registers with the CA, builds a consortium chain network, deploys smart contracts, and initializes the consortium chain.

[0042] S2: The user registers with the CA, generates attribute keys and signature keys

[0043] S3: The user of the device registers the device and connects it.

[0044] S4: Define the ciphertext access control policy, obtain the communication nodes, send the monitored data ciphertext to the consortium chain, generate metadata, and finally send the monitored data ciphertext to the IoT platform.

[0045] S5: The user requests access, obtains the policy structure, and generates a signature. The consortium chain verifies the signature, and if it is legal, it generates a Token.

[0046] S6: The user accesses the IoT platform data using the Token, the platform administrator performs verification, and if the verification is successful, the proof is written into the consortium chain, and the ciphertext is returned to the user.

[0047] S7: Users obtain data integrity proof from the consortium blockchain and verify the proof.

[0048] S8: If the verification fails, the user initiates a compensation verification to the consortium blockchain. The consortium blockchain obtains the proof information, performs the verification, and determines the responsible party.

[0049] A verifiable access control method for the Internet of Things based on consortium blockchains, the process is as follows: Figure 2 As shown,

[0050] S1: Each AA initiates a registration request to the trusted CA, jointly building a consortium blockchain network on the internal network, and performing initialization, creating groups, and deploying smart contracts. The steps are as follows:

[0051] S11: Each AA initiates a registration request to the trusted CA to obtain a certificate and jointly maintains the consortium blockchain member nodes. The CA generates a globally common parameter GP and stores it in the consortium blockchain system parameter contract. The CA generates a unique identifier AA for each AA. id And by AA id The GP generates a public-private key pair, APK and ASK, for each AA. After AA registration, the public key APK is stored in the consortium blockchain system parameter contract.

[0052] CA→{AA id APK i ASK i} (1-1)

[0053] Upload(AA id APK i → contract (1-2)

[0054] S12: In the consortium blockchain network, each node runs via Docker, and each node's certificate is packaged into a Docker container. After the nodes are configured, multiple channels are established. Nodes in each channel jointly maintain a consortium blockchain network, and the channels are isolated from each other to ensure scalable performance.

[0055] Build(conf,Cert node )→Imgae, Run(Image)→Container (1-3)

[0056] Init(channel)→{blockchain,ledger} (1-4)

[0057] S13: The smart contract required for the deployment plan, and the consensus reached among the nodes.

[0058]

[0059] S14: After the smart contract is deployed, the consortium chain network initializes it. The Init function is executed to instantiate the smart contract, create a design document, and view functions.

[0060]

[0061] S2: The user registers an account through a trusted CA. After successful registration, the CA notifies each AA to generate attribute private keys for the user, including attribute keys and signature keys.

[0062] S21: The user initiates a registration request to the trusted CA, and the CA generates a unique U id ID for each user. id The CA generates a public-private key pair UPK and USK for the user, and saves the user public key UPK in the system parameter contract.

[0063] CA→{U id , UPK, USK} (1-7)

[0064] Upload(U id , UPK)→contract (1-8)

[0065] S22: The CA notifies each AA responsible for the relevant attributes to generate attribute keys for the user to decrypt ciphertexts and signature keys for signing authorization requests based on the user's attribute information. The specific steps are as follows:

[0066] (1): Each AA executes the ABE.KeyGen(GP, U id , i, ASK i ) function offline. The input includes the public parameter GP, the user's unique identifier U id , the attribute i held by the user managed by each AA, and the private key ASK i of each AA. The output is the attribute key ABE.SK i sent to the user. The user combines all the attribute keys obtained to get the attribute key set {ABE.SK i}.

[0067]

[0068] (2): Each AA executes the ABS.KeyGen(GP, U id , ASK i , UPK) function offline. The input includes the public parameter GP, the user's unique identifier U id , the attribute i held by the user managed by each AA, the private key ASK i of each AA, and the user's public key UPK. The output is the signature key ABS.SK iSends to the user. The user combines all the signature keys obtained to obtain a set of signature keys {ABS. SK i}.

[0069]

[0070] S3: The user to whom the device belongs registers the Internet of Things device and accesses the Internet of Things platform.

[0071] S31: The user to whom the device belongs registers the device from the CA, obtains the device unique identifier deviceID and the device public and private keys {devicePK, deviceSK}, and saves them in the alliance chain Token configuration contract.

[0072] CA, U id → {deviceID, devidePK, deviceSK} (3-1)

[0073] S32: The user to whom the device belongs accesses the Internet of Things platform through the MQTT protocol, and saves the device unique identifier deviceID and the public key devicePK in the Internet of Things platform. The devicePK is used for Token verification in the subsequent access control process.

[0074]

[0075] S4: The Internet of Things device formulates an access control strategy and encrypts the monitored data every fixed time period, saves the access control strategy in the strategy configuration contract, then initiates a data processing request to the alliance chain, obtains a communication node, sends the encrypted ciphertext to the communication node, generates metadata and a commitment value, reaches consensus and saves them in the alliance chain network, and finally the communication node saves the ciphertext in the Internet of Things platform and deletes the local data.

[0076] S41: For the data file F monitored by the device every time period, define the access strategy structure (A, p), A is an LSSS matrix constructed by a Boolean form access strategy tree, and p is a function that maps each row of the matrix to an attribute. A symmetric key K is randomly selected to encrypt F to generate a ciphertext CT1, then a chain function Encrypt (GP, K, (A, p), {APK i}) is executed, the input includes the public parameter GP, the key K to be encrypted, the defined access strategy structure (A, p) and the public key {APK i} of the AA responsible for the related attribute, and the key K is encrypted to generate a ciphertext CT2. The ciphertext CT = {CT1, CT2}. Finally, the access strategy structure is saved in the strategy configuration contract in the form of {deviceID, timeInterval, (A, p)}.

[0077] S42: Call the communication node selection smart contract, and pass in the parameters (Size, H(CT), T, timeInterval) as the file size of the ciphertext of the monitoring data in this time period, the ciphertext hash value, the time stamp of the initiation, and the monitoring start and end time. The node processing this transaction is selected as the communication node through the PBFT consensus algorithm.

[0078] S43: Call the metadata generation smart contract, and send the ciphertext to the communication node. Pass in the parameters (CT, n). The communication node will verify whether CT matches H(CT) sent when the node was previously selected. If it matches, the communication node generates n metadata according to the sent ciphertext CT and calculates the commitment value.

[0079] The specific steps are as follows:

[0080] (1): The communication node takes a large prime number p (p>2 160 ), for and 4a 3 +27b 2 ≠0. Define the elliptic curve equation E p (a,b).

[0081] E p (a,b): y 2 ≡x 3 +ax+b(mod p) (4-1)

[0082] All points of this equation form an elliptic curve. The communication node selects two points Q and G on the curve, where G is the predetermined generating point of the curve, and Q=kG (k is the private key of the node, and Q is the public key obtained by using the elliptic curve multiplication of the private key).

[0083] (2): Define Pedersen commitment: the communication node as the committer can select Let r make a commitment to x, and the commitment value calculation formula is:

[0084] C(x,r)=xG+rQ (4-2)

[0085] (3): Define the pseudo-random function f: take and {1,2,...,n} to do Cartesian product, and map the obtained set to

[0086]

[0087] (4): Define the pseudo-random permutation: take and {1,2,...,n} to do Cartesian product, and map the obtained set to {1,2,...,n}.

[0088]

[0089] (5) Calculate random values;

[0090] r i = f(i) 1≤i≤n (4-5)

[0091] (6) Calculate the hash value according to the n random values obtained;

[0092] h i = H(F||r i ) 1≤i≤n (4-6)

[0093] (7) The communication node performs n Pedersen commitments on the n random values and hash values obtained:

[0094] C i = C(h i , r i ) = h i G + r i Q 1≤i≤n (4-7)

[0095] (8) The communication node saves the metadata and the generated commitment value in the metadata generation smart contract, and broadcasts the transaction of calling the contract to set the commitment value to the nodes of the alliance chain. The nodes of the alliance chain reach consensus.

[0096] S44: The communication node sends the ciphertext to the IoT platform in the form of {deviceID, CT, H(CT), timeInterval, Tx}. After receiving the file, the IoT platform first obtains the hash value of the ciphertext by checking the transaction of calling the contract when the communication node selects the contract of the user to which the device belongs, and compares it with the hash value of the data sent by the communication node. If they are consistent, it means that there is no error in the transmission process. The IoT platform calls the file storage result function in the metadata generation smart contract and inputs "1" to represent storage success, and triggers the file storage success event. After the communication node views the file storage success event, it knows that the data has been stored successfully, and deletes the local file CT. If they are not consistent, the file storage result function is called and "0" is input to represent storage failure, and the file storage failure event is triggered, and the data needs to be sent again.

[0097] When generating metadata, n metadata are generated for any ciphertext file initially. As the number of access verifications increases, when the metadata are about to be exhausted, new metadata need to be generated for subsequent access verification. The selected scheme in this paper is that the alliance chain node initiates a request to the IoT platform to reacquire the ciphertext file, and uses the remaining metadata to perform integrity verification on the sent ciphertext file. After verification, metadata are generated again according to the above steps, and the file data is deleted locally, so as to realize dynamic updating of the metadata.

[0098] S5: The user initiates an access control request to the alliance chain, requesting to obtain authorization for accessing data of a specified device. The alliance chain judges whether the user has access rights according to the saved access control policy and the signature information of the user.

[0099] S51: The user calls the alliance chain policy configuration contract to obtain the access policy structure (A, p) defined by the device owner according to the deviceID and time interval of the device to be accessed. Then the user executes the off-chain function Sign(GP, M, (A, p), USK, UID, {ABS. SK i}) to input the public parameter GP, the message M to be signed {U id , deviceID, timeInterval}, the private key USK of the user and the signature key set {ABS. SK i} of the user. When {ABS. SK i} satisfies (A, p), the signature sigma of the message M with (A, p) can be generated.

[0100] PolicyConfContract(deviceID, timeInterval)→(A, p) (5-1)

[0101]

[0102] S52: The user calls the access control contract signature verification function. The device information {deviceID, timeInterval} to be accessed, the signed message M, U id and the signature information sigma are input. The on-chain function Verify(GP, U id , sigma, (A, p), M, {APK i}) is executed inside this function. Where M represents the message to be verified, and {APK i} represents the public key set of AA corresponding to the attributes appearing in the access control policy. If the verification is successful, the Token is generated and returned to the user, otherwise, the error information is returned.

[0103]

[0104] S53: After verifying the legality of the user's signature, it can be proved that the identity of the access user satisfies the access policy, and then the Token configuration contract is called to issue Token for the user. Specifically, U idDevice information, policy information, etc., are stored in the payload. Then, the consortium blockchain node selects a random number i, calculates w = π(i), and checks whether w already exists in set L. If it does not exist, w is used as the index of the random value in the metadata used for this user access; if it exists, the next random value is taken. w is stored in set L to ensure that different metadata is used for each user access, thus preventing the IoT platform from reusing proofs generated from previously generated metadata. w and r are then... w It is also stored in the payload. Subsequently, the consortium blockchain node calls the Token configuration contract to obtain the deviceSK of the requested device. The header and payload in the Token are RSA-signed using the deviceSK to generate a Signature, which is then combined into the Token. The Token and r are then... w The corresponding h w Return it to the user along with the other information.

[0105] S6: After obtaining the token, the user sends a request to the IoT platform for data resources within the access permissions.

[0106] S61: The user sends a resource acquisition request to the IoT platform with a token.

[0107]

[0108] S62: The IoT platform administrator verifies the validity of the token. First, it verifies whether the request subject matches the subject information in Token.Payload. Then, it uses the devicePK of the accessed device to verify Token.Signature. After successful token verification, the IoT platform administrator parses the device attributes and metadata information stored in Token.Payload to find the encrypted CT of the monitored data stored by the device. Based on the r in the metadata... w The hash value is obtained by hashing the saved encrypted file CT, a proof is generated, and written into the chain.

[0109]

[0110] Upload(deviceID,timeInterval,evidence)→contract (6-3)

[0111] The execution steps are as follows:

[0112] (1): File F and random value r w Hash operations on concatenation: h' w =H(CT||r w )

[0113] (2): Generate the proof: evidence = (w, r w , h w )

[0114] (3): The last IoT platform administrator writes the generated proof combined with the device ID and monitoring time period (deviceID, timeInterval, evidence) into the integrity verification contract, and triggers the proof generation event, waiting for the user to obtain and verify.

[0115] S63: Send the ciphertext file of the data the user wants to access to the user.

[0116]

[0117] S7: After the user obtains the ciphertext file CT and sees the proof generation event, the user can call the integrity verification contract to obtain the data integrity proof and verify the proof, and determine whether the h w returned by the IoT platform is equal to the h w in the metadata sent by the alliance chain this time. If they are equal, the verification is passed, and the IoT platform indeed maintains the file data integrity. The user can execute the off-chain function Decrypt(GP, U id , CT2, {ABE. SK i}) to decrypt CT2 to obtain the symmetric key K. The function input is the public parameter GP, the user's unique identifier U id , the ciphertext CT2, and the user's attribute key {ABE. SK i}. After obtaining K, the user can execute decryption on CT1 to obtain the original data. Conversely, if they are not equal, the verification fails, and the user applies for compensation verification with the communication node.

[0118]

[0119] S8: When the data integrity proof obtained by the user is inconsistent with the locally saved h w , interact with the communication node to call the compensation verification contract to apply for compensation verification, and the communication node verifies the proof to determine the responsible party.

[0120] The compensation verification steps are as follows:

[0121] S81: The user calls the compensation verification function in the compensation verification contract, and inputs the issued Token.

[0122] S82: The communication node verifies and parses the Token to obtain the metadata w and r wand device identifier deviceID and monitoring time interval timeInterval, denoted as S=(deviceID, timeInterval, w, r w ).

[0123] S83: The communication node calls the acquisition verification proof function in the integrity verification contract to acquire the integrity proof evidence=(w, r w , h' w ) of the file data monitored by the device in this time interval saved by the Internet of Things platform according to S.deviceID, S.timeInterval, judges whether S.r w is equal to evidence.r w . If not, it means that the Internet of Things platform uses the previous integrity proof verification as this time proof, and there is a replay attack. If they are equal, the commitment value C' w is calculated through evidence.r w and evidence.h' w , and the calculation formula is as follows:

[0124] C' w = C(evidence.h' w , evidence.r w ) = (evidence.h' w )G + (evidence.r w )Q (8-1)

[0125] S84: The communication node calls the acquisition file commitment value function in the metadata generation contract to obtain the commitment value C w of the initially generated file metadata according to S.deviceID, S.timeInterval and S.w, judges whether C' w is equal to C w . If they are equal, it means that the Internet of Things platform has no error, the data is saved completely, and it is the user's responsibility, triggering the user responsibility event; if they are not equal, it means that the Internet of Things platform data is not complete, and it is the responsibility of the Internet of Things platform, triggering the Internet of Things platform responsibility event, and the party responsible needs to compensate.

[0126] A kind of Internet of Things verifiable access control method based on alliance chain smart contract design as Figure 3 shown, the method mainly involves eight smart contracts:

[0127] (1) System parameter contract (SPC)

[0128] SPC is mainly used to store and manage system parameters used in the whole access control process, which can be called by all users. It includes global shared parameters, user public key, AA public key, etc. It provides chain code functions such as adding, modifying, querying and deleting for managed parameters.

[0129] (2) Policy configuration contract (PCC)

[0130] PCC is mainly used to store and manage the access control policy defined by the user to which the device belongs, and to provide the verifier with the signature generated by the accesser in the execution of the access control.

[0131] (3) Access control contract (ACC)

[0132] ACC is a contract directly called by the user to execute access control, which will process the user's request and verify whether the user's signature on the access policy structure is valid, so as to determine whether the user meets the access control policy. If it meets, it will issue Token for authorization.

[0133] (4) Token configuration contract (TCC)

[0134] The core function of TCC is to issue Token for the user after the user passes the access policy verification. Token contains user unique identifier, device attribute information and metadata used to verify the integrity of the queried data. After the user gets Token, he initiates a data access request to the Internet of Things platform. The administrator of the Internet of Things platform verifies the user's Token and reads the user's obtained permissions, and then returns the corresponding ciphertext data. In the device access stage, TCC also saves the ID and public key of the device, which is used for Token verification.

[0135] (5) Communication node selection contract (CSC)

[0136] CSC is mainly used for device to select communication node, which is convenient for subsequent uploading of monitoring data to generate metadata and execute Pedersen commitment.

[0137] (6) Metadata generation contract (MGC)

[0138] MGC is used to generate and save the metadata of the monitoring data file, and to calculate the commitment value according to the file and the metadata. After consensus, it is saved in the alliance chain network, which is used for the verification of data integrity in the subsequent access process.

[0139] (7) Integrity Verification Contract (IVC)

[0140] IVC is mainly used for the storage and reading of data integrity proof. After the user access verification, the user is issued a Token, which contains the metadata of the accessed data. When the user requests access to the data from the IoT platform, the user obtains the proof generated by the IoT platform through the IVC to perform data integrity verification.

[0141] (8) Compensation Verification Contract (CVC)

[0142] After the user obtains the data stored by the IoT platform, the user performs integrity verification, and when the verification fails, the user submits an arbitration to the alliance chain through the CVC. The alliance chain node obtains the proof stored in the IVC by the IoT platform, completes the arbitration between the user and the IoT platform according to all the parameters stored by itself, and finally gives the responsible party.

Claims

1. A verifiable access control method for IoT data based on consortium blockchain, characterized in that: Includes the following steps: S1. The administrator registers with the CA, builds the consortium blockchain network, deploys smart contracts, and initializes the consortium blockchain; S2. The user registers with the CA and generates an attribute key and a signature key; S3. The user to whom the device belongs registers the device and connects to the device; S4. Define the encrypted access control policy, obtain the communication node, send the encrypted monitoring data to the consortium blockchain, generate metadata, and finally send the encrypted monitoring data to the IoT platform. The monitoring data upload process includes: defining access control policies; acquiring communication nodes; sending encrypted monitoring data to the consortium blockchain, generating metadata, calculating commitment values, and storing them in a smart contract; and sending the encrypted data to the IoT platform, specifically including the following steps: S41: Define access control policies; For the data file F monitored by the device per time interval, define the access policy structure (A, p), A is an LSSS matrix constructed by a Boolean form access policy tree, p is a function that maps each row of the matrix to an attribute; randomly select a symmetric key K to encrypt F to generate ciphertext CT1, then execute the off-chain function Encrypt (GP, K, (A, p), {APK i}), input includes public parameters GP, the key to be encrypted K, the defined access policy structure (A, p) and the public key of the AA responsible for the related attributes {APK i}, encrypt the key K to generate ciphertext CT2; ciphertext CT = {CT1, CT2}; finally save the access policy structure in the form of {deviceID, timeInterval, (A, p)} in the policy configuration contract; S42: Obtain the communication node; The user calls the communication node to select a smart contract, and passes in the parameters (Size, H(CT), T, timeInterval), which are the file size of the encrypted data monitored in this time period, the encrypted hash value, the timestamp of the initiation, and the start and end times of monitoring, respectively. The node that processes this transaction is selected as the communication node through the PBFT consensus algorithm. S43: Sending encrypted monitoring data and calculating the consensus of the commitment value are done in the smart contract; The user will call the metadata to generate a smart contract and send the ciphertext to the communication node with the parameters (CT, n). The communication node will verify whether CT matches H(CT) sent when the node was previously selected. If they match, the communication node will generate n metadata based on the ciphertext CT and calculate the generated commitment value. S44: Send the encrypted message to the IoT platform; The communication node stores the encrypted data used to generate metadata on the IoT platform and deletes the local data; S5. When a user requests access, the strategy structure is obtained and a signature is generated; the consortium blockchain verifies the signature, and if it is valid, a token is generated. S6. Users use tokens to access IoT platform data. The platform administrator verifies the tokens. Once the verification is successful, the proof is written into the consortium blockchain and returned to the user in encrypted form. S7. The user obtains the data integrity certificate from the consortium blockchain and verifies the certificate; S8. If the verification fails, the user initiates a compensation verification to the consortium blockchain. The consortium blockchain obtains the proof information, performs the verification, and determines the responsible party.

2. The IoT data verifiable access control method based on consortium blockchain according to claim 1, characterized in that, In step S1, the administrator registers as an attribute authorization center (AA) and initiates a registration request to the trusted CA to obtain a certificate, jointly maintaining the consortium blockchain member nodes; the CA generates a global public parameter GP and stores it in the consortium blockchain system parameter contract; CA generates a unique identifier AA for each AA id and by AA id and GP generates a public-private key pair APK and ASK for each AA; the public key APK is saved in the consortium chain system parameters contract after AA registration.

3. The IoT data verifiable access control method based on consortium blockchain according to claim 1, characterized in that, In step S2, user registration involves the user registering an account through a trusted CA. After successful registration, the CA notifies each AA to generate a key for the user. including an attribute key set {ABE.SK i} and a signature key set {ABS.SK i}, specifically comprising the following steps: S21: Generate attribute keys; Each AA executes ABE.KeyGen(GP, U) in the chain. id ,i,ASK i The function takes the common parameters GP and the user's unique identifier U as inputs. id The attributes i held by the users managed by each AA and the private key ASK of each AA. i Output attribute key ABE.SK i Send to the user; the user combines all the received attribute keys to obtain the attribute key set {ABE.SK}. i }; S22: Generate the signature key; Each AA executes ABS.KeyGen(GP, U) off-chain. id ASK i The function (UPK) takes the common parameter GP and the user's unique identifier U as input. id The attributes i held by users managed by each AA, and the private key ASK of each AA. i The user's public key UPK is used to output the signing key ABS.SK. i Send to the user; the user combines all the received signature keys to obtain the signature key set {ABS.SK}. i }:

4. The method for verifiable access control of IoT data based on consortium blockchain according to claim 1, characterized in that, In step S3, device registration involves the user of the device registering the device with the CA, obtaining the device's unique identifier deviceID and device public and private keys {devicePK, deviceSK}, and storing them in the consortium blockchain smart contract. After device registration, the device connects to the IoT platform via the MQTT protocol, and stores the device's unique identifier deviceID and public key devicePK on the IoT platform. devicePK is used for token verification in the subsequent access control process.

5. The IoT data verifiable access control method based on consortium blockchain according to claim 1, characterized in that, In step S43, the commitment value is calculated and generated; the commitment scheme is as follows: (1) The communication node is chosen to be a large prime number p, where p>2 160 ,for And 4a 3 +27b 2 ≠0; Define the equation of the elliptic curve E p (a,b); E p (a,b)∶y 2 ≡x 3 +ax+b(mod p)(4-1) All points of this equation form an elliptic curve; the communication node selects two points Q and G on the curve, where G is the predetermined generation point of the curve, Q = kG, k is the node's private key, and Q is the public key obtained by multiplying the private key using elliptic curve multiplication. (2) Define Pedersen commitment: The communication node can choose to act as the committer. Let r make a commitment to x, and the formula for calculating the commitment value is: C(x,r)=xG+rQ (4-2) (3) Define a pseudo-random function f: Perform a Cartesian product with {1,2,...,n}, and map the resulting set to... (4) Define pseudo-random permutation: Perform a Cartesian product with {1,2,...,n} to map the resulting set to {1,2,...,n}; (5) Calculate the random value; r i =f(i) 1≤i≤n; (4-5) (6) Calculate the hash value based on the n random values ​​obtained; h i =H(F || r i ) 1≤i≤n; (4-6) (7) The communication node performs n Pedersen commitments on the obtained n random values ​​and hash values: C i =C(h i ,r i )=h i G+r i Q 1≤i≤n (4-7) (8) The communication node stores the metadata and the generated commitment value in the metadata generation smart contract. The communication node broadcasts this transaction that calls the contract to set the commitment value to each node of the consortium chain, and the consortium chain nodes reach a consensus.

6. The IoT data verifiable access control method based on consortium blockchain according to claim 1, characterized in that, In step S5, the user request for access involves the user initiating an access control request to the consortium blockchain, requesting authorization to access data from a specified device. The user invokes the consortium blockchain policy configuration contract to obtain the access policy structure (A, ρ) defined by the device owner based on the device ID and time period of the device to be accessed. Then, the user executes the off-chain function Sign(GP, M, (A, ρ), USK, UID, {ABS.SK i }), the input includes the public parameter GP, and the message to be signed M = {U id The set of user keys {ABS.SK}, deviceID, timeInterval}, user's private key USK, and user's signing key set {ABS.SK} i }, in {ABS.SK i When (A, ρ) is satisfied, a signature σ of a message M with (A, ρ) can be generated; after the user generates the signature, the access control contract signature verification function will be called; the device information requested for access {deviceID, timeInterval}, the signed message M, and U are passed in. id and signature information σ; inside this function, the on-chain function Verify(GP, U) will be executed. id ,σ,(A,p),M,{APK i }); where M represents the message whose signature is to be verified, {APK i } represents the set of public keys of the AA corresponding to the attribute appearing in the access control policy; if the verification is successful, a token is generated and returned to the user; otherwise, an error message is returned.

7. The IoT data verifiable access control method based on consortium blockchain according to claim 1, characterized in that, In step S6, token verification involves the user requesting access to data resources from the IoT platform after obtaining a token issued by the consortium blockchain. The IoT platform administrator verifies the token's validity by first verifying that the requesting entity matches the entity information in Token.Payload, and then using the accessed device's devicePK to verify Token.Signature. After successful token verification, the IoT platform administrator parses the device attributes and metadata information stored in Token.Payload, finds the encrypted CT of the monitored data stored on the device, and then uses the r in the metadata... w The hash value is obtained by hashing the saved encrypted file CT, a proof is generated, and written into the chain; the execution steps are as follows: S61: Calculate the hash value File F and random value r w Perform hash operations on the concatenation; h′ w =H(CT||r w ) S62: Generating a proof from known information By w, r w and h′ w Generate proof: evidence = (w, r w ,h′ w ) S63: Write the proof into the contract The IoT platform administrator writes the generated proof, along with the device ID and monitoring time period (deviceID, timeInterval, evidence), into the integrity verification contract and triggers the proof generation event, which is then retrieved and verified by the user. Finally, the administrator sends the encrypted file of the data that the user wants to access to the user.

8. The IoT data verifiable access control method based on consortium blockchain according to claim 1, characterized in that, In step S7, after the user obtains the encrypted file CT and sees the proof generation event, the data integrity verification can call the integrity verification contract to obtain the data integrity proof and verify the proof, judging the h′ returned by the IoT platform. w The h in the metadata sent by the consortium blockchain during this access w Check if they are equal; if they are equal, the verification passes, and the IoT platform has indeed maintained the integrity of the file data; the user can execute the off-chain function Decrypt(GP,U id ,CT2,{ABE.SK i The function decrypts CT2 to obtain the symmetric key K; its inputs are the common parameter GP and the user-unique identifier U. id , Ciphertext CT2 and user-related attribute key {ABE.SK i After obtaining K, CT1 can be decrypted to obtain the original data. Conversely, if they are not equal, the verification fails, and the user requests compensation verification from the communication node.

9. The IoT data verifiable access control method based on consortium blockchain according to claim 1, characterized in that, In step S8, the compensation verification involves the user initiating another verification request to the consortium blockchain after failing to verify data integrity. The steps are as follows: S81: The user sends a token; The user calls the compensation verification function in the compensation verification contract, passing in the issued token; S82: Perform token parsing; The communication node verifies and parses the token, retrieving the metadata w and r stored in the token. w And the device identifier deviceID and the monitoring time period timeInterval, denoted as S = (deviceID, timeInterval, w, r w ); S83: The communication node calculates the commitment value; The communication node calls the "Get Verification Proof" function in the integrity verification contract to obtain the integrity proof evidence (w, r) of the file data monitored by the device during this time period, stored by the IoT platform, based on S.deviceID and S.timeInterval. w ,h′ w ), determine Sr w With evidence.r w If they are equal, it means the IoT platform used the proof from the previous integrity verification as the proof for this verification, indicating a replay attack; if they are equal, then it passes the evidence.r test. w and evidence.h′ w Calculate the generated commitment value C′ w The calculation formula is as follows: C′ w =C(evidence.h′ w ,evidence.r w )=(evidence.h′ w )G+(evidence.r w )Q(8-1) S84: Comparison of commitment values ​​between communication nodes; The communication node calls the function to obtain the file commitment value in the metadata generation contract, and obtains the commitment value C of the initially generated file metadata based on S.deviceID, S.timeInterval, and Sw. w Determine C′ w With C w If the values ​​are equal, it means the IoT platform has no errors and the data is stored completely, which is the user's responsibility and triggers a user liability event. If the values ​​are not equal, it means the IoT platform's data is not stored completely, which is the IoT platform's responsibility and triggers an IoT platform liability event, in which the responsible party needs to provide compensation.

Images