Skip to content

Where Trust Begins: Exynos Anchors Post-Quantum Security at the Root of Mobile SoCs

  • mail

Mobile devices have evolved into platforms where payments, authentication, work tasks, and personal data are concentrated in a single device, and where operating systems and firmware are continuously updated. As functionality and data become increasingly centralized, what a device considers trustworthy and executes as legitimate becomes the starting point of security. The foundational technology that enforces this starting point is secure boot, which verifies the legitimacy of code during the boot process to ensure that only trusted components are executed. Conversely, once this verification is compromised, the trust chain itself can collapse, regardless of how many security features are added in later stages.

In 2026, the tech industry has reached a tipping point where quantum computing is no longer a theoretical risk to hardware-level verification but rather an active threat. In this environment, all eyes turn to leading device manufacturers and technology companies to define how trust will be established and preserved at the hardware level.

 

Exynos’ Response to Quantum Threats

The challenge is that quantum computing has the potential to weaken, over the long term, public-key signature verification, which is a core assumption underpinning boot validation. As a result, the possibility that the security of public-key cryptography may be undermined extends beyond simply replacing algorithms; it becomes a design question of where the trust anchor is placed and how long it can be maintained. In particular, mobile SoCs are designed to operate for seven years or more with consideration of EU regulations in mind. They also continue to receive changes to functionality and security policies via over-the-air (OTA) updates even after deployment in the field, so the transition to post-quantum security must be approached not as a one-off feature addition, but as a redesign of the trust framework itself.

In preparation for these quantum threats, Exynos has been designed so that secure boot verification based on post-quantum cryptography (PQC) is performed immediately from the Boot ROM stage, strengthening the boot trust chain and key protection. To achieve this, the Boot ROM and secure core are placed inside a Primary Security Processor (i.e., an isolated security processor, or enclave) that is segregated from the main system. As a result, the root of trust (RoT) — which serves as the trust anchor of the boot process — is strengthened. This architecture isolates the RoT from the complexity and potential vulnerabilities of the main system, minimizing the trusted computing base (TCB) and attack surface, while reinforcing the integrity of the boot trust chain and key protection. At the same time, by anchoring PQC-based verification from the very first validation point in the boot chain, it ensures that trust is preserved even in the quantum era.
 

Diagram of the secure communication architecture between Exynos 2600 and Exynos Modem 5410 using PQC and ECC.
Figure 1. PQC-ready security architecture of Exynos 2600 and Exynos Modem 5410
Diagram of the secure communication architecture between Exynos 2600 and Exynos Modem 5410 using PQC and ECC.
Figure 1. PQC-ready security architecture of Exynos 2600 and Exynos Modem 5410

 

The Need for PQC Signatures

Currently, code signing and secure boot on commercial devices primarily rely on RSA- and ECC (ECDSA)–based digital signatures.¹ However, it is well known that if sufficiently large-scale quantum computers emerge, Shor’s algorithm² will be able to solve integer factorization and the discrete logarithm problem (DLP) in polynomial time, rendering RSA- and ECC-based public-key systems structurally vulnerable.

Accordingly, NIST has advanced PQC standards based on problem classes that are not part of the traditional factoring/DLP family and are assessed to be relatively resilient against quantum attacks. In August 2024, NIST finalized the PQC FIPS standards.³ Among these, ML-DSA is a module-lattice-based digital signature proposed by NIST as the primary signature algorithm; unlike factoring- or DLP-based signatures to which Shor-class attacks apply directly, it relies on lattice-based problems as its security assumption, thereby providing a long-term foundation for signature verification in a post-quantum environment.

On this basis, Exynos has adopted ML-DSA as its PQC signature scheme. More importantly, the transition to PQC goes beyond the technical choice of adopting a new algorithm and leads to a trust question: “What will be recognized as legitimate over the long term?”

 

Trust Now, Forge Later

