Smart contract cross-domain access method based on master-slave chain architecture

Abstract

The invention provides an intelligent contract cross-domain access method based on a master-slave chain architecture, and the method comprises the steps: analyzing and verifying a cross-domain access request according to a public key of a slave chain corresponding to the Internet of Things equipment when the slave chain receives the cross-domain access request sent by any Internet of Things equipment; when the cross-domain access request passes verification, according to the analyzed cross-domain access request and an authority control strategy stored by the smart contract, determining whether the Internet of Things device has the authority to access the current Internet of Things domain; the authority control strategy stored by the smart contract is to dynamically adjust the access authority of the Internet of Things equipment by analyzing the historical behavior and request content of the Internet of Things equipment; when the Internet of Things equipment has the access authority, a cross-domain access request is sent from the chain to the main chain; and when the slave link receives the cross-domain access certificate issued by the main chain, the cross-domain access certificate is sent to the Internet of Things equipment. The authentication steps are reduced, the access process is simplified, and the access efficiency is improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain, and in particular relates to a cross-domain access method for smart contracts based on a master-slave chain architecture. Background Art

[0002] With the rapid development of the Internet of Things, the demand for data access by terminal devices in different trusted application domains is growing. In most cases, IoT devices authenticate themselves through their registered trusted application domains and access relevant data resources. However, with the surge in the number of trusted application domains, the interaction between domains is becoming increasingly intensified. In some cases, terminal devices need to access data in non-registered trusted application domains in order to collaborate with devices in other domains to complete specific tasks.

[0003] Different from intra-domain access, cross-domain access faces greater security challenges. In order to ensure the security of access, related technologies set up complex access rights verification, which has a lengthy process, low processing efficiency, and poor flexibility. Summary of the invention

[0004] In view of this, the purpose of the present invention is to provide a smart contract cross-domain access method and device based on a master-slave chain architecture to meet the needs of improving processing efficiency and flexibility.

[0005] In order to achieve the above object, the present invention provides the following technical solutions:

[0006] According to a first aspect, the present invention provides a smart contract cross-domain access method based on a master-slave chain architecture, the master-slave chain architecture includes an Internet of Things domain layer, a slave chain layer and a main chain layer, any slave chain corresponds to at least one Internet of Things domain, and an Internet of Things domain layer includes multiple Internet of Things devices, the method comprising: when a cross-domain access request issued by any Internet of Things device is received from a link, the cross-domain access request is parsed and verified according to the public key of the slave chain corresponding to the Internet of Things device; when the cross-domain access request passes the verification, according to the parsed cross-domain access request and the permission control policy stored in the smart contract, it is determined whether the Internet of Things device has the permission to access the current Internet of Things domain, and the permission control policy stored in the smart contract is to dynamically adjust the access rights of the Internet of Things device by analyzing the historical behavior of the Internet of Things device and the request content; when the Internet of Things device has the access rights, the slave chain sends a cross-domain access request to the main chain; when the slave link receives the cross-domain access certificate issued by the main chain, the cross-domain access certificate is sent to the Internet of Things device, so that the Internet of Things device can perform cross-domain access according to the cross-domain access certificate.

[0007] Optionally, a cross-domain access method for smart contracts based on a master-slave chain architecture also includes: when the slave link receives an access request carrying a cross-domain access certificate from any IoT device, the access request is verified; when the access request verification is successful, the slave chain sends a verification pass message carrying the cross-domain access certificate to the master chain so that the master chain can open an access interface; the slave link receives an access interface opening confirmation message issued by the master chain.

[0008] Optionally, a cross-domain access method for smart contracts based on a master-slave chain architecture also includes: when an intra-domain access request is received from any IoT device, the intra-domain access request is parsed and verified according to the public key of the slave chain corresponding to the IoT device, the intra-domain access request contains sensitive data, and the sensitive data is homomorphically encrypted data; when the intra-domain access request passes the verification, it is determined whether the IoT device has intra-domain access rights based on the parsed intra-domain access request and the permission control policy stored in the smart contract, and the permission control policy stored in the smart contract is to dynamically adjust the access rights of the IoT device by analyzing the historical behavior of the IoT device and the request content; when the IoT device has access rights, an intra-domain access certificate is generated from the slave chain, and the intra-domain access certificate is sent to the IoT device and the master chain, and the intra-domain access certificate is homomorphically encrypted data.

[0009] Optionally, the cross-domain access request issued by the IoT device contains sensitive data, and the sensitive data is encrypted using homomorphic encryption; the cross-domain access certificate is homomorphically encrypted data.

