Quantcast
Channel: Cadence Functional Verification
Viewing all articles
Browse latest Browse all 652

Verification of Integrity and Data Encryption(IDE) for PCIe Devices

$
0
0

The concept of Trusted Execution Environments (TEE) was developed in the early 2000s to standardize key encryptions, end-to-end security and authenticity, and confidentiality of devices in a system. With the increase in computing and connected devices due to IoT, there are large number of applications which are installed or accessed by users in a server or mobile resulting in an increased probability of data being compromised. Hence, the need for TEE. Integrity and Data Encryption (IDE) capability in PCIe provides a mechanism to implement TEE in a PCIe based system.

In ‘Why IDE Security Technology for PCIe and CXL?’ we covered what PCIe IDE is and why it is needed. Here, we will take a closer look at verification considerations for PCIe IDE at the block and sub-system levels.

PCIe IDE compliant devices have a mixture of link streams and selective streams to be encrypted. For link streams, all TLPs from the source port to the destination port are encrypted. Selective streams entail selected TLPs within a given RID and the address range is to be encrypted.  Thorough IDE, verification needs to address a random number of link streams. Selective streams are associated with random stream-id and traffic class mapping.

For illustration, let’s take the scenario mentioned in the table below with 5 Stream IDs enabled with a combination of link and selective IDs. The recommendation here would be to initiate transactions for different traffic classes in a random fashion with a mix of encrypted and unencrypted TLPs for good path testing. The sample transaction flow with posted, non-posted and completion sub-stream with traffic class is shown below. Similarly, error injection scenarios in TLPs with different sub-streams and traffic classes imitating real-time situations with malicious devices could help cover spurious verification intents.

                                   

                                                    

                             Figure 1: Sample IDE configuration and traffic flow between two PCIe ports

             

Another critical verification aspect for IDE is PR (Posted Request) counters which are introduced to make sure that the ordering of TLPs in a respective sub-stream is maintained. Any re-ordering or deletion of TLPs in a real system could result in stale data being written or read. Verification engineers need to make sure that PR counters are appropriately updated for all streams and sub-streams with posted, non-posted requests, completion packets, and IDE sync messages. In the case of an intentional error from testbench in the ordering of TLP, sent PR counters in a particular stream should result in PR counter underflow and overflow conditions.  In addition, scenarios catering to key refreshes at random intervals via toggling K bit in IDE prefix should be included.

Any error seen on IDE link like MAC mismatch, PCRC corruption, IDE PR counters, etc. results in a transition into an insecure state and invalidates the key and IV for the given IDE stream. Engineers must make sure that devices enter the insecure state on IDE error and recover from it gracefully after setting-up new keys and enabling IDE again.

                                                                          

                                                                                   

                                                                                    Figure 2: IDE State Machine

Lastly, IDE provides an option for aggregated TLPs in which the Message Authentication Code (MAC) is sent only in last TLP of the aggregated TLPs. This way, design architects can optimize bandwidth utilization and latency seen by application layers by supporting different variants of TLP aggregations. Various combinations of aggregated and non-aggregated TLPs should be included in the test plan.

Once IDE functionality is verified, it is advised that verification must be done on performance and latency aspects confirming that encrypted packets do not result in unexpected delays within the PCIe subsystem. On similar lines, integrating the IDE design module should not introduce unwanted delays in unencrypted data flow through PCIe stack.

As established by now, verifying IDE requires a robust and exhaustive approach, Cadence PCIe Verification IP and TripleCheck solution can help significantly reduce verification project cycles with comprehensive APIs, checkers for protocol violation and test suite provided.

 

More Information:


Viewing all articles
Browse latest Browse all 652

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>