Quantum threats are often first explained from a confidentiality perspective, exemplified by harvest now, decrypt later (HNDL), which refers to the threat of collecting ciphertexts today and decrypting them in the future once quantum computers become available, thereby breaking confidentiality. However, in signature-based systems, the more fundamental risk is not the loss of secrecy but the collapse of trust itself. A representative example of this is trust now, forge later (TNFL), which refers to the risk that signatures and certificates trusted as secure today may be forged in the future, causing trust based on authentication and integrity to break down. 

Today, devices trust classical signature schemes such as vendors’ RSA or ECDSA and perform legitimate updates accordingly. But once RSA/ECDSA-class signature schemes become effectively compromised in the future, attackers will be able to generate forged signatures that appear legitimate. As a result, devices will accept malicious boot images or updates masquerading as having been properly signed. While HNDL unlocks secrets from the past, TNFL threatens trust itself in the future, and in commercial devices, this trust is largely defined along the verification path at boot time.

This threat is particularly severe because that verification path is typically fixed at boot time and cannot be easily changed during operation. Even if operating systems or applications are updated rapidly, if a quantum-vulnerable link remains in the verification path executed during early boot, attackers can exploit it to pass secure boot with “legitimately signed malicious images,” after which system recovery becomes extremely difficult. Ultimately, the key to mitigating TNFL lies in where and how the criteria for determining legitimacy are defined during early boot — and this question leads directly to the design of verification at the Boot ROM stage.

 

PQC Secure Boot from Boot ROM

In commercial devices, the point at which trust criteria are most strongly determined is the first verification stage of secure boot, and its starting point is the Boot ROM. At this stage, the signature scheme recognized at the first verification point defines what the device accepts as “legitimate.” Therefore, the core of PQC secure boot is to perform PQC signature verification at this initial stage, anchoring the trust criteria at the lowest layer. If the ROM is designed to verify only classical signatures, then no matter how later stages adopt PQC, the starting point of the chain remains bound to classical cryptography. Conversely, if PQC signature verification is implemented by design, the trust baseline of the boot chain transitions to PQC from the lowest layer, and subsequent verification stages accumulate along the same trust axis.

The challenge is that the Boot ROM is effectively immutable after manufacturing. While this characteristic reduces the attack surface, from an operational perspective it also means that the approach of “fixing it later if needed,” which may work for application or service layers, does not apply. As a result, from a secure boot standpoint, the more fundamental issue is not “which algorithm to use,” but rather “where that algorithm is anchored.”
 

CNSA 2.0 implementation timeline from 2022 to 2033 for various technology sectors.
CNSA 2.0 implementation timeline from 2022 to 2033 for various technology sectors.
Figure 2. NSA timeline for CNSA 2.0[1]  

 

Reflecting this reality, the NSA’s Commercial National Security Algorithm Suite (CNSA) 2.0 treats the transition of software and firmware signing on a separate timeline and addresses it as “more urgent,” recommending early adoption and migration across the entire asset base.[2] This emphasis is not solely due to the timing of the quantum threat itself but also reflects the fact that signature verification is often anchored in the RoT or Boot ROM; if the transition is deferred, field replacement costs and operational risks increase sharply. Ultimately, a quantum-ready RoT and secure boot must be designed proactively from the Boot ROM onward, with the entire product lifecycle in mind. To this end, Exynos has preemptively applied PQC secure boot starting at the Boot ROM stage immediately after boot, ensuring that trust is preserved even in the quantum era.

 

A Hybrid Approach to PQC
Hybrid bootloader verification flow using ECDSA and ML-DSA signatures.
Figure 3. Hybrid PQC strategy with AND policy
Hybrid bootloader verification flow using ECDSA and ML-DSA signatures.
Figure 3. Hybrid PQC strategy with AND policy

 