[0010] Optionally, a cross-domain access method for smart contracts based on a master-slave chain architecture, the method also includes: the smart contract obtains the behavioral data of the IoT device when processing homomorphically encrypted data, and analyzes the behavior of the IoT device; the smart contract determines whether the behavior of the IoT device is legal and meets the decryption conditions. When it is legal and meets the decryption conditions, a decryption key is issued through the master chain or the slave chain corresponding to the IoT device, so that the IoT device can use the key to decrypt and access its content.

[0011] Optionally, a cross-domain access method for smart contracts based on a master-slave chain architecture also includes: the smart contract continuously monitors the behavioral data of IoT devices and analyzes the behavior of IoT devices, and when the behavior of the IoT devices is abnormal, the decryption key is revoked.

[0012] Optionally, a cross-domain access method for smart contracts based on a master-slave chain architecture, and a permission control strategy for smart contract storage, include: the smart contract obtains historical behavior data of the Internet of Things device; the smart contract determines whether the historical behavior of the Internet of Things device meets the permission upgrade conditions based on the historical behavior data, and when the permission upgrade conditions are met, adjusts the access permission level of the Internet of Things device.

[0013] Optionally, a cross-domain access method for smart contracts based on a master-slave chain architecture also includes: the smart contract predicts the data access type of the IoT device based on the historical behavior data of the IoT device, and controls the corresponding IoT domain to pre-cache the corresponding access type data; when an access request from the IoT device is received, the corresponding data is retrieved from the access type data pre-cached in the corresponding IoT domain.

[0014] According to the second aspect, an embodiment of the present invention provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the steps of the cross-domain access method for smart contracts based on the master-slave chain architecture described in the first aspect or any implementation scheme of the first aspect.

[0015] According to the third aspect, an embodiment of the present invention provides a computer storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the cross-domain access method for smart contracts based on the master-slave chain architecture as described in the first aspect or any embodiment of the first aspect.

[0016] The present invention provides a cross-domain access method for smart contracts based on a master-slave chain architecture. Under the dynamic smart contract mechanism, the permission control strategy stored in the smart contract is to dynamically adjust the access rights of the IoT device by analyzing the historical behavior of the IoT device and the request content. This dynamic adjustment method makes the permission management more flexible and adaptable. At the same time, if the IoT device has good behavior in the previous access, its permission will also be larger. This means that in subsequent cross-domain access, it is no longer necessary to perform a complete permission authentication, which reduces the authentication steps and improves the access efficiency.

[0017] Other advantages, objectives and features of the present invention will be described in the following description and will be apparent to those skilled in the art to some extent, or those skilled in the art may be taught from the practice of the present invention. The objectives and other advantages of the present invention may be realized and obtained through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to make the purpose, technical solution and beneficial effects of the present invention clearer, the present invention provides the following drawings for illustration:

[0019] Figure 1 A master-slave chain architecture diagram applicable to a cross-domain access method for smart contracts based on a master-slave chain architecture in the present invention;

[0020] Figure 2 This is a specific example flow chart of a cross-domain access method for smart contracts based on a master-slave chain architecture in the present invention;

[0021] Figure 3A data interaction diagram of an IoT device, a main chain, and a slave chain during a cross-domain access process in the present invention;

[0022] Figure 4 A data interaction diagram of an IoT device, a main chain, and a slave chain during the intra-domain access process in the present invention;

[0023] Figure 5 It is a principle block diagram of a specific example of an electronic device in an embodiment of the present invention. DETAILED DESCRIPTION

[0024] The technical solution of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0025] In the description of the present invention, it should be noted that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, it can also be the internal connection of two components, it can be a wireless connection, or it can be a wired connection. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0026] In addition, the technical features involved in the different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0027] This embodiment provides a cross-domain access method for smart contracts based on a master-slave chain architecture, which is applied to the master-slave chain architecture. Figure 1 As shown, it includes an IoT domain layer, a slave chain layer, and a master chain layer. Any slave chain corresponds to at least one IoT domain. An IoT domain layer includes multiple IoT devices. The cross-domain access method of smart contracts based on the master-slave chain architecture is as follows: Figure 2 As shown, including:

[0028] S101, when a cross-domain access request is received from any IoT device from the link, the cross-domain access request is parsed and verified according to the public key of the IoT device corresponding to the slave chain;

