Violation Type:Secure Enclave with Remote Attestation

From Violations Tracker
Jump to: navigation, search
Violation Type

Secure Enclave with Remote Attestation

Violation InstanceViolator
Intel x86 CPUs/ENCLAVEIntel x86 CPUs

This is so unique and so uniquely disturbing it gets its own violation type, since nothing else really fits it.

Intel's Secure Enclave functionality combines:

  • The ability to load code into a memory region and then make that code inaccessible even to ring 0 (!)
  • The loaded program can be executed without ring 0 ever being able to manipulate its execution or examine or change its registers or memory area
  • The memory of the program is even encrypted when it is written back from cache to RAM (!)
  • The CPU can enable remote attestation of the hash of the program running in the enclave.

This enables un-debuggable code which cannot be reverse engineered. A program can be formed of an encrypted payload and a loader program. The program is loaded into an enclave and becomes inaccessible to even ring 0. It has the CPU generate some form of verifiable attestation as to the hash of the running program. It establishes a secure channel (e.g. via TLS) with some server. This channel terminates inside the enclave and so ring 0 cannot inspect what is transmitted over it. A remote server receives the attestation, verifies it, and verifies that the hash attested to is on some approved list. Only then does it respond with the decryption key for the program body. The program body is decrypted and run inside the enclave. The program body executes but cannot be inspected or debugged by anything. Because enclave data written to RAM is encrypted, not even freezing and removing RAM modules breaks the enclave.

It should be emphasised that, while this capability is profoundly disturbing, it is not necessarily inherently bad. However it is hard to see any probable use case which is to the benefit of the owner of the machine, and so in practice this capability is an extreme cause for concern.