Jasmine Makhija

Community Member

Blog Activity
Options

Verification of PCIe's TDISP for Device Interface Security

• 5 minute read

The TEE Device Interface Security Protocol (TDISP) is a critical component in ensuring the Interface security of devices operating within a Trusted Execution Environment (TEE). It gives a set of rules designed to prevent and mitigate security threats in devices managed by a Trusted Computing Base (TCB). The TCB, comprising software, hardware, and firmware, enforces these security rules to ensure system integrity. Acting as the upper layer of security, TDISP serves as a guardian layer for Integrity and Data Encryption (IDE). This blog provides an overview of TDISP, its requirements, setup, and the challenges faced during its verification. 

Key Components

  • Trusted Execution Environment (TEE): A secure area within a device where operations are considered trustworthy. 
  • TEE Virtual Machine (TVM): A virtual machine within the TEE. 
  • TEE Security Manager (TSM): Manages security rules on the host. 
  • TEE Device Interface (TDI): Managed by the TVM, it can be an entire device or a specific function. 
  • Device Security Manager (DSM): Manages security rules on the device. 
  • VMM (Virtual Machine Monitor): Manages virtual machines. 
  • Legacy VM: A standard virtual machine without TEE capabilities. 
  • Device Interface Configuration: Manages how devices are exposed to VMs. 
  • PF Driver (Physical Function Driver): Interfaces with the physical device. 

Figure1: TDISP Components

Figure 1: TDISP architecture with example host and device and logical communication paths

 

How TDISP Protects Against Attacks 

TDISP is designed to safeguard PCIe devices operating within a TEE by addressing multiple vectors of potential attacks. It ensures device authenticity and integrity through cryptographic verification using the CMA/SPDM protocol, which helps prevent tampering with critical identifiers like Vendor ID and Device ID. To secure communication between the device and host, TDISP leverages IDE, protecting data from physical interception or manipulation. It also enforces strict control over TDI management, mitigating risks associated with unauthorized changes to DMA and interrupt remapping tables. Furthermore, TDISP isolates sensitive data and enforces access control to prevent physical functions from influencing the security properties of virtual machines. Through these layered defenses, TDISP establishes a robust framework for protecting PCIe devices in secure computing environments. 

Figure 2: Identification of Requests

                                                                      Figure 2: Identification of Requests

TDISP Messages 

TDISP uses a specific set of messages transmitted via CMA/SPDM over Data Object Exchange (DOE). These messages include: 

  • GET_TDISP_VERSION: Initiates version negotiation. 
  • LOCK_INTERFACE_REQUEST: Locks the configuration space. 
  • START_INTERFACE_REQUEST: Moves the TDI to the RUN state. 
  • STOP_INTERFACE_REQUEST: Moves the TDI to the Unlock state. 
  • TDISP_ERROR: Response to error conditions such as version inconsistencies, nonce mismatch, IDE insecure state, etc. 
  • TDISP_VERSION: Response to GET_TDISP_VERSION with version of TDISP. 
  • LOCK_INTERFACE_RESPONSE: Response to Lock the configuration space. 
  • START_INTERFACE_RESPONSE: Response to move the TDI to the RUN state. 
  • STOP_INTERFACE_RESPONSE: Response to move the TDI to the Unlock state 

 

TDISP State Machine 

Each TDI has an internal state machine representing its security state. The states include: 

  • CONFIG_UNLOCKED: Default state, data is not secure. 
  • CONFIG_LOCKED: Configuration space is locked. 
  • RUN: TDI resources are accessible. 
  • ERROR: Indicates a security breach or error condition. 

 Figure 3: TDISP Finite State Machine

                                        Figure 3: TDISP Finite State Machine

TDISP Requirements and Setup 

To enable TDISP, the following are required: 

  • Data Object Exchange (DOE): For transmitting CMA/SPDM messages. 
  • Component Measurement and Authentication (CMA-SPDM): For device authentication. 
  • Integrity and Data Encryption (IDE): For secure data transfer. 

Verification Challenges 

Verifying TDISP involves several challenges: 

Integration with Existing Systems: 

  • Ensuring TDISP integrates seamlessly with existing security protocols. 
  • Managing dependencies on other components like DOE and CMA/SPDM

FSM Transitions:

  • Ensuring seamless transitions of the finite state machine (FSM) under various scenarios. 

Error Handling:

  • Validating mechanisms for handling unpredictable failures, such as nonce mismatches and version inconsistencies. 

IDE Encryption:

  • Validating IDE encryption under different security states to ensure robust protection against data breaches. Transitioning to IDE insecure state to validate TDI behaviour. 

Reset and Error States:

  • Ensuring correct behavior of TDISP transactions during reset and error states, requiring extensive debugging and iterative refinements.

Conclusion 

As the demand for secure and high-performance computing continues to grow, protocols like TDISP are becoming essential in safeguarding PCIe devices within Trusted Execution Environments. TDISP provides a structured and robust framework that addresses key security concerns from device authentication and secure communication to interface management and access control. TDISP verification requires a deep understanding of system architecture, validation of state transitions, and careful integration with existing security mechanisms. Despite these challenges, the successful implementation and verification of TDISP can significantly enhance the trustworthiness of modern computing platforms.  

Learn More