[0029] Exemplarily, the system used in this embodiment includes a three-layer architecture: the IoT domain layer, the slave chain layer, and the main chain layer, with the focus on performing permission authentication and data processing during cross-domain access through dynamic smart contracts. The IoT domain layer consists of multiple IoT devices, systems, and users. In cross-domain access, the request of the IoT device will be authenticated and data encrypted through a dynamic smart contract. The slave chain is responsible for generating blocks and maintaining communications between IoT devices, managing intra-domain and cross-domain identity authentication, and dynamic smart contracts ensure that permission issues can be flexibly handled according to different devices and access requests. As a trusted sharing platform, the main chain handles cross-domain requests and data transmission to ensure cross-chain security. The main chain will dynamically generate smart contracts based on the requests of the slave chains to handle the cross-domain requirements of different IoT devices.

[0030] This embodiment provides a data interaction diagram of IoT devices, the main chain, and the slave chain during cross-domain access, such as Figure 3 As shown in the figure, the smart contract processes cross-domain requests on the main chain, and determines whether the IoT device can access resources in other IoT domains across domains by parsing and verifying the access rights of the IoT device from the chain. Take the IoT device D in IoT domain 1 wanting to access IoT domain 2 as an example to describe the cross-domain access mechanism. The subchain of IoT domain 1 is called SC1, and the subchain of IoT domain 2 is called SC2.

[0031] IoT device D sends a cross-domain access request to slave chain SC2, which contains the public key PK. S , IoT device D’s private key signs the private key of slave chain SC1 and timestamp T1. The signature is the signature of the cross-domain access request using the private key of IoT device D. Its specific format can be:

[0032]

[0033] Among them, rq represents the specific content of the request, and from, to, and inf represent other information related to the request, such as time or specific data content.

[0034] As an optional implementation, the cross-domain access request also contains sensitive data, which is protected by homomorphic encryption. Homomorphic encrypted data is a special encryption technology that allows encrypted data to be operated without decrypting the data, and the result of the operation is still correct after encryption and decryption. This means that data can be operated or processed in an encrypted state without exposing the plaintext content of the data. By introducing homomorphic encryption technology, IoT devices can process data without decrypting it during cross-domain access, thereby further enhancing the security of private data. This ensures data security during cross-domain access and ensures that smart contracts always meet privacy protection requirements when processing sensitive data. While optimizing smart contracts, the risk of data leakage is greatly reduced.

[0035] After receiving the cross-domain access request from the slave chain SC2, the identity information of IoT device D is verified, and after confirming its permissions, a request containing homomorphic encrypted data is sent to the main chain. A dynamic smart contract will be generated in the slave chain to handle the cross-domain request and permission issues of IoT device D. Specifically, after receiving the request from the slave chain SC2, the public key PK of the IoT device is used to S Parse the request rq and the information of IoT device D.

[0036] S102, when the cross-domain access request passes the verification, determine whether the IoT device has the permission to access the current IoT domain based on the parsed cross-domain access request and the permission control policy stored in the smart contract. The permission control policy stored in the smart contract is to dynamically adjust the access rights of the IoT device by analyzing the historical behavior of the IoT device and the request content;

[0037] For example, when it is determined that the IoT device D is legal, the permission control policy Polity stored in the smart contract in the slave chain SC2 is used. SC2 , to determine whether IoT device D has access rights. Polity, a permission control strategy for smart contract storage SC2 To dynamically adjust the access rights of IoT devices by analyzing the historical behavior and request content of IoT devices. Specifically, the permission control strategy stored in the smart contract is Polity. SC2 It can be to analyze only the current access behavior and adjust the permissions of the IoT device. For example, during the device access process, if the IoT device shows stable and legal access behavior, the smart contract automatically upgrades its permissions and allows the device to access more resources. In addition, the permission control strategy Polity SC2 Alternatively, the access rights may be adjusted by regularly auditing the device behavior. This embodiment does not limit the specific form of the permission control policy, and those skilled in the art may determine it as needed.

[0038] S103, when the IoT device has access rights, the slave chain sends a cross-domain access request to the main chain;

[0039] For example, if the authentication is successful, a request for access is sent to the main chain MC:

[0040]

[0041] Among them, PK MC Indicates the public key of the main chain MC, Represents the public key of the slave chain SC2, PK SC1 Represents the public key of the slave chain SC1, SK SC2 Represents the private key of the slave chain SC2, PK D Represents the public key of IoT device D, Sig i (j) indicates that i is used to sign j.

[0042] If the authentication fails, it means that the device does not have the authority to access the local domain, and a rejection message of rejecting the IoT device D is returned from the chain SC2.

[0043]

[0044] Among them, Nack means insufficient authority.

