As NIST finalizes post-quantum cryptography standards, the semiconductor industry faces a defining challenge: how to embed quantum-resistant algorithms into silicon without sacrificing performance, power efficiency, or updatability. This deep dive explores PQC hardware accelerators, TPM and TEE integration, root of trust architectures, and firmware update strategies — plus how PQC-enabled trust anchors are reshaping anti-counterfeiting.
Why Post-Quantum Cryptography Matters for Hardware Engineers
Quantum computers running Shor’s algorithm can break RSA and ECC — the asymmetric cryptographic foundations that protect secure boot, firmware signing, TLS handshakes, and device attestation. While large-scale fault-tolerant quantum machines remain years away, the “harvest now, decrypt later” threat is already real: adversaries can capture encrypted data today and decrypt it once quantum capability arrives.
In August 2024, NIST published the first three finalized post-quantum cryptographic standards:
- FIPS 203 (ML-KEM) — based on CRYSTALS-Kyber, for key encapsulation
- FIPS 204 (ML-DSA) — based on CRYSTALS-Dilithium, for digital signatures
- FIPS 205 (SLH-DSA) — based on SPHINCS+, a hash-based signature scheme
In March 2025, NIST selected HQC as the fifth PQC algorithm, serving as a code-based backup for general encryption. The 6th PQC Standardization Conference is scheduled for September 2025.
These standards trigger an urgent question for hardware architects: How do you implement PQC in silicon efficiently, securely, and with room for future algorithm updates?
What Are PQC Hardware Accelerators and Why Are They Needed?
Post-quantum algorithms demand significantly more computation than their classical counterparts. Lattice-based schemes like ML-KEM and ML-DSA rely heavily on Number Theoretic Transforms (NTT), polynomial arithmetic, and large matrix operations. Running these in pure software on resource-constrained microcontrollers introduces unacceptable latency and power overhead — particularly in IoT, automotive, and industrial environments.
PQC hardware accelerators offload these compute-intensive operations to dedicated logic, achieving orders-of-magnitude improvements in throughput and energy efficiency.
Key Architectural Approaches
1. Dedicated ASIC Accelerators
Companies like PQShield offer purpose-built PQC IP cores. Their PQPerform-Flare product provides pure hardware acceleration of ML-KEM and ML-DSA, targeting high-throughput applications such as TLS acceleration, next-generation firewalls, and VPN gateways. These cores are FIPS 140-3 CAVP-certified and available for both ASIC and FPGA integration.
2. FPGA-Based Accelerators
FPGAs provide a flexible platform for PQC prototyping and deployment. Recent research from Yale University demonstrated the first hand-optimized hardware design of HQC on FPGAs, while a 2025 paper presented a high-performance FPGA accelerator for the CROSS signature scheme that generates key pairs in as little as 9 µs and signs messages in 404 µs on a Xilinx Artix-7 device.
3. RISC-V SoC Integration
A growing body of work integrates PQC acceleration into RISC-V system-on-chip architectures. Research published in IEEE demonstrates a RISC-V SoC with a dedicated NTT-based computational accelerator for Kyber and Dilithium, achieving significant speedups over pure software execution. SEALSQ’s QS7001 platform exemplifies commercial adoption — it pairs a secure 32-bit RISC-V core with Kyber and Dilithium acceleration for IoT device security.
4. Multi-Scheme Flexible Accelerators
A notable 2024 study introduced a scalable hardware accelerator supporting four NIST PQC finalists simultaneously, achieving up to 81.85% area efficiency compared to state-of-the-art single-scheme designs. This approach is critical because organizations may need to support multiple algorithms during the transition period.
How Do PQC Accelerators Compare in Performance?
| Metric | Software-Only (ARM Cortex-M4) | FPGA Accelerator | ASIC IP Core |
|---|---|---|---|
| ML-KEM KeyGen | ~1 ms | ~10 µs | <5 µs |
| ML-DSA Sign | ~5 ms | ~100 µs | <50 µs |
| Power Consumption | Baseline | 2–5× lower per op | 10–50× lower per op |
| Flexibility | High (firmware update) | Medium (bitstream update) | Low (fixed function) |
Note: Exact figures vary by implementation, security level, and platform. Data synthesized from published NIST PQC conference papers and vendor datasheets.
How Are TPMs Adapting to Post-Quantum Cryptography?
The Trusted Platform Module (TPM) is the de facto hardware root of trust in PCs, servers, and increasingly in IoT edge devices. TPMs handle secure boot, firmware signing, key storage, attestation, and disk encryption.
TPM 2.0 Version 1.85: PQC Arrives at the Root of Trust
The Trusted Computing Group (TCG) updated the TPM 2.0 specification to version 1.85, adding native support for:
- ML-KEM (Kyber-based key encapsulation) via new
TPM2_EncapsulateandTPM2_Decapsulatecommands - ML-DSA (Dilithium-based digital signatures) via
TPM2_SignSequenceStart,TPM2_VerifySequenceStart, and related commands - Context-based signing for processing large messages through the TPM’s post-quantum engines
This update is significant because TPMs are already deployed at massive scale across enterprise IT, data centers, and industrial settings. The PQC update path enables existing infrastructure to migrate without full hardware replacement.
Infineon OPTIGA TPM SLB 9672: A Practical Example
Infineon released the OPTIGA TPM SLB 9672, which features a PQC-protected firmware update mechanism using XMSS (eXtended Merkle Signature Scheme) signatures. This stateful hash-based scheme provides quantum resistance specifically for firmware integrity verification, reducing the risk of firmware corruption by attackers with future quantum capabilities.
The key design insight: even if the TPM’s primary cryptographic operations haven’t fully migrated to PQC, the firmware update channel itself must be quantum-resistant to prevent an attacker from pushing malicious firmware updates using a compromised classical signature.
What Role Do TEEs Play in the PQC Transition?
A Trusted Execution Environment (TEE) provides an isolated processing environment that runs alongside the main operating system. Unlike TPMs, which are discrete or integrated hardware modules, TEEs leverage processor-level isolation (e.g., ARM TrustZone, Intel SGX, RISC-V PMP) to protect code and data in use.
TEE and PQC: Complementary Layers
TEEs are critical to PQC migration for several reasons:
- Crypto Agility Runtime: TEEs can host PQC algorithm libraries that are updatable without modifying the main application firmware. Entrust’s CodeSafe platform, for example, runs inside HSM TEEs and allows PQC algorithm deployment via secure software updates.
- Key Management Isolation: PQC keys are larger than classical keys (ML-KEM public keys are ~800 bytes at NIST Level 1 vs. ~32 bytes for X25519). TEEs provide the secure memory space needed to handle these larger key materials without exposing them to the untrusted OS.
- Hybrid Cryptography Orchestration: During the transition period (2025–2033 per CNSA 2.0 timelines), systems must run both classical and PQC algorithms simultaneously. TEEs can manage hybrid key exchange and dual-signature verification securely.
How Does PQC Strengthen the Hardware Root of Trust?
A hardware root of trust (RoT) is the immutable foundation on which all secure operations depend. It contains the cryptographic keys and logic for secure boot, attestation, and key provisioning. If the RoT is compromised, the entire trust chain collapses.
The Quantum Threat to Root of Trust
Current RoT implementations rely on RSA or ECC for:
- Secure boot chain verification — each firmware stage is signed and verified
- Remote attestation — proving device integrity to a remote verifier
- Key provisioning and sealing — binding secrets to a specific hardware configuration
All of these operations become vulnerable once a quantum computer can forge signatures or derive private keys from public keys.
PQC-Ready Root of Trust Architectures
Rambus offers a family of quantum-safe RoT IP cores:
- RT-634: Programmable RoT with quantum-safe cryptography acceleration
- RT-654: Adds DPA (Differential Power Analysis) resistance
- RT-664: Adds FIA (Fault Injection Attack) protection
These cores integrate ML-KEM and ML-DSA acceleration alongside classical algorithms, enabling hybrid operation during the transition.
Open-source initiatives are also advancing. Caliptra (backed by Google, AMD, NVIDIA, and Microsoft) and OpenTitan provide transparent, auditable RoT designs where PQC can be integrated into the secure boot chain and attestation flows. Their open architecture enables firmware-based algorithm updates as PQC standards evolve.
Firmware Update Strategies: How Do You Keep PQC Hardware Future-Proof?
PQC standardization is ongoing. NIST continues evaluating additional signature schemes, and real-world cryptanalysis may weaken some algorithms over time. Hardware that ships today must remain secure for 10–20 years. This demands robust firmware update strategies.
What Is Cryptographic Agility?
Cryptographic agility means designing systems that can swap cryptographic algorithms without hardware replacement. For PQC, this translates to:
- Algorithm-agnostic accelerator architectures — hardware that accelerates shared operations (NTT, hashing, polynomial arithmetic) rather than a single algorithm
- Firmware-updatable TPMs — like Infineon’s SLB 9672 with XMSS-protected update channels
- FPGA-based crypto modules — where the entire accelerator logic can be updated via secure bitstream reprogramming
Dual-Firmware Banks and Safe Rollback
For IoT and embedded devices, dual-firmware banks are essential. The device stores two firmware images:
- Bank A: Current production firmware
- Bank B: Updated firmware candidate
If a PQC-signed firmware update fails verification or causes a boot failure, the device automatically reverts to the previous bank. This prevents bricking during the PQC migration.
Threshold Signing for Gradual Migration
Threshold signing enables progressive PQC adoption:
- Phase 1: Accept firmware signed with either a classical signature OR a PQC signature
- Phase 2: Require both a classical AND a PQC signature (hybrid mode)
- Phase 3: Accept PQC signature only, deprecate classical
This staged approach reduces risk and allows field-deployed devices to migrate at their own pace.
NXP’s Balanced Approach
NXP Semiconductors embeds PQC at the hardware root of trust for new products, enabling PQC-secured boot, firmware updates, and communications out of the box. For existing systems, NXP provides firmware upgrade paths that enhance quantum resilience without full hardware replacement — extending the security lifespan of deployed platforms.
How Does PQC Enable Next-Generation Anti-Counterfeiting?
Counterfeiting costs the global semiconductor industry billions annually. Traditional anti-counterfeiting relies on ECC-based device certificates and challenge-response authentication. Quantum computers threaten to clone device identities by deriving private keys from public certificates.
PQC-Based Device Identity
PQC-enabled secure elements can issue quantum-resistant device certificates using ML-DSA signatures. These certificates bind a device’s identity to a hardware root of trust that cannot be forged even by a quantum-capable adversary.
SEALSQ is building a U.S.-based Post-Quantum Root of Trust that delivers quantum-resistant PKI and device identity services. Their roadmap includes:
- 2025–2026: Integration of NIST-approved PQC algorithms into secure elements and HSMs
- 2027–2030: Hybrid ECC + PQC deployments for CNSA 2.0 compliance
- 2030+: Full post-quantum cryptography across IoT, identity, and industrial authentication
Supply Chain Authentication
PQC-signed firmware and PQC-authenticated provisioning records create a tamper-proof chain of custody from chip fabrication to end-user deployment. Each device’s identity, configuration, and firmware history are cryptographically bound, making component substitution or remarking detectable.
What Timelines Should Hardware Teams Follow?
The CNSA 2.0 guidelines from the NSA set clear milestones:
| Milestone | Deadline |
|---|---|
| PQC for firmware signing and software/firmware updates | 2025 |
| PQC for web browsers and cloud services | 2025 |
| PQC for all network equipment and operating systems | 2030 |
| Full transition for National Security Systems | 2033 |
In June 2025, Executive Order 14306 further directed CISA to maintain updated lists of PQC-capable hardware and software categories, signaling that federal procurement will increasingly mandate PQC readiness.
Key Takeaways for Hardware Architects
- Start with the firmware update channel. Even before full PQC migration, protect your update mechanism with quantum-resistant signatures (XMSS, LMS, or ML-DSA).
- Design for cryptographic agility. Use algorithm-agnostic accelerator architectures and ensure your RoT supports firmware-based algorithm swaps.
- Leverage TPM 2.0 v1.85. The PQC extensions for ML-KEM and ML-DSA bring quantum resistance to the most widely deployed trust anchor in computing.
- Plan for hybrid operation. The 2025–2033 transition window requires running classical and PQC algorithms simultaneously.
- Use PQC for anti-counterfeiting now. Quantum-resistant device certificates and supply chain authentication provide immediate value against both current and future threats.
Frequently Asked Questions
What is the difference between ML-KEM and ML-DSA?
ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism, FIPS 203) is used for secure key exchange — establishing shared secrets between parties. ML-DSA (Module-Lattice-Based Digital Signature Algorithm, FIPS 204) is used for digital signatures — verifying the authenticity and integrity of data, firmware, and certificates.
Can existing TPMs be upgraded to support PQC?
Some TPMs with firmware update capabilities, like the Infineon OPTIGA TPM SLB 9672, can receive PQC algorithm support via secure firmware updates. However, many older TPMs lack sufficient memory or processing power for PQC operations and will require hardware replacement.
How much larger are PQC keys compared to classical keys?
ML-KEM (Level 1) public keys are approximately 800 bytes, compared to 32 bytes for X25519. ML-DSA (Level 2) public keys are approximately 1,312 bytes, compared to 32 bytes for Ed25519. This increase impacts memory, bandwidth, and storage requirements in hardware designs.
Is CRYSTALS-Kyber the same as ML-KEM?
Yes. ML-KEM is the standardized name (FIPS 203) for the algorithm previously known as CRYSTALS-Kyber during the NIST selection process. Similarly, ML-DSA (FIPS 204) is the standardized name for CRYSTALS-Dilithium.
发表回复
要发表评论，您必须先登录。