wolfBoot for CNSA 2.0 Secure Boot on Zynq UltraScale+ MPSoC

    • Executive Summary

    Problem: Zynq UltraScale+ MPSoC secure boot authenticates the FSBL with RSA-4096 in immutable BootROM. CNSA 2.0 requires post-quantum algorithms for long-term software and firmware verification. RSA-4096 is not quantum-resistant, so the BootROM cannot be the final CNSA 2.0 firmware-authentication answer.

    Solution: Use wolfBoot as the system-level post-quantum authorization layer. Keep AMD secure boot enabled, encrypt the FSBL with the device AES-GCM key, minimize the FSBL, and require wolfBoot to verify all operational firmware with LMS, XMSS, or ML-DSA-87 before execution.

    Result: The ZynqMP BootROM remains RSA-based, but the deployed system can enforce CNSA 2.0-aligned firmware verification before protected software, bitstreams, update authority, secrets, or mission functions are released.

    Important caveat: wolfBoot does not make the ZynqMP BootROM quantum-safe. If the requirement is no attacker-controlled instruction can ever execute, then a ZynqMP-only software approach is not enough; the design needs an external PQC root of trust, a pre-boot supervisor, or silicon with native PQC boot authentication.

    CNSA 2.0 Requirement

    CNSA 2.0 addresses the risk that a cryptographically relevant quantum computer could break today’s public-key algorithms. For software and firmware signing, current NSA guidance identifies these post-quantum options:

    Algorithm Specification Use
    LMS NIST SP 800-208 Approved for firmware/software verification.
    XMSS NIST SP 800-208 Approved for firmware/software verification.
    ML-DSA-87 FIPS 204 AES-256 equivalent stateless signature option.

    Implication: A boot chain that relies only on RSA-4096 cannot be the long-term CNSA 2.0 trust story. The platform needs a post-quantum signature decision that an attacker cannot bypass after defeating RSA.

    ZynqMP Constraint

    Immutable BootROM: The ZynqMP BootROM supports AMD secure boot with RSA authentication and AES-GCM encryption, but it does not support LMS, XMSS, or ML-DSA-87 authentication of the FSBL.

    Attack model: If RSA-4096 can be forged in a post-quantum scenario, RSA authentication no longer proves that the FSBL came from the device owner. An attacker may be able to create a boot image with malicious FSBL metadata and a valid-looking RSA signature.

    Encryption still matters: AMD’s secure-boot design can encrypt boot partitions with AES-GCM using a protected device key in eFUSE, BBRAM, or PUF-protected form. UG1085 also states that the CSU locks out the protected AES key as a runtime AES source when the FSBL is not encrypted. This helps preserve confidentiality of encrypted partitions, even if RSA authentication is no longer trustworthy.

    Limit: Encryption protects access to protected code and data, but it does not by itself provide post-quantum authenticity. The missing piece is a PQC authorization decision before operational software runs.

    Recommended Architecture

    Use wolfBoot as the mandatory post-quantum boot policy stage.

    ZynqMP BootROM
  -> RSA-4096 authentication + AES-GCM decryption

Encrypted minimal FSBL
  -> Initialize only what is needed to reach wolfBoot

wolfBoot
  -> Verify LMS, XMSS, or ML-DSA signature
  -> Enforce rollback and update policy

Operational firmware
  -> U-Boot, Linux, RTOS, bitstreams, or application payloads

    Boot policy:

    1. BootROM: Use the strongest AMD secure-boot configuration available: RSA authentication plus encrypted FSBL.
    2. FSBL: Keep this stage small, static, and reviewable. Avoid placing mission policy or update authority here.
    3. wolfBoot: Verify the next image using a CNSA 2.0-approved PQC signature.
    4. Runtime handoff: Boot only images that pass PQC verification and rollback checks.
    5. Updates: Accept only PQC-signed firmware packages with valid version metadata.

    Why wolfBoot

    wolfBoot is a small secure bootloader built for embedded systems. It provides:

    • PQC signatures: LMS, XMSS, ML-DSA, and hybrid options.
    • Secure update: Authenticated firmware update and fallback recovery.
    • Anti-rollback: Signed version metadata prevents downgrade attacks.
    • Small trusted code base: Easier to review than a full second-stage bootloader.
    • Flexible payload support: Bare-metal apps, U-Boot, Linux images, RTOS payloads, and other firmware.
    • TPM integration path: Useful for measured boot, sealing, and remote attestation.

    For ZynqMP, wolfBoot provides the post-quantum enforcement point that the BootROM cannot provide.

    Security Argument

    Core claim: wolfBoot does not replace the BootROM. It adds a post-quantum authorization boundary after the encrypted FSBL, so protected firmware cannot run unless it carries a valid CNSA 2.0-aligned signature.

    What this protects:

    • Operational software such as U-Boot, Linux, RTOS images, and applications.
    • FPGA bitstreams and other protected payloads.
    • Firmware update authority and rollback policy.
    • Secrets and credentials released only after expected software is verified.
    • Remote trust decisions when paired with TPM measurement or attestation.

    Residual risk: If RSA is defeated, an attacker may still attempt to boot an arbitrary unencrypted FSBL. AMD AES-key lockout behavior helps prevent that FSBL from using the protected device AES key to decrypt protected partitions. However, preventing any attacker-controlled FSBL from executing requires an external pre-boot enforcement point or newer silicon.

    Implementation Guidance

    FSBL scope: Keep the FSBL minimal. It should initialize memory, clocks, storage, and the handoff path to wolfBoot. Move authorization, update, rollback, and mission-policy decisions into wolfBoot.

    Signature selection: Prefer LMS for near-term CNSA 2.0 firmware-signing alignment. XMSS is also approved. ML-DSA-87 is attractive where stateless signing is operationally important, subject to program validation and certification needs.

    Stateful signing: LMS and XMSS require careful signing-state management. The production signing system must prevent one-time key reuse and should provide audit, backup, and disaster-recovery controls.

    Key provisioning: Protect the ZynqMP AES key through eFUSE, BBRAM, or PUF-backed flows. Store the wolfBoot PQC public key so it cannot be replaced by an attacker, for example inside the encrypted wolfBoot image or protected authenticated metadata.

    TPM and attestation: A TPM strengthens the design but does not independently solve the FSBL trust problem. Use TPM measurements after the wolfBoot PQC decision to support sealing, remote attestation, and network access control.

    Management Positioning

    Clear answer: ZynqMP silicon cannot be made natively PQC at BootROM, but wolfBoot can enforce CNSA 2.0 firmware-signing policy before operational firmware runs.

    Recommended message to customers:

    1. Acknowledge the ZynqMP BootROM limitation: FSBL authentication is RSA-4096.
    2. Preserve AMD secure boot: encrypted FSBL and protected AES key storage.
    3. Minimize pre-PQC code: keep the FSBL small and static.
    4. Enforce PQC with wolfBoot: LMS, XMSS, or ML-DSA-87 verification.
    5. Protect updates: anti-rollback, signed metadata, and recovery behavior.
    6. Extend with TPM or external root of trust where policy requires stronger guarantees.

    Conclusion

    wolfBoot provides the missing post-quantum authorization layer for ZynqMP systems facing CNSA 2.0 requirements. The practical architecture is to use AMD secure boot and AES-GCM encryption for the earliest stage, then use wolfBoot to verify all operational firmware with LMS, XMSS, or ML-DSA-87 before execution.

    This approach is honest about the silicon limitation while still giving customers a viable path: keep ZynqMP, preserve AMD hardware protections, and enforce CNSA 2.0 firmware signing at the system level.

    Sources

    If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

    Download wolfSSL Now