Skip to main content

Combining TEE and Blockchain

Combining TEE and Blockchain
This blog post will discuss the latest development in improving blockchain - using Trusted Execution Environments (TEE) to increase scalability and confidentiality.

Blockchain Background

For those who aren’t familiar with blockchain, here is a quick rundown of what is blockchain. 
Blockchain decentralizes and distributes data across a network of computers, functioning as distributed
ledgers. Each participant, or node on the network, has a copy of the stored data in a secure, distributed,
and shared database which eliminates the need for a centralized authority. Any changes or additions to
the database must be validated by the collective members before the entire network is updated. This
provides an unchangeable record and ensures data quality and integrity. 


Users are able to submit transactions, which are collected as a block and the network then distributes
and verifies the blocks and appends them to an irreversible chain.  Additionally, blockchains use
cryptographic signatures to ensure accuracy and create an immutable - or unchangeable - ledger. 

How does TEE play a role in this?

Normally, transactions are processed on the blockchain, which presents a scalability challenge
because every node in the chain needs to be informed of the transaction and update its copy of the
distributed ledger. This system ensures that transactions are transparent and the integrity is solid, but
it reduces the throughput - the speed at which transactions are processed - as well as confidentiality. 
A solution was proposed by Hyperledger Avalon, a fairly new Hyperledger project, a month ago.
The solution or at least the middle ground for this problem lies in performing some operations
“off-chain” using a combination of or simply one of the following: TEE, MPC (multi-party compute),
and ZK (zero-knowledge proofs). Due to the scope of this blog post, the latter two components will
not be discussed. The following image shows the structure.
When a transaction needs to be executed, the requester creates a Work Order which is passed into the
Trusted Compute Service where a worker performs the task. Afterward, a receipt is created which goes
to the chain.

 Intel SGX capabilities such as code verification, execution isolation, and attestation verification can
help provide a reliable link between the main chain and off-chain compute resources. SGX’s prevention
of code modification or data disclosure allows blockchain data to be protected through encryption until
required for a transaction and verification of correct computation to be performed. Additionally, attestation
is important because trusted worker processes need to be vetted and cataloged within a registry that
includes their attestation information. 

Possible Drawbacks

A number of potential roadblocks have been considered.
  1. Centralized remote attestation service
    • To do a remote attestation, you must contact Intel’s cloud service
    • Not really decentralized
  2. SGX is disabled by default
    • Not a problem for computer-savvy people, but what about non-technical users of blockchain? 
    • Many mobile devices don’t have SGX
  3.  Unclear licensing and terms of use for SGX by Intel 
    • Intel themselves have supported Hyperledger Avalon, but it is unclear how they will respond to future business

References


Comments

Post a Comment

Popular posts from this blog

Angr: A Multi-Architecture Binary Analysis Toolkit

This blog is quoted from several angr blogs and documentations, click  here  and  here . angr is a multi-architecture binary analysis toolkit, with the capability to perform dynamic symbolic execution (like Mayhem, KLEE, etc.) and various static analyses on binaries. We've tried to make using angr as pain-free as possible - our goal is to create a user-friendly binary analysis suite, allowing a user to simply start up iPython and easily perform intensive binary analyses with a couple of commands. That being said, binary analysis is complex, which makes angr complex. This documentation is an attempt to help out with that, providing narrative explanation and exploration of angr and its design. Several challenges must be overcome to programmatically analyze a binary. They are, roughly: Loading a binary into the analysis program. Translating a binary into an intermediate representation (IR). Performing the actual analysis. This could be: A partial or full-prog...
Post a Comment
Read more

SWAPGS Attack: A Spectre Variant

With the recent developments of Spectre [1] and Meltdown [1] as we discussed in class, it should come to no surprise that various odd methods of accessing kernel memory through user level permissions have popped up.   One such interesting method utilizes the SWAPGS instruction, called the SWAPGS Attack, found by Bitdefender researchers just a few months ago [2].   This article will explore what the attack is, how to exploit it on existing hardware and operating systems, and what mitigations can be implemented for current hardware. SWAPGS Attack Overview The SWAPGS Attack, as the name implies, utilizes the SWAPGS instruction.   This instruction swaps two Model Specific Registers (MSRs), IA32_GS_BASE and IA32_GS_KERNEL_BASE, which point to the user mode's per-thread data structure and kernel mode per-thread data structure respectively.   In Windows, the addresses stored in these registers are used to quickly access information about the current Thread Informa...
Post a Comment
Read more

ARM TrustZone, its Applications, and the MCU Xpresso55S69

ARM TrustZone, its Applications, and the MCU Xpresso55S69 Overview: The creation of ARM TrustZone stems from a simple question: how can high-value code and data be protected (primarily in IoT devices and systems) without significantly slowing development?  The core idea put forth by the developers of ARM TrustZone is that the objective above can be accomplished by isolating critical firmware and private information. TrustZone’s isolation is hardware-enforced, with a “Secure” and a “Non-Secure”/”Normal” world (shown as “Trusted view” and “None-trusted view” in Figure 1 below). Present on ARM’s Cortex-M and Cortex-A processors, TrustZone is a “SoC (System-on-Chip) and CPU system-wide security solution”, per Pinto and Santos [4]. By restricting access to “secure” (“trusted”) memory and I/O, ARM TrustZone reduces the attack surface of critical components.    Figure 1: An Overview of TrustZone Being implemented at the hardware level gives TrustZone s...
Post a Comment
Read more