[0045] The main chain MC receives the access request information from the slave chain SC2 and uses the public key of the slave chain to verify whether the request is legal. The main chain will dynamically generate smart contracts based on the cross-chain request to ensure the legality and security of data transmission and sharing between different domains. At the same time, the main chain MC generates a cross-domain access certificate and returns the certificate to the slave chain SC2. As an optional implementation method, the main chain MC uses homomorphic encryption when generating a cross-domain access certificate, and performs homomorphic encryption on the cross-domain access certificate to improve data security. The specific implementation method is as follows:

[0046] After the main chain MC receives the information from the slave chain SC2, it uses the public key PK of the slave chain SC2 SC2 Parse the data information, save the data from the chain locally, dynamically generate smart contracts, and generate a cross-domain access certificate Cert for IoT device D MD .

[0047]

[0048] Here, deadline indicates the validity period.

[0049] After the main chain MC generates the cross-domain access certificate, it returns the cross-domain access certificate to the slave chain SC2.

[0050] S104, when the cross-domain access certificate issued by the main chain is received from the link, the cross-domain access certificate is sent to the IoT device, so that the IoT device performs cross-domain access according to the cross-domain access certificate.

[0051] The above steps S101-S104 are given below as pseudo code for reference:

[0052]

[0053] The following is a detailed explanation of the above pseudo code:

[0054] Input: This is generated by the slave chain SC2 using its private key SK SC1 Contains the device public key PK D and its signature on message M The actual message is encrypted using a homomorphic encryption mechanism.

[0055] Output: Returns the certificate or returns an error.

[0056] 1. Parse the cross-domain access message using the public key from chain 1.

[0057] 2. If the cross-domain access message is illegal, an error message is returned.

[0058] 3. Otherwise, a dynamic smart contract is generated, and the main chain generates or calls the corresponding smart contract based on the request. Sensitive data in the entire smart contract execution process is kept encrypted through homomorphic encryption.

[0059] 4. Send the signed message together with the public key to the slave chain.

[0060] 5. Parse and decrypt the homomorphically encrypted data using the public key from chain 2.

[0061] 6. If the cross-domain access message is illegal, an error message is returned.

[0062] 7. Otherwise save the access data information.

[0063] 8. Generate and sign a cross-domain access certificate using homomorphic encryption MD , ensuring that access rights are verifiable while being encrypted.

[0064] 9. Return the generated cross-domain access certificate.

[0065]

[0066] The following is a detailed explanation of the above pseudo code:

[0067] Input: First, the IoT device D signs the message M, and then the main chain MC signs the signature of the IoT device D. The data is encrypted using homomorphic encryption technology.

[0068] Output: Verify the validity of the signature. If the verification passes, it returns the signature; if it fails, it returns an error.

[0069] 1. Use the main chain’s public key to parse cross-domain access messages.

[0070] 2. If the cross-domain access message is illegal, an error message is returned.

[0071] 3. Otherwise, use dynamic smart contracts to parse encrypted historical data, perform security authentication, ensure that cross-access or message delivery is legal and domain-secure, and send the signed message together with the public key to the slave chain.

[0072] 4. If the cross-domain message M is illegal, an error message is returned.

[0073] 5. Otherwise, if the cross-domain access message does not satisfy the permission control policy of chain 2, an error message is returned.

[0074] 6. Otherwise, obtain access data information.

[0075] 7. Generate a signature.

[0076] 8. Return the signature.

[0077] This embodiment provides a cross-domain access method for smart contracts based on a master-slave chain architecture. Under the dynamic smart contract mechanism, the permission control strategy stored in the smart contract is to dynamically adjust the access rights of the IoT device by analyzing the historical behavior and request content of the IoT device. This dynamic adjustment method makes the permission management more flexible and adaptable. At the same time, if the IoT device has good behavior in previous accesses, its permissions will also be greater. In a smart contract, once the IoT device obtains a higher trust level through behavior monitoring, the contract can maintain open permissions for a certain period of time, allowing the device to perform multiple cross-domain accesses within the time range without reapplying for permissions each time. This is equivalent to granting a "temporary pass" to the IoT device, simplifying the access process within a certain time window, and no longer requiring a complete permission authentication, reducing the authentication steps and improving access efficiency.

[0078] As an optional implementation, the cross-domain access method for smart contracts based on the master-slave chain architecture also includes: when the slave link receives an access request carrying a cross-domain access certificate from any IoT device, the access request is verified; when the access request verification is passed, the slave chain sends a verification pass message carrying the cross-domain access certificate to the master chain, so that the master chain can open the access interface; the slave link receives the access interface opening confirmation information issued by the master chain.

