What It Takes To Make An SoC Design Quantum Safe

When it comes to quantum computing attacks, the first question people ask is “will my design be impacted?” In the majority of cases, the answer is yes. For any device that cannot function with manually programmed symmetric keys, which is most devices, you must plan to make upgrades. The good news is that your architecture is not impacted. Secure domains remain secure domains and keys can be stored in the same locations. Data storage remains secure. But for communication over existing interfaces, the case is more difficult. Security is impacted because existing session key exchange and authentication mechanisms (RSA or ECDH) are vulnerable to quantum attacks, but the computationally heavy lifting, i.e., the data plane encryption, remains secure. Bottom line is that all public key algorithm-based use cases leveraging RSA and ECC algorithms, that exist today, must be updated or replaced. Check out my most recent blog for more background information on this, as well as a detailed look at the cryptographic algorithms that will protect data and hardware in the quantum computing era.

Public key or asymmetric cipher algorithms are in use about everywhere. They are used for secure firmware verification at boot (secure boot), secure software and firmware updates, secure debug enablement via JTAG, as well as communication establishment. Payments, document signing, access control, content protection. All these use cases generally perform digital signature verification and authentication operations based on public key algorithms. Beyond this, a system may store (encapsulate) or exchange keys using public key-based mechanisms for other purposes, which are all impacted. Finally, another area of concern is secure protocols and their key exchanges. All TLS and IPsec key exchanges rely on today’s public key algorithms. The risk is that these key exchanges can be captured/logged by an attacker together with their data today, and once quantum computers become powerful enough, these keys can be extracted, and the data decrypted.

So, what exactly does this all translate to in terms of concrete changes at an SoC level?

1. Secure boot

NIST has standardized stateful hash-based signature schemes that are considered quantum safe for boot and firmware verification. These are XMSS (eXtended Merkle Signature Scheme) and LMS (Leighton-Micali Signatures) specified in NIST SP800-208, as well as SHAKE and SHA-3 for eXtendable Output Function. These schemes come with some challenges in that to provide robust security private key components must be updated every time a signature is generated. This is not ideal for use cases such as backups.

2. Secure debug

Secure debug operations are equally important to revisit. Typically, an authorized user sign in happens with a signature verification, enabling full debug/system access. Today, these accesses are mostly granted based on ECC or RSA verify operations, and this opens the risk of unauthorized access to the full system. CRYSTALS-Dilithium, or an equivalent quantum safe algorithm, is needed here to protect this ability to access your device.

3. Key encapsulation, sign/verify

While your system is operational, boot and debug are protected, but other subsequent key encapsulation, as well as sign and verify operations enabling access into the system must be evaluated. For example, during boot, firmware image verification is equally important for firmware/software updates of the system. To avoid “rewinding” to older images without proper protection, life cycle management is critical and firmware images must use a validated minimum version number. Another operation used in many modern systems is key encapsulation. For both these types of operations, ECC and RSA must be avoided and instead CRISTALS-Kyber can be used.

4. IPsec/TLS/DTLS key exchange

As mentioned earlier, all key exchanges are affected and must be updated. Although not an immediate threat for the system, compromising communication and the data that comes along with it introduces many threats for both sender and receiver. Store-now-decrypt-later attacks on secure communication are a big and very immediate concern for privacy-minded individuals and nation states. Encryption is used everywhere online from internet searches to gaming, and decryption mostly happens after receiving the data real-time over a data stream with a validated origin. While these connections can, in theory, be established with pre-shared keys, generally sessions are set up using verified certificates. Session keys are generally exchanged using ECC and RSA-based public key cryptography as defined in RFCs and IEEE standards. To ensure protection against quantum attacks, these key exchanges will have to happen with CRYSTALS-Kyber (for the key encapsulation) and CRYSTALS-Dilithium (for authentication of the exchanged key) or equivalent quantum safe cryptography. It is expected that the IETF and IEEE protocol standards for certificate infrastructures, as well as for the TLS, DTLS and IPsec standards will be updated in the future to reflect these requirements.

5. Public key acceleration in a dedicated quantum safe hardware module

A Root of Trust is often used for accelerating public key-based operations. By updating this component in your device, your security critical operations will be quantum safe. The Rambus RT-600 Root of Trust series is at the forefront of a new category of programmable hardware-based security cores with its new quantum safe cryptography features. The RT-634, RT-654 and RT-664 Root of Trust products include Quantum Safe Cryptography supporting the CRYSTALS-Kyber Key Encapsulation mechanism and the CRYSTALS-Dilithium digital signature algorithms, as well as secure boot and firmware verification use cases with the stateful hash-based signature verification methods XMSS and LMS specified in NIST SP800-208. Visit the Rambus website to explore Root of Trust IP solutions with Quantum Safe Cryptography.

Resources