HK40029518A - Securely executing smart contract operations in a trusted execution environment - Google Patents

Description

Securely executing intelligent contract operations in a trusted execution environment

Technical Field

This document relates to securely executing intelligent contract operations in a trusted execution environment.

Background

Distributed Ledger System (DLS), which may also be referred to as a consensus network and/or a blockchain network, enables participating entities to securely and tamperproof store data. Without reference to any particular use case, DLS is often referred to as a blockchain network. An example of one type of blockchain network may include a federated blockchain network provided for a selected set of entities that controls the consensus process, and the federated blockchain network includes an access control layer.

An intelligent contract is a program that executes on a blockchain. A smart contract contains a set of predefined rules according to which parties to the smart contract agree to interact with each other. The protocol defined in the intelligent contract will be automatically enforced if the predefined rules of the intelligent contract are satisfied. Smart contracts typically have tamper-resistant capabilities and facilitate, verify and enforce negotiation or execution of protocols or transactions.

In a federated blockchain network, since only a selected group of nodes control the consensus process, an attacker must gain control over a relatively small number of nodes to affect the consensus process. Although techniques have been proposed for solving these types of security problems in federated blockchain networks, a more efficient and secure solution would be advantageous.

Disclosure of Invention

Techniques for securely executing requested intelligent contract operations in a Trusted Execution Environment (TEE) executing at block chain nodes are described herein. More specifically, embodiments herein enable blockchain nodes to perform intelligent contract operations within a TEE in a secure and verifiable manner such that parties may trust that the environment in which the operations are performed has not been tampered with or compromised.

Also provided herein are one or more non-transitory computer-readable storage media coupled to one or more processors and having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.

Also provided herein are systems for implementing the methods provided herein. The system includes one or more processors and a computer-readable storage medium coupled to the one or more processors and having instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.

It should be appreciated that methods in accordance with the present disclosure may include any combination of the aspects and features described herein. That is, methods according to the present disclosure are not limited to the combinations of aspects and features specifically described herein, but also include any combination of the aspects and features provided.

The details of one or more embodiments of the disclosure are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.

Drawings

FIG. 1 is a diagram illustrating an example of an environment that may be used to perform embodiments herein.

Fig. 2 is a diagram illustrating an example of an architecture according to embodiments herein.

Fig. 3 is a diagram illustrating an example of a system according to embodiments herein.

Fig. 4 is a diagram illustrating an example of a system according to embodiments herein.

Fig. 5 depicts an example of a process that may be performed according to embodiments herein.

Fig. 6 depicts an example of modules of an apparatus according to embodiments herein.

Like reference numbers and designations in the various drawings indicate like elements.

Detailed Description

Techniques for securely executing requested intelligent contract operations in a Trusted Execution Environment (TEE) executing at block chain nodes are described herein. More specifically, embodiments herein enable blockchain nodes to perform intelligent contract operations within a TEE in a secure and verifiable manner such that parties may trust that the environment in which the operations are performed has not been tampered with or compromised.

To provide further context for embodiments herein, and as noted above, Distributed Ledger Systems (DLSs), which may also be referred to as consensus networks (e.g., consisting of point-to-point nodes) and blockchain networks, enable participating entities to securely, non-tamperproof conduct transactions and store data. Although the term blockchain is generally associated with a particular network and/or use case, blockchains are used herein to refer to DLSs generally without reference to any particular use case.

Blockchains are data structures that store transactions in a transaction-untamperable manner. Thus, the transactions recorded on the blockchain are reliable and trustworthy. A block chain includes one or more blocks. Each block in the chain is linked to the immediately preceding block in the chain by a cryptographic hash value (cryptographic hash) that contains the preceding block. Each tile also includes a timestamp, its own cryptographic hash value, and one or more transactions. Transactions that have been verified by nodes in the blockchain network are hashed and encoded into a merkel (Merkle) tree. A Merkle tree is a data structure in which data at leaf nodes of the tree is hashed and all hash values in each branch of the tree are concatenated at the root of the branch. This process continues down the tree up to the root of the entire tree where hash values representing all of the data in the tree are stored. The hash value of a transaction purportedly stored in the tree can be quickly verified by determining whether it is consistent with the structure of the tree.

A blockchain is a decentralized or at least partially decentralized data structure for storing transactions, while a blockchain network is a network of computing nodes that manage, update, and maintain one or more blockchains by broadcasting, validating, and confirming transactions, etc. As described above, the blockchain network may be provided as a public blockchain network, a private blockchain network, or a federated blockchain network. Embodiments herein are described in further detail herein with reference to federated blockchain networks. However, it is contemplated that embodiments herein may be implemented in any suitable type of blockchain network.

