Trusted Execution Environments (TEEs) promise integrity and confidentiality of (remote) computation. 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 program has not been tampered with and is actually  running on a genuine TEE, even if the machine is physically located in an off-site data center.Assuming we trust the integrity and design competence of TEE manufacturers,  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.

There are two kinds of risks: A malicious TEE manufacturer could attest fake devices, introduce backdoors or suddenly refuse to remotely attest genuine devicesDesign flaws (Intel SGX: Foreshadow, Plundervolt, SGAxe)Various vulnerabilities have been found by white hat hackers and fixed by Intel by means of microcode patches. Integritee requires regular refreshing of remote attestation (around every 24h) to verify that the most recent patches have been applied.As always in cybersecurity: It’s a race against time. TEEs just add another layer of security on top of state-of-the art protection measures.

Our parachain, sidechains and off-chain workers continue to work. But they can’t refresh their remote attestation and no new SGX machines can join. If IAS is offline for a longer time, on-chain governance would have to ensure that all registered enclaves stay enabled even if they don’t refresh remote attestation.

Our sidechains are validated by remotely attested TEEs, so there is no need for a communication-heavy consensus protocol. Sidechains work mostly like substrate blockchains and they are compatible with substrate runtime pallets.

Because validators are trusted TEEs, we only need a handful of validators per shard for availability and liveness.

All Polkadot/Kusama relay-/parachains can interface with Integritee workers or sidechains through XCMP.

Any light-client capable blockchain can be trustlessly bridged to Integritee by running their light client inside our enclaves. This way, Integritee workers or sidechains can read state of foreign blockchains, verify inclusion proofs or send transactions.  You can find a concept for an Integritee-based Ethereum bridge as a speculative web3 grant proposal.