A Basis for Trust
A Trusted Execution Environment (TEE) is a segregated area of a processor and memory where the architecture is designed to protect the data and code inside it from users, general processes, and even the overall processor operating system. You can think of a TEE as being similar to a Hardware Security Module (HSM) - like the tamper-evident USB keys or “dongles” used for authentication or software licensing, but built as a portion of the main processor rather than a physically external device.
Manufacturers have developed varying approaches to implementing TEEs. However...
TEEs are all designed to have specific properties:
- TEEs are the only element of a chip that have full access to the chip’s resources (power, processing, memory…). Not even the chip’s operating system can override the TEE.
- TEEs are manufactured with a hardware-protected and tamper-evident area within the chip. A unique identifier and set of cryptographic keys are burned into the silicon within the protected space. Nothing outside of the TEE has access to the keys or identifier.
- TEEs can use their keys to establish additional areas of processing and storage that only the TEE is able to access. These areas are called enclaves.
- TEEs can generate an attestation of an enclave, providing evidence of a Trusted Computing Base (hardware, software, code and data in memory, persistent state, etc.).
TEEs first started showing up in the 2015-2016 timeframe.
By 2018, Intel included a TEE (Software Guard Extensions or SGX) in most of the chips it produced. Manufacturers now offer TEEs on 7 or 8 different platform combinations including AMD, ARM, IBM, RISC, and others. But despite the security capabilities a TEE offers, we haven’t seen much about them in the operations technology (OT), industrial control systems (ICS), or critical infrastructure spaces. Why is that?
Manufacturers have taken differing approaches to TEE architecture, most importantly including how the TEE accesses memory. So, applications written to take advantage of a TEE must be designed for a specific platform. While a total of 7 or 8 different platform combinations cover over 90% of available TEEs, few software manufacturers want to code and maintain 7 or 8 different versions of their software.
ankrd solves this problem by serving as a translation layer.
We write and maintain the code for operating on the various platform combinations and roll that into a lightweight library providing a TLS tunnel.
If your app can run over TLS, it can use ankrd.
Have you heard about how we use this to enable secure transactions in untrusted environments and move secrets away from the attack surface?