Typically, a federated blockchain network is private between the participating entities. In a federated blockchain network, the consensus process is controlled by an authorized set of nodes, which may be referred to as consensus nodes, one or more of which are operated by respective entities (e.g., financial institutions, insurance companies). For example, a federation of ten (10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, and each entity may operate at least one node in the federated blockchain network.

In some examples, within a federated blockchain network, a global blockchain is provided as a blockchain that is replicated across all nodes. That is, all consensus nodes are in a fully consensus state with respect to the global blockchain. To achieve consensus (e.g., agree to add blocks to a blockchain), a consensus protocol is implemented within the federated blockchain network. For example, a federated blockchain network may implement a Practical Byzantine Fault Tolerant (PBFT) consensus, described in further detail below.

Fig. 1 is a diagram illustrating an example of an environment 100 that may be used to perform embodiments herein. In some examples, the exemplary environment 100 enables entities to participate in a federated blockchain network 102. The exemplary environment 100 includes computing devices 106, 108 and a network 110. In some examples, the network 110 includes a Local Area Network (LAN), a Wide Area Network (WAN), the internet, or a combination thereof, and connects network sites, user devices (e.g., computing devices), and backend systems. In some examples, network 110 may be accessed through wired and/or wireless communication links.

In the depicted example, computing systems 106, 108 may each comprise any suitable computing system capable of participating as a node in federation blockchain network 102. Exemplary computing devices include, but are not limited to, servers, desktop computers, laptop computers, tablet computing devices, and smart phones. In some examples, computing systems 106, 108 carry one or more computer-implemented services for interacting with federation blockchain network 102. For example, the computing system 106 may host a computer-implemented service of a first entity (e.g., user a), such as a transaction management system that the first entity uses to manage transactions with one or more other entities (e.g., other users). The computing system 108 may host a computer-implemented service of a second entity (e.g., user B), such as a transaction management system that the second entity uses to manage transactions with one or more other entities (e.g., other users). In the example of fig. 1, the federated blockchain network 102 is represented as a Peer-to-Peer network of nodes (Peer-to-Peer network), and the computing systems 106, 108 provide nodes of first and second entities, respectively, that participate in the federated blockchain network 102.

Fig. 2 depicts an example of a conceptual architecture 200 according to embodiments herein. The conceptual architecture 200 includes a physical layer 202, a managed services layer 204, and a blockchain network layer 206. In the depicted example, the entity layer 202 includes three participants, participant a, participant B, and participant C, each having a respective transaction management system 208.

In the depicted example, the hosted services layer 204 includes an interface 210 for each transaction management system 210. In some examples, the respective transaction management systems 208 communicate with the respective interfaces 210 over a network (e.g., the network 110 of fig. 1) using a protocol (e.g., hypertext transfer protocol secure (HTTPS)). In some examples, each interface 210 provides a communication connection between the respective transaction management system 208 and the blockchain network layer 206. More specifically, the interface 210 communicates with a blockchain network 212 of the blockchain network layer 206. In some examples, communication between the interface 210 and the block chain network layer 206 is performed using Remote Procedure Calls (RPCs). In some examples, the interface 210 "carries" blockchain network nodes for the respective transaction management systems 208. For example, interface 210 provides an Application Programming Interface (API) for accessing blockchain network 212.

As described herein, a blockchain network 212 is provided as a point-to-point network, the blockchain network 212 including a plurality of nodes 214 that record information in a blockchain 216 without tampering. Although a single blockchain 216 is schematically depicted, multiple copies of blockchain 216 are provided and multiple copies of blockchain 216 are maintained across blockchain network 212. For example, each node 214 stores a copy of the block chain. In some embodiments, blockchain 216 stores information associated with transactions performed between two or more entities participating in the federation blockchain network.

A chain of blocks (e.g., block chain 216 of fig. 2) consists of a chain of blocks, each block storing data. Exemplary data includes transaction data representing a transaction between two or more participants. Although "transaction" is used herein by way of non-limiting example, it is contemplated that any suitable data may be stored in the blockchain (e.g., documents, images, video, audio). Exemplary transactions may include, but are not limited to, exchanges of value (e.g., assets, products, services, currency). Transaction data is stored in the blockchain in a non-tamperproof manner. That is, the transaction data cannot be changed.

The transaction data is hashed prior to being stored in the chunk. The hash process is a process of converting transaction data (provided as character string data) into a fixed-length hash value (also provided as character string data). It is not possible to perform a de-hash process (un-hash) on the hash value to obtain the transaction data. The hashing process ensures that even slight changes in the transaction data will result in an entirely different hash value. Further, as described above, the hash value has a fixed length. That is, the length of the hash value is fixed regardless of the size of the transaction data. The hash process includes processing the transaction data through a hash function to generate a hash value. Examples of hash functions include, but are not limited to, Secure Hash Algorithm (SHA) -256, which outputs a 256-bit hash value.

Transaction data for a plurality of transactions is hashed and stored in a block. For example, hash values for two transactions are provided, and themselves are hashed to provide another hash value. This process is repeated until a single hash value is provided for all transactions to be stored in the block. This hash value is called the Merkle root hash value and is stored in the header of the chunk. Any change in a transaction causes its hash value to change and ultimately the Merkle root hash value to change.

The blocks are added to the block chain by a consensus protocol. A plurality of nodes in the blockchain network participate in the consensus protocol and perform an operation of adding a block to the blockchain. Such nodes are referred to as consensus nodes. The PBFT introduced above serves as a non-limiting example of a consensus protocol. The consensus node performs a consensus protocol to add a transaction to the blockchain and updates the overall state of the blockchain network.

In further detail, the consensus node generates a chunk header, hashes all transactions in the chunk, and combines the hash values in pairs to generate further hash values until a single hash value (Merkle root hash value) is provided for all transactions in the chunk. This hash value is added to the block header. The consensus node also determines the hash value of the nearest chunk in the chain of chunks (i.e., the last chunk added to the chain of chunks). The consensus node also adds a random number (nonce) value and a timestamp to the chunk header.

Typically, PBFT provides a practical byzantine state machine replication that is tolerant of byzantine faults (e.g., failed nodes, malicious nodes). This is achieved in the PBFT by assuming that a failure will occur (e.g., assuming that there is an independent node failure and/or a steering message sent by a common node). In PBFT, the consensus nodes are provided in a sequence comprising a primary consensus node and a backup consensus node. The master consensus node is changed periodically. The transaction is added to the blockchain by agreeing on the world state of the blockchain network by consensus nodes within the blockchain network. In this process, messages are transmitted between the consensus nodes, and each consensus node proves that a message was received from a designated peer node and verifies that the message was not modified during transmission.

In PBFT, a consensus protocol is provided in multiple stages, with all consensus nodes starting in the same state. First, a client sends a request to a master consensus node to invoke a service operation (e.g., perform a transaction within a blockchain network). In response to receiving the request, the master consensus node multicasts the request to the standby consensus node. The backup consensus nodes execute the request and each backup consensus node sends a reply to the client. The client waits until a threshold number of replies are received. In some examples, the client waits to receive f +1 replies, where f is the maximum number of fault-aware nodes that can be tolerated within the blockchain network. The end result is that a sufficient number of consensus nodes agree on the order of records to be added to the blockchain, and the records are accepted or rejected.

In some blockchain networks, privacy of transactions is maintained using cryptography. For example, two nodes may encrypt transaction data if they want to maintain transaction privacy so that other nodes in the blockchain network cannot see the details of the transaction. Exemplary encryption processes include, but are not limited to, symmetric encryption and asymmetric encryption. Symmetric encryption refers to an encryption process that uses a single key to both encrypt (generate ciphertext from plaintext) and decrypt (generate plaintext from ciphertext). In symmetric encryption, the same key may be used for multiple nodes, so each node may encrypt/decrypt transaction data.

Asymmetric encryption uses key pairs, each key pair comprising a private key and a public key, the private key being known only to the respective node, and the public key being known to any or all other nodes in the blockchain network. A node may encrypt data using a public key of another node, and the encrypted data may be decrypted using a private key of the other node. For example, referring again to fig. 2, participant a may encrypt data using participant B's public key and send the encrypted data to participant B. Participant B can use its private key to decrypt the encrypted data (ciphertext) and extract the original data (plaintext). Messages encrypted using a node's public key can only be decrypted using the node's private key.

Asymmetric encryption is used to provide a digital signature that enables a participant in a transaction to confirm the other participants in the transaction and the validity of the transaction. For example, a node may digitally sign a message, and another node may confirm that the message was sent by the node based on the digital signature of participant a. Digital signatures may also be used to ensure that messages are not tampered with during transmission. For example, referring again to fig. 2, participant a will send a message to participant B. Participant a generates a hash value of the message and then encrypts the hash value using its private key to provide a digital signature as an encrypted hash value. Participant a appends the digital signature to the message and sends the message with the digital signature to participant B. Participant B decrypts the digital signature using participant a's public key and extracts the hash value. Participant B hashes the message and compares the hash values. If the hash values are the same, participant B can confirm that the message did come from participant A and has not been tampered with.

In some embodiments, a node of and/or a node in communication with a blockchain network may operate using a TEE. At a high level, a TEE is a trusted environment within hardware (one or more processors, memory) that is isolated from the operating environment (e.g., Operating System (OS), basic input/output system (BIOS)) of the hardware. In more detail, a TEE is a separate secure area of a processor that ensures confidentiality and integrity of code executing within the main processor, as well as data loaded within the main processor. Within the processor, the TEE runs in parallel with the OS. At least a portion of a so-called Trusted Application (TA) executes within the TEE and has access to the processor and memory. With TEE, the TA is protected from other applications running in the main OS. Furthermore, the TEE cryptographically isolates the TAs from each other within the TEE.

Examples of TEEs include software protection extensions (SGX) provided by intel corporation of santa clara, california. Although SGX is discussed herein by way of example, it is contemplated that embodiments herein may be implemented using any suitable TEE.

SGX provides hardware-based TEE. In SGX, trusted hardware is the core of a Central Processing Unit (CPU), and a portion of physical memory is isolated to protect selected code and data. The isolated portion of memory is called an enclave (enclave). More specifically, the enclave is provided as an Enclave Page Cache (EPC) in memory and mapped to an application address space. The memory (e.g., DRAM) includes a reserved random access memory (PRM) for the SGX. The PRM is the lowest BIOS level of contiguous memory space and is not accessible by any software. Each EPC is a set of memory (e.g., 4KB) allocated by the OS to load application data and code in the PRM. EPC metadata (EPCM) is the entry address of each EPC and ensures that each EPC can only be shared by one enclave. That is, a single enclave may use multiple EPCs, with the EPCs dedicated to a single enclave.

During execution of the TA, the processor operates in a so-called enclave mode when accessing data stored in the enclave. Operation in enclave mode enforces an additional hardware check for each memory access. In SGX, the TAs are compiled into a trusted part and an untrusted part. Such as an OS, BIOS, privileged system code, Virtual Machine Manager (VMM), System Management Mode (SMM), etc. to access the trusted section. In operation, the TA runs and creates an enclave within the PRM of memory. Trusted functions executed by trusted portions within the enclave are called by untrusted portions, and code executing within the enclave treats the data as clear data (unencrypted), and external access to the data is denied. The trusted part provides an encrypted response to the call and the TA continues execution.

An authentication process may be performed to verify that the expected encoding (e.g., the trusted portion of the TA) is being performed securely within the TEE providing the SGX. Typically, the authentication process includes the TA receiving an authentication request from a challenger (e.g., another node in the blockchain network, a Key Management System (KMS) of the blockchain network). In response, the TA requests that it generate remote authentication, also known as citation, on the fly. Generating the remote authentication includes sending a local authentication from the enclave to a so-called quote enclave, which verifies the local authentication and converts the local authentication to the remote authentication by signing the local authentication using an asymmetric authentication key. The remote authentication (quote) is provided to a challenger (e.g., the KMS of the blockchain network).

The challenger verifies the remote authentication using the authentication verification service. For SGX, intel provides Intel Authentication Service (IAS) which receives a remote authentication from a challenger and verifies the remote authentication. More specifically, the IAS processes the remote authentication and provides a report (e.g., Authentication Verification Report (AVR)) indicating whether the remote authentication is verified. If not, an error may be indicated. If verified (with the expectation that the code is executing securely in the TEE), the challenger may start or continue to interact with the TA. For example, in response to the verification, the KMS (as a challenger) may issue an asymmetric cryptographic key (e.g., a public and private key pair) to the node executing the TEE (e.g., through a key exchange process, such as elliptic curve Diffie-hellman (ecdh)) to enable the node to securely communicate with other nodes and/or clients.

In some blockchain networks, so-called intelligent contracts may be implemented. Smart contracts may be described as digital representations of real-world legal contracts having contract terms that affect parties. In an example context, intelligent contracts are implemented, stored, updated (as needed), and executed within a federated blockchain network. Contractual parties (e.g., buyers and sellers) associated with the intelligent contract are represented as nodes in a federated blockchain network. In some examples, a contractual party may include an entity (e.g., a business enterprise) associated with (e.g., as a party to) an intelligent contract.

In more detail, the intelligent contracts are provided as computer-executable programs executing on blockchains (e.g., nodes within a blockchain network). A smart contract contains a set of predefined rules according to which parties to the smart contract agree to interact with each other. The protocol defined in the intelligent contract will be automatically executed if the predefined rules of the intelligent contract are satisfied. Smart contracts typically have tamper-resistant capabilities and facilitate, verify and enforce negotiation or execution of protocols or transactions.

Fig. 3 is a diagram illustrating an example of a system 300 according to embodiments herein. As shown, system 300 includes a blockchain network 302, which blockchain network 302 includes blockchain nodes 304 a-d. The blockchain nodes 304a-d include service TEEs 306a-d and Key Management (KM) TEEs 308 a-d. Nodes 304a-d may access intelligent contract service logic 330. Key management center 310 is communicatively coupled to nodes 304 a-d.

Each of the nodes 304a-d is a blockchain node that participates in the blockchain network 302 and facilitates maintenance of a blockchain associated with the blockchain network 302 (not shown). As described above, nodes 304a-d may participate in consensus processing associated with blockchain network 302, may collect transactions into blockchains to add to blockchains, may process transactions requested by users of blockchain network 302, may perform operations encoded in intelligent contracts, and perform other tasks related to blockchain management. In some embodiments, each node may be a computing device (e.g., a server) that includes one or more processors, storage devices, and other components. In some cases, the nodes 304a-d communicate with each other and other nodes participating in the blockchain network 302 through a communication network (not shown). For the remainder of the description of FIG. 3, node 304a will be described as an example, with the understanding that nodes 304b-d may also include features of node 304 a.

Node 304a includes a serving TEE306 a. In some embodiments, the service TEE306a is a secure application environment implemented using TEE technology (e.g., intel SGX). The service TEE306a may execute one or more software programs or libraries. For purposes herein, the service TEE306a refers to the secure environment (TEE) and software executing within the TEE that performs the operations. In some embodiments, service TEE306a performs the intelligent contract operation specified by the encrypted client request and outputs the encryption result associated with the intelligent contract operation. This functionality is described in more detail below with respect to fig. 4.

Node 304a also includes a key management tee (km tee)308 a. In some embodiments, KM TEE308a is a secure application environment implemented using TEE technology (e.g., intel SGX). KM TEE308a may execute one or more software programs or libraries. For purposes herein, KM TEE308a refers to a secure environment (TEE) and software executing within the TEE that performs the operations. In some embodiments, KM TEE308a obtains encryption keys from key management center 310, as described in more detail below with reference to fig. 4.

Key management center 310 may generate, store, and maintain encryption keys. The key management center 310 may also authenticate the identity of the KM TEEs 308a-d and provide encryption keys to the nodes 304a-d through a remote authentication and key deployment process 320. In some embodiments, key management may further provide encryption keys to clients to interact with nodes 304 a-d. This functionality is described in more detail below with respect to fig. 4. In some embodiments, the key management center 310 may be one or more servers or other computing devices in communication with one or more nodes of the blockchain network 302 over a communication network (not shown). Key management center 310 may also include one or more storage devices coupled to key management center 310 or accessible over a communication network for storing encryption keys and other data.

In some cases, key management center 310 operates to authenticate the identity of KM TEE308a-d prior to encryption key deployment. For example, key management center 310 may verify the authenticity of KM TEE308a before providing one or more encryption keys (described below) to KM TEE308 a. This validation ensures that the software executed by KM TEE308a has not been tampered with after being provisioned. In some embodiments, verification may include a remote authentication process 320, such as described above.

After KM TEEs 308a-d obtain one or more encryption keys from key management center 310, the keys may be forwarded to service TEEs 306a-d to perform cryptographic operations. In some cases, while the KM TEE and service TEE pairs (e.g., KMTEE 308a and service TEE306 a) operate on a single node (e.g., node 304a), they each have their own independent TEEs. As a result, information communicated between KM TEEs 308a-d and service TEEs 306a-d is sent over untrusted areas. In this case, KM TEEs 308a-d may authenticate the identity of service TEEs 306a-d, for example, by performing a local authentication process.

Local authentication may allow an enclave to prove its identity or authenticity to another enclave within the same local platform. For example, KM TEE308a may send a challenge to verify the authenticity of service TEE306 a. Upon receiving the challenge, the service TEE306a may request hardware (e.g., a CPU) of the node 304a to generate a report that includes cryptographic evidence that the service TEE306a exists on the node 304 a. The report may be provided to KM TEE308a to verify that the enclave report was generated by node 304a on the same platform. In some cases, local authentication may be based on a symmetric key system, where only the reported KM TEE308a is verified and the enclave hardware generating the report knows the symmetric key, which is embedded in the hardware platform of node 304 a.

After authenticating the service TEEs 306a-d through local authentication, the KM TEEs 308a-d may provide one or more encryption keys to the service TEEs 306 a-d. In some cases, KM TEEs 308a-d may provide encryption keys in response to authentication of service TEEs 306a-d, or may provide keys in response to one or more requests by service TEEs 306 a-d.

Intelligent contract service logic 330 includes one or more intelligent contract definitions. Nodes 304a-304d perform certain operations from intelligent contract service logic 330 (e.g., upon request by a client, as shown in FIG. 4). In some embodiments, the intelligent contract definitions in intelligent contract service logic 330 include instructions executed by nodes of blockchain network 302. Intelligent contract service logic 330 may include intelligent contract definitions stored in one or more blockchains maintained by blockchain network 302 (not shown).

Fig. 4 is a diagram illustrating an example of a system 400 according to implementations herein. As shown, the system 400 includes a node 304a (including a service TEE306a and a KM TEE308 a) and a key management center 310 described with respect to fig. 3. The system 400 also includes a client 480 communicatively coupled to the key management center 310.

In operation, system 400 may securely execute smart contract instructions and produce encrypted operation results (e.g., included in a blockchain). As described above, key management center 310 may perform remote authentication to authenticate the identity of KM TEE308a prior to trust with the encryption key. After KM TEE308 is authenticated, key management center 310 may provide KM TEE308a for node 304a with unseal private key 402, root key 404, and signature private key 406. Key management center 310 also carries a sealing public key 414 and an authentication public key 416. Key management center 310 provides these keys to authorized clients to encrypt and decrypt various data associated with service TEE306a, as described below.

As shown, key management center 310 provides sealed public key 414 to client 480. In some cases, key management center 310 authenticates client 480 and provides only sealed public key 414 if client 480 is authorized to access sealed public key 414. Key management center 310 may query internal or external licensed resources to make this determination. Sealed public key 414 is associated with decapsulation private key 402 provided to KM TEE308 a. Sealing public key 414 and unsealing private key 402 form a key pair, meaning that data encrypted with sealing public key 414 can be decrypted using unsealing private key 402.

Client 480 identifies a requested contract operation 450, which is an intelligent contract operation performed by an etherhouse Virtual Machine (VM)460 deployed in service TEE306 a. In some cases, smart contract operations 450 include one or more instructions encoded in a smart contract programming language for execution by a VM that operates to execute the instructions of the language. The intelligent contract operations 450 may include an execution state for the intelligent contract associated with the request contract operation 450. During execution of an intelligent contract, a plurality of nodes of a blockchain network respectively execute each instruction of the intelligent contract and produce a result indicating an execution state of the intelligent contract after completion of the instruction. The execution state may include data associated with the smart contract. Each executed instruction of the contract may change the content of the data (e.g., store values to be used by subsequent instructions in the intelligent contract). After executing the instructions of the intelligent contract, the nodes of the blockchain network agree on a new execution state after executing the instructions. The consensus process is performed for each instruction executed in the intelligent contract to agree on the execution path of the intelligent contract and ultimately on the final outcome of the execution.

At 452, the client 480 encodes (or seals) the contract operation 450 requested in the digital envelope 454 for transmission to the service TEE306a executed by the node 304 a. For example, client 480 generates temporary symmetric key 408 and encrypts requested contract operation 450 using key 408. Client 480 then encrypts temporary symmetric key 408 using sealed public key 414 and concatenates encrypted contract operation 450 and encryption key 408 to produce digital envelope 454.

The client 480 sends the digital envelope 454 to the node 304a, where the digital envelope 454 is provided to the service TEE306 a. In some cases, client 480 may send digital envelope 454 to multiple nodes 304a-d to request processing of requested contract operation 450. In some cases, client 480 may send a digital envelope created using a sealed public key for a particular node. Client 480 may also broadcast digital envelope 454 to nodes 304a-d with the same sealed public key 414 and unsealed private key 402 associated with all nodes 304 a-d.

Service TEE306a receives digital envelope 454 from client 480 and recovers requested contract operations 450 from digital envelope 454. As shown, service TEE306a decodes digital envelope 454 using unsealing private key 402 obtained from KM TEE308 a. In some cases, service TEE306a decrypts (unseals) temporary symmetric key 408 using unseal private key 402 (at 456), and then decrypts requested contract operation 450 using temporary symmetric key 408 (at 458).

Service TEE306a then performs the requested contract operation 450 using VM 460 deployed in service TEE306 a. In some embodiments, VM 460 may be a VM (e.g., an etherhouse VM or other type of VM) configured to execute instructions of a smart contract programming language. In some cases, VM 460 may access resources external to service TEE306a during execution of operation 450, e.g., external servers, blockchains, databases, or other resources indicated by operation 450. In some embodiments, access to external resources may be restricted or denied such that the overall execution of an operation depends only on data stored in service TEE306a (e.g., smart contract state). This type of restriction may further reduce the likelihood of performance of the tampering operation 450.

Execution of operation 450 by VM 460 may produce one or more results. In some cases, the result may include the execution state of the smart contract after execution of operation 450, as described above. The result of intelligent contract operation 450 is encrypted by service TEE306a using contract key 412 at 462. A contract key 412 is derived (at 410) from the root key 404 based on a Key Derivation Function (KDF). In some examples, the KDF may be performed based on an iterative hash algorithm such as HMAC-based extract-expanded key derivation function (HKDF) or pseudo-random function (PRF). The contract key may be provided by KM TEE308a to service TEE306 a. In some embodiments, root key 404 may be a symmetric encryption key associated with node 304 a. Root key 404 may also include one or more subkeys that may be derived from root key 404. Contract key 412 may be one of these subkeys. In some cases, the root key 404 itself may be used to encrypt the results at 462.

After encrypting the result, at 464, the service TEE308a signs the encrypted result using the private signature key 406 provided by KM TEE308a to service TEE306a to produce a signed result 466. This may allow a third party (e.g., a client) to later verify the signature result using a verification public key 416 (correspondingly paired with signature private key 406) maintained by key management center 310. In some cases, signing the encrypted result by signature private key 406 may include encrypting the encrypted result along with contract key 412 used to encrypt the result. In this case, a third party holding verification public key 416 may first decrypt contract key 412 and further decrypt the result using contract key 412.

In some cases, the service TEE306a may store the signature result 466 in the blockchain. As described above, a third party holding verification public key 416 may use the key to decrypt results 466 for verification. For example, client 480 may retrieve verification public key 416 from key management center 310 (e.g., authenticated as described previously), and may use verification public key 416 to access signature result 466 and decrypt signature result 466. Client 480 may then request service TEE306a to perform the next operation in the intelligent contract, and may include the requested next operation and the execution state of the intelligent contract (from decrypted signature result 466) in the digital envelope sent to service TEE306 a.

Fig. 5 depicts an example of a process that may be performed according to embodiments herein. At 502, a block chain node (e.g., 304a) participating in a block chain network (e.g., 302) receives a request to execute one or more software instructions in a serving TEE carried by the block chain node, wherein the request is encrypted by a public key associated with the serving TEE.

At 504, the blockchain node decrypts the request using a first private key associated with a service TEE, wherein the first private key is paired with the public key.

At 506, the blockchain node executes one or more software instructions to produce an encrypted result.

At 508, the blockchain node encrypts the execution result using a client encryption key associated with the service TEE to produce an encrypted result.

At 510, the blockchain node signs the encrypted result using a second private key associated with the TEE to produce a signed encrypted result.

In some cases, the public key is a first public key and the client encryption key is one of a second public key or a symmetric key derived from a root key based on a key derivation function.

In some cases, the block chain node also carries a key management TEE that stores the first private key and/or the second private key, and after authenticating the identity of the service TEE based on performing local authentication initiated by the key management TEE, the key management TEE provides the first private key, the second private key, and the root key to the service TEE.

In some cases, the first private key, the second private key, and the root key are generated by a key management center and provided to the key management TEE after authenticating the identity of the key management TEE based on performing local authentication initiated by the key management center.

In some cases, the first private key and the root key are provided by the key management TEE to the service TEE in response to a restart operation of the service TEE.

In some cases, the one or more software instructions are associated with a smart contract, and the root key is selected from a plurality of root keys stored in a key management TEE based on a state of the smart contract.

In some cases, the first public key is generated by the key management center and provided to the client to encrypt the request.

In some cases, the request received by the chunk link node further comprises encrypting one or more software instructions using a client encryption key.

In some cases, decrypting the request with the first private key further comprises: decrypting the client encryption key using the first private key; and decrypting the one or more software instructions using the client-side encryption key.

Fig. 6 depicts an example of modules of an apparatus 600 according to embodiments herein. Apparatus 600 may be an example embodiment of a blockchain link point executing within a blockchain network. The apparatus 600 may correspond to the embodiments described above, and the apparatus 600 comprises the following: a receiving module 602 that receives a request to execute one or more software instructions in a serving TEE carried by a block chain node, wherein the request is encrypted by a public key associated with the serving TEE; a decryption module 604 to decrypt the request using a first private key associated with a service TEE, wherein the first private key is paired with the public key; an execution module 606 that executes one or more software instructions to produce an execution result; an encryption module 608 to encrypt the execution result using a client encryption key associated with the service TEE to produce an encrypted result; a signature module 610 that signs the encrypted result using a second private key associated with the TEE to produce a signed encrypted result.

The system, apparatus, module or unit shown in the previous embodiments may be implemented by using a computer chip or entity, or may be implemented by using an article of manufacture having a specific function. Typical embodiment devices are computers, which may be personal computers, laptop computers, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email messaging devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

For example processing of functions and roles of each module in the device, example processing of corresponding steps in the previous method may be referred to. Details are omitted here for simplicity.

As the apparatus embodiments substantially correspond to the method embodiments, reference may be made to the relevant description in the method embodiments for the relevant parts. The device embodiments described previously are examples only. Modules described as separate parts may or may not be physically separate, and parts shown as modules may or may not be physical modules, may be located in one location, or may be distributed across multiple network modules. Some or all of the modules may be selected based on actual needs to achieve the goals of the present solution. Those of ordinary skill in the art will understand and appreciate the embodiments of the present application without undue experimentation.

Referring again to fig. 6, it may be interpreted as showing the internal functional modules and structures of the blockchain nodes that execute within the blockchain network and serve as execution subjects. In essence, the execution subject may be an electronic device comprising the following: one or more processors; and a memory configured to store executable instructions of the one or more processors.

The techniques described herein produce one or more technical effects. For example, the described techniques enable parties to a federated blockchain network to verify that the blockchain link points in the network that are responsible for performing intelligent contract operations and that agree on the results of those operations are not corrupted by an attacker. This verification has the effect of reducing the likelihood of preventing or reducing an attacker from controlling one or more blockchain nodes and successfully tampering with the execution of the smart contract operations or consensus process, leading to a more secure embodiment of a federated blockchain network that is more resistant to attacks.

Embodiments of the described subject matter may include one or more features, either alone or in combination. One embodiment includes a computer-implemented method comprising the acts of: receiving, by a blockchain node participating in a blockchain network, a request to execute one or more software instructions in a serving TEE carried by the blockchain node, wherein the request is encrypted by a public key associated with the serving TEE; decrypting, by a block chain node, the request in a serving TEE using a first private key associated with the serving TEE, wherein the first private key is paired with the public key; executing, by the blockchain node, one or more software instructions in the service TEE to produce an execution result in response to decrypting the request; encrypting, by the chunk chain node, the execution result in a service TEE using a client encryption key associated with the service TEE to produce an encrypted result; and signing, by the block chaining point, the encrypted result in the TEE using a second private key associated with the TEE to produce a signed encrypted result.

The foregoing and other described embodiments may each optionally include one or more of the following features:

the first feature, which may be combined with any feature that specifies that the public key is a first public key and that the client encryption key is one of a second public key or a symmetric key derived from a root key based on a key derivation function.

A second feature, which may be combined with any of the preceding or following features, specifies that the blockchain node also carries a key management TEE that stores the first private key and/or the second private key, and that after authenticating the identity of the service TEE based on performing local authentication initiated by the key management TEE, the key management TEE provides the first private key, the second private key, and the root key to the service TEE.

A third feature, which may be combined with any of the preceding or following features, specifies that the first private key, the second private key, and the root key are generated by a key management center and are provided to the key management TEE after authenticating the identity of the key management TEE based on performing a remote authentication initiated by the key management center.

The fourth feature, which may be combined with any of the preceding or following features, specifies that the first private key and the root key are provided by the key management TEE to the service TEE in response to a restart operation of the service TEE.

A fifth feature, which may be combined with any of the preceding or following features, specifies that the one or more software instructions are associated with a smart contract, and wherein the root key is selected from a plurality of root keys stored in a key management TEE based on a state of the smart contract.

A sixth feature, which can be combined with any of the preceding or following features, specifies that the first public key is generated by a key management center and provided to a client to encrypt the request.

A seventh feature, which may be combined with any of the preceding or following features, that specifies that the request received by the block link node further comprises encrypting one or more software instructions using a client encryption key.

An eighth feature, which can be combined with any of the preceding or following features, that specifying that the request is decrypted using the first private key further comprises: decrypting the client encryption key using the first private key; and decrypting the one or more software instructions using the client-side encryption key.

The ninth feature, which may be combined with any of the preceding or following features, specifies that the key management center stores a verification public key corresponding to the second private key and provides the verification public key to the client to verify the encrypted result of the signature.

Embodiments of the subject matter, the acts, and the operations described herein may be implemented in digital electronic circuitry, tangibly embodied computer software or firmware, computer hardware, including the structures disclosed herein and structural equivalents thereof, or combinations of one or more of them. Embodiments of the subject matter described herein may be implemented as one or more computer programs, e.g., one or more modules of computer program instructions, encoded on a computer program carrier for execution by, or to control the operation of, data processing apparatus. For example, the computer program carrier may include one or more computer-readable storage media having instructions encoded or stored thereon. The carrier may be a tangible, non-transitory computer-readable medium such as a magnetic, magneto-optical disk or optical disk, a solid state drive, Random Access Memory (RAM), Read Only Memory (ROM), or other type of medium. Alternatively or additionally, the carrier may be an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by the data processing apparatus. The computer storage medium may be or be partially a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. Computer storage media is not a propagated signal.

A computer program can also be referred to or described as a program, software application, app, module, software module, engine, script, or code and can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages; and it can be deployed in any form, including as a stand-alone program or as a module, component, engine, subroutine, or other unit suitable for execution in a computing environment, which may include one or more computers at one or more locations interconnected by a communications data network.

A computer program may, but need not, correspond to a file in a file system. A computer program can be stored in a portion of a file that holds other programs or data, such as one or more scripts stored in a markup language document; in a single file dedicated to the program in question; or multiple coordinated files, such as files that store one or more modules, sub programs, or portions of code.

Processors for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data of a computer program for execution from a non-transitory computer readable medium coupled to the processor.

The term "data processing apparatus" includes all types of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The data processing apparatus may comprise special purpose logic circuitry, e.g., an FPGA (field programmable gate array), an ASIC (application-specific integrated circuit), or a GPU (graphics processing unit). In addition to hardware, the apparatus can include code that creates an execution environment for the computer program, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

The processes and logic flows described herein can be performed by one or more computers or processors executing one or more computer programs to perform operations by operating on input data and generating output. The processes and logic flows can also be performed by, and in combination with, special purpose logic circuitry, e.g., an FPGA, an ASIC, a GPU, etc., and one or more programmed computers.

A computer adapted to execute a computer program may be based on a general purpose microprocessor and/or a special purpose microprocessor, or any other kind of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory and/or a random access memory. Elements of a computer may include a central processing unit for executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or integrated in, special purpose logic circuitry.

Typically, a computer will also include or be operatively coupled to receive data from or transfer data to one or more storage devices. The storage device may be, for example, a magnetic, magneto-optical disk or optical disc, a solid state drive, or any other type of non-transitory computer readable medium. However, a computer need not have such devices. Thus, a computer may be coupled to one or more storage devices, e.g., one or more memories, which may be local and/or remote. For example, the computer may include one or more local memories as an integral part of the computer, or the computer may be coupled to one or more remote memories in a cloud network. Moreover, a computer may be embedded in another device, e.g., a mobile telephone, a Personal Digital Assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device such as a Universal Serial Bus (USB) flash drive, to name a few.

The components may be "coupled" to each other directly or via one or more intermediate components by being in communication with each other, e.g., electrically or optically connected. Components may also be "coupled" to one another if one of the components is integrated into another component. For example, a storage component is integrated into, or "coupled to," a processor (e.g., an L2 cache component).

To provide for interaction with a user, embodiments of the subject matter described herein can be implemented on or configured to communicate with a computer having: a display device, e.g., an LCD (liquid crystal display) monitor, for displaying information to a user; and input devices through which a user may provide input to the computer, such as a keyboard and a pointing device, such as a mouse, trackball or touch pad. Other types of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and may receive any form of input from the user, including acoustic, speech, or tactile input. Further, the computer may interact with the user by sending and receiving documents to and from the device used by the user; for example, by sending a web page to a web browser on a user device in response to a request received from the web browser, or by interacting with an application (app) running on the user device, such as a smartphone or electronic tablet. In addition, the computer may interact with the user by sending a text message or other form of message to a personal device (e.g., a smartphone running a messaging application) and receiving a response message in return from the user.

The term "configured" is used herein in relation to systems, apparatuses, and computer program components. For a system of one or more computers configured to perform particular operations or actions, it is meant that the system has installed thereon software, firmware, hardware, or a combination thereof that, when executed, causes the system to perform the operations or actions. For one or more computer programs configured to perform specific operations or actions, it is meant that the one or more programs include instructions, which when executed by a data processing apparatus, cause the apparatus to perform the operations or actions. By dedicated logic circuitry configured to perform a particular operation or action is meant that the circuitry has electronic logic to perform the operation or action.

Although this document contains many specific implementation details, these should not be construed as limitations on the scope of the claims, which are defined by the claims themselves, but rather as descriptions of specific features of particular embodiments. Certain features that are described herein in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claims may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings and are recited in the claims in a particular order, this should not be understood as: it may be desirable to perform the operations in the particular order shown, or in sequence, or to perform all of the operations shown, in order to achieve desirable results. In some cases, multitasking parallel processing may be advantageous. Moreover, the division of the various system modules and components in the embodiments described above should not be understood as requiring such division in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Specific embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not require the particular order shown, or sequence, to achieve desirable results. In some cases, multitasking parallel processing may be advantageous.

Claims (12)

1. A computer-implemented method for securely executing intelligent contract operations in a trusted execution environment, TEE, the method comprising:

receiving, by a blockchain node participating in a blockchain network, a request to execute one or more software instructions in a serving TEE carried by the blockchain node, wherein the request is encrypted by a public key associated with the serving TEE;

the blockchain node decrypts the request in the service TEE using a first private key associated with the service TEE, wherein the first private key is paired with the public key;

in response to decrypting the request, the blockchain node executing the one or more software instructions in the service TEE to produce an execution result;

the blockchain node encrypts the execution result in the service TEE using a client encryption key associated with the service TEE to produce an encrypted result; and

the blockchain node signs the encrypted result in the TEE using a second private key associated with the TEE to produce a signed encrypted result.

2. The computer-implemented method of claim 1, wherein the public key is a first public key and the client encryption key is one of a second public key or a symmetric key derived from a root key based on a key derivation function.

3. The computer-implemented method of claim 2,

the blockchain node also bears a key management TEE, which stores the first private key and/or the second private key, and

after authenticating the identity of the service TEE based on performing local authentication initiated by the key management TEE, the key management TEE provides the first private key, the second private key, and the root key to the service TEE.

4. The computer-implemented method of any of the preceding claims, wherein,

the first private key, the second private key, and the root key are generated by a key management center, and

after authenticating the identity of the key management TEE based on performing remote authentication initiated by the key management center, the first private key, the second private key, and the root key are provided to the key management TEE.

5. The computer-implemented method of any preceding claim, wherein the key management TEE provides the first private key and the root key to the service TEE in response to a restart operation of the service TEE.

6. The computer-implemented method of any of the preceding claims, wherein,

the one or more software instructions are associated with a smart contract, and

the root key is selected from a plurality of root keys stored in the key management TEE based on a state of the smart contract.

7. The computer-implemented method of any preceding claim, wherein the first public key is generated by the key management center and provided to a client to encrypt the request.

8. The computer-implemented method of any preceding claim, wherein the request received by the chunk link node further comprises encrypting the one or more software instructions using the client encryption key.

9. The computer-implemented method of claim 8, wherein decrypting the request using the first private key further comprises:

decrypting the client encryption key using the first private key; and

decrypting the one or more software instructions using the client encryption key.

10. The computer-implemented method of any preceding claim, wherein the key management center stores a verification public key corresponding to the second private key and provides the verification public key to the client to verify the signed encryption result.

11. A system for securely executing intelligent contract operations in a trusted execution environment, TEE, comprising:

one or more processors; and

one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of claims 1-10.

12. An apparatus for securely executing intelligent contract operations in a trusted execution environment, TEE, the apparatus comprising a plurality of modules for performing the method of any of claims 1-10.