Launching Integritee’s Attesteer

Integritee uses a public blockchain to verify remote attestation of TEEs and its novel Attesteer service integrates with any 3rd party enclave to close the last gaps in the trust chain towards public auditability.

As secure and isolated environments, Trusted Execution Environments (TEEs) leverage hardware-security features that ensure the integrity of data and code as well as the confidentiality of the data while in use by that code. This way, not even the operator or superuser of the host machine has access to the data or can change the behavior of the TEE. If you are not running such a machine on your own desk but in a data center, how can you be sure there’s actually a real TEE on the other end? That’s what remote attestation (RA) is about. It provides verification for three things: (1) the application’s identity, (2) its integrity (that it has not been tampered with), and (3) that it is running securely and confidentially within a genuine machine.

More specifically, remote attestation is the process of authenticating the TEE hardware and providing a report confirming its genuineness. This process also measures the hash of the binary that the secure environment is executing, which confirms that what’s running inside the secure environment is, in fact, what you expect. Because such a report also includes the individual TEE’s public signing key, you can thereafter authenticate the TEE instance and its responses upon every interaction by verifying its signature.

Obtaining attestation for an instance of a service usually requires the use of a manufacturer-provided API (like IAS for Intel SGX), which is sometimes delegated to data centers (like DCAP for Intel SGX). This is an undesirable setup because the parties who offer RA can go offline or refuse the deliver RA (censorship). Integritee decouples RA to a public blockchain and ensures that RA can be performed by anyone without the consent of any 3rd party.

Source Code
It all starts with the code and if it really does what the end-user expects it to do. The code is the most critical piece of any secure setup because TEEs are worthless if the code has exploitable vulnerabilities or undesired features

Release
What’s the value of a code audit if we have to trust the operator that it executes a genuine build of the audited code? If a software vendor signs their build, we need to trust that vendor, which is — again — an undesirable trust requirement. The holy grail here is deterministic build: Anyone can build the software from source and yield the bit-exact equivalent of the build which is executed

Execution
In the case of TEEs, it doesn’t really matter who is executing an enclave, because the operator doesn’t need to be trusted. However, because of several hardware-based side-channel vulnerabilities of all known TEEs, we do suggest enforcing execution in certified data centers which enforce very strict policies for those who have physical access to the servers.

Attestation
This is where Integritee’s Attesteer comes in: Remote attestation (RA) is the process of proving that some remote device is genuine and that it executes the correct build inside an enclave. This is enabled by public-key authentication with a hardware key in the TEE device. With Integritee’s Attesteer and on-chain DCAP, there is no need to rely on an available or cooperative TEE manufacturer anymore.

User Verification
End users are already used to the green tick in the browser window which confirms that the webpage they visit has a valid certificate for its domain and that all communication with that site is encrypted. What the attesteer enables on top of that, is a confirmation of encrypted processing of your data in use and that nothing else happens with your data than just the functionality which has been audited by a 3rd party.

Audit
In the most favorable case, the code is open source for anyone to audit. Even if we should not expect end-users to review the code themselves, it strengthens trust that they could if they want to. We expect professional 3rd party auditors to publish reports on TEE-based services. If not open-sourced, these parties could be granted exclusive read access to the code for the audit.

Covering all TEE manufacturers

The Attesteer itself relies on Intel SGX technology because of its superior remote attestation capabilities. However, the Attesteer is able to remotely attest any kind of TEE through certificate verification with non-repudiation. The trust assumptions, however, are different for every TEE manufacturer:

• Intel SGX
  Intel started RA with its EPID attestation service. Only legal entities with a commercial license could obtain RA with their API, which leaves room for censorship. Then, Intel came up with DCAP, which delegates RA to cloud providers. Still, DCAP is a complicated process that only cloud providers are expected to operate, so now the censorship risk is with the cloud providers. The Integritee Network offers a decentralized DCAP service on a public blockchain that cannot be stopped or censored. The Attesteer enables using that service with any Intel SGX enclave.
• AMD SEV and AWS Nitro
  These technologies provide execution with memory encryption, but they do not provide thorough RA. Here, the cloud provider has to be trusted to only sign for genuine devices running the correct software. Even if this leaves a gap in the trust chain, the Attesteer can verify the certificate from cloud providers inside an SGX enclave and supply publicly auditable RA for these technologies.
• Open Source Hardware TEE
  While still academic, projects like Sanctum and Keystone pave the way to production-ready open-source hardware TEEs. Such TEEs could be produced by multiple silicon fabs in parallel. RA, however, requires someone to testify to the genuineness of each individual device. In the best case, that entity is the silicon fab directly, certifying that they produced the untampered TEE design. The Integritee Network would offer a platform for public RA in this case: Manufacturers register the public key for each device on our immutable network when the devices leave the fab. Every RA process from then on would just require authentication with a lookup in our public ledger.

Why do you need the Attesteer?

Our attestation service is relevant to any user of TEEs seeking to benefit from public auditability and an effortless, seamlessly integrable service. A Proof of Execution is delivered by the Attesteer and registered on Integritee’s blockchain, delivering the transparency and trust of blockchain and the security of confidential computing technologies.

You don’t need to hold crypto tokens in order to use the service. Hence, a company rooted in Web2, which doesn’t want to expose itself to blockchain directly for whatever reason doesn’t need to do that but can still get all the guarantees that Web3 provides namely an immutable, decentralized, trustless attestation registry.

Our public ledger registration makes confidential computing verifiable to any third party, like institutions that want to prove to their customers that their data is secure. There are unparalleled benefits when using Integritee Attesteer, including:

• Transparency and trust — The data and processes’ integrity is verified and registered on our own public blockchain network
• Customizable — The Attesteer proves authenticity remotely at both the frequency and the duration of your choice, which is very advantageous because every project has its own structure and needs
• Interoperability — Our Attesteer can be used with Intel SGX machines and other TEE technologies in the future.

If you’re looking for a more decentralized, flexible, and customizable remote attestation service, you found it.

How to integrate with the service: Check it out here.