Many online resources cover the history and current state of industry development for the concept that, in Integrity and Data Encryption (IDE), we refer to as a Trusted Execution Environment (TEE). In this blog, I will only talk about how the TEE concept applies when using IDE. An essential observation is that the foundational responsibility of a secure Endpoint, Switch, or Root Complex is to secure itself. This “local” TEE may apply to the entity in its entirety, or perhaps only selected parts. Component Measurement and Authentication (CMA) and Distributed Management Task Force’s (DMTF) Security Protocol and Data Model (SPDM) provide a toolset to help confirm that an entity within a platform is secure, but only to the extent that the entity itself correctly implements self-protective measures as needed for the level of security required for the intended use. It is essential that a given entity satisfies platform or application security requirements, but outside the scope of PCI Express^® (PCIe^®) architecture. 

Composed TEEs

IDE enables various secured entities (including the RC, Switches and/or Endpoints) to connect by a secured communication path using PCIe technology, and a group of entities connected in this way can be considered a “composed TEE.” In some cases, it may be possible to fully secure all the elements of a composed TEE. In other cases, additional mechanisms must be used to ensure that operations associated with unsecured parts of an entity are not able to improperly interact with secured parts of the same entity. For example, in a Multi-Function Device, it is necessary to isolate Functions associated with different TEEs from each other, and all Functions not associated with any TEE. A Root Complex may also have some software running within one or more TEEs, while at the same time other software is running in one or more untrusted environments. Existing mechanisms such as Translation Agents (aka IOMMUs) can be used to differentiate traffic. New mechanisms provided by IDE – as defined by the PCIe ECN – can also be used. For example, the ‘T’ bit can be used to indicate that a specific IDE TLP originated within a trusted environment. 

Translation Agents

Translation Agents have significantly improved the security of PCIe systems and IDE can further extend the level of security provided. When properly implemented, Address Translation Services (ATS) and Address Translation Caching (ATC) significantly improve the performance of many workloads. When improperly implemented, it may be possible to bypass the Translation Agent, thereby providing an attack mechanism. Before CMA/SPDM, no specification defined a way to evaluate a device implementing ATS/ATC to determine that it is authentic and not tampered with. By implementing CMA/SPDM, a device manufacturer can provide tools to ensure that “masquerade" attacks – where an attack device presents itself to the system as a legitimate device – and attacks using tampered device firmware can be detected. IDE extends this protection so that “attacker in-the-middle” attacks can be detected and prevented. This is done by ensuring that only the system entities that have properly established IDE communications can communicate with each other and that corrupted, dropped or reordered TLPs are immediately detected at the receiver. Because PCIe TLP level communication is considered “reliable”, IDE requires that the first occurrence of an integrity check failure be considered a failure of the IDE connection altogether. 

Combating Attacks

Likewise, because integrity check failures will not occur in a correctly configured system when a failure is detected, the detecting entity must consider itself to be under attack. It is the responsibility of each entity to protect itself in such cases by ensuring that secure data is not improperly exposed and that the entity blocks incoming requests affecting the secured parts of the entity. A security exposure could occur, for example, if the entity fails to stop the transmission of data intended to be secure, or if the entity mistakenly establishes an IDE connection with an attacker by failing to appropriately evaluate the attacker’s credentials. In cases where a system is under attack, it may not be possible for the first component detecting the attack to communicate the fact to other system entities, because the attacker may block such attempts. Error reporting messages can help in debugging an improperly configured system but cannot be relied upon to communicate the fact of an attack. Additional mechanisms such as timeouts, possibly in combination with a periodic “heartbeat” mechanism, are required.   

Ultimately, it is the responsibility of each component to ensure its security and the security of any composted TEE it is associated with. 

If you would like to learn more about IDE, please view my recent PCI-SIG hosted webinar on the topic.