[0079] For example, IoT device D uses Cert MD Send the access request to the slave chain SC2 IoT domain again:

[0080]

[0081] Among them, SK D Represents the private key of IoT device D.

[0082] The slave chain SC2 verifies the request. After passing the verification, the verification pass message carrying the cross-domain access certificate is sent to the main chain:

[0083]

[0084] The main chain MC processes the data information and opens the access interface, so that the IoT device D can access it and sends a confirmation message to the slave chain SC2:

[0085]

[0086] Among them, Ack indicates confirmation information.

[0087] As an optional implementation method, the cross-domain access method of smart contracts based on the master-slave chain architecture also includes: when an intra-domain access request is received from any IoT device, the intra-domain access request is parsed and verified according to the public key of the slave chain corresponding to the IoT device, the intra-domain access request contains sensitive data, and the sensitive data is homomorphically encrypted data; when the intra-domain access request passes the verification, it is determined whether the IoT device has intra-domain access rights based on the parsed intra-domain access request and the permission control policy stored in the smart contract, and the permission control policy stored in the smart contract is to dynamically adjust the access rights of the IoT device by analyzing the historical behavior of the IoT device and the request content; when the IoT device has access rights, the slave chain generates an intra-domain access certificate, and sends the intra-domain access certificate to the IoT device and the master chain, and the intra-domain access certificate is homomorphically encrypted data.

[0088] For example, this embodiment provides a data interaction diagram of the IoT device, the main chain, and the slave chain during the intra-domain access process, such as Figure 4 As shown in the figure, the smart contract verifies the identity and permissions of the IoT device on the slave chain to determine whether it can access the system in the IoT domain. In the IoT domain, if an IoT device wants to access the IoT system, it will authenticate and access through the slave chain, and the main chain is only responsible for saving the status data of the IoT device. The IoT device, IoT system, slave chain and main chain are represented by D, S, SC and MC respectively. When accessing within the domain, the IoT device initiates an access request to the slave chain, and the slave chain is responsible for verifying whether the device has the permission to access the corresponding system. After receiving the request, the smart contract will be dynamically deployed and executed.

[0089] When an IoT device sends a domain access request, IoT device D generates a public key and a private key, and performs homomorphic encryption on the request data (including sensitive information). IoT device D signs the request with the private key and sends the public key, signature, and timestamp to the slave chain SC. Specifically, IoT device D generates a public key PK D and private key SK D , generate a domain access request rq, and use your own private key SK D Sign the certificate and then use your public key PK D , certificate signature and timestamp T1 are sent to the slave chain SC.

[0090]

[0091] in, IoT device D uses its own private key SK D Digital signature of the requested information ensures the authenticity and integrity of the information.

[0092] The slave chain SC uses the public key of device D to parse the request, verify whether the request is legal, and determine whether the device has access rights based on the storage permission control policy. The dynamic smart contract will generate or adjust the permission verification logic according to different request types and device characteristics. Specifically, after receiving the request from the slave chain SC, the public key PK of IoT device D is used to verify whether the request is legal. D Parse the request and the information of IoT device D, and according to the storage policy information Polity in the chain SC SC , determine whether the IoT device has access rights.

[0093] If the authentication is successful, a domain access certificate is generated for IoT device D:

[0094]

[0095] Here, deadline indicates the validity period.

[0096] After the intra-domain access certificate is generated, it is sent to the IoT device D and the main chain MC. This intra-domain access certificate will be used to access the IoT system S. Homomorphic encryption ensures that during data transmission, even if the slave chain or the main chain cannot decrypt the data, the privacy of the data is still guaranteed. The slave chain SC generates an intra-domain access certificate (including encrypted certificate information) and sends it to the main chain MC as follows:

[0097]

[0098] After the master link receives the domain access certificate sent by the slave link, it saves the domain access certificate Cert D ,PKD The hash value of the chain SC is returned, and the specific content is as follows:

[0099]

[0100] IoT device D receives the domain access certificate, and uses the domain access certificate to initiate an access request to IoT system S. After chain SC authenticates it, it opens the access interface. Specifically, IoT device D uses Cert D Send an access request to the IoT system S and receive a Cert from the chain SC D After that, it is authenticated. After successful authentication, the access interface is opened and IoT device D can access it.

[0101] IoT device D uses the domain access certificate to initiate an access request to IoT system S as follows:

[0102]

[0103] If the authentication fails, it means that the IoT device D does not have the permission to access the local domain, and a rejection message of the IoT device D is returned. Specifically:

