CN113438068B - Method and device for realizing dynamic encryption based on block height - Google Patents

Method and device for realizing dynamic encryption based on block height Download PDF

Info

Publication number
CN113438068B
CN113438068B CN202110666018.5A CN202110666018A CN113438068B CN 113438068 B CN113438068 B CN 113438068B CN 202110666018 A CN202110666018 A CN 202110666018A CN 113438068 B CN113438068 B CN 113438068B
Authority
CN
China
Prior art keywords
contract
encrypted
key
block
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110666018.5A
Other languages
Chinese (zh)
Other versions
CN113438068A (en
Inventor
刘琦
闫莺
魏长征
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced New Technologies Co Ltd
Original Assignee
Advanced New Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advanced New Technologies Co Ltd filed Critical Advanced New Technologies Co Ltd
Priority to CN202110666018.5A priority Critical patent/CN113438068B/en
Publication of CN113438068A publication Critical patent/CN113438068A/en
Application granted granted Critical
Publication of CN113438068B publication Critical patent/CN113438068B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/008—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Abstract

One or more embodiments of the present disclosure provide a method and apparatus for implementing dynamic encryption based on block height, where the method may include: decrypting the received transaction in a trusted execution environment by the blockchain node to determine an intelligent contract corresponding to the transaction; the blockchain node executes the intelligent contract in a trusted execution environment, so that the contract state contained in the intelligent contract is modified; the blockchain node encrypts the contract state in a trusted execution environment according to a public key and an influence factor to write the encrypted contract state into a database, wherein the influence factor comprises the block height of a block where the exchange is located.

Description

Method and device for realizing dynamic encryption based on block height
Technical Field
One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and apparatus for implementing dynamic encryption based on a block height.
Background
Blockchain technology builds on top of transport networks (e.g., point-to-point networks). Network nodes in the transport network utilize the chained data structures to validate and store data and employ distributed node consensus algorithms to generate and update data. Nodes in these blockchain networks sometimes need to be added.
The biggest two challenges in the current enterprise-level blockchain platform technology are privacy and performance, which are often difficult to solve simultaneously. Most solutions trade off performance for privacy, or do not consider privacy much to pursue performance. Common encryption technologies for solving privacy problems have high complexity such as homomorphic encryption (Homomorphic encryption) and Zero-knowledge proof (Zero-knowledgeproof), have poor generality, and may also bring about serious performance loss.
In addressing privacy, trusted execution environments (Trusted Execution Environment, TEE) are another solution. The TEE may act as a black box in the hardware, and code and data executed in the TEE cannot be peeped by the operating system layer, and can only be operated through a predefined interface in the code. In terms of efficiency, due to the black box property of the TEE, plaintext data is operated in the TEE instead of complex cryptographic operation in homomorphic encryption, and efficiency loss is avoided in the calculation process, so that the safety and privacy of the blockchain can be improved to a large extent on the premise of small performance loss by combining the TEE. The current industry is concerned with TEE solutions, where almost all mainstream chip and software alliances have their own TEE solutions, including TPM (Trusted Platform Module ) on software and Intel SGX (Software Guard Extensions, software protection extension), ARM trust zone (trust zone) and AMD PSP (Platform Security Processor ) on hardware.
Disclosure of Invention
In view of this, one or more embodiments of the present disclosure provide a method and apparatus for implementing dynamic encryption based on block heights.
In order to achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:
according to a first aspect of one or more embodiments of the present specification, a method for implementing dynamic encryption based on block height is provided, including:
decrypting the received transaction in a trusted execution environment by the blockchain node to determine an intelligent contract corresponding to the transaction;
the blockchain node executes the intelligent contract in a trusted execution environment, so that the contract state contained in the intelligent contract is modified;
the blockchain node encrypts the contract state in a trusted execution environment according to a public key and an influence factor to write the encrypted contract state into a database, wherein the influence factor comprises the block height of a block where the exchange is located.
According to a second aspect of one or more embodiments of the present specification, there is provided an apparatus for implementing dynamic encryption based on block height, comprising:
a decryption unit for decrypting the received transaction in a trusted execution environment to determine an intelligent contract corresponding to the transaction;
An execution unit that executes the smart contract in a trusted execution environment, such that a contract state included in the smart contract is modified;
an encryption unit for encrypting the contract state according to a public key and an influence factor in a trusted execution environment, wherein the influence factor comprises the block height of the block where the trade is located;
and the storage unit is used for writing the encrypted contract state into the database.
According to a third aspect of one or more embodiments of the present specification, there is provided an electronic device comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method of the first aspect by executing the executable instructions.
According to a fourth aspect of one or more embodiments of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method as described in the first aspect.
Drawings
FIG. 1 is a schematic diagram of creating a smart contract provided by an exemplary embodiment.
FIG. 2 is a schematic diagram of a call to a smart contract provided by an exemplary embodiment.
Fig. 3 is a flowchart of a method for implementing dynamic encryption based on block heights according to an exemplary embodiment.
Fig. 4 is an encryption diagram of an exemplary embodiment where the impact factor includes only block height.
FIG. 5 is a diagram illustrating encryption when an impact factor includes both block height and transaction offset according to an exemplary embodiment.
FIG. 6 is an encryption diagram illustrating an impact factor including both block height and the modified order of contract states according to an exemplary embodiment.
FIG. 7 is an encryption diagram illustrating an impact factor including block height, transaction offset, and modified order of contract states according to an exemplary embodiment.
Fig. 8 is a schematic diagram of a key-value pair of a contract state according to an exemplary embodiment.
Fig. 9 is a schematic diagram of a key-value pair of another contract state provided by an exemplary embodiment.
Fig. 10 is a schematic diagram of an apparatus according to an exemplary embodiment.
Fig. 11 is a block diagram of an apparatus for implementing dynamic encryption based on block heights according to an exemplary embodiment.
Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with aspects of one or more embodiments of the present description as detailed in the accompanying claims.
It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments.
Blockchains are generally divided into three types: public chains (Public Blockchain), private chains (Private Blockchain) and federated chains (Consortium Blockchain). In addition, there are many types of combinations, such as different combinations of private chain+federation chain, federation chain+public chain, and the like. The participants of the blockchain, namely the blockchain nodes (or simply nodes), can read the data records on the blockchain, participate in transactions, compete for the accounting rights of new blocks and the like, and each blockchain node forms a corresponding blockchain network. Among the above types of blockchains, the most decentralized is the public chain. The public chain is represented by bitcoin and ethernet, and participants joining the public chain can read data records on the chain, participate in transactions, compete for accounting rights of new blocks, and the like, and each participant can join and leave the network freely. The private chain is the opposite, the write rights of the relevant network are controlled by some organization or organization, and the data read rights are specified by the organization or organization. In short, the private chain may be a weakly centralized system with strict restrictions and few participants. This type of blockchain is more suitable for use within a particular organization. The alliance chain is a block chain between public and private chains, and can realize 'partial decentralization'. Each node in the federation chain typically has an entity organization or organization corresponding thereto; participants join the network by authorization and form a benefit-related federation, collectively maintaining blockchain operation.
Whether public, private, or federation, it is possible to provide the functionality of a smart contract. Intelligent contracts on blockchains are contracts on blockchain systems that can be executed by transaction triggers. The smart contracts may be defined in the form of codes.
Taking the ethernet as an example, support users create and invoke some complex logic in the ethernet network, which is the biggest challenge for ethernet to distinguish from the bitcoin blockchain technology. At the heart of the ethernet as a programmable blockchain is an Ethernet Virtual Machine (EVM), which can be run by each ethernet node. The EVM is a graphics-complete virtual machine, meaning that various complex logic can be implemented by it. The user's issuing and invoking of the smart contract in the ethernet is running on the EVM. In practice, the virtual machine runs directly on virtual machine code (virtual machine bytecode, hereinafter "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.
For example, as shown in fig. 1, bob sends a transaction containing information to create a smart contract to the ethernet network, the EVM of node 1 may execute the transaction and generate the corresponding contract instance. "0x6f8ae93 …" in fig. 1 represents the address of this contract, the data field of the transaction may hold byte code, and the to field of the transaction is empty. After agreement is reached between nodes through the consensus mechanism, this contract is successfully created and can be invoked in a subsequent process. After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain, and the contract account is stored with a specific address. The behavior of the smart contract is controlled by the contract code. In other words, the smart contract causes a virtual account to be generated on the blockchain that includes a contract code and an account store (Storage).
Still taking the ethernet as an example, as shown in fig. 2, bob sends a transaction for invoking a smart contract to the ethernet network, the EVM of a node may execute the transaction and generate the corresponding contract instance. In fig. 2, the from field of the transaction is the address of the account of the transaction initiator (i.e. Bob), the "0x6f8ae93 …" in the to field represents the address of the called smart contract, the value field is the value of the ethernet in the ethernet, and the data field of the transaction holds the method and parameters for calling the smart contract. The intelligent contract is independently executed at each node in the blockchain network in a specified mode, all execution records and data are stored on the blockchain, so that when the transaction is completed, transaction credentials which cannot be tampered and cannot be lost are stored on the blockchain.
As previously described, the smart contracts deployed on the blockchain may be in the form of bytecodes. Bytecode consists of a series of bytes, each of which can identify an operation. Based on various aspects of development efficiency, readability and the like, a developer can select a high-level language to write intelligent contract codes instead of directly writing byte codes. The intelligent contract code written in the high-level language is compiled by a compiler to generate byte codes, and then the byte codes can be deployed on a blockchain. The high-level languages supported by ethernet are numerous, such as Solidity, serpent, LLL language.
Taking the Solidity language as an example, the contracts written therewith are very similar to classes (classes) in an object-oriented programming language, and various members may be declared in a contract, including contract states, functions, function modifiers, events, and the like. The contract state is a value permanently stored in the account store of the smart contract for saving the state of the contract.
The following is an example of a simple smart contract code written in the solubility language:
typically, after this contract is deployed in the blockchain, the storage state corresponding to the contract state is plain text, and anyone can see the state without privacy-preserving settings and capabilities. If the user wants to protect the state privacy, the current solution of zero knowledge proof and homomorphic encryption is needed to rewrite the contract, so that the contract state of "policy" is encrypted and protected, and all operations of the policy on the encryption domain are needed to be supported. Generally, the encryption mode has complex operation, and it is difficult to design a proper algorithm to support in an encryption domain. In some blockchain-TEE combined solutions, however, some or all of the contract states of the smart contracts are stored as data requiring privacy protection in a database maintained by the blockchain node for privacy protection. The database, the physical carrier of which may be a storage medium, such as a persistent storage medium.
TEE is a trusted execution environment based on a secure extension of CPU hardware and completely isolated from the outside. TEE was originally proposed by Global Platform for resolving secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications in parallel to the operating system. The ARM Trust Zone technology has at the earliest realized the true commercial TEE technology. Along with the high-speed development of the internet, the security demands are higher and higher, and the security demands are not limited to mobile devices, cloud devices and data centers for TEE. The TEE concept has also been developed and expanded at a high rate. The TEE now has been a more generalized TEE than the originally proposed concept. For example, server chip manufacturers Intel, AMD, etc. have successively introduced hardware-assisted TEEs and enriched the concepts and characteristics of TEEs, which have been widely accepted in the industry. The TEE now lifted is often more directed to such hardware assisted TEE technology. Unlike the mobile terminal, the cloud access needs remote access, and the terminal user is invisible to the hardware platform, so that the first step of using the TEE is to confirm the true credibility of the TEE. Therefore, the existing TEE technology introduces a remote attestation mechanism, and a hardware manufacturer (mainly a CPU manufacturer) endorses and ensures that a user can verify the TEE state through a digital signature technology.
At the same time, just secure resource isolation may not meet the security requirements, so that further data privacy protection is also proposed. Commercial TEEs, including Intel SGX, AMD SEV, also provide memory encryption techniques that limit trusted hardware to the CPU, and the data on the bus and memory are ciphertext to prevent malicious users from snooping. TEE technology, such as intel's software protection extension (SGX), isolates code execution, remote attestation, security configuration, secure storage of data, and trusted paths for executing code. Applications running in the TEE are secured and are almost impossible to access by third parties.
Taking Intel SGX technology as an example, SGX provides an enclosure (also called enclave), i.e., an encrypted trusted execution area in memory, that protects data from theft by the CPU. Taking a block link point as an example, a CPU supporting SGX is adopted, and a part of region EPC (Enclave Page Cache, enclosure page buffer or enclave page buffer) can be allocated in the memory by using a newly added processor instruction, and the data in the region EPC is encrypted by an encryption engine MEE (Memory Encryption Engine) in the CPU. The encrypted content in the EPC is decrypted into plaintext only after entering the CPU. Thus, in SGX, a user may not trust the operating system, VMM (Virtual Machine Monitor ), or even BIOS (Basic Input Output System, basic input output System), but only trust the CPU to ensure that private data does not leak. Therefore, under the encryption protection of the CPU, intelligent contracts can be executed in the enclosure, contract states can be generated, the contract states requiring privacy protection in the enclosure are encrypted, and then the obtained ciphertext contract states are transmitted and stored, so that the powerful calculation power of the CPU can be utilized, and data leakage is not worried.
FIG. 3 is a flowchart of a method for implementing dynamic encryption in a blockchain in accordance with an exemplary embodiment. As shown in fig. 3, the method applied to the blockchain node may include the steps of:
in step 302, the blockchain node decrypts the received transaction in the trusted execution environment to determine the smart contract to which the transaction corresponds.
In one embodiment, a client may create a transaction for creating or invoking a smart contract. The client can encrypt the transaction through the secret key and send the encrypted transaction to the blockchain node, so that the blockchain node can decrypt the encrypted transaction in the trusted execution environment, and the intelligent contract corresponding to the transaction is determined.
As described above, when the transaction is used to create an intelligent contract, the data field of the transaction stores the code of the intelligent contract, so that after the block link point decrypts the transaction, the corresponding intelligent contract can be read from the data field of the transaction. When the transaction is used for calling the intelligent contract, the to field of the transaction contains the address of the called intelligent contract, so that after the block link point decrypts the transaction, the address of the intelligent contract can be read from the to field of the transaction, and the code of the corresponding intelligent contract can be acquired based on the address.
When a transaction is used to invoke a smart contract, there may be multiple nested calls. For example, the transaction directly invokes smart contract 1, while the code of smart contract 1 invokes smart contract 2, and the code in smart contract 2 points to the contract address of smart contract 3, such that the transaction actually indirectly invokes the code of smart contract 3. Thus, the present specification can store the modified contract state in an encrypted manner, regardless of whether the contract state defined in the smart contract 1, the smart contract 2, or the smart contract 3 is modified.
In one embodiment, the encryption mode of the transaction by the client may be symmetric encryption, asymmetric encryption, or a combination of symmetric encryption and asymmetric encryption. When symmetric encryption is adopted, the client encrypts the transaction through an encryption key, and the blockchain node decrypts the transaction through the same encryption key; accordingly, the symmetric encryption algorithm may be DES algorithm, 3DES algorithm, TDEA algorithm, blowfish algorithm, RC5 algorithm, IDEA algorithm, etc. When the asymmetric encryption is adopted, the client encrypts the transaction through a public key and the blockchain node decrypts the transaction through a private key; accordingly, the asymmetric encryption algorithm used is, for example, RSA, elgamal, knapsack algorithm, rabin, D-H, ECC (elliptic Curve encryption algorithm), etc. When symmetric encryption is combined with asymmetric encryption, the client may encrypt the transaction using a symmetric encryption algorithm, i.e., a key of the symmetric encryption algorithm is used to encrypt the transaction, and use an asymmetric encryption algorithm to encrypt a key used in the symmetric encryption algorithm, such as a public key of the asymmetric encryption algorithm; thus, after the block chain link point receives the encrypted transaction, the private key of the asymmetric encryption algorithm can be adopted to decrypt the encrypted transaction, so that the secret key of the symmetric encryption algorithm is obtained, and the secret key of the symmetric encryption algorithm is used to decrypt the transaction.
Step 304, the blockchain node executes the smart contract in a trusted execution environment, such that a contract state included in the smart contract is modified.
As previously described, the blockchain node may ensure that the contract state and its value do not leak by executing a smart contract in the TEE. For example, after the foregoing decryption process, the blockchain node may obtain the plaintext code of the smart contract corresponding to the transaction, and execute the obtained plaintext code in the TEE. Specifically, the blockchain node may utilize a newly added processor instruction in the CPU, and may allocate a part of the region EPC in the memory, and encrypt the plaintext code by using an encryption engine MEE in the CPU and store the plaintext code in the EPC. The encrypted content in the EPC enters the CPU and is decrypted into a plaintext, namely the plaintext code, so that the CPU can operate on the plaintext code to finish the execution process.
In SGX technology, the EVM may be loaded into the enclosure described above, so that the EVM may execute the plaintext code described above within the enclosure, thereby fully utilizing the powerful computing power of the CPU. In the remote proving process, the key management server can calculate the hash value of the local EVM code and compare the hash value with the hash value of the EVM code loaded in the block chain link point, and the comparison result is correct as a necessary condition for passing the remote proving, thereby completing the measurement of the code loaded by the block chain node SGX enclosure. Through the measurement, the correct EVM can execute the plaintext code of the intelligent contract corresponding to the transaction in the SGX, and ensure that all correct EVMs have the same result after executing the same piece of code.
Generally, after the CPU executes the plaintext code of the intelligent contract, a part or all of contract states defined in the plaintext code may be changed, that is, a part or all of contract states may be modified, and the description may be stored in a database maintained by the blockchain node after reliably encrypting the modified contract states, so as to implement high-level data security and privacy protection.
At step 306, the blockchain node encrypts the contract status in a trusted execution environment according to a public key and an impact factor to write the encrypted contract status into a database, wherein the impact factor includes a blockheight of a block in which the transaction is located.
In one embodiment, the contract state is stored in the blockchain, and from the perspective of the blockchain node, the contract state is written to a database, such as a local database. The database is typically stored in a storage medium, more commonly a persistent storage medium. The persistent storage medium may be a magnetic disk, a floppy disk, or a memory which can recover data after power-on so as to be capable of being stored permanently.
In an embodiment, the blockchain node may encrypt the contract state according to the public key and the influencing factor, so that the value of the encrypted contract state is simultaneously acted by the public key and the influencing factor, and under the condition that the public key is the same, the randomness of the encrypted contract state may be increased by the differentiated influencing factor. In other words, when the public keys are the same, by employing different influencing factors, the resulting encrypted contract states will have different values even if encrypted for the same value contract states. Therefore, compared with the encryption of all the contract states by adopting the public key, the method can avoid the lawless persons from grasping the value change rule of the encrypted contract states, prevent the lawless persons from presuming the value of the contract states through trial and comparison, and has higher security.
In one embodiment, the influencing factor may only include the block height of the block where the transaction is located. Thus, for contract states that are modified after transactions for different blocks are performed, the block link points will employ different valued impact factors. When the blockchain node encrypts the contract state according to the public key and the influence factor, the encrypted contract state is completely different due to the difference of the heights of the blocks serving as the influence factors even if the contract state before encryption has the same value, so that the randomness of the value of the encrypted contract state is increased. Therefore, when the influence factor is the block height of the block where the transaction center is located, the value randomness of each encrypted contract state can be increased in the dimension of the block, so that the fact that regular and circulated value changes are not generated among the encrypted contract states corresponding to the transactions of different blocks is ensured.
Assume that a block B1 and a block B2 are included in a certain blockchain network, the block height of the block B1 is H1, and the block height of the block B2 is H2. For ease of understanding, it is assumed that the block B1 includes the transactions Tx1 and Tx2, the block B2 includes the transactions Tx3 and Tx4, the corresponding position offsets of the transactions Tx1 and Tx3 in the blocks B1 and B2 are both Offset1, and the corresponding position offsets of the transactions Tx2 and Tx4 in the blocks B1 and B2 are both Offset2; meanwhile, contract states Balance1 and Balance2 are defined in transactions Tx1 and Tx3, and contract states Balance3 and Balance4 are defined in transactions Tx2 and Tx 4.
When the impact factor includes only block height, as shown in fig. 4: for the contract states such as the contract 1, the contract 2, the contract 3 and the contract 4 related to the block B1, whether the contract states are from the same transaction or different transactions or not, a public Key Key128 (i.e. a security Key with a version number of 128, which can be see the description about the Key version below, or other forms of public keys can be adopted, which are only used for example herein) and the block height H1 are adopted to implement encryption operation, so as to obtain corresponding encrypted contract states, such as S-contract 1-1 corresponding to the contract 1, S-contract 2-1 corresponding to the contract 2, S-contract 3-1 corresponding to the contract 3, S-contract 4-1 corresponding to the contract 4, and the like.
Similarly, for block B2, the encryption operation is performed using the public key128 and the block height H2, whether or not the contract states are from the same transaction or different transactions, so as to obtain the encrypted contract states, such as R-Balance1-1 corresponding to Balance1, R-Balance2-1 corresponding to Balance2, R-Balance3-1 corresponding to Balance3, R-Balance4-1 corresponding to Balance4, and so on.
In addition to "block height of the block where the trade is located", the influence factor may further include other conditions, for example, the other conditions may include one or more of "a position offset of the trade in the block where the trade is located", "a modified order of contract states when the smart contract is executed", etc., so as to obtain the influence factor formed by combining a plurality of conditions, and the encryption operation may be performed on the contract states in other dimensions.
In one embodiment, the influencing factor may be a block height of the block where the transaction is located, a position offset of the transaction in the block where the transaction is located. In combination with the above description of the condition "block height of the trade in block", the condition "positional offset of trade in block", it is known that: the condition of 'the block height of the block where the transaction is located' can realize encryption control of the block dimension, ensure that the encrypted contract state cannot be changed in a regular and reproducible way among different blocks, and the condition of 'the position offset of the transaction in the block where the transaction is located' can realize encryption control of the transaction dimension, ensure that the encrypted contract state cannot be changed in a regular and reproducible way among different transactions in the same block, so that when the influence factors simultaneously comprise the two conditions, the encryption control of the block dimension and the transaction dimension can be realized, and the encrypted contract state cannot be changed in a regular and reproducible way among different transactions, regardless of whether the transactions are in the same block or different blocks. Wherein, for different transactions in the same block, encryption control can be realized by the condition of 'the position offset of the transaction in the block where the transaction is located', because the different transactions in the same block necessarily have different position offsets; for different transactions of different blocks, even if the positions of the transactions in the corresponding blocks are the same, the encryption control can be further realized by the condition of "the block height of the block in which the transaction is located", because the transactions of different blocks necessarily have different block heights.
The above blocks B1 and B2 are also taken as examples. As shown in fig. 5, when the blockchain node considers the position Offset corresponding to the transaction at the same time, for the contract states such as the Balance1, the Balance2, the Balance3, and the Balance4 related to the block B1, since the position Offset corresponding to the transaction Tx1 is Offset1 from the Balance1, the Balance1 and the Balance2 are encrypted respectively by the public Key128, the block height H1, and the position Offset1, for example, the Balance1 is encrypted to obtain S-Balance1-2, and the Balance2 is encrypted to obtain S-Balance2-2. Meanwhile, since the Balance3 and the Balance4 are derived from the transaction Tx2, and the Offset corresponding to the transaction Tx2 is Offset2, the Balance3 and the Balance4 are encrypted respectively by the public Key128, the block height H1 and the Offset2, for example, the Balance3 is encrypted to obtain S-Balance3-2, and the Balance4 is encrypted to obtain S-Balance4-2.
Similarly, for block B2, since the positions of the blocks B2 and B1 are Offset1 from the transaction Tx3, the block height H2 and the Offset1 are used to encrypt the blocks B1 and B2 by the public Key128, the block height H2 and the Offset1, for example, encrypting the block B1 to obtain R-block 1-2, and encrypting the block B2 to obtain R-block 2-2. Meanwhile, since the positions of the Balance3 and the Balance4 are derived from the transaction Tx4 and the Offset corresponding to the transaction Tx4 is Offset2, the Balance3 and the Balance4 are encrypted respectively by the public Key128, the block height H2 and the Offset2, for example, the Balance3 is encrypted to obtain R-Balance3-2, and the Balance4 is encrypted to obtain R-Balance4-2.
In one embodiment, the impact factor may be the block height of the block where the exchange is located, the order in which the contract states were modified when the smart contract was executed. In combination with the above description of the condition "block height of block where trade is located", the condition "modified order of contract states when intelligent contracts are executed", it is known that: the condition of 'the block height of the block where the transaction is located' can realize encryption control of the block dimension, ensure that the encrypted contract states cannot be changed in a regular and circulated way among different blocks, ensure that the encrypted contract states cannot be changed in a regular and circulated way among different contract states generated by the same transaction, and ensure that the encrypted contract states cannot be changed in a circulated way, so that when the influence factors simultaneously comprise the two conditions, the encryption control of the block dimension and the state dimension can be realized, and the encrypted contract states generated by a plurality of transactions on different blocks cannot be changed in a regular and circulated way even if the encrypted contract states have the same modified order. Wherein, for a plurality of contract states generated by the same transaction, encryption control may be implemented by the condition "the modified order of the contract states when the smart contract is executed" because different contract states generated by the same transaction necessarily have different modified orders; and for the contract states respectively generated by a plurality of transactions of different blocks, even if the contract states have the same modified times in the respective transactions, encryption control can be further realized by the condition of 'the block height of the block where the transaction is located', because the transactions of different blocks necessarily have different block heights.
The above blocks B1 and B2 are also taken as examples. As shown in FIG. 6, when the blockchain node considers both the block height and the modified order of the contract states, for the contract states of Balance1, balance2, balance3, and Balance4, etc. related to the block B1, since Balance1 and Balance2 are from the same transaction Tx1, balance1 and Balance2 necessarily correspond to different modified orders, such as Balance1 corresponds to modified order U1 and Balance2 corresponds to modified order U2, balance1 is encrypted by the public Key Key128, the block height H1, and the modified order U1 to obtain encrypted S-Balance1-3, and Balance2 is encrypted by the public Key Key128, the block height H1, and the modified order U2 to obtain encrypted S-Balance2-3. Meanwhile, since the Balance3 and the Balance4 come from the same transaction Tx2, the Balance3 and the Balance4 necessarily correspond to different modified orders respectively, for example, the Balance3 corresponds to the modified order U1, the Balance4 corresponds to the modified order U2, so that the Balance3 is encrypted by the public Key128, the block height H1 and the modified order U1 to obtain the encrypted S-Balance3-3, and the Balance4 is encrypted by the public Key128, the block height H1 and the modified order U2 to obtain the encrypted S-Balance4-3.
Similarly, for the contract states of Balance1, balance2, balance3, and Balance4 related to block B2, since Balance1 and Balance2 are from the same transaction Tx3, balance1 and Balance2 necessarily correspond to different modified orders, such as Balance1 corresponds to modified order U1 and Balance2 corresponds to modified order U2, balance1 is encrypted by public Key Key128, block height H2, and modified order U1 to obtain encrypted R-Balance1-3, and Balance2 is encrypted by public Key Key128, block height H2, and modified order U2 to obtain encrypted R-Balance2-3. Meanwhile, since the Balance3 and the Balance4 come from the same transaction Tx4, the Balance3 and the Balance4 necessarily correspond to different modified orders respectively, for example, the Balance3 corresponds to the modified order U1, the Balance4 corresponds to the modified order U2, so that the Balance3 is encrypted by the public Key128, the block height H2 and the modified order U1 to obtain the encrypted R-Balance3-3, and the Balance4 is encrypted by the public Key128, the block height H2 and the modified order U2 to obtain the encrypted R-Balance4-3.
In an embodiment, the influencing factors may be "block height of the block where the trade is located", "position offset of the trade in the block where the trade is located" and "modified order of the contract states when the intelligent contract is executed", and encryption control of the block dimension, the trade dimension and the state dimension may be implemented, so that encrypted contract states generated by any two contract states will not necessarily generate regular and reproducible value changes, whether the any two contract states are from the same trade or different trade, or whether the different trade is from the same block or different block. Wherein, for a plurality of contract states generated by the same transaction, encryption control may be implemented by the condition "the modified order of the contract states when the smart contract is executed" because different contract states generated by the same transaction necessarily have different modified orders; and for the contract states respectively generated by different transactions of the same block, even if the contract states have the same modified times in the respective transactions, encryption control can be further realized by the condition of 'the position offset of the transactions in the block where the transaction is located', because the different transactions of the same block necessarily have different position offsets; and for the contract states respectively generated by a plurality of transactions of different blocks, even if the contract states have the same modified times in the respective transactions, encryption control can be further realized by the condition of 'the block height of the block where the transaction is located', because the transactions of different blocks necessarily have different block heights.
The above blocks B1 and B2 are also taken as examples. As shown in fig. 7, when the blockchain node considers the block height, the position Offset corresponding to the transaction and the modified order of the contract states at the same time, for the contract states such as the block B1, the block 2, the block 3, and the block 4, since the block 1 and the block 2 come from the transaction Tx1, the block 1 and the block 2 must respectively correspond to different modified orders, for example, the block 1 corresponds to the modified order U1, the block 2 corresponds to the modified order U2, and meanwhile, assuming that the position Offset corresponding to the transaction Tx1 is Offset1, the encrypted S-block 1-4 can be obtained by encrypting the public Key128, the block height H1, the position Offset1, and the modified order U1, and the encrypted S-block 2-4 can be obtained by encrypting the public Key128, the block height H1, the position Offset1, and the modified order U2. Meanwhile, since the Balance3 and the Balance4 come from the transaction Tx2, the Balance3 and the Balance4 necessarily correspond to different modified orders respectively, for example, the Balance3 corresponds to the modified order U1, the Balance4 corresponds to the modified order U2, and meanwhile, assuming that the position Offset corresponding to the transaction Tx2 is Offset2, the Balance3 may be encrypted by the public Key128, the block height H1, the position Offset2 and the modified order U1 to obtain an encrypted S-Balance3-4, and the Balance4 may be encrypted by the public Key128, the block height H1, the position Offset2 and the modified order U2 to obtain an encrypted S-Balance4-4.
Similarly, for the contract states of Balance1, balance2, balance3, and Balance4 related to block B2, since Balance1 and Balance2 are from transaction Tx3, balance1 and Balance2 necessarily correspond to different modified orders, such as Balance1 corresponds to modified order U1, and Balance2 corresponds to modified order U2, while assuming that the position Offset corresponding to transaction Tx3 is Offset1, balance1 may be encrypted by public Key128, block height H2, position Offset Offset1, and modified order U1 to obtain encrypted R-Balance1-4, and Balance2 is encrypted by public Key128, block height H2, position Offset Offset1, and modified order U2 to obtain encrypted R-Balance2-4. Meanwhile, since the Balance3 and the Balance4 come from the transaction Tx4, the Balance3 and the Balance4 necessarily correspond to different modified orders respectively, for example, the Balance3 corresponds to the modified order U1, the Balance4 corresponds to the modified order U2, and meanwhile, assuming that the position Offset corresponding to the transaction Tx4 is Offset2, the Balance3 may be encrypted by the public Key128, the block height H2, the position Offset2 and the modified order U1 to obtain the encrypted R-Balance3-4, and the Balance4 may be encrypted by the public Key128, the block height H2, the position Offset2 and the modified order U2 to obtain the encrypted R-Balance4-4.
In one embodiment, the block link reads the received encrypted transaction into the trusted execution environment to decrypt and execute the corresponding intelligent contract, encrypts the generated modified contract state in the trusted execution environment, writes the encrypted contract state into the database to store, ensures that the encrypted transaction is encrypted outside the trusted execution environment to ensure data security, and can decrypt the encrypted transaction into the plaintext inside the trusted execution environment to process so as to fully utilize the computing power of the CPU.
When the blockchain node encrypts the constraint state according to the public key and the influence factor in the trusted execution environment, a plurality of optional encryption means exist, and encryption solutions in the related technology can be referred to. Two possible encryption solutions are described below.
In one embodiment, the blockchain node may encrypt the contract state by a GCM (Galois/Counter Mode) algorithm; letter G in GCM stands for GMAC (Galois message authentication code mode, galois message authentication code), letter C stands for CTR (CounTeR mode). The inputs to the GCM algorithm include 3 parts: the data to be encrypted, the symmetric key and the initialization vector (IV, initialization Vector) can be used in the specification, wherein the contract state is used as the data to be encrypted, the public key is used as the symmetric key required by the GCM algorithm, and the influence factor is used as the initialization vector required by the GCM algorithm, so that the contract state is encrypted, and a corresponding encrypted contract state and a corresponding check code are generated, and the check code can be used for checking the integrity of the encrypted contract state.
Thus, when storing encrypted contract states, a blockchain point may write a check code to the database in association with the encrypted contract states. Then, when decrypting the encrypted contract state subsequently, if the decrypting fails, the encrypted contract state can be verified by the verification code: when verification is successful, the data indicating the encrypted contract state is complete and should be a decryption failure caused by other factors, such as an input key or an influence factor error; when the verification fails, the data indicating the encrypted contract state is incomplete.
In another embodiment, the blockchain node may generate a derivative key according to the public key and the influencing factor, for example, hash or other operations are performed after the public key and the influencing factor are spliced to obtain the derivative key; the blockchain node may then encrypt the contract state based on the derivative key, generating an encrypted contract state.
In one embodiment, the public key is stored in an enclosure on the blockchain node. Since only the CPU can access the public key stored in the enclosure, the public key is safe enough and cannot be theoretically obtained by lawbreakers, so that the security of the encrypted contract state is ensured.
The public key may be distributed to the blockchain node by a Key Management Server (KMS) after remote attestation by a blockchain node; alternatively, the public key may be negotiated between nodes in the blockchain network; alternatively, the public key may be obtained by other means, which is not limited in this specification.
The key obtained based on the above approach may not be a public key. For example, the key obtained by the channel may be a secure key, and the secure key may implement version evolution, thereby evolving to obtain the public key. In other words, the public key may be a specified version of the secure key; among the neighboring versions of the security keys, the lower version of the security key is irreversibly calculated from the higher version of the security key, for example, the highest version of the security key is the root key, while the other versions of the security keys are directly or indirectly irreversibly calculated from the root key. For example, the low-version security key is obtained by performing hash operation on the high-version security key and preset information, so that the low-version security key cannot be reversely deduced from the high-version security key due to the characteristics of hash operation, and the replacement of the public key is facilitated through version evolution of the security key, and the same public key is prevented from being used for a long time. And, in replacing the public key, it can be ensured that the version of the key after replacement is always higher than the version of the key before replacement to ensure: on one hand, even if the key used previously leaks, the key can be replaced by a key with a high version so as to stop damage in time; on the other hand, as long as having a high version of the key, a low version of the key can be evolved, and the previously used key is compatible, thereby decrypting the previously encrypted contract state.
The version evolution rules between security keys may be: and carrying out hash operation on the version numbers corresponding to the adjacent high-version keys and the adjacent low-version keys to obtain the adjacent low-version keys. For example, if 256 versions of keys with version numbers of 0-255 are required to be derived, hash calculation can be performed on the root key and version number 0xFF (corresponding decimal value of 255) to obtain key-255 with version number 255; carrying out hash calculation on the key-255 and the version factor 0xFE (the corresponding decimal value is 254) to obtain the key-254 with the version number of 254; … … the key-0 with version number 0 is obtained by performing hash calculation on the key-1 and version factor 0x00 (corresponding decimal value is 0). Due to the characteristics of the hash algorithm, the calculation between the high-version key and the low-version key is irreversible, for example, the key-0 can be calculated by the key-1 and the version factor 0x00, but the key-1 cannot be reversely deduced by the key-0 and the version factor 0x 00. Thus, a version of the security key may be selected and set as the public key used by the blockchain node for encryption of the contract state.
As previously described, the blockchain node encrypts the contract state based on the public key and the influencing factor to obtain an encrypted contract state. If the public key and the influence factor are fixed values, the public key and the influence factor are only required to be respectively and independently stored in the enclosure; however, if the public key or the influencing factor has a dynamic value, that is, different public keys or influencing factors may be used when encrypting different contract states, then when storing the encrypted contract states, the corresponding used public key, influencing factor or information indicating the value thereof should be stored in association for facilitating the subsequent decryption operation.
Given that there is a dynamic change in the value of the impact factor, the impact factor may be written to the database in association with the encrypted contract state. For example, as shown in FIG. 8, the blockchain node stores the encrypted contract state in the form of key-value pairs (key-value). The value of Key may be determined by referring to a related art manner, for example, key=hash (RLP (value)), that is, the value of Key is a hash value of the value encoded by RLP (Recursive Length Prefix ). And the components of value may include: encrypted contract status, check value, and impact factor. The encrypted contract state may be obtained by encrypting according to the public key and the influencing factor in the manner described in the above embodiments. And when encryption is performed using, for example, a GCM algorithm or other encryption algorithm, a check value may also be obtained; of course, if no check value exists, the value may not include the check value. The influence factor in fig. 8 includes the block height, the transaction offset and the modification order, that is, the influence factor is formed by "the block height of the block where the transaction is located", "the position offset of the transaction in the block where the transaction is located" and "the modification order of the contract state when the smart contract is executed".
Based on the embodiment shown in fig. 8, after reading this key pair, the blockchain node can obtain the impact factor required for decryption from the value of the key pair, thereby decrypting the encrypted contract state in combination with the public key. In some scenarios, the impact factors may be encrypted, such as by the blockchain node encrypting the impact factors in the TEE during the storage phase, such that the value contains the encrypted impact factors, rather than the impact factors in plaintext form; accordingly, after the key value pair shown in fig. 8 is read, the influence factor in the plaintext form cannot be directly obtained, so that the decryption threshold for the encrypted contract state can be further improved, and the security is improved.
The blockchain node may encrypt the impact factor using any key. Although the above-mentioned public key may be used to encrypt the influencing factor, in order to increase the diversity of the key and improve the security, other keys different from the public key may be used to encrypt the influencing factor. For example, when the public key is the aforementioned one version of the key, the key that encrypts the influence factor may be another version, so as to be distinguished from the public key; for example, the influencing factor may be encrypted with the lowest version key having a version number of 0, and the version number of the public key may be set to necessarily be greater than 0.
The public key may have version information, such as a security key for which the public key is a version. When the blockchain node stores the key value pair for the encrypted contract state, version information of the public key can be contained in the value, particularly, under the condition that the version of the public key used by the blockchain node is updated, the version of the currently adopted public key can be different from the previously stored historical public key adopted by the encrypted contract state in encryption, so that the version information contained in the value can help the blockchain node to accurately select the key required to be adopted. For example, as shown in fig. 9, an information field may be included in the value of the key value pair, and the information field may further include a version information subfield for recording version information of the public key, based on the embodiment shown in fig. 8.
The blockchain node may encrypt the version information and then add the encrypted version information to the value instead of recording the version information in a plaintext form. The key used to encrypt the version information may be a public key or other keys different from the public key, such as a lowest version key with version number 0 may be used to encrypt the version information similar to the influencing factor described above.
In summary, according to the method and the device, the contract state is encrypted according to the public key and the influencing factors, and compared with the method and the device for encrypting by only adopting the public key, the randomness of the contract state after encryption can be increased through the influencing factors, so that the data security is improved.
Fig. 10 is a schematic structural diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 10, at the hardware level, the device includes a processor 1002, an internal bus 1004, a network interface 1006, a memory 1008, and a non-volatile memory 1010, although other hardware required by other services is possible. The processor 1002 reads the corresponding computer program from the nonvolatile memory 1010 into the memory 1008 and then runs, forming a means to achieve dynamic encryption based on block height on a logical level. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or a logic device.
Referring to fig. 11, in a software implementation, the apparatus for implementing dynamic encryption based on block height may include:
A decryption unit 1101 that decrypts the received transaction in a trusted execution environment to determine an intelligent contract to which the transaction corresponds;
an execution unit 1102 that executes the smart contract in a trusted execution environment, causing a contract state contained in the smart contract to be modified;
an encryption unit 1103 that encrypts the contract status according to a public key and an impact factor in a trusted execution environment, wherein the impact factor includes a block height of a block where the transaction is located;
a storage unit 1104 for writing the encrypted contract status to the database.
Optionally, the influence factor further includes at least one of: the amount of positional offset of the transaction in the block at which the contract state is modified as the smart contract is executed.
Optionally, the impact factor is written to a database in association with the encrypted contract state.
Optionally, after the impact factor is encrypted in the trusted execution environment, the impact factor is written to a database in association with the encrypted contract state.
Optionally, the encryption unit 1103 is specifically configured to:
the public key is used as a symmetric key required by a GCM algorithm, the influence factor is used as an initialization vector required by the GCM algorithm, the contract state is encrypted through the GCM algorithm, and the encrypted contract state and the corresponding check code are generated; wherein the check code is written to a database in association with the encrypted contract status.
Optionally, the encryption unit 1103 is specifically configured to:
generating a derivative key according to the public key and the influence factor;
encrypting the contract state according to the derivative key to generate the encrypted contract state.
Optionally, the public key includes: a security key of a specified version; wherein, among the neighboring versions of the security keys, the low version of the security key is irreversibly calculated from the high version of the security key.
Optionally, the highest version of the secure key is a root key, and the other versions of the secure key are directly or indirectly calculated irreversibly from the root key.
Optionally, version information of the public key is written to a database in association with the encrypted contract state.
Optionally, after the version information of the public key is encrypted in the trusted execution environment, the version information is written into a database in association with the encrypted contract state.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.
In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.
The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
The terminology used in the one or more embodiments of the specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the specification. As used in this specification, one or more embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments of the present description. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.
The foregoing description of the preferred embodiment(s) is (are) merely intended to illustrate the embodiment(s) of the present invention, and it is not intended to limit the embodiment(s) of the present invention to the particular embodiment(s) described.

Claims (14)

1. A method for implementing dynamic encryption based on block height, comprising:
the block chain node decrypts the received transaction in a trusted execution environment and determines an intelligent contract corresponding to the transaction;
the blockchain node executing the smart contract in a trusted execution environment such that a contract state of the smart contract is modified;
the blockchain node encrypts the contract state according to a public key and an influence factor in a trusted execution environment, and writes the encrypted contract state into a database; wherein the impact factors include a block height of the block in which the exchange is located, a positional offset of the exchange in the block in which the exchange is located, and a modified order of the contract states when the smart contract is executed.
2. The method of claim 1, wherein the impact factors include a blockheight that indicates a blockchain node to encrypt with impact factors of different values for a contract state in which transactions in different blocks are modified after being executed.
3. The method of claim 1, the writing the encrypted contract state to a database, comprising:
the impact factor is written to a database in association with the encrypted contract status.
4. The method of claim 3, the writing the impact factor to a database in association with the encrypted contract state, comprising:
encrypting the influence factors in a trusted execution environment, and writing the encrypted influence factors into a database in association with the encrypted contract state.
5. The method of claim 1, wherein the corresponding positional offsets for transactions are related to the order of arrangement in the block so that different transactions in the same block have different positional offsets.
6. The method of claim 1, the blockchain node encrypting the contract status in a trusted execution environment according to a public key and an impact factor, comprising:
the block chain link point takes the public key as a symmetric key required by a GCM algorithm, takes the influence factor as an initialization vector required by the GCM algorithm, encrypts the contract state through the GCM algorithm, and generates the encrypted contract state and a corresponding check code; wherein the check code is written to a database in association with the encrypted contract status.
7. The method of claim 1, the blockchain node encrypting the contract status in a trusted execution environment according to a public key and an impact factor, comprising:
the blockchain node generates a derivative key according to the public key and the influence factor;
and the blockchain node encrypts the contract state according to the derivative key to generate the encrypted contract state.
8. The method of claim 1, the public key comprising: a security key of a specified version; wherein, among the neighboring versions of the security keys, the low version of the security key is irreversibly calculated from the high version of the security key.
9. The method of claim 8, the highest version of the secure key being a root key, other versions of the secure key being calculated irreversibly directly or indirectly from the root key.
10. The method of claim 8, the version information of the public key being written to a database in association with the encrypted contract state.
11. The method of claim 8, wherein the version information of the public key is written to a database in association with the encrypted contract state after being encrypted in a trusted execution environment.
12. An apparatus for implementing dynamic encryption based on block height, comprising:
a decryption unit for decrypting the received transaction in a trusted execution environment and determining an intelligent contract corresponding to the transaction;
an execution unit that executes the smart contract in a trusted execution environment, causing a contract state of the smart contract to be modified;
an encryption unit that encrypts the contract state in a trusted execution environment according to a public key and an impact factor, the impact factor including a block height of a block in which the transaction is located, a positional offset of the transaction in the block, and a modified order of the contract state when the smart contract is executed;
and the storage unit is used for writing the encrypted contract state into the database.
13. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor is configured to implement the method of any of claims 1-11 by executing the executable instructions.
14. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-11.
CN202110666018.5A 2019-05-31 2019-05-31 Method and device for realizing dynamic encryption based on block height Active CN113438068B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110666018.5A CN113438068B (en) 2019-05-31 2019-05-31 Method and device for realizing dynamic encryption based on block height

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910471633.3A CN110266467B (en) 2019-05-31 2019-05-31 Method and device for realizing dynamic encryption based on block height
CN202110666018.5A CN113438068B (en) 2019-05-31 2019-05-31 Method and device for realizing dynamic encryption based on block height

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN201910471633.3A Division CN110266467B (en) 2019-05-31 2019-05-31 Method and device for realizing dynamic encryption based on block height

Publications (2)

Publication Number Publication Date
CN113438068A CN113438068A (en) 2021-09-24
CN113438068B true CN113438068B (en) 2024-01-09

Family

ID=67916276

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202110666018.5A Active CN113438068B (en) 2019-05-31 2019-05-31 Method and device for realizing dynamic encryption based on block height
CN201910471633.3A Active CN110266467B (en) 2019-05-31 2019-05-31 Method and device for realizing dynamic encryption based on block height

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN201910471633.3A Active CN110266467B (en) 2019-05-31 2019-05-31 Method and device for realizing dynamic encryption based on block height

Country Status (2)

Country Link
CN (2) CN113438068B (en)
WO (1) WO2020238959A1 (en)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020238878A1 (en) * 2019-05-31 2020-12-03 创新先进技术有限公司 Dynamic encryption method and device
CN113438068B (en) * 2019-05-31 2024-01-09 创新先进技术有限公司 Method and device for realizing dynamic encryption based on block height
CN110968895B (en) * 2019-11-29 2022-04-05 北京百度网讯科技有限公司 Data processing method and device, electronic equipment and storage medium
CN112001731B (en) * 2020-04-02 2022-05-24 支付宝(杭州)信息技术有限公司 Block chain account balance deposit certificate and recovery method and device
CN111523895A (en) * 2020-05-06 2020-08-11 杭州复杂美科技有限公司 Data delay publishing method, device and storage medium
CN111597567B (en) * 2020-05-14 2022-03-04 腾讯科技（深圳）有限公司 Data processing method, data processing device, node equipment and storage medium
CN112801785B (en) * 2021-01-13 2023-10-20 中央财经大学 Fair data transaction method and device based on blockchain intelligent contract
CN112507369B (en) * 2021-01-29 2021-05-25 腾讯科技（深圳）有限公司 Service processing method and device based on block chain, readable medium and electronic equipment
CN113393327A (en) * 2021-06-10 2021-09-14 杭州溪塔科技有限公司 Privacy protection method and device for on-chain evidence-storing transaction and electronic equipment
CN115758396B (en) * 2022-08-31 2023-05-30 兰州大学 Database security access control technology based on trusted execution environment

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101330379A (en) * 2007-06-22 2008-12-24 华为技术有限公司 Method and apparatus for down distributing cryptographic key
WO2017122187A2 (en) * 2016-01-15 2017-07-20 Enrico Maim Methods and systems implemented in a network architecture with nodes capable of performing message-based transactions
CN107342858A (en) * 2017-07-05 2017-11-10 武汉凤链科技有限公司 A kind of intelligent contract guard method and system based on trusted context
CN109039649A (en) * 2018-08-03 2018-12-18 北京大学深圳研究生院 Key management method, device and storage medium based on block chain in a kind of CCN
CN109360091A (en) * 2018-08-30 2019-02-19 阿里巴巴集团控股有限公司 A kind of arbitrary object choosing method and device based on block chain

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10841082B2 (en) * 2015-11-24 2020-11-17 Adi BEN-ARI System and method for blockchain smart contract data privacy
CN109792386B (en) * 2016-09-29 2022-08-02 诺基亚技术有限公司 Method and apparatus for trusted computing
US10484346B2 (en) * 2017-02-07 2019-11-19 Microsoft Technology Licensing, Llc Establishment of consortium blockchain network
US10922692B2 (en) * 2017-04-05 2021-02-16 Samsung Sds Co., Ltd. Method for calculating confirmation reliability for blockchain based transaction and blockchain network monitoring system for performing the method
US10452564B2 (en) * 2017-04-25 2019-10-22 Entit Software Llc Format preserving encryption of object code
US10742393B2 (en) * 2017-04-25 2020-08-11 Microsoft Technology Licensing, Llc Confidentiality in a consortium blockchain network
CN107273759B (en) * 2017-05-08 2020-07-14 上海点融信息科技有限责任公司 Method, apparatus, and computer-readable storage medium for protecting blockchain data
CN107425982B (en) * 2017-07-07 2020-05-12 众安信息技术服务有限公司 Method and block chain for realizing intelligent contract data encryption
CN109587200B (en) * 2017-09-29 2021-07-16 中兴通讯股份有限公司 Block chain as-a-service platform and system
US11244309B2 (en) * 2017-11-22 2022-02-08 Cornell University Real-time cryptocurrency exchange using trusted hardware
EP3718069B1 (en) * 2017-11-30 2024-04-17 Visa International Service Association Blockchain system for confidential and anonymous smart contracts
CN108416577B (en) * 2018-03-02 2021-03-05 上海汉得信息技术股份有限公司 Block chain service system
CN108632045A (en) * 2018-05-10 2018-10-09 阿里巴巴集团控股有限公司 A kind of block chain data processing method, device, processing equipment and system
CN109345242B (en) * 2018-09-18 2022-10-28 百度在线网络技术（北京）有限公司 Key storage and update method, device, equipment and medium based on block chain
CN109450856B (en) * 2018-10-12 2021-09-28 西安电子科技大学 Block chain-based data link information flow control system and method
CN109559105A (en) * 2018-11-05 2019-04-02 深圳市恒达移动互联科技有限公司 Digital wallet generation method and system based on TEE and encryption chip
CN109493049A (en) * 2018-11-21 2019-03-19 利尔·契夫 A kind of wallet asset protection system based on block chain
CN109766712B (en) * 2018-12-14 2020-08-25 华东师范大学 Credit reporting streaming method based on block chain and Intel SGX
CN109741057A (en) * 2018-12-27 2019-05-10 石更箭数据科技(上海)有限公司 Collecting method and system, platform, storage medium
CN109697613B (en) * 2018-12-29 2020-08-25 链博(成都)科技有限公司 Security authentication method and system for network transaction in block chain
CN109768865A (en) * 2019-01-18 2019-05-17 深圳市威赫科技有限公司 Block chain upper body part under credible performing environment digitizes realization method and system
CN113438068B (en) * 2019-05-31 2024-01-09 创新先进技术有限公司 Method and device for realizing dynamic encryption based on block height
CN110263547B (en) * 2019-05-31 2021-07-20 创新先进技术有限公司 Method and device for realizing dynamic encryption based on contract state modification sequence
CN110276610B (en) * 2019-05-31 2021-04-06 创新先进技术有限公司 Method and device for realizing dynamic encryption based on transaction offset

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101330379A (en) * 2007-06-22 2008-12-24 华为技术有限公司 Method and apparatus for down distributing cryptographic key
WO2017122187A2 (en) * 2016-01-15 2017-07-20 Enrico Maim Methods and systems implemented in a network architecture with nodes capable of performing message-based transactions
CN107342858A (en) * 2017-07-05 2017-11-10 武汉凤链科技有限公司 A kind of intelligent contract guard method and system based on trusted context
CN109039649A (en) * 2018-08-03 2018-12-18 北京大学深圳研究生院 Key management method, device and storage medium based on block chain in a kind of CCN
CN109360091A (en) * 2018-08-30 2019-02-19 阿里巴巴集团控股有限公司 A kind of arbitrary object choosing method and device based on block chain

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
姚爽.基于SGX保护国密算法运行环境的研究与实现.《中国优秀硕士学位论文全文数据库 信息科技辑》.2019,摘要，正文第14-39页. *

Also Published As

Publication number Publication date
CN110266467A (en) 2019-09-20
CN113438068A (en) 2021-09-24
CN110266467B (en) 2021-04-27
WO2020238959A1 (en) 2020-12-03

Similar Documents

Publication Publication Date Title
CN113438068B (en) Method and device for realizing dynamic encryption based on block height
US11048825B2 (en) Managing a smart contract on a blockchain
CN110245506B (en) Intelligent contract management method and device based on block chain and electronic equipment
CN111614464B (en) Method for safely updating secret key in blockchain, node and storage medium
CN111475849B (en) Private data query method and device based on blockchain account
CN110032884B (en) Method for realizing privacy protection in block chain, node and storage medium
CN110263544B (en) Receipt storage method and node combining transaction type and judgment condition
CN110263087B (en) Receipt storage method and node based on multi-dimensional information and with conditional restriction
CN110266644B (en) Receipt storage method and node combining code marking and transaction types
CN110032876B (en) Method, node and storage medium for implementing privacy protection in block chain
CN110020549B (en) Method, node and storage medium for implementing privacy protection in block chain
CN110264196B (en) Conditional receipt storage method and node combining code labeling and user type
CN110276610B (en) Method and device for realizing dynamic encryption based on transaction offset
CN110245947B (en) Receipt storage method and node combining conditional restrictions of transaction and user types
CN110245942B (en) Receipt storage method and node combining user type and judgment condition
CN110264192B (en) Receipt storage method and node based on transaction type
CN110245504B (en) Receipt storage method and node combined with condition limitation of multi-type dimensionality
CN110033266B (en) Method, node and storage medium for implementing privacy protection in block chain
CN110245503B (en) Receipt storage method and node combining code marking and judging conditions
CN110245945B (en) Receipt storage method and node combining code marking and user type
CN111475850B (en) Intelligent contract-based privacy data query method and device
CN110264197B (en) Receipt storage method and node combining event function type and judgment condition
CN110264193B (en) Receipt storage method and node combining user type and transaction type
CN110245944B (en) Receipt storage method and node based on user type
CN111898156A (en) Method, node and storage medium for realizing contract calling in block chain

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant