By: Alain Brenzikofer

Hello from the SubstraTEE team at Supercomputing Systems AG! In this post we’d like to introduce key concepts of trusted off-chain computing. We’ll show what you can do with our tool, SubstraTEE, today and what our vision is for future applications.

SubstraTEE↗ is a framework that integrates trusted execution environments (TEEs) with Substrate-built blockchains — in other words, chains built using Polkadot’s native building tool and the easiest ones to connect with the Polkadot network. SubstraTEE aims to improve the privacy, scalability and interoperability of blockchains by off-loading state updates into TEEs.

What’s a TEE?

We have become accustomed to the fact that we have to trust our IT administrators. While these administrators used to be in-house employees at our companies, today we often work on rented cloud platforms.

These administrators can read and modify all the data processed on any machine they manage. Unfortunately, this ability extends not only to known administrators we trust but also to hackers who can obtain administrator privileges. No company, no matter how qualified, is immune to such attacks.

Enter TEEs.

You may envision a TEE as a co-processor that manages its own cryptographic keys and only executes programs whose hash, or fingerprint, corresponds to the original code. The manufacturer of the processor guarantees, by the design of their hardware, that nobody has access to the internal keys of the TEE or can read its memory. Moreover, the manufacturer can authenticate each TEE and provide remote attestation to a user to confirm that her untampered program is actually running on a genuine TEE, even if the machine is physically located in an off-site data center.

TEEs promise, in short, integrity and confidentiality of (remote) computation. You should be aware, however, of possible security threats↗.

Assuming we trust TEE manufacturers’ integrity and design competence, TEEs allow us to execute any state update without sharing our data with the blockchain validator or other users. Private token transfers, private smart contracts and private state channels thus become possible and relatively cheap.

Achieving Privacy on Blockchains

Blockchains are transparent by nature. They have to be to ensure decentralization. You can achieve pseudonymity easily, but many use cases require confidentiality. Enterprises don’t want to leak trade secrets, and they have to comply with European data-privacy laws (GDPR↗). The latter means no personal data should ever touch an unpermissioned blockchain↗. Validating the integrity of computations while not being able to read the data which is processed poses another challenge. Here TEEs offer a perfect solution: integrity and confidentiality of computations.

TEE vs. Zero Knowledge Proofs

Zero-knowledge proofs (ZKP) enable ZCash↗ to achieve private token transfers. While ZKPs guarantee privacy without trusting hardware manufacturers, they come with computation-heaviness and large transaction sizes. Moreover, ZKP are a cutting-edge field of research and understanding them requires specialized expertise.

TEEs on the other hand, have already entered the mainstream and provide reasonable ease of use. Purists may complain that manufacturers these days don’t share their designs with the public, thereby avoiding scientific peer-review. Keystone↗ already has launched an open-source TEE project that may result in well-audited TEEs one day. We would still need, however, to trust the manufacturer of Keystone ASICs, which has to provide remote attestation.

Private Transactions with SubstraTEE

Supercomputing Systems has been working hard to complete a working proof-of-concept of their product SubstraTEE. Private token transactions rest at the heart of the first use cases.

Let’s walk through an example of how a private token transaction would work. Alice wants to transfer 100 tokens to Bob without anyone but Bob knowing about the details of this transfer. She creates a shielded SubstraTEE transaction:

let call = TrustedCall::balance_transfer(alice_incognito.public(), bob_incognito.public(), 100);

Alice encrypts this call with SubstraTEE worker’s shielding key and sent to the SubstraTeeRegistry runtime module as a normal Substrate extrinsic. Because the payload is encrypted, no one but the SubstraTEE worker TEE can decrypt it and see the details of this call. The SubstraTeeRegistry acts as a proxy and dispatches an event including the opaque payload.

The SubstraTEE-worker listens to such invocation events and forwards the payload into its TEE. The TEE then decrypts the payload and retrieves the original call, which is processed by the state transition function (STF). For this demo, the STF is exactly the same code as Substrate’s balances runtime module.

The STF operates on an encrypted off-chain state and performs the state update. In this case, it transfers 100 tokens from account alice_incognito to bob_incognito. The resulting state is encrypted and stored in IPFS. The worker then sends a confirmation extrinsic to the chain, including the hash of the call and the hash of the updated state.

Alice can now convince Bob that the transfer happened by sending him the raw call over any private communication channel. Bob can now scan on-chain confirmations for that call’s hash. Bob can also see his updated balance by querying the worker directly through a websocket interface.

You can watch this live SubstraTEE demo ↗on YouTube.

Remote Attestation

How can Alice and Bob rest assured that the SubstraTEE-worker is indeed running the expected code on a genuine TEE?

Remote attestation is the process of asking the TEE manufacturer to authenticate a TEE and sign a report that confirms the genuineness of the TEE as well as the hash of the binary that the TEE is executing. Such a report also includes the TEE’s public signing key, so we can rest assured that we are truly talking to the right TEE by verifying its signature.

SubstraTEE simplifies this process for its users by storing remote attestations on-chain in the SubstraTeeRegistry. This way we avoid the need for users to register with the manufacturers attestation services.

Redundancy

What happens if a SubstraTEE-worker goes offline? If there is only one single worker, the entire state might get lost forever. In order to achieve redundancy, we need several workers to operate on the same state. They all need to know the state encryption key.

We designed SubstraTEE to be permissionless and allow anyone to join the the set of workers by regularly supplying remote attestations to our SubstraTeeRegistry. A newly joining worker will ask an established worker for the keys. The two workers will perform mutual remote attestation and the keys will be provisioned. The new worker will fetch the most recent state from IPFS and immediately start to process requests in parallel to all other workers. Now we could kill all but one worker and the network stays alive and reactive.

Outlook

We have shown how SubstraTEE↗ enhances privacy. Next comes trustless access to the chain state. We are working to provide generic private computation with ink! contracts↗ and build chain bridges↗.

Soon we might implement direct invocation, boosting scalability. While our current solution requires 1+N on-chain transactions per request (N being the number of workers), direct invocation means that requests are directly sent to the worker and are confirmed on-chain in batches, allowing 1000s of requests per second↗. Direct invocation comes with another benefit with regard to GDPR: the right to erasure. Because no personal data ever touches the blockchain, the right to erasure can be implemented as a functionality of the STF.

This work has been supported by a grant from the Web3 Foundation↗.