[0104]

[0105] This embodiment provides a cross-domain access method for smart contracts based on a master-slave chain architecture. By introducing homomorphic encryption technology, IoT devices can process data without decryption during intra-domain access, thereby further enhancing the security of private data. This ensures data security during intra-domain access and ensures that smart contracts always meet privacy protection requirements when processing sensitive data. While optimizing smart contracts, the risk of data leakage is greatly reduced. Data security is protected and the security of data access is improved.

[0106] As an optional implementation method, a cross-domain access method for smart contracts based on a master-slave chain architecture also includes: the smart contract obtains the behavioral data of the IoT device when processing homomorphically encrypted data, and analyzes the behavior of the IoT device; the smart contract determines whether the behavior of the IoT device is legal and meets the decryption conditions. When it is legal and meets the decryption conditions, a decryption key is issued through the master chain or the slave chain corresponding to the IoT device, so that the IoT device can use the key to decrypt and access its content.

[0107] Exemplarily, a smart contract can obtain behavior data by monitoring the transaction or behavior log of an IoT device. The behavior data may include the time, frequency, and method of the device accessing encrypted data. Smart contracts analyze the behavior of IoT devices through pre-written logic. In this embodiment, whether to issue a decryption key is determined by judging the legality of the IoT device behavior and whether it meets the decryption conditions. The legality can be determined by judging whether the IoT device behavior has corresponding authorization, or judging whether the IoT device behavior is abnormal. Abnormal behavior can be identified by comparing the device behavior with the preset normal behavior pattern.

[0108] The decryption condition can be to determine whether the current security level of the IoT device meets the requirements. The security level is the level that the smart contract automatically adjusts and evaluates based on the historical behavior data of the IoT device. That is, when the IoT device exhibits unsafe behavior, the smart contract downgrades its security level, or after the IoT device performs safe behavior multiple times, the smart contract upgrades its security level. The decryption condition can also be to determine whether the IoT device has completed a specific pre-task. When the specific pre-task is completed, it is considered to meet the decryption condition. The pre-task can be a task set to achieve a certain goal. This embodiment does not limit this, and technicians in this field can determine it as needed.

[0109] Once the smart contract determines that the behavior of the IoT device is legal and meets the decryption conditions, it can issue the decryption key through the main chain or the slave chain corresponding to the IoT device. This process can be achieved through cross-chain smart contracts, allowing communication and interaction between different blockchains. After obtaining the decryption key, the IoT device can decrypt the data and access its content.

[0110] This embodiment provides a cross-domain access method for smart contracts based on a master-slave chain architecture. By analyzing whether the behavior of the IoT device meets the legal conditions and decryption conditions, it is determined whether to grant the IoT device the authority to access the encrypted content, thereby compensating for the security risks brought about by automatically adjusting permissions to allow the device to perform multiple cross-domain accesses within the time range without having to reapply for permissions each time, thereby improving the security of data access.

[0111] As an optional implementation method, the cross-domain access method of smart contracts based on the master-slave chain architecture also includes: the smart contract continuously monitors the behavioral data of the Internet of Things devices and analyzes the behavior of the Internet of Things devices. When the behavior of the networked devices is abnormal, the decryption key is revoked.

[0112] For example, if the IoT device exhibits any abnormal behavior during operation, such as frequent unreasonable access requests or abuse of authority, the smart contract immediately revokes the decryption key and prevents the IoT device from further accessing encrypted data. The smart contract can revoke the decryption key in such a way that the smart contract includes a key update mechanism. When abnormal behavior is detected, a new key is automatically generated, and the old key is marked as invalid. A key revocation transaction is created, and when specific conditions are met, the transaction is automatically executed to remove the relevant key from the valid list.

[0113] This embodiment provides a cross-domain access method for smart contracts based on a master-slave chain architecture, which continuously monitors the behavior of IoT devices and promptly revokes decryption keys when anomalies are discovered, thereby ensuring the security of data content.

[0114] As an optional implementation method, the permission control strategy stored in the smart contract includes: the smart contract obtains the historical behavior data of the IoT device; the smart contract determines whether the historical behavior of the IoT device meets the permission upgrade conditions based on the historical behavior data, and adjusts the access permission level of the IoT device when the permission upgrade conditions are met.

[0115] For example, when an IoT device initiates a cross-domain access request to the slave chain of the target IoT domain, the smart contract first checks its initial permissions and begins to monitor the device's access behavior. During the IoT device's access process, if the IoT device exhibits stable and legal access behavior, the smart contract automatically increases its permissions, allowing the IoT device to access more resources and simplifying the subsequent cross-domain access process. On the contrary, if the device's behavior is abnormal, the smart contract will immediately reduce its permissions or suspend access to ensure the security of the entire system.

