Considerations for using XTS/XEX encryption in an SoC.
In my blog “The Methods of Memory Encryption to Protect Data in Use,” I discussed how the XTS/XEX mode of encryption was the appropriate choice for protecting data stored in and accessed from memory, also known as, protecting data in use. As a quick recap, XTS/XEX uses two keys, one key for block encryption, and another key to process a “tweak.” The tweak ensures every block of memory is encrypted differently. Any changes in the plaintext result in a complete change of the ciphertext, preventing an attacker from obtaining any information about the plaintext. In this blog, I’d like to cover considerations for implementing XTS/XEX encryption in an SoC.
Since increasingly the throughput of memory systems is extremely high, a high-performance XTS/XEX solution is required to keep up. Often, this requires the implementation of parallelism to provide the needed performance. Scalability of an architecture is crucial to address the increased bandwidth capabilities of the latest generation DDR5 and HBM3 memory systems.
Latency is another important factor. Encryption is a complex operation which by its very nature adds latency. For example, encrypting an AES block with a 256-bit key requires 14 rounds of operation. Similarly, SM4 requires 32 rounds of operation. Typically, one round takes one clock cycle to complete, and thus encryption using AES would add 14 clock cycles, and SM4 would add 32 clock cycles of latency.
When multiple VM guests or domains run on a single processor, multi-tenancy needs to be implemented and data needs to be protected under separate security keys. Switching to a different key could increase latency when not done properly. Modern implementations allow interleaving of data streams to ensure performance is not affected while using different keys for each individual access.
Talking about the keys, even as the XTS/XEX mode provides the needed security to encrypt memory, the keys it employs must still be protected from disclosure. Root of Trust technologies used to protect data-at-rest can be used to protect and manage the system keys and derive the corresponding memory encryption session key for each domain or guest.
The XTS/XEX memory encryption engine must also be protected from side-channel attacks. Methods like Differential Power Attacks (DPA) can be used to extract any used security keys by measuring power or electromagnetic emittance from the system if it is unprotected from DPA side-channel attacks. Countermeasures to side-channel and fault injection attacks should be implemented to ensure that the strong cryptographic protections of XTS/XEX can’t be bypassed.
In summary, there are a lot of challenges to designing and implementing a secure memory encryption solution. Rambus is a leading provider of both memory and security technologies and understands the challenges from both the memory and security viewpoints. Rambus provides state-of-the-art Inline Memory Encryption (IME) and Root-of-Trust silicon IP solutions that overcome the challenges and protect against the threats discussed above. Chip designers can leverage Rambus IP to build high-performance, secure, and scalable memory encryption solutions tailored for the needs of their target applications.
Additional resources:
 |
 |
 |
 |
 |
 |
Leave a Reply