Project Identifier

The Trusted Compute Framework is a ledger independent implementation of the Trusted Compute Specifications published by the Enterprise Ethereum Alliance.

The TCF extends computational trust to off-chain execution enabling.

Improved blockchain throughput and scalability
Improved transaction privacy
Attested Oracles, trusted reporters of data generated outside of the blockchain.

Context

The TCF prototype has been released to open source as a Hyperledger Lab project at https://github.com/hyperledger-labs/trusted-compute-framework.

The TCF was first developed at another Hyperledger Lab project – Private Data Objects (PDO) that can be found at https://github.com/hyperledger-labs/private-data-objects.

The TCF complies with existing and emerging standards especially, the Off-Chain Trusted Compute Specification developed by the Enterprise Ethereum Alliance (EEA). The spec can be found at https://entethalliance.org/wp-content/uploads/2019/05/EEA_Off_Chain_Trusted_Compute_Specification_V1_0.pdf.

A prototype (work in progress) that integrates TCF and Hyperledger Fabric can be found at https://github.com/jeffgarratt/fabric-prototype/tree/tcf-demo and https://github.com/jeffgarratt/hyperledger-member-summit-2019-tcf-demo-app

Dependent Projects

TCF does not depend on other Hyperledger projects. Other Hyperledger projects are encouraged to use TCF as a component.

Motivation

The Trusted Compute Framework (TCF) enables the secure movement of blockchain processing off the main chain to dedicated computing resources. This enables

Improved blockchain throughput and lower latency
Improved transaction privacy
Attested Oracles, trusted reporters of data generated outside of the blockchain.

TCF is designed to help developers gain the benefits of computational trust and mitigate its drawbacks. A blockchain is used to enforce execution policies and ensure transaction auditability, while associated off-chain trusted compute resources execute transactions.

Preservation of the integrity of execution and the enforcement of confidentiality guarantees come through the use of a Trusted Compute (TC) option, such as

Trusted Execution Environments (TEE)
Multi Party Compute (MPC))
Zero Knowledge Proofs (ZKP)

The approach will work with any Trusted Compute option that guarantees integrity for code and integrity and confidentiality for data. Our initial implementation uses a Trusted Execution Environment enabled by Intel^@ Software Guard Extensions (SGX).

The TCF uses a distributed ledger to

Maintain a registry of the trusted workers (including their attestation info)
Provide a mechanism for submitting work orders from a client(s) to a worker
Preserve a log of work order receipts and acknowledgments

Status

This project will start in incubation.

The initial core functionality of the project has been implemented and the community will deliver additional functionality and bring project quality to product level standards.

Solution

Early blockchains delivered computational trust via massive replication but had limited throughput, and imperfect privacy and confidentiality. Adding trusted off-chain execution to a blockchain is proposed as way to improve blockchain performance in these areas. A main blockchain maintains a single authoritative instance of the objects, enforces execution policies, and ensures transaction and results auditability, while associated off-chain trusted computing allows greater throughput, increases Work Order integrity, and protects data confidentiality.

The figure above depicts an example of blockchain with N member enterprises. Each enterprise has Requesters, a blockchain node and one or more Trusted Workers (hosted by a Trusted Compute Service). Requesters submit Work Orders, and Workers execute these Work Orders. Work Order receipts can be recorded on the blockchain. While each of the enterprises in the figure above contains all three major components, this is not necessary. For example, Requesters from Enterprise 1 may send Work Orders to a Worker at Enterprise 2 and vice versa. Ultimately, an enterprise is free to host any combination of the three elements depicted on the figure above (blockchain node, Requester, off-chain Trusted Compute Service). Accessing resources across multiple enterprises increases network resilience, allows more efficient use of resources, and provides access to greater total capacity than most individual enterprises can afford.

A diagram below depicts TCF architecture at high-level.

Trusted Compute Service (TCS) hosts trusted Workers and makes them available for execution of Work Orders (WO) submitted by Requesters via front end UI or command line tools. Work orders also can be submitted by (Enterprise app specific) smart contracts running on the DLT.

There are four interfaces implemented according to [EEA-TC-SPEC]. Even though initially designed for Ethereum, these interfaces are uniformly implemented for all supported DLTs.

TCS catalog lists available TCS and provides blockchain address and/or URI where about their corresponding Workers can be discovered
Worker registry that lists Trusted Compute Workers. It includes attestation verification report, public RSA encryption key, and public ECDSA SECP256K1 verification key
Work order processing API that allows Requesters to submit Work Order requests and receive corresponding responses with data encrypted end-to-end between the Requester the Worker. Both the request and response may include multiple data items independently encrypted by different parties using different keys. The Requester may optionally sign its requests. Even if the Requester doesn’t sign the request (aka anonymous request), there a mechanism enforcing Work Order request integrity. The enclave always signs its responses.
Work Order receipts API that can be used for payment processing, auditing, and dispute resolution. The receipts are signed by the Requester and the worker.

There are two models of operation:

Proxy model relies on the smart contract (Ethereum or Sawtooth with Seth) or chaincode (Fabric) running on the DLT for managing all or any subset of APIs listed above
- DLT connector on the diagram above depicts components implementing interactions between the DLT and TCS. DLT specific plug-in adapters are responsible for abstracting DLT specific APIs from the rest of implementation.
- Requester utilizes a TCF API running on the blockchain and implemented using the blockchain specific mechanism, e.g. Solidity smart contracts on Ethereum or Sawtooth (via Seth) or as chaincode on Fabric.
Direct model provides a JSON RPC API for any of the APIs listed above except TCS catalog.
- TCS listener on the diagram above depicts components implementing the direct model APIs.

Direct model was introduced as a complement to the proxy model to facilitate specific use cases that are hard to address relying on the proxy model alone, e.g. processing sensor data streams (data filtering and pre-processing for IoT, supply chain), handling custom worker key update polices, and aggregating (large volume of) worker receipts.

Currently, only direct model is implemented. Proxy model for Ethereum and Fabric will be implemented next.

It is expected that real world applications may benefit from a hybrid model that will combine elements of both proxy and direct models.

Trusted Worker executes applications specific workloads and implements following capabilities

Worker Attestation service, e.g. in case of Intel SGX TEE it can be an Intel IAS or 3^rd party (DCAP) Service
Work Order Invocation service verifies integrity of the Work Order and the Requester signature, decrypts input and encrypts output data, signs the result, and creates the Work Order receipt update
External IO Plug-in Interfaces allows a workload running inside of TEE to read and write data from/to external data source, e.g. hosted locally by the TCS or remotely in the cloud. The Interface provide a basic infrastructure from crossing trust boundaries. Actual data access and format is application specific and depicted as Data Connector on the diagram

Workloads can be implemented to execute pre-defined fixed functions which are precompiled at build time (written, for instance in Rust or C++), or can be implemented as runtime script interpreters, (e.g. Solidity or Python). In the latter case the script interpreter is precompiled into the worker at build time, and scripts are loaded at runtime as a part of the Work Order. Scripts can be chosen from a list provided by the TCS, or dynamically provided by the Requester (unknown to the TCS). The specific policy enforcement is application-dependent.

In the current implementation, interactions between TCS components is brokered via a KV (Key-Value) Storage that is implemented on top of LMDB. The KV Storage Connector allows utilizing the KV Storage on a single physical system or across multiple physical systems. The Adaptor abstracts LMDB from the rest of TCS so production implementation may choose to replace LMDB with another database of their choice.

Components shown in blue on the diagram depict functions that are generic for all or most applications. Components shown in orange depict functions that are always application-specific. Decentralized components (smart contracts or chaincode) running on DLT are depicted as a mix of both colors because in some case TCF baseline implementation can be sufficient, while in others dApp may have to differ or extend baseline implementation.

The diagram below depicts a high level execution flow in proxy model.

During the registration phase, TCS

Instantiates a Worker. The Worker generates signing and encryption key pairs and stores the private keys in a way accessible to the Worker only, e.g. in case of Intel SGX TEE, it will be in its sealed storage
Produces an attestation quote for the Worker (including an attestation chain for its public keys) and submits it for a verification, e.g. in case of Intel SGX TEE, to Intel IAS
The attestation verification report from the previous step along with the public keys is submitted to and recorded in the Worker Registry on blockchain

During the discovery phase a Requester looks up an appropriate Worker and validates its attestation verification report and stores the Worker’s public keys for further use.

During the invocation phase

The Requester creates a Work Order request payload (JSON). To encrypt the data, the Requester generates a one time symmetric key that also submitted as a part of the request, but encrypted with the Worker’s public encryption key. The request includes an encrypted hash of its key parameters and data items (integrity enforcement). The request can also be signed by the Requester.
The Requester submits the request to the Work Order Queue on the blockchain and creates a corresponding Work Order Receipt on the blockchain.
After the Work Order request is submitted to the Work Order queue on the blockchain, TCS receives a notification (aka event or alert) and retrieves the Work Order request from the Work Order Queue on blockchain. TCS verifies the Requester’s signature (if provided).
The Work Order request is submitted to the Worker. The Worker decrypts the data and verifies the Work Order integrity. Then the Worker processes the Work Order and generates a response. The Worker uses the symmetric data encryption key from the request to encrypt output data and signs the response using its private signing key.

During the results phase

TCS submits the Work Order response to the Work Order Queue on the blockchain and updates the Work Order receipt on the blockchain.
After the Work Order Result is submitted, the Recipient receives a notification and retrieves the result from the blockchain. It may also retrieve the updated Work Order Receipt. In many use cases the receipt is used by 3^rd party (not by a requester itself) for payment processing, dispute resolution, auditing, or regulation compliance
The requester decrypts the result using the same one-time key that was generated during the invocation phase. The Requester uses the Worker’s public verification key to verify that the result was signed by the Worker (and hence the Work Order indeed was processed by the right Worker).

Efforts and Resources

