Trusted Execution Environment
And Why Trustless Networks Need It
This is the third instalment of our Super Protocol in-depth series. A previous article explained how big tech hijacked the term cloud and why Web3 is about to reinstate its original meaning.
Today we’re into a more complex theme of the Trusted Execution Environment (TEE): what it is and how Web3 can benefit from using it. You can skip the tech part, but building up the understanding of the technology in detail would make it way easier to follow the argument on its benefits.
What is a Trusted Execution Environment?
Most articles define TEE as an area of the processor that is isolated from the rest of the operating system and stops at that. Reading this usually leaves a lot of questions, so we’ll try to address them here.
How is TEE isolated? On a hardware level, TEE architecture is very much similar to the way your Web3 wallet works — external access to an area of the processor is protected by a set of private keys. Just as only you can approve transactions with a unique private key that no one else has, only trusted applications can access this area and execute code within it. So TEE is literally a part of the processor no unauthorized application can access or even peek into (basically, those apps don’t even “know” such an area exists).
That’s not the only line of defence. When the application is launched, the processor logs the hash of the initial state (just as with blockchains) and of all the states that follow, so there’s no way to deviate from the original chain without altering the whole chain of hashes, which in this case is impossible.
Why is this more secure? By default, if you control the access, you can decide what kind of applications can be executed. TEE often includes encrypted storage, meaning even the code of an authorized application could not be modified in order to somehow alter it in a way the original developer did not intend to. This also concerns all the data that these applications process.
What if an attacker somehow manages to authorize their app? The ideal scenario assumes that every authorized app’s code is reviewed, and thus it is ensured that it does not attempt to do anything shady. Reality is often disappointing, but not this time. An authorized app has a key that allows it to access only specific parts of the processor, meaning even with the key, it won’t be able to access its other sections and see into other applications’ code or runtime.
A metaphor for better understanding (and explaining TEE at the parties): imagine you live in a block of flats that has a big wall of post boxes (one per tenant). Only you have the keys; your key fits only the lock in your postbox. TEE works the same way. No other tenant could access it and read your mail. Also, anyone who writes to you is using a secret code only you can decipher, so if the mailman misreads the numbers on the box and your neighbour gets your mail — they won’t be able to read it!
Now let’s move on to why this is a much-needed functionality for Web3 tech.
Dealing with transactions on the blockchain is one thing, yet most apps require more data and sophisticated computations that could not be performed on a chain in order to provide value for its users. Most apps have to process personal data, financial data, or other types of sensitive information. If we’re about to take DeFi mainstream, securing these types of data should be the number one priority. TEE and confidential computing built on top of it could make a major chunk of hacker attacks nearly impossible. Even if some component, another app, or the provider itself is compromised — that would not affect our apps in any way.
Also, as all the data is protected, that would make social engineering attacks way harder to perform as the attackers won’t be able to extract any meaningful information.
Last but not least, transparency could be harmful. In case an attacker, or any other party, has exact knowledge of what you’re running and where they could use it in order to harm the whole network (particular attack angles may vary from denial of service to more sophisticated node isolation types).
That’s why we’re building Super Protocol — a platform that would make TEE-based confidential computing accessible and Web3 native.