[0116] The way to determine whether an IoT device exhibits stable and legal access behavior is to evaluate stability by monitoring the device's heartbeat packets, data transmission frequency, and data volume. When data is transmitted within the expected time frame, there will be no frequent connection / disconnection, and the data transmission volume remains within a reasonable range, then the device access behavior is considered stable. Legitimacy is evaluated by checking the device's authentication log, access control list, and security policy. Legitimate devices only access authorized resources within the authorized time and scope, and will not attempt to access unauthorized data or perform any unauthorized operations.

[0117] This embodiment provides a cross-domain access method for smart contracts based on a master-slave chain architecture. This dynamic smart contract execution mechanism makes cross-domain access of IoT devices not only more flexible and efficient, but also ensures the security of the system and the rational allocation of resources.

[0118] As an optional implementation method, the cross-domain access method of smart contracts based on the master-slave chain architecture also includes: the smart contract predicts the data access type of the IoT device based on the historical behavior data of the IoT device, and controls the corresponding IoT domain to pre-cache the corresponding access type data; when an access request from the IoT device is received, the corresponding data is retrieved from the access type data pre-cached in the corresponding IoT domain.

[0119] For example, the smart contract collects the historical behavior data of the IoT device, which may include access frequency, access time, requested data type, etc. By analyzing these data, the smart contract learns the access pattern of the IoT device. For example, if the IoT device requests a certain type of sensor data each time, the smart contract will automatically cache this type of data during subsequent accesses. When the IoT device requests again, it does not need to wait for the data retrieval process, thereby speeding up the access speed.

[0120] The embodiment of the present application also provides a smart contract cross-domain access device based on a master-slave chain architecture. The master-slave chain architecture includes an Internet of Things domain layer, a slave chain layer, and a master chain layer. Any slave chain corresponds to at least one Internet of Things domain. An Internet of Things domain layer includes multiple Internet of Things devices. The device includes:

[0121] A request verification module is used to parse and verify the cross-domain access request according to the public key of the slave chain corresponding to the IoT device when receiving a cross-domain access request from any IoT device from the slave chain;

[0122] The permission determination module is used to determine whether the IoT device has the permission to access the current IoT domain based on the parsed cross-domain access request and the permission control policy stored in the smart contract when the cross-domain access request passes the verification. The permission control policy stored in the smart contract is to dynamically adjust the access rights of the IoT device by analyzing the historical behavior of the IoT device and the request content;

[0123] The request sending module is used to send a cross-domain access request from the chain to the main chain when the IoT device has access rights;

[0124] The certificate sending module is used to send the cross-domain access certificate issued by the main chain to the IoT device when the cross-domain access certificate is received from the link, so that the IoT device can perform cross-domain access according to the cross-domain access certificate.

[0125] The present application also provides an electronic device, such as Figure 5 As shown, a processor 501 and a memory 502, wherein the processor 501 and the memory 502 may be connected via a bus or other means.

[0126] The processor 501 may be a central processing unit (CPU). The processor 501 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or a combination of the above chips.

[0127] The memory 502 is a non-transient computer-readable storage medium that can be used to store non-transient software programs, non-transient computer executable programs and modules, such as program instructions / modules corresponding to the cross-domain access method of smart contracts based on the master-slave chain architecture in the embodiment of the present invention. The processor executes various functional applications and data processing of the processor by running the non-transient software programs, instructions and modules stored in the memory.

[0128] The memory 502 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created by the processor, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory 502 may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0129] The one or more modules are stored in the memory 502, and when executed by the processor 501, the following is performed: Figure 1 The cross-domain access method of smart contracts based on the master-slave chain architecture in the illustrated embodiment.

[0130] For details of the above electronic equipment, please refer to Figure 2 The corresponding related descriptions and effects in the illustrated embodiments can be understood and will not be repeated here.

[0131] This embodiment also provides a computer storage medium, which stores computer executable instructions, and the computer executable instructions can execute the cross-domain access method of smart contracts based on the master-slave chain architecture in any of the above method embodiments. Among them, the storage medium can be a disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), a flash memory (Flash Memory), a hard disk (Hard Disk Drive, abbreviated: HDD) or a solid-state drive (SSD), etc.; the storage medium can also include a combination of the above types of memory.

[0132] Finally, it should be noted that the above preferred embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail through the above preferred embodiments, those skilled in the art should understand that various changes can be made in form and details without departing from the scope defined by the claims of the present invention.