Initial functional implementation is already available as a Hyperledger Lab [TCF-GITHUB]. The TCF implementation is derived from another Hyperledger Lab called PDO [TCF-GITHUB]. Then a private branch was created by Intel to build the initial TCF implementation with contributions from iExec.

There is a growing TCF community already. Below is list of companies that have already expressed a formal support for the project and more companies and individuals are in the process of learning and ramping up on TCF with plans to joint TCF project and utilize it for their product development. Number of contributors represents an initial commitments with many companies intended to increase participation as the project advances to the next phase.

Intel Corporation: 7 contributors to deliver core TCF infrastructure and Intel SGX specific code

iExec: 4 contributors will develop Ethereum smart contracts, integrate TEE options that support most of the the mainstream programming languages and native applications, and improve TCF easy-of-use for developers

Alibaba: 2 contributors who will work to adopt TCF for its Ali Cloud and contribute to the TCF core to extend supported programming environments, e.g. GOLANG

Baidu: 2 contributors who will work on enhancing core capabilities and integration of MesaTEE based workers.

BGI: Will contribute to the integration of TCF into Hyperldeger Fabric

Chainlink: 3 contributors that will contribute to the TCF's plans for how to integrate with decentralized oracles and attested oracles, which will be able to provide both TCF computations and various on-chain computations enabled by them with secure access to various key API inputs and enterprise/payment event outputs.

Consensys: 2 contributors to work on the TCF architecture, documentation, and spec compliance

EEA: expects to use TCF as a base for its EEA Off chain TC Specification certification program and cooperate with the TCF community to drive improvements to the Specification

IBM: 1 contributor to work on integrating TCF with Fabric

Kaleido (A ConsenSys Business): 1 contributor working on deployment and manageability solution for hosting Trusted Compute Service

Microsoft: provides Azure resources to run a TCF test net and contribute to Trusted Token usage implementation

Santander: 3 contributors to provide reference implementation of critical use cases and incorporate TCF into Santander's cyber-security policies.

WiPro: 2 contributors working on design and implementation of resource types (ZKP, MPC etc.)

How To

The project will be managed in a Hyperledger GitHub repository and will follow community norms present in other Hyperledger projects.

We propose creation of the following repository: github.com/hyperledger/tcf

References

[TCF-GITHUB]

TCF Hyperledger Labs repo: https://github.com/hyperledger-labs/trusted-compute-framework

[PDO-GITHUB]

PDO Hyperledger Labs repo: https://github.com/hyperledger-labs/private-data-objects

[EEA-TC-SPEC]

EEA Off-Chain Trusted Compute Specification: https://entethalliance.org/wp-content/uploads/2019/05/EEA_Off_Chain_Trusted_Compute_Specification_V1_0.pdf

[TCF-BLOG]

TCF Introduction BLOG: https://software.intel.com/en-us/articles/ecosystem-support-for-eea-trusted-compute-specification-v10-improves-blockchain-privacy-and

[FABRIC-TCF-POC]

GITHUB repositories for the ongoing POC project that integrates TCF with Hyperledger Fabric:

https://github.com/jeffgarratt/fabric-prototype/tree/tcf-demo and https://github.com/jeffgarratt/hyperledger-member-summit-2019-tcf-demo-app

FAQ

What is TCF and Gardener connection? TCF and Gardener discovered each other recently and we definitely agree that there is shared scope between these two projects and both projects are interested in working together in the process of evaluating optimal collaboration options.

Chainlink work with Google- does this have any bearing (except for the Ethereum angle)? Chainlink joined TCF to contribute implementation and use case for attested decentralized oracles.

Intel SGX vulnerabilities - what bearing will this have on the work? Intel tracks information about vulnerabilities and mitigations on a central website at following links facts-about-side-channel-analysis-and-intel-products and engineering-new-protections-into-hardware. Please refer to the website for information about specific security vulnerabilities, resources, and responses, including mitigation by product CPU model.

What are identity bindings between off-chain identities (both Enterprise and TCF identities) and on-chain? At this time TCF assumes that identities can be user defined, blockchain address, or public signature verification key of the requester. This is an area that can be defined further, e.g. to accommodate DID.

Any current work or hooks in TCF that deals with other forms of trusted computation (Hardware TEEs, HME, MPC, ZK etc.)? The TCF architecture is specifically designed to accommodate additional trusted compute options (via KV storage interface). There is a work in the process to locate potential contributors with appropriate domain expertise via EEA. Also TCF encourages anybody with such expertise to join the project and contribute additional worker types to the project.

Closure

The success of this project can be measured by successful integration of TCF with multiple DLTs and, more importantly, by its broad utilization in real world enterprise-focused use cases emphasizing requirements of scalability and privacy preservation.

Reviewed By

Arnaud Le Hors
Baohua Yang
Binh Nguyen
Christopher Ferris
Dan Middleton
Hart Montgomery
Kelly Olson
Mark Wagner
Mic Bowman
Nathan George
Silas Davis

Page tree

Trusted Compute Framework (TCF)