²ÝÁñÉçÇø

In late 2021, PCI-SIG released an ECN titled Integrity and Data Encryption (IDE) which added optional capabilities for PCIe devices to perform hardware encryption and integrity checking on packets transferred across PCIe links.  Fundamentally, the goal of IDE is to protect against hardware-level attacks conducted by skilled attackers with both sophisticated tools and direct access to their victim systems.  In prior years, this scenario would have been viewed as astronomically unlikely as companies owned and operated their own datacenters, staffed them with their own trusted employees, and considered physical security to be of paramount importance.  One result of the shift to ¡°cloud computing¡± is that fewer and fewer companies fit that direct ownership model, with more and more of them relying on shared resources inside massive shared datacenters ¨C potentially located half the world away.  Suddenly the idea of an attacker with a cart filled with logic analyzers and oscilloscopes pulling the covers off running servers probing their internal busses didn¡¯t seem so far-fetched.  

The IDE ECN is specifically geared to defeat such attackers equipped with laboratory equipment (like bus analyzers) and even malicious dedicated hardware (such as interposer cards and co-opted PCIe switches).   With the new ECN, PCIe devices can use defined AES GCM algorithms to cryptographically sign and/or encrypt each packet transferred across the PCIe link.  The two types of IDE Streams are: Link ¨C valid only from one device directly connected to another, and Selective ¨C intended to be carried across PCIe switches.  These two Stream types can be combined as shown in Figure 1, with some links carrying both types, and other links only one type.  One important protection this provides is that devices expecting to be directly connected via a Link IDE Stream will fail to establish a secure connection if a malicious PCIe switch is unexpectedly added in between them.  Similarly, Selective IDE Streams are carried unmodified across PCIe switches ¨C meaning the switch itself can never decrypt the data, so an attacker can at best make a copy of the encrypted data.  Mechanisms within the IDE specification protect against further attacks such as forcing retries and injecting packets in attempts to force repeated transmission of the same data to expose the cryptographic keys being used.

As the industry has evolved to support the kinds of shared data centers described above, the concept of Trusted Execution Environments (TEEs) has arisen in virtualization.  Here, the idea is that the owner of a Virtual Machine (VM) may not want to trust the Virtual Machine Manager (VMM) (sometimes called a Hypervisor) in the same way a physical server owner might not want to trust the datacenter personnel.  Within a TEE, the VMM still controls resource management as in a traditional virtual environment, but unlike a legacy VM, a TEE Virtual Machine (TVM) can manage its own security.  For example, the VMM may allocate certain encryptable memory pages to the TVM, but it¡¯s the TVM that controls the encryption keys for those memory pages.  On the CPU and memory side of the server, these controls are specific to the CPU and memory architecture in use, so no new specifications are needed to expose them to the VMM.  When the concept is extended to an I/O interface like PCIe, it¡¯s much more important to have an open framework that doesn¡¯t require the VMM or TVM to have such specific knowledge of the devices being connected.

TDISP stands for TEE Device Interface Security Protocol, and it provides for three main functions:

1) Establishing a trust relationship between a TVM and a TDISP-capable device

2) Securing the PCIe path between the host and TDISP-capable device

3) Attaching/detaching a TDISP-capable device¡¯s interface to/from a TVM in a secure manner

While much of this functionality resides in software (or firmware), the TDISP specification requires a number of different behaviors and PCIe features in TDISP-capable devices.  

TDISP currently focuses on using Virtual Functions as defined by the PCI SIG Single-Root I/O Virtualization (SR IOV) specification, but notes that future revisions may be extended to other schemes.  Physical Functions (PFs) are defined as PCIe Functions which include the SR-IOV capability structure and can therefore operate as the management entities for associated Virtual Functions (VFs).  VFs were originally envisioned as lightweight functions which could be directly assigned to VMs, but which might rely on the VMM to emulate some aspects of their PCIe configuration space.  

Designers developing SoCs for hyperscale datacenters and other security-conscious applications should review the TDISP specification with their customers to see if it can improve the overall security of their systems.  TEE Device Interface Security Protocol or TDISP offers optional support for trusted I/O virtualization and ties together with existing PCI-SIG technologies for SR-IOV and hardware security via IDE.  Implementers of TDISP need to pay close attention to mechanisms for securing their DSMs and take note of changes which may be necessary to any pre-existing IDE implementations.  ²ÝÁñÉçÇø offers a wide range of PCIe and CXL controller IP including support for encryption with IDE and providing the mechanisms necessary for secure TDISP implementation.  ²ÝÁñÉçÇø further offers an array of secured processors and cryptographic tools which can greatly simplify implementation of DSMs.