Claims

1. A cross-domain access method for smart contracts based on a master-slave chain architecture, characterized in that: The master-slave chain architecture includes an Internet of Things domain layer, a slave chain layer and a master chain layer. Any slave chain corresponds to at least one Internet of Things domain. An Internet of Things domain layer includes multiple Internet of Things devices. The method includes: When a cross-domain access request is received from any IoT device, the cross-domain access request is parsed and verified according to the public key of the corresponding slave chain of the IoT device; When the cross-domain access request passes the verification, determine whether the IoT device has the permission to access the current IoT domain based on the parsed cross-domain access request and the permission control policy stored in the smart contract. The permission control policy stored in the smart contract is to dynamically adjust the access rights of the IoT device by analyzing the historical behavior of the IoT device and the request content; When the IoT device has access rights, a cross-domain access request is sent from the chain to the main chain; When the slave link receives the cross-domain access certificate issued by the main chain, the cross-domain access certificate is sent to the IoT device so that the IoT device can perform cross-domain access based on the cross-domain access certificate.

2. According to claim 1, a cross-domain access method for smart contracts based on a master-slave chain architecture is characterized in that: Also includes: When receiving an access request with a cross-domain access certificate from any IoT device from the link, verify the access request; When the access request is verified, the slave chain will send a verification message carrying the cross-domain access certificate to the main chain so that the main chain can open the access interface; Receive the access interface sent by the main chain from the link to open the confirmation information.

3. According to claim 1, a cross-domain access method for smart contracts based on a master-slave chain architecture is characterized in that: Also includes: When receiving an intra-domain access request from any IoT device, the intra-domain access request is parsed and verified according to the public key of the slave chain corresponding to the IoT device. The intra-domain access request contains sensitive data, which is homomorphically encrypted data. When the intra-domain access request passes the verification, determine whether the IoT device has intra-domain access rights based on the parsed intra-domain access request and the permission control policy stored in the smart contract. The permission control policy stored in the smart contract is to dynamically adjust the access rights of the IoT device by analyzing the historical behavior of the IoT device and the request content; When the IoT device has access rights, an intra-domain access certificate is generated from the chain and sent to the IoT device and the main chain. The intra-domain access certificate is homomorphically encrypted data.

4. According to claim 1, a method for cross-domain access of smart contracts based on a master-slave chain architecture is characterized in that: The cross-domain access request sent by the IoT device contains sensitive data, which is encrypted using homomorphic encryption; the cross-domain access certificate is homomorphically encrypted data.

5. According to claim 3 or 4, a cross-domain access method for smart contracts based on a master-slave chain architecture is characterized in that: The method further comprises: Smart contracts obtain the behavior data of IoT devices when processing homomorphically encrypted data and analyze the behavior of IoT devices; The smart contract determines whether the behavior of the IoT device is legal and meets the decryption conditions. If it is legal and meets the decryption conditions, the decryption key is issued through the main chain or the corresponding slave chain of the IoT device, so that the IoT device can use the key to decrypt and access its content.

6. According to claim 5, a method for cross-domain access of smart contracts based on a master-slave chain architecture is characterized in that: Also includes: Smart contracts continuously monitor the behavioral data of IoT devices and analyze the behavior of IoT devices. When the behavior of connected devices becomes abnormal, the decryption key is revoked.

7. According to claim 1, a method for cross-domain access of smart contracts based on a master-slave chain architecture is characterized in that: The permission control strategy for smart contract storage includes: Smart contracts obtain historical behavior data of IoT devices; Based on historical behavior data, the smart contract determines whether the historical behavior of the IoT device meets the conditions for permission upgrade. If the conditions for permission upgrade are met, the access permission level of the IoT device is adjusted.

8. According to claim 7, a method for cross-domain access of smart contracts based on a master-slave chain architecture is characterized in that: Also includes: The smart contract predicts the data access type of the IoT device based on the historical behavior data of the IoT device, and controls the corresponding IoT domain to pre-cache the corresponding access type data; When an access request from the IoT device is received, corresponding data is retrieved from the access type data pre-cached in the corresponding IoT domain.

9. An electronic device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the steps of the cross-domain access method for smart contracts based on the master-slave chain architecture as described in any one of claims 1 to 8.

10. A computer storage medium having computer instructions stored thereon, characterized in that: When the instruction is executed by the processor, the steps of the cross-domain access method of smart contracts based on the master-slave chain architecture described in any one of claims 1-8 are implemented.

Images