CN110266467B - 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
CN110266467B
CN110266467B CN201910471633.3A CN201910471633A CN110266467B CN 110266467 B CN110266467 B CN 110266467B CN 201910471633 A CN201910471633 A CN 201910471633A CN 110266467 B CN110266467 B CN 110266467B
Authority
CN
China
Prior art keywords
contract
encrypted
transaction
key
block
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
CN201910471633.3A
Other languages
Chinese (zh)
Other versions
CN110266467A (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.)
Ant Chain Technology 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 CN201910471633.3A priority Critical patent/CN110266467B/en
Priority to CN202110666018.5A priority patent/CN113438068B/en
Publication of CN110266467A publication Critical patent/CN110266467A/en
Priority to PCT/CN2020/092231 priority patent/WO2020238878A1/en
Priority to PCT/CN2020/092611 priority patent/WO2020238959A1/en
Application granted granted Critical
Publication of CN110266467B publication Critical patent/CN110266467B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Accounting & Taxation (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

One or more embodiments of the present specification provide a method and an apparatus for implementing dynamic encryption based on block height, where the method may include: the block chain node decrypts the received transaction in the trusted execution environment to determine an intelligent contract corresponding to the transaction; the blockchain node executes the intelligent contract in a trusted execution environment, so that contract state contained in the intelligent contract is modified; and the block chain node encrypts the contract state in a trusted execution environment according to a public key and an influence factor so as to write the encrypted contract state into a database, wherein the influence factor comprises the block height of a block where the transaction 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 block chaining technology, and in particular, to a method and an apparatus for implementing dynamic encryption based on block height.
Background
The blockchain technique is built on top of a transport network, such as a point-to-point network. Network nodes in a transport network utilize a chained data structure to validate and store data and employ a distributed node consensus algorithm to generate and update data. The nodes in these blockchain networks sometimes need to be increased.
The two biggest challenges in the current enterprise-level blockchain platform technology are privacy and performance, which are often difficult to solve simultaneously. Most solutions trade privacy for loss of performance or do not consider privacy much to pursue performance. Common encryption technologies for solving privacy problems, such as Homomorphic encryption (Homomorphic encryption) and Zero-knowledge proof (Zero-knowledge proof), have high complexity and poor universality, and may cause serious performance loss.
In terms of addressing privacy, a Trusted Execution Environment (TEE) is another approach. The TEE can function as a black box in hardware, codes and data executed in the TEE cannot be peeped by an operating system layer, and the TEE can be operated only through an interface predefined in the codes. In the aspect of efficiency, due to the black box property of the TEE, plaintext data is operated in the TEE instead of complex cryptography operation in homomorphic encryption, efficiency loss does not exist in the calculation process, and therefore the safety and privacy of a block chain can be improved to a great extent on the premise of small performance loss by combining the TEE. The industry is concerned with TEE solutions, and almost all mainstream chip and Software consortiums have their own TEE solutions, including Software-oriented TPM (Trusted Platform Module) and hardware-oriented Intel SGX (Software Guard Extensions), ARMTrustzone (Trusted zone), and AMD PSP (Platform Security Processor).
Disclosure of Invention
In view of the above, one or more embodiments of the present disclosure provide a method and apparatus for implementing dynamic encryption based on block height.
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, there is provided a method for implementing dynamic encryption based on block height, including:
the block chain node decrypts the received transaction in the trusted execution environment to determine an intelligent contract corresponding to the transaction;
the blockchain node executes the intelligent contract in a trusted execution environment, so that contract state contained in the intelligent contract is modified;
and the block chain node encrypts the contract state in a trusted execution environment according to a public key and an influence factor so as to write the encrypted contract state into a database, wherein the influence factor comprises the block height of a block where the transaction 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, including:
the decryption unit is used for decrypting the received transaction in the trusted execution environment so as to determine the intelligent contract corresponding to the transaction;
an execution unit that executes the intelligent contract in a trusted execution environment, causing a contract state included in the intelligent contract to be modified;
the encryption unit encrypts the contract state in a trusted execution environment according to a public key and an influence factor, wherein the influence factor comprises the block height of a block where the transaction 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 apparatus including:
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, a computer-readable storage medium is presented, having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to the first aspect.
Drawings
FIG. 1 is a schematic diagram of creating an intelligent contract, provided by an exemplary embodiment.
FIG. 2 is a schematic diagram of a calling smart contract provided by an exemplary embodiment.
Fig. 3 is a flowchart of a method for implementing dynamic encryption based on block height according to an exemplary embodiment.
Fig. 4 is a schematic diagram of an exemplary embodiment of encryption when the impact factor only includes the block height.
FIG. 5 is a block diagram illustrating encryption when the impact factor includes both block height and transaction offset according to an exemplary embodiment.
FIG. 6 is a schematic diagram of encryption with an impact factor comprising both block height and modified order of contract status provided by an exemplary embodiment.
FIG. 7 is a schematic diagram of encryption with impact factors comprising block height, transaction offset, and modified order of contract status, according to an exemplary embodiment.
FIG. 8 is a block diagram of a key-value pair for a contract state, provided in an exemplary embodiment.
FIG. 9 is a key-value pair structure diagram 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 height according to an exemplary embodiment.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent 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 certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.
It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.
Blockchains are generally divided into three types: public chain (Public Blockchain), private chain (PrivateBlockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The participants of the block chain are block chain nodes (or simply nodes), the block chain nodes can read data records on the chain, participate in transactions, compete for the accounting right of new blocks and the like, and each block chain node forms a corresponding block chain network. Among the above types of blockchains, the most decentralized is the public chain. The public chain is represented by bitcoin and ether house, the participant joining the public chain can read the data record on the chain, participate in transaction, compete for the accounting right of the new block, and the like, and each participant can freely join and leave the network. Private chains are the opposite, with the write rights of the associated network controlled by an organization or organization and the read rights of the data specified by the organization or organization. Briefly, a private chain can be a weakly centralized system with strict restrictions and few participants. This type of blockchain is more suitable for use within a particular establishment. A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; participants jointly maintain blockchain operation by authorizing to join the network and forming a benefit-related alliance.
Whether public, private, or alliance, may provide the functionality of an intelligent contract. An intelligent contract on a blockchain is a contract that can be executed on a blockchain system triggered by a transaction. An intelligent contract may be defined in the form of code.
Taking the ethernet as an example, the support user creates and invokes some complex logic in the ethernet network, which is the biggest challenge of ethernet to distinguish from bitcoin blockchain technology. The core of the ethernet plant as a programmable blockchain is the ethernet plant virtual machine (EVM), each ethernet plant node can run the EVM. The EVM is a well-behaved virtual machine, which means that a variety of complex logic can be implemented through it. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, what the virtual machine directly runs is virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.
For example, as shown in fig. 1, after Bob sends a transaction containing information to create an intelligent contract to the ethernet network, the EVM of node 1 may execute the transaction and generate a corresponding contract instance. The "0 x6f8ae93 …" in fig. 1 represents the address of the contract, the data field of the transaction holds the byte code, and the to field of the transaction is empty. After agreement is reached between the nodes through the consensus mechanism, this contract is successfully created and can be invoked in subsequent procedures. After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain and has a specific address, and the contract code is stored in the contract account. The behavior of the intelligent contract is controlled by the contract code. In other words, an intelligent contract causes a virtual account to be generated on a blockchain that contains a contract code and an account store (Storage).
As shown in fig. 2, still taking an ethernet house as an example, after Bob sends a transaction for invoking an intelligent contract to the ethernet house network, the EVM of a certain node may execute the transaction and generate a corresponding contract instance. The from field of the transaction in fig. 2 is the address of the account of the transaction initiator (i.e., Bob), the "0 x6f8ae93 …" in the to field represents the address of the smart contract called, and the value field is the value of tai-currency in the etherhouse, 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, and all execution records and data are stored on the blockchain, so that after the transaction is completed, transaction certificates 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. A bytecode consists of a series of bytes, each of which can identify an operation. Based on the multiple considerations 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 by the high-level language is compiled by a compiler to generate byte codes, and the byte codes can be deployed on the block chain. The high-level languages supported by Etherns are many, such as Solidity, Serpent, LLL, etc.
Taking the Solidity language as an example, the contract written by the method is similar to a Class (Class) in an object-oriented programming language, and various members including contract states, functions, function modifiers, events and the like can be declared in one contract. The contract state is a value permanently stored in the account store of the intelligent contract that is used to save the state of the contract.
The following is an example of code for a simple intelligent contract written in the Solidity language:
Figure BDA0002080989080000061
generally, after the contract is deployed in a blockchain, the storage state corresponding to the contract state of "balance" is plaintext, and anyone can see the state without setting and capability of privacy protection. If a user wants to protect state privacy, the contract needs to be rewritten by adopting a zero-knowledge proof and homomorphic encryption solution at present, so that the contract state of balance is protected through encryption, and all operations of balance in an encryption domain need to be supported. Generally, the encryption method is complex in operation, and it is difficult to design a proper algorithm to support the encryption domain. In some solutions where blockchains are combined with TEE, some or all of the contract state of an intelligent contract is stored as data requiring privacy protection in a database maintained at blockchain nodes in order to achieve privacy protection. The physical carrier of the database may be a storage medium, such as a persistent storage medium.
The TEE is a trusted execution environment that is based on a secure extension of the CPU hardware and is completely isolated from the outside. TEE was originally proposed by Global Platform to address the secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications parallel to the operating system. The Trust Zone technology of ARM realizes the real commercial TEE technology at the earliest. Along with the high-speed development of the internet, the security requirement is higher and higher, and more requirements are provided for the TEE by mobile equipment, cloud equipment and a data center. The concept of TEE has also been developed and expanded at a high rate. The concept now referred to as TEE has been a more generalized TEE than the concept originally proposed. For example, server chip manufacturers Intel, AMD, etc. have introduced hardware-assisted TEE in turn and enriched the concept and characteristics of TEE, which have gained wide acceptance in the industry. The mention of TEE now is more generally directed to such hardware assisted TEE techniques. Unlike the mobile terminal, the cloud access requires remote access, and the end user is not visible to the hardware platform, so the first step of using the TEE is to confirm the authenticity and credibility of the TEE. Therefore, the current TEE technology introduces a remote attestation mechanism which is endorsed by a hardware manufacturer (mainly a CPU manufacturer) and ensures that a user can verify the TEE state through a digital signature technology.
Meanwhile, only secure resource isolation may not meet the security requirements, so that further data privacy protection is also proposed. Commercial TEE including Intel SGX, AMD SEV also provide memory encryption techniques, limiting trusted hardware within the CPU, with the data of the bus and memory being ciphertext to prevent snooping by malicious users. For example, TEE technology such as intel's software protection extensions (SGX) isolates code execution, remote attestation, secure 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 the Intel SGX technology as an example, SGX provides an enclosure (also called enclave), that is, an encrypted trusted execution area in memory, and a CPU protects data from being stolen. Taking a CPU supporting SGX as an example of a certain block link point, a part of an EPC (enclosure Page Cache, Enclave Page Cache, or Enclave Page Cache) may be allocated in a memory by using a newly added processor instruction, and data therein 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. Therefore, in the SGX, a user may not trust an operating System, a VMM (Virtual Machine Monitor), or even a BIOS (Basic Input Output System), and only need to trust the CPU to ensure that private data is not leaked. Therefore, under the encryption protection of the CPU, the intelligent contract can be executed in the enclosure, the contract state can be generated, the contract state which needs privacy protection in the enclosure is encrypted, and the obtained ciphertext contract state is transmitted and stored, so that the strong computing power of the CPU can be utilized, and data leakage does not need to be worried about.
Fig. 3 is a flowchart of a method for implementing dynamic encryption in a blockchain according to an exemplary embodiment. As shown in fig. 3, the method applied to the blockchain node may include the following steps:
in step 302, the blockchain node decrypts the received transaction in the trusted execution environment to determine the intelligent contract corresponding to the transaction.
In one embodiment, a client may create a transaction that is used to create or invoke a smart contract. The client can encrypt the transaction through the key and send the encrypted transaction to the blockchain node, so that the blockchain node can decrypt the encrypted transaction in a trusted execution environment, and the intelligent contract corresponding to the transaction is determined.
As mentioned above, when the transaction is used to create a smart contract, the data field of the transaction holds the code of the smart contract, so that after the block link point decrypts the transaction, the corresponding smart contract can be read from the data field of the transaction. When the transaction is used for invoking the intelligent contract, the to field of the transaction contains the address of the invoked 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 is obtained based on the address.
When the transaction is used to invoke a smart contract, it may be an invocation of multiple nested structures. For example, a transaction directly calls intelligent contract 1, while the code of intelligent contract 1 calls intelligent contract 2, and the code in intelligent contract 2 points to the contract address of intelligent contract 3, so that the transaction actually indirectly calls the code of intelligent contract 3. In this way, when the contract state defined in the smart contract 1, the smart contract 2, or the smart contract 3 is modified, the specification can encrypt and store the modified contract state.
In one embodiment, the encryption 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 block chain nodes decrypt the transaction through the same encryption key; correspondingly, the adopted symmetric encryption algorithm can be a DES algorithm, a 3DES algorithm, a TDEA algorithm, a Blowfish algorithm, an RC5 algorithm, an IDEA algorithm and the like. When asymmetric encryption is adopted, the client encrypts the transaction through a public key, and the block chain nodes decrypt 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 can encrypt the transaction by adopting a symmetric encryption algorithm, namely encrypting the transaction by adopting a key of the symmetric encryption algorithm, and encrypting the key adopted in the symmetric encryption algorithm by using the asymmetric encryption algorithm, such as encrypting the key adopted in the symmetric encryption algorithm by adopting a public key of the asymmetric encryption algorithm; therefore, after the block chain node receives the encrypted transaction, the block chain node can firstly decrypt by adopting the private key of the asymmetric encryption algorithm to obtain the key of the symmetric encryption algorithm, and then decrypt the transaction by using the key of the symmetric encryption algorithm.
Step 304, the blockchain node executes the intelligent contract in a trusted execution environment, so that the contract state contained in the intelligent contract is modified.
As previously described, block link points may be enabled by performing intelligent contracts in the TEE to ensure that the contract state and its values do not leak. For example, after the decryption process, the block link point may obtain the plaintext code of the smart contract corresponding to the transaction, and execute the obtained plaintext code in the TEE. Specifically, the block link point may use a processor instruction newly added in the CPU, may allocate a part of the area 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 is decrypted into a plaintext, i.e., the plaintext code, after entering the CPU, so that the CPU can perform an operation on the plaintext code to complete an execution process.
In the SGX technique, the EVM can be loaded into the enclosure, so that the EVM can execute the plain-text code in the enclosure, thereby fully utilizing the powerful computing power of the CPU. In the remote certification process, the key management server can calculate the hash value of the local EVM code, compare the hash value with the hash value of the EVM code loaded in the block chain link point, and correctly use the comparison result as a necessary condition for passing the remote certification, thereby completing the measurement of the code loaded by the block chain node SGX enclosure. Measured, the correct EVM can execute the plaintext code of the intelligent contract corresponding to the transaction in the SGX, and ensure that the results of all correct EVMs after executing the same code section are the same.
Generally, after the CPU executes the plaintext code of the intelligent contract, part or all of the contract states defined in the plaintext code may change, that is, part or all of the contract states are modified, and the specification may reliably encrypt the modified contract states and store the encrypted contract states in a database maintained by a block link point, so as to implement high-level data security and privacy protection.
And step 306, encrypting the contract state by the blockchain node in the trusted execution environment according to the public key and the influence factor to write the encrypted contract state into the database, wherein the influence factor comprises the block height of the block where the transaction is located.
In one embodiment, the contract status is stored in the block chain, and from the perspective of the block link point, the contract status is written to a database, such as a local database. The database is typically stored on a storage medium, more commonly a persistent storage medium. The persistent storage medium may be a magnetic disk, a floppy disk, or a memory or the like which can restore data after being powered on so as to be persistently stored.
In an embodiment, the block chain nodes may encrypt the contract state according to the public key and the influence factor, so that the value of the encrypted contract state is simultaneously affected by the public key and the influence factor, and the randomness of the encrypted contract state may be increased by the differentiated influence factor under the condition that the public keys are the same. In other words, when the public keys are the same, by using different influencing factors, even if the encryption is performed on the contract states with the same value, the obtained encrypted contract states have different values. Therefore, compared with the method that all contract states are encrypted by adopting the public key, the method can prevent lawless persons from mastering the value change rule of the encrypted contract states, prevent the lawless persons from speculating the value of the contract states through trial and comparison, and has higher safety.
In one embodiment, the impact factor may only include the block height of the block where the transaction is located. Thus, for contract states that are modified after transactions of different blocks are executed, block nodes will adopt different valued impact factors. Then, when the block chain node encrypts the contract state according to the public key and the influence factor, even if the contract state before encryption has the same value, the contract state after encryption is completely different due to different block heights serving as the influence factors, so that the value randomness of the contract state after encryption is increased. Therefore, when the influence factor is the block height of the block where the transaction is located, the value randomness of each encrypted contract state can be increased in the block dimension, and regular value change which can be traced cannot be generated between the encrypted contract states respectively corresponding to the transactions of different blocks.
Assuming that block B1 and block B2 are included in a certain blockchain network, the block height of block B1 is H1 and the block height of block B2 is H2. For convenience of understanding, it is assumed that the block B1 includes transactions Tx1 and Tx2, the block B2 includes transactions Tx3 and Tx4, the position offsets corresponding to the transactions Tx1 and Tx3 in the blocks B1 and B2 are Offset1, and the position offsets corresponding to the transactions Tx2 and Tx4 in the blocks B1 and B2 are Offset 2; meanwhile, the transactions Tx1 and Tx3 each define contract states Balance1 and Balance2, and the transactions Tx2 and Tx4 each define contract states Balance3 and Balance 4.
When the impact factor includes only the block height, as shown in fig. 4: for the contract states such as Balance1, Balance2, Balance3, Balance4 and the like related to block B1, whether each contract state comes from the same transaction or a different transaction, an encryption operation is performed by using the public Key128 (i.e., the security Key with the version number of 128, see the description below about the Key version, or other forms of public keys may be used, which is only used for example here) and the block height H1, so as to obtain corresponding encrypted contract states, such as S-Balance1-1 corresponding to Balance1, S-Balance2-1 corresponding to Balance2, S-Balance3-1 corresponding to Balance3, S-Balance4-1 corresponding to Balance4, and the like.
Similarly, for block B2, regardless of whether each contract state comes from the same transaction or different transactions, encryption operation is performed by using the public key128 and the block height H2, so as to obtain corresponding 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 the like.
In addition to the "tile height of the tile where the deal is located", the influence factor may further include other conditions, for example, the other conditions may include one or more of "offset of position of the deal in the tile", "modified order of contract state when the intelligent contract is executed", and the like, so as to obtain the influence factor formed by combining a plurality of conditions, and the encryption operation may be performed on the contract state in other dimensions.
In one embodiment, the impact factor may be a tile height of the tile in which the transaction is located, a position offset of the transaction in the tile in which the transaction is located. In conjunction with the above description of the condition "height of block where transaction is located", and the condition "offset of position where transaction is located in block", respectively, it can be seen that: the condition 'the block height of the block where the transaction is located' can realize encryption control of the dimension of the block, ensure that the encrypted contract state cannot generate regular value change between different blocks necessarily, and the condition 'the position offset of the transaction in the block' can realize encryption control of the transaction dimension, ensure that the encrypted contract state cannot generate regular value change between different transactions in the same block necessarily, so when the influence factors simultaneously comprise the two conditions, the encryption control of the dimension of the block and the transaction dimension can be realized, so that the encrypted contract state cannot generate regular value change between different transactions necessarily, no matter whether the transactions are in the same block or different blocks. For different transactions in the same block, encryption control can be realized through the condition of 'position offset of the transaction in the block where the transaction is located', because different transactions in the same block necessarily have different position offsets; for different transactions of different blocks, even if the corresponding position offsets of the blocks where the transactions are located are the same, encryption control can be further realized by the condition of 'the block height of the block where the transactions are located', because the transactions of different blocks necessarily have different block heights.
The above-mentioned blocks B1 and B2 are also taken as examples. As shown in fig. 5, when the block link points simultaneously consider the position Offset amount corresponding to the block height and the transaction, for the contract states such as Balance1, Balance2, Balance3, Balance4 and the like related to the block B1, since Balance1 and Balance2 come from the transaction Tx1 and the position Offset amount corresponding to the transaction Tx1 is Offset1, Balance1 and Balance2 are encrypted respectively by the public Key128, the block height H1 and the position Offset amount Offset1, for example, S-Balance1-2 is obtained after encryption of Balance1, and S-Balance2-2 is obtained after encryption of Balance 2. Meanwhile, since Balance3 and Balance4 come from transaction Tx2, and the position Offset corresponding to the transaction Tx2 is Offset2, Balance3 and Balance4 are respectively encrypted through the public Key128, the block height H1 and the position Offset2, for example, Balance3 is encrypted to obtain S-Balance3-2, and Balance4 is encrypted to obtain S-Balance 4-2.
Similarly, for block B2, since Balance1 and Balance2 come from transaction Tx3, and the position Offset corresponding to the transaction Tx3 is Offset1, Balance1 and Balance2 are encrypted respectively by public Key128, block height H2 and position Offset1, for example, Balance1 is encrypted to obtain R-Balance1-2, and Balance2 is encrypted to obtain R-Balance 2-2. Meanwhile, Balance3 and Balance4 come from transaction Tx4, and the position Offset corresponding to the transaction Tx4 is Offset2, so that Balance3 and Balance4 are respectively encrypted through the public Key128, the block height H2 and the position Offset2, for example, Balance3 is encrypted to obtain R-Balance3-2, and Balance4 is encrypted to obtain R-Balance 4-2.
In one embodiment, the impact factor may be a block height of a block where the transaction is located, a modified order of contract states when the smart contract is executed. In conjunction with the above description of the condition "block height of the block where the transaction is located", and the condition "modified order of contract states when the smart contract is executed", respectively, it can be seen that: the condition "the block height of the block where the transaction is located" can realize encryption control of the block dimension, and ensure that the encrypted contract states cannot be caused to generate value variation with a rule that can be followed inevitably among different blocks, and the condition "the modified sequence of the contract states when the intelligent contract is executed" can realize encryption control of the state dimension, and ensure that the encrypted contract states cannot be caused to generate value variation with a rule that can be followed inevitably among different contract states generated by the same transaction, so when the influence factors simultaneously include the two conditions, encryption control of the block dimension and the state dimension can be realized, so that even if the contract states respectively generated by a plurality of transactions on different blocks have the same modified sequence, value variation with a rule that can be generated by the encrypted contract states cannot be caused inevitably. Wherein, for a plurality of contract states generated by the same transaction, the encryption control can be realized by the condition "the modified order of the contract states when the intelligent contract is executed", because different contract states generated by the same transaction necessarily have different modified orders; the contract states respectively generated for a plurality of transactions of different blocks can be further encrypted under the condition of "block height of the block where the transaction is located" even if the contract states have the same number of times of being modified in the respective transactions, since transactions of different blocks necessarily have different block heights.
The above-mentioned blocks B1 and B2 are also taken as examples. As shown in fig. 6, when the block link points simultaneously consider the modified orders of the block heights and the contract states, for the contract states such as Balance1, Balance2, Balance3, Balance4 and Balance 8525 involved in the block B1, since Balance1 and Balance2 are from the same transaction Tx1, Balance1 and Balance2 necessarily correspond to different modified orders respectively, for example, Balance1 corresponds to the modified order U1 and Balance2 corresponds to the modified order U2, Balance1 is encrypted by the public Key128, the block height H1 and the modified order U1 to obtain the encrypted S-Balance1-3, and Balance2 is encrypted by the public Key 39128, the block height H1 and the modified order U2 to obtain the encrypted S-Balance 2-3. Meanwhile, since Balance3 and Balance4 come from the same transaction Tx2, Balance3 and Balance4 necessarily correspond to different modified orders respectively, for example, Balance3 corresponds to modified order U1, Balance4 corresponds to modified order U2, Balance3 is encrypted through public Key128, block height H1 and modified order U1 to obtain encrypted S-Balance3-3, and Balance4 is encrypted through public Key128, block height H1 and modified order U2 to obtain encrypted S-Balance 4-3.
Similarly, for the contract states of Balance1, Balance2, Balance3, Balance4 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 respectively, for example, Balance1 corresponds to modified order U1 and Balance2 corresponds to modified order U2, Balance1 is encrypted through public Key128, block height H2 and modified order U1 to obtain encrypted R-Balance1-3, and Balance2 is encrypted through public Key128, block height H2 and modified order U2 to obtain encrypted R-Balance 2-3. Meanwhile, since Balance3 and Balance4 come from the same transaction Tx4, Balance3 and Balance4 necessarily correspond to different modified orders respectively, for example, Balance3 corresponds to modified order U1, Balance4 corresponds to modified order U2, Balance3 is encrypted through public Key128, block height H2 and modified order U1 to obtain encrypted R-Balance3-3, and Balance4 is encrypted through public Key128, block height H2 and modified order U2 to obtain encrypted R-Balance 4-3.
In one embodiment, the influence factor may be "block height of a block where the transaction is located", "position offset of the transaction in the block" and "modified order of the contract states when the smart contract is executed", and encryption control of the block dimension, the transaction dimension and the state dimension may be implemented, so that encrypted contract states generated by any two contract states do not necessarily generate regular value change, regardless of whether the any two contract states are from the same transaction or different transactions, and whether different transactions are from the same block or different blocks. Wherein, for a plurality of contract states generated by the same transaction, the encryption control can be realized by the condition "the modified order of the contract states when the intelligent contract is executed", because different contract states generated by the same transaction necessarily have different modified orders; for 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 through a condition of 'position offset of the transactions in the block', because different transactions of the same block necessarily have different position offsets; the contract states respectively generated for a plurality of transactions of different blocks can be further encrypted under the condition of "block height of the block where the transaction is located" even if the contract states have the same number of times of being modified in the respective transactions, since transactions of different blocks necessarily have different block heights.
The above-mentioned blocks B1 and B2 are also taken as examples. As shown in fig. 7, when block link points simultaneously consider the block heights, the transaction-corresponding position offsets, and the modified order of the contract states, for example, Balance1, Balance2, Balance3, Balance4, which are related to block B1, since Balance1 and Balance2 are from transaction Tx1, Balance1 and Balance2 respectively correspond to different modified orders, for example, Balance1 corresponds to modified order U1, Balance2 corresponds to modified order U2, and assuming that the transaction Tx1 corresponds to position Offset1, Balance1-4 can be encrypted by public Key128, block height H1, position Offset of 1, and modified order U1, and Balance1-4 can be encrypted, while Balance1 is encrypted by public Key128, block height H1, position Offset 72, and modified order U1, Balance 1-368744 is encrypted. Meanwhile, since Balance3 and Balance4 come from transaction Tx2, Balance3 and Balance4 necessarily correspond to different modified orders respectively, for example, Balance3 corresponds to modified order U1, Balance4 corresponds to modified order U2, and assuming that the position Offset corresponding to transaction Tx2 is Offset2, Balance3 can be encrypted through public Key128, block height H1, position Offset of 2 and modified order U1 to obtain encrypted S-Balance3-4, and Balance4 can be encrypted through public Key128, block height H1, position Offset of 2 and modified order U2 to obtain encrypted S-Balance 4-4.
Similarly, for the contract states of Balance1, Balance2, Balance3, Balance4 and Balance4 related to block B2, since Balance1 and Balance2 are from transaction Tx3, Balance1 and Balance2 necessarily correspond to different modified orders respectively, for example, Balance1 corresponds to modified order U1 and Balance2 corresponds to modified order U2, and assuming that the position Offset corresponding to transaction Tx3 is Offset1, Balance1 may be encrypted by public Key128, block height H2, position Offset1 and modified order U1 to obtain encrypted R-Balance1-4, while Balance2 may be encrypted by public Key128 Key, block height H2, position Offset1 and modified order U2 to obtain encrypted R-Balance R-2. Meanwhile, since Balance3 and Balance4 come from transaction Tx4, Balance3 and Balance4 necessarily correspond to different modified orders respectively, for example, Balance3 corresponds to modified order U1, Balance4 corresponds to modified order U2, and assuming that the position Offset corresponding to transaction Tx4 is Offset2, Balance3 can be encrypted through public Key128, block height H2, position Offset of 2 and modified order U1, so as to obtain encrypted R-Balance3-4, and Balance4 can be encrypted through public Key128, block height H2, position Offset of 2 and modified order U2, so as to obtain encrypted R-Balance 4-4.
In one embodiment, the block link point reads the received encrypted transaction into the trusted execution environment for decryption and executes the corresponding intelligent contract, encrypts the contract state which is modified in the trusted execution environment, and writes the contract state into the database for storage, so that the cryptograph is ensured outside the trusted execution environment to ensure data security, and the cryptograph can be decrypted into the plaintext in the trusted execution environment for processing to fully utilize the computing power of the CPU.
When the block chain node encrypts the contract state according to the public key and the influence factor in the trusted execution environment, various selectable encryption means exist, and the encryption solution in the related technology can be used for reference. Two possible encryption solutions are described below.
In one embodiment, the block link point may encrypt the contract status via a GCM (Galois/Counter Mode) algorithm; the letter G in the GCM represents GMAC (Galois message authentication code) and the letter C represents CTR (countter CounTeR mode). The inputs to the GCM algorithm include 3 parts: in this specification, the contract state may be used as data to be encrypted, the public key may be used as a symmetric key required by a GCM algorithm, and the influence factor may be used as an Initialization Vector required by the GCM algorithm, so as to encrypt the contract state, and generate a corresponding encrypted contract state and a corresponding check code, where the check code may be used to check the integrity of the encrypted contract state.
Thus, the blockchain node, when storing the encrypted contract state, may write a check code to the database in association with the encrypted contract state. Then, when subsequently decrypting the encrypted contract state, if the decryption fails, the encrypted contract state can be verified through the verification code: when the verification is successful, the data indicating the encrypted contract state is complete, and the decryption failure caused by other factors, such as an input key or an influence factor error; when the check fails, the data indicating the encrypted contract status is incomplete.
In another embodiment, the block nodes may generate the derived key according to the public key and the impact factor, for example, the public key and the impact factor are concatenated and then subjected to a hash operation or other operations to obtain the derived key; the block link node may then encrypt the contract state based on the derived key to generate an encrypted contract state.
In one embodiment, the public key is stored in a surrounding ring on a block link point. Because only the CPU can access the public key stored in the enclosure, the public key is safe enough and can not be obtained by lawless persons theoretically, and the safety of the encrypted contract state is ensured.
The public key can be distributed to the block chain nodes by a Key Management Server (KMS) after being remotely proved by the block chain nodes; or, the public key can be obtained by negotiation among all nodes in the block chain network; alternatively, the public key may be obtained in other ways, which is not limited by 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 security key, and the security key may implement version evolution, so that the public key is evolved. In other words, the public key may be a security key of a specified version; among the neighboring versions of the security key, 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 a root key (root key), and the other versions of the security key are irreversibly calculated directly or indirectly from the root key. For example, the low-version security key is obtained by performing hash operation on the high-version security key and the preset information, and due to the characteristics of the hash operation, the low-version security key cannot be reversely deduced from the high-version security key, so that the public key can be replaced by the version evolution of the security key, and the same public key is prevented from being used for a long time. And, when the public key is replaced, the version of the key after replacement can be ensured to be always higher than that of the key before replacement, so as to ensure that: on one hand, even if the key used previously is leaked, the key can be replaced by a key with a high version to stop loss in time; on the other hand, as long as the high-version key is possessed, the low-version key can be evolved, and the previously used key is compatible, so that the previously encrypted contract state is decrypted.
The version evolution rules between security keys may be: and carrying out hash operation on the adjacent high-version secret key and the version number corresponding to the adjacent low-version secret key to obtain the adjacent low-version secret key. For example, if 256 versions of keys with version numbers of 0 to 255 are derived, hash calculation can be performed on the root key and the version number 0xFF (corresponding decimal value is 255) to obtain a key-255 with the version number of 255; carrying out hash calculation on the key-255 and a 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 the 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 cryptographic processing of the contract state.
As described above, the block link node encrypts the contract status according to the public key and the influence factor to obtain the encrypted contract status. If the public key and the influence factor are fixed values, the public key and the influence factor are only required to be separately stored in the enclosure; however, if the public key or the impact factor has a dynamic value, that is, different public keys or impact factors may be used when encrypting different contract states, then when storing the encrypted contract state, the public key, the impact factor or information indicating the value should be stored in association with each other, so as to facilitate the subsequent decryption operation.
Given the 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 a key-value pair (key-value). The Key value may be determined by referring to a manner in the related art, such as Key hash (RLP (value)), that is, the Key value is a hash value of a value encoded by RLP (Recursive Length Prefix). While the components of value may include: a post-encryption contract state, a check value, and an impact factor. The encrypted contract status may be obtained by encrypting according to the public key and the influencing factor in the manner described in the above embodiment. When encryption is performed using, for example, the GCM algorithm or other encryption algorithms, a check value may also be obtained; of course, if no check value exists, the check value may not be included in the value. The values of the impact factors exist in the above-mentioned cases, and fig. 8 takes the case that the impact factors include the block height, the transaction offset and the modification order at the same time, that is, the impact factors are composed of "the block height of the block where the transaction is located", "the position offset of the transaction in the block" and "the modified order of the contract state when the intelligent contract is executed".
Based on the embodiment shown in fig. 8, after reading this key-value pair, the blockchain node may obtain the impact factor required for decryption from the value of the key-value pair, so as to decrypt the encrypted contract state in combination with the public key. In some scenarios, the impact factor may be encrypted, for example, the impact factor is encrypted in the TEE by the blockchain node in the storage stage, so that the value includes the encrypted impact factor instead of the impact factor in the form of plaintext; 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 of the encrypted contract state can be further improved, and the security is improved.
The block chain node may encrypt the impact factor with 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, the influencing factor may be encrypted by using another key different from the public key. For example, when the public key is a key of a certain version, the key for encrypting the influencing factor can be of another version so as to be distinguished from the public key; for example, the impact factor may be encrypted using the lowest version key with a version number of 0, and the version number of the public key may be set to be necessarily greater than 0.
Version information may exist for the public key, such as a security key for which the public key is a version of the aforementioned version. When the blockchain node stores the key value pair of the encrypted contract state, the value may include version information of the public key, and particularly, when the version of the public key used by the blockchain node is updated, the version of the currently used public key may be different from the previously stored historical public key used in the encrypted contract state, so that the version information included in the value may help the blockchain node to accurately select the key to be used. For example, as shown in fig. 9, based on the embodiment shown in fig. 8, 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.
The block link point can be added to the value after encrypting the version information, instead of recording the version information in a plaintext form. The key used for encrypting the version information may be a public key, or another key different from the public key, for example, the version information may be encrypted with the lowest version key having a version number of 0, similar to the aforementioned influencing factor.
In summary, compared with the method of encrypting by using a public key alone, the method of encrypting the contract state by using the public key according to the present specification can increase randomness of the encrypted contract state by using the impact factor, so as to improve data security.
FIG. 10 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 10, at the hardware level, the apparatus includes a processor 1002, an internal bus 1004, a network interface 1006, a memory 1008, and a non-volatile memory 1010, although it may also include hardware required for other services. The processor 1002 reads a corresponding computer program from the non-volatile memory 1010 into the memory 1008 and then runs the computer program, thereby forming a device for realizing dynamic encryption based on the block height on a logic level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Referring to fig. 11, in a software implementation, the apparatus for implementing dynamic encryption based on block height may include:
a decryption unit 1101, configured to decrypt the received transaction in the trusted execution environment to determine a smart contract corresponding to the transaction;
an execution unit 1102 that executes the intelligent contract in a trusted execution environment, causing a contract state included in the intelligent contract to be modified;
an encryption unit 1103, configured to encrypt the contract state in the trusted execution environment according to a public key and an impact factor, where the impact factor includes a block height of a block where the transaction is located;
a storage unit 1104, configured to write the encrypted contract status into the database.
Optionally, the influence factor further includes at least one of: the position offset of the transaction in the block, the modified order of the contract states when the intelligent contract is executed.
Optionally, the impact factor is written to a database in association with the encrypted contract state.
Optionally, the impact factor is written to the database in association with the encrypted contract state after being encrypted in the trusted execution environment.
Optionally, the encryption unit 1103 is specifically configured to:
the public key is used as a symmetric key required by the 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 a 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 derived key according to the public key and the influence factor;
and encrypting the contract state according to the derived key to generate the encrypted contract state.
Optionally, the public key includes: a security key of a specified version; wherein, among the adjacent versions of the security key, the low version of the security key is irreversibly calculated from the high version of the security key.
Optionally, the security key of the highest version is a root key, and the security keys of the other versions are computed irreversibly from the root key directly or indirectly.
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 to the database in association with the encrypted contract state.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging 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 forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
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 computer storage media 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, 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 media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
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 an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may 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 may also be possible or may be advantageous.
The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification 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 and 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, such 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 herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims (11)

1. A method for implementing dynamic encryption based on block height, comprising:
the block chain node decrypts the received transaction in the trusted execution environment to determine an intelligent contract corresponding to the transaction;
the blockchain node executes the intelligent contract in a trusted execution environment, so that contract state contained in the intelligent contract is modified;
the block chain node encrypts the contract state in a trusted execution environment according to a public key and an influence factor so as to write the encrypted contract state into a database, wherein the influence factor comprises the block height of a block where the transaction is located, so that the contract state modified after each transaction in different blocks is executed respectively, and the encrypted contract states obtained by encrypting each contract state by the block chain node according to the public key and the influence factor are different;
wherein the impact factor is written to a database in association with the encrypted contract state; the impact factor is written to a database in association with the encrypted contract state, including: the impact factor is written to a database in association with the encrypted contract state after being encrypted in a trusted execution environment.
2. The method of claim 1, the impact factors further comprising at least one of: the position offset of the transaction in the block, the modified order of the contract states when the intelligent contract is executed.
3. The method of claim 1, the blockchain node encrypting the contract state in a trusted execution environment according to a public key and an impact factor, comprising:
the block chain node uses the public key as a symmetric key required by a GCM algorithm, uses 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.
4. The method of claim 1, the blockchain node encrypting the contract state in a trusted execution environment according to a public key and an impact factor, comprising:
the block chain node generates a derived key according to the public key and the influence factor;
and the block chain link point encrypts the contract state according to the derived key to generate the encrypted contract state.
5. The method of claim 1, the public key comprising: a security key of a specified version; wherein, among the adjacent versions of the security key, the low version of the security key is irreversibly calculated from the high version of the security key.
6. The method of claim 5, wherein the highest version of the security key is a root key, and other versions of the security key are computed irreversibly or directly from the root key.
7. The method of claim 5, wherein version information for the public key is written to a database in association with the encrypted contract state.
8. The method of claim 7, wherein 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.
9. An apparatus for implementing dynamic encryption based on block height, comprising:
the decryption unit is used for decrypting the received transaction in the trusted execution environment so as to determine the intelligent contract corresponding to the transaction;
an execution unit that executes the intelligent contract in a trusted execution environment, causing a contract state included in the intelligent contract to be modified;
the encryption unit encrypts 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 a block where the transaction is located, so that for the contract state modified after each transaction in different blocks is executed respectively, the encrypted contract states obtained by encrypting each contract state by the block chain node according to the public key and the influence factor are different;
a storage unit configured to write the impact factor in association with the encrypted contract status into a database; wherein writing the impact factor to a database in association with the encrypted contract state comprises: the impact factor is encrypted in a trusted execution environment and the encrypted impact factor is written to a database in association with the encrypted contract state.
10. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method of any one of claims 1-8 by executing the executable instructions.
11. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 8.
CN201910471633.3A 2019-05-31 2019-05-31 Method and device for realizing dynamic encryption based on block height Active CN110266467B (en)

Priority Applications (4)

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
PCT/CN2020/092231 WO2020238878A1 (en) 2019-05-31 2020-05-26 Dynamic encryption method and device
PCT/CN2020/092611 WO2020238959A1 (en) 2019-05-31 2020-05-27 Method and device for realizing dynamic encryption based on block height

Applications Claiming Priority (1)

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

Related Child Applications (1)

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

Publications (2)

Publication Number Publication Date
CN110266467A CN110266467A (en) 2019-09-20
CN110266467B true CN110266467B (en) 2021-04-27

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 Before (1)

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

Country Status (2)

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

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113438068B (en) * 2019-05-31 2024-01-09 创新先进技术有限公司 Method and device for realizing dynamic encryption based on block height
WO2020238878A1 (en) * 2019-05-31 2020-12-03 创新先进技术有限公司 Dynamic encryption method and device
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
CN114679284A (en) * 2020-12-24 2022-06-28 中国移动通信有限公司研究院 Trusted remote attestation system, storage method, verification method and storage medium thereof
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 (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109559105A (en) * 2018-11-05 2019-04-02 深圳市恒达移动互联科技有限公司 Digital wallet generation method and system based on TEE and encryption chip
CN109697613A (en) * 2018-12-29 2019-04-30 重庆巴奥科技有限公司 For network trade safety certification method and system 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

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101330379B (en) * 2007-06-22 2011-02-09 华为技术有限公司 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
WO2017090041A1 (en) * 2015-11-24 2017-06-01 Ben-Ari Adi A system and method for blockchain smart contract data privacy
US11115205B2 (en) * 2016-09-29 2021-09-07 Nokia Technologies Oy Method and apparatus for trusted computing
US20180225661A1 (en) * 2017-02-07 2018-08-09 Microsoft Technology Licensing, Llc Consortium blockchain network with verified blockchain and consensus protocols
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
CN107342858B (en) * 2017-07-05 2019-09-10 武汉凤链科技有限公司 A kind of intelligent contract guard method and system based on trusted context
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
CN109039649B (en) * 2018-08-03 2021-08-06 北京大学深圳研究生院 Key management method and device based on block chain in CCN and storage medium
CN109360091B (en) * 2018-08-30 2020-09-01 阿里巴巴集团控股有限公司 Random object selection method and device based on block chain
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
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
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 (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109559105A (en) * 2018-11-05 2019-04-02 深圳市恒达移动互联科技有限公司 Digital wallet generation method and system based on TEE and encryption chip
CN109697613A (en) * 2018-12-29 2019-04-30 重庆巴奥科技有限公司 For network trade safety certification method and system 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

Also Published As

Publication number Publication date
CN113438068A (en) 2021-09-24
CN110266467A (en) 2019-09-20
WO2020238959A1 (en) 2020-12-03
CN113438068B (en) 2024-01-09

Similar Documents

Publication Publication Date Title
CN110266467B (en) Method and device for realizing dynamic encryption based on block height
CN110245506B (en) Intelligent contract management method and device based on block chain and electronic equipment
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
CN110276610B (en) Method and device for realizing dynamic encryption based on transaction offset
CN110245944B (en) Receipt storage method and node based on user type
CN110245947B (en) Receipt storage method and node combining conditional restrictions of transaction and user types
CN110266644B (en) Receipt storage method and node combining code marking and transaction types
CN110263087B (en) Receipt storage method and node based on multi-dimensional information and with conditional restriction
CN110245942B (en) Receipt storage method and node combining user type and judgment condition
CN110264192B (en) Receipt storage method and node based on transaction type
CN110263086B (en) Receipt storage method and node combining user type and event function type
CN110245945B (en) Receipt storage method and node combining code marking and user type
CN110264196B (en) Conditional receipt storage method and node combining code labeling and user type
CN110245946B (en) Receipt storage method and node combining code labeling and multi-type dimensionality
CN110032876B (en) Method, node and storage medium for implementing privacy protection in block chain
CN110245504B (en) Receipt storage method and node combined with condition limitation of multi-type dimensionality
CN110264193B (en) Receipt storage method and node combining user type and transaction type
CN110245503B (en) Receipt storage method and node combining code marking and judging conditions
CN110245489B (en) Receipt storage method, node and system based on plaintext log
CN110276684B (en) Receipt storage method and node combining transaction type and event function type
CN110033266B (en) Method, node and storage medium for implementing privacy protection in block chain
CN110264194B (en) Receipt storage method and node based on event function type
CN110263090B (en) Receipt storage method and node with multiple types of dimensions
CN110008737B (en) Method, node and storage medium for implementing privacy protection 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
TA01 Transfer of patent application right

Effective date of registration: 20200924

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Applicant after: Innovative advanced technology Co.,Ltd.

Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Applicant before: Advanced innovation technology Co.,Ltd.

Effective date of registration: 20200924

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Applicant after: Advanced innovation technology Co.,Ltd.

Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands

Applicant before: Alibaba Group Holding Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20240913

Address after: Guohao Times City # 20-01, 128 Meizhi Road, Singapore

Patentee after: Ant Chain Technology Co.,Ltd.

Country or region after: Singapore

Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Patentee before: Innovative advanced technology Co.,Ltd.

Country or region before: Cayman Islands

TR01 Transfer of patent right