Since PQC algorithms have a much shorter period of validation and maturity than RSA or ECDSA, there is concern that unforeseen vulnerabilities could be discovered by classical computers, not quantum ones. Accordingly, during the transition period, a hybrid strategy is required rather than relying exclusively on a single algorithm. However, hybrid does not simply mean attaching two signatures. During the transition phase in which classical and PQC algorithms are operated together, the key issue is how to define verification policies in order to maintain the security baseline. The most conservative approach is an AND policy, in which booting is permitted only if both the classical signature and the PQC signature are valid. A realistic roadmap begins with a hybrid AND model, transitions to PQC-mandatory enforcement, and ultimately converges on a PQC-only model.

From an implementation perspective, both performance and reliability must be satisfied simultaneously. Depending on the implementation, PQC signature verification can impose a burden on boot time and power consumption. Because mobile SoCs have tight constraints on boot time and power budgets, hardware acceleration or offloading to a security subsystem capable of efficiently handling PQC operations must be considered in parallel. In addition, in hybrid verification, sequential processing of the two algorithms can significantly increase latency; therefore, a design that minimizes latency through parallel verification, where possible, is advantageous.

To enable secure PQC migration, Exynos supports a hybrid scheme in which ECDSA and ML-DSA are both used for signing, starting from the Boot ROM. Although ML-DSA requires tens of kilobytes of memory compared to legacy signature schemes, memory usage has been optimized with consideration for the resource constraints of embedded systems. NTT⁴ operations and related computations are accelerated using hardware backing, achieving performance on par with existing ECDSA implementations. Additionally, during hybrid signature verification, ECDSA and ML-DSA are processed in parallel to optimize boot time. 

 

Strengthening the Root of Trust

PQC cannot be treated as an optional future upgrade, and because the secure boot verification path is fixed in an immutable Boot ROM, post-deployment changes are largely infeasible. Recognizing this reality, Exynos has proactively incorporated PQC-based secure boot at the Boot ROM stage in a hybrid configuration, absorbing the uncertainties that may arise during the transition period directly into the system architecture. Furthermore, hybrid verification is implemented through an AND-policy–based validation model, ensuring that security standards are not relaxed during the transition period, and security against PQC threats across overall smartphone usage is further strengthened by using this ROM-booted hybrid approach in conjunction with Samsung’s S3SSE2A security chip. 

Ultimately, the effectiveness of PQC lies not in whether it is adopted, but where it is applied. And when trust is anchored at the RoT, secure boot can provide consistent trust across the entire product lifecycle. Within this framework, Exynos will continue to strengthen the RoT over time while responding proactively to attacker capabilities as they evolve. 
 



References

[1] National Security Agency (NSA), Commercial National Security Algorithm Suite (CNSA) 2.0, 2025.
https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF↗

[2] National Security Agency (NSA), Commercial National Security Algorithm Suite (CNSA) 2.0, 2025.
https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF↗
 



1
 Rivest–Shamir–Adleman (RSA) and elliptic curve cryptography (ECC) are two widely used methods for securing digital systems through public-key cryptography. RSA relies on the difficulty of factoring very large numbers, while ECC is based on the mathematical properties of elliptic curves. Elliptic Curve Digital Signature Algorithm (ECDSA) is a specific type of digital-signature method built on ECC and is commonly used to verify that software or firmware has not been altered.

2 Shor’s algorithm is aquantum algorithm capable of efficiently solving the integer factorization and discrete logarithm problems that underpin the security of RSA and ECC. If executed on a sufficiently large-scale quantum computer, it could enable the derivation of private keys, fundamentally weakening the security of widely deployed public-key cryptosystems based on factorization and discrete logarithms.

3 FIPS 203: ML-KEM, FIPS 204: ML-DSA, FIPS 205: SLH-DSA

4 Number Theoretic Transform (NTT) is a mathematical technique used as a core building block of lattice-based PQC and helps make PQC signature verification fast enough for practical use in secure boot.
 



* All images shown are provided for illustrative purposes only and may not be an exact representation of the product. All images are digitally edited, modified, or enhanced.

* All product specifications reflect internal test results and are subject to variations by user's system configurations. Actual performance may vary depending on use conditions and environment.