Privacy in Litentry III: TEE Sidechain

Published in

Litentry

6 min readJan 12, 2023

Sequel to the previous article where we explained Trusted Execution Environment (TEE), this treatise digs even deeper into explaining the TEE sidechain and its components.

Layers 0, 1, and 2

The diagram below shows three layers of blockchains, each with its own responsibilities:

To achieve identity aggregation, Litentry must store sensitive user data, such as an Ethereum account and computed credit score. We have thus chosen Trusted Execution Environment (TEE) to ensure the security and privacy of data storage and processing. Litentry has developed a sidechain consisting of multiple TEE-equipped nodes, offering distributed storage and processing of user data in a secure, private manner.

Layer 0 — The main net of relay chains, such as Kusama or Polkadot, is responsible for providing shared security across the entire relay chain and parachain network. It also functions as a router for XCM messages.
Layer 1 — Litentry Parachain and Litmus Parachain are employed as application-specific blockchains. They interconnect with the relay chain by occupying a parachain slot, allowing the relay chain to validate its blocks and oversee XCM messages.
Layer 2 — The TEE sidechain is supported by Integritee and enables the runtime to execute in an SGX secure run environment. This is distinct from the Layer 1 parachain which makes all states and extrinsics public and visible.

The most impressive aspect of the architecture is that all three layers of the blockchain are built on the Substrate framework. This framework is highly customizable, allowing developers to configure its runtime and execution logic to fulfill a variety of roles.

The parachain is composed of nodes that utilize a dPOS (Delegated Proof of Stake) mechanism to synchronize and generate blocks while the sidechain is made up of nodes equipped with Trusted Execution Environments (TEEs).

Software Components

In the Parachain-Sidechain-Client diagram above, there are four major software components: the Teerex Pallet, SGX Runtime, Identity Hub Client, and Worker Server(s).

Teerex pallet

The Teerex pallet in Parachain enables TEE workers to register, discover, and communicate with one another. Its main features are:

Acting as a verified registry that allows remote verification of SGX enclaves — providing public auditability.
Designed with confidentiality at its core to bridge the trust gap between the enclave and enable anyone to verify the codes that are executed.
Acting as an indirect proxy for off-chain confidential state transition calls executed by SGX enclaves.

For more detailed information, please refer to the Integritee documentation.

SGX Runtime

The SGX runtime in the sidechain worker enables confidential execution and integration of all substrate-compatible pallets.

SGX pallets are instantiated in the TEE SGX worker enclave, compiled into WASM blob/binary, and depend on tee-sgx-sdk. It stores privacy data in the SGX node, linking identities, verifying assertions, and storing ID graphs. Extrinsic parameters/addresses are encrypted in the parachain and the private keys are only known by SGX nodes, which decrypt data in SGX and dispatch calls to runtime. This helps maintain user data privacy, which Litentry stands for.

Further information can be found in the SGX runtime repo.

Identity Hub Client

The Identity Hub Client is used to execute calls or operations and it is also substrate-based.

The client interacts with parachain & sidechain via RPC/WSS (Diagram doesn’t show sidechain interaction as it is not open yet.) Calls made to the parachain are encrypted and opaque to invoke confidentiality. The content of the operation is only visible to the Client and the sidechain TEE (SGX, SGX workers/nodes, and SGX runtime).

There are different types of calls that can be executed by the client based on the operation destination. They include:

Untrusted Call: The client interacts with the parachain node via untrusted calls, sending transactions or queries. For example, a balance transfer via client is an untrusted call.
Trusted call: The client interacts with the TEE worker server. E.g. calling link_eth, which is extrinsic from the SGX account linker pallet. Or query the encrypted data in SGX.
Direct call: Client calls extrinsic in SGX runtime (same as a trusted call).
Indirect call: Client encrypts SGX runtime call, sends to Teerex Pallet in parachain. Worker node syncs blocks identify call_work extrinsic, parses call from parachain, and dispatches to SGX runtime. The details could be found in the diagram below:

Worker Server(s)

The Worker Server(s) execute functions with specified inputs and resource limits in response to TEE calls and operations. To ensure a sufficient level of scaling, there are usually many worker servers required for these executions.

Servers are the most complicated part of the whole TEE and their major functions are as follows:

Used in carrying out remote attestation — the process of asking the TEE manufacturer (Intel) to authenticate a TEE. The manufacturer signs a report to confirm that both the TEE itself and the hash of the binary it is executing, are genuine
Provides the execution environment for SGX runtime in the trusted node
Sync up the blocks from parachain, decrypt and parse the data from call_work
Generates side chain’s block, sync up and carry out a consensus between nodes
Provides RPC and WSS service
Send a response to the parachain via extrinsic

From a software running point of view, the server is the boundary between trusted and untrusted TEE parts. Trusted codes are executed in the SGX while Untrusted ones such as the start-up process, RPC server, enclave initialization, etc. are carried out in the pallet.

Sharding — the principle of dividing up the overall workload that servers need to handle into smaller, more manageable chunks — is supported from the beginning of sidechain design. The server node joins one shard (each call both direct and indirect has a default parameter shard identity). The server node then executes the call with the same shard that it joined. The benefit of sharding is as follows:

The state for each shard is isolated — the different shard nodes can’t see each other’s private data
Shard nodes can skip the call from another shard. This help to save resources and makes it faster to execute less extrinsic in the block
Sharding makes it possible to use our solution at a large scale, at the same time protecting user data

What data are handled in a TEE?

When requesting identity linking (Web2 <> Web3, or cross-chain wallets linking) or verifiable credential generation in Identity Hub, all data involved to complete the request will be stored and computed in the TEE environment.

This includes the request itself, the relationship between different wallets, data fetched from a specific wallet that supports the claim in a VC, etc.

Litentry Parachain’s initial functionalities including token transfer, governance, staking, and cross-chain transfer do not involve privacy-preserving processes.

A special shoutout to Mel Zhou, Eric Zhang, and Kailai Wang for their knowledge and expertise-based contribution to the series of articles we published to educate users, community members, and privacy enthusiasts about our Privacy and Identity Management solution.

Here are links to read our previous publications to better understand the novel solution we are building at Litentry:

Feel free to leave a comment if you have questions.