The Hardware Security Engine (HSE)

The HSE runs its own firmware on a dedicated core and communicates with the application core over a Messaging Unit (MU). It is responsible for performing cryptographic operations, managing a protected key store, and enforcing access policies on those keys. Because the keys are held inside the HSE and referenced by handle rather than by value, sensitive material such as long-term private keys and SHE keys are never exposed to application memory.

Supported HSE Algorithms:

Random number generation:

• Hardware TRNG

Hashing:

• SHA-256 Symmetric encryption:

• AES-CBC with 256-bit keys
• AES-GCM with 256-bit keys

Message authentication:

• AES-CMAC with 128, 192, and 256-bit keys

Asymmetric:

• RSA sign and verify on 2048-bit and 4096-bit
• ECDSA sign and verify on P-256 and P-521

SHE (Secure Hardware Extension) Support:

The port exposes the SHE interface through a set of wc_SHE_* APIs. SHE defines a standardized key layout and a secure key-update protocol used widely in automotive applications. The port supports loading and updating SHE keys using the M1 through M5 memory-update protocol with M4 and M5 verification, applying SHE key-usage and protection flags such as CMAC usage and write protection, AES and CMAC operations using SHE-managed keys, and reading the device identity. SHE keys live inside the HSE key store and are operated on by handle, so the application never sees the raw key bytes.

Secure Key Storage with the HSE Key Store:

A central benefit of the HSE is its protected key store. Keys are organized into NVM and RAM key catalogs, then provisioned into specific groups and slots. Once a key is in the store, wolfCrypt refers to it through a key identifier rather than a buffer of key material. In the port, the hardware-backed paths use the wolfCrypt _Id initialization APIs, which tell wolfSSL to operate on a stored key instead of a software key in RAM. This keeps private keys inside the HSE for their entire lifetime. You can provision a key once, then sign, verify, encrypt, or compute a MAC with it indefinitely without ever loading it into application memory.

Multi-Threaded and Parallel Operation:

The port is built for concurrent use under an RTOS. By default it drives two Messaging Units in parallel, MU0 and MU1, each an independent request and response channel to the HSE. One thread can run AES-CBC on MU0 while another runs SHA-256 on MU1, so unrelated operations overlap instead of serializing through a single path. Each MU also exposes a pool of channels, where a channel is one in-flight HSE request, so multiple requests can be outstanding on the same MU at once. Responses are delivered by interrupt, and a requesting task yields to the scheduler while it waits, which keeps the core available to other work.

Benchmarks:

The HSE is first and foremost a security module. The reason to use it is hardware-isolated key storage and cryptographic execution, where private keys and secrets live inside the engine and are referenced by handle rather than ever appearing in application memory. Raw throughput is a secondary concern. The HSE Port accelerates a specific subset of operations: AES-256 in CBC and GCM, SHA-256, AES-CMAC, RSA, and ECC. The charts below cover only the HSE-accelerated operations. These numbers were captured with the wolfCrypt benchmark on an S32K344 (Cortex-M7 @ 48 MHz) using 1024-byte blocks.

Public key operations (HSE-accelerated):

AES:

Hashing and message authentication:

Questions? 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

AI-based code analysis tools are advancing rapidly, but questions remain about their effectiveness when applied to highly reviewed security-critical software.

Join wolfSSL and AISLE on June 11 at 9 AM PT for a technical discussion on AI-assisted vulnerability discovery. AISLE will share results from applying AI-assisted analysis to curl, followed by a technical review of findings identified within the wolfSSL codebase and discussion of how those results were evaluated.

This webinar will cover:

Applying AI-assisted analysis to security-critical open source software

Findings identified within the wolfSSL codebase

Technical review and evaluation of selected findings

Lessons learned from applying AI to vulnerability discovery

Ask the Experts: Answer Key Questions

Q: Can AI find issues in software that has already undergone extensive security review? A: Results generated from applying AI-assisted analysis to curl provide a practical example of how these tools perform on widely used security-critical software. Q: What findings were identified within the wolfSSL codebase? A: Findings identified through AI-assisted analysis, along with the technical evaluation used to assess their significance. Q: How should AI-generated security findings be interpreted? A: The process of investigating AI-generated results, distinguishing meaningful findings from noise, and understanding where human expertise remains essential.

  Register now: PQC Update 2026: Standards, Performance, and Migration Reality Date: June 11 | 9 AM PT

See what AI analysis uncovered when applied to real-world security-critical software.

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

Join us on June 9 at 9 AM PT for a practical update on the PQC landscape in 2026. We’ll review where standards stand today, compare real-world performance data, examine emerging deployment strategies, and discuss the challenges organizations are encountering as they begin migration efforts.

This webinar will cover:

PQC standards update: NIST, CNSA 2.0, and current IETF activity

Hybrid cryptography and current deployment approaches

PQC implementation status and support across the wolfSSL ecosystem

Performance analysis: ECC vs ML-KEM and ML-DSA benchmarking results

Migration challenges, interoperability concerns, and certification considerations

Ask the Expert: Answers the Key Questions

  Q: Are organizations deploying PQC today, or is it still too early? A: Hybrid cryptography is already being deployed as organizations gain operational experience while maintaining compatibility with existing infrastructure. Early deployments are helping teams understand migration requirements before broader adoption.

Q: How much performance impact should engineers expect from PQC? A: ML-KEM and ML-DSA introduce different performance and resource trade-offs than traditional ECC. We’ll review benchmark data and discuss what those differences mean for real-world deployments.

Q: How do organizations start PQC migration without breaking existing systems? A: Most organizations are adopting hybrid approaches that combine classical and post-quantum algorithms. This allows teams to gain operational experience while maintaining compatibility with current infrastructure.

  Date: June 9 | 9 AM PT Duration: 60 minutes

Register now for a practical look at the decisions, trade-offs, and challenges shaping PQC adoption in 2026.

As always, our webinar will include Q&A throughout. If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 452 8247.

Download wolfSSL Now

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

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:

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

####

• NSA, CNSA 2.0 Cybersecurity Advisory, September 2022
• NSA, CNSA 2.0 FAQ, December 2024 update
• NSA CSfC, Multi-Site Connectivity Capability Package v1.3.0, Section 5.13
• AMD, Zynq UltraScale+ MPSoC Software Developer Guide UG1137, Encryption
• wolfSSL, wolfBoot Secure Bootloader
• wolfSSL, wolfBoot Manual: Post-Quantum Signatures

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

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:

**BootROM:** Use the strongest AMD secure-boot configuration available: RSA authentication plus encrypted FSBL.

**FSBL:** Keep this stage small, static, and reviewable. Avoid placing mission policy or update authority here.

**wolfBoot:** Verify the next image using a CNSA 2.0-approved PQC signature.

**Runtime handoff:** Boot only images that pass PQC verification and rollback checks.

**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:

Acknowledge the ZynqMP BootROM limitation: FSBL authentication is RSA-4096.

Preserve AMD secure boot: encrypted FSBL and protected AES key storage.

Minimize pre-PQC code: keep the FSBL small and static.

Enforce PQC with wolfBoot: LMS, XMSS, or ML-DSA-87 verification.

Protect updates: anti-rollback, signed metadata, and recovery behavior.

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

NSA, CNSA 2.0 Cybersecurity Advisory, September 2022 NSA, CNSA 2.0 FAQ, December 2024 update NSA CSfC, Multi-Site Connectivity Capability Package v1.3.0, Section 5.13 AMD, Zynq UltraScale+ MPSoC Software Developer Guide UG1137, Encryption wolfSSL, wolfBoot Secure Bootloader wolfSSL, wolfBoot Manual: Post-Quantum Signatures

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

Post-Quantum Secure Boot on a Cost-Constrained Part

Embedded devices manufactured today will be in the field when large-scale quantum computers arrive. The signature algorithm chosen for the boot chain at manufacturing time effectively decides whether firmware updates can still be trusted a decade later. The KL26 is a deliberately constrained target for that conversation: a Cortex-M0+ at 48 MHz with 128 KB of flash, 16 KB of SRAM, no DSP instructions, no TrustZone, and no crypto accelerator. If post-quantum secure boot can run there, it can run on most of the embedded fleet that already ships. The KL26 port includes a working configuration based on LMS (Leighton-Micali Signatures, RFC 8554, NIST SP 800-208), one of the two NIST-approved stateful hash-based post-quantum signature schemes.

What’s in the Port

Three example configurations ship with the port:

• kinetis-kl26.config – ECC256 over SHA256 (classical signatures)
• kinetis-kl26-lms.config – LMS over SHA256 with the production parameters L=1, H=20, W=8 (1,048,576 lifetime signatures, 1776-byte signature, multi-minute initial keygen)
• kinetis-kl26-lms-small.config – LMS with L=1, H=10, W=8 (1,024 signatures, 1,456-byte signature, sub-second keygen) for development and other situations where the H=20 cost is not warranted.

All three have been exercised end-to-end on hardware, including the firmware update protocol with a v2 signed image, partition swap, and rollback verification.

Resource Footprint on the Chip

Measurements taken on the FRDM-KL26Z:

Notably, LMS comes in lighter than ECC256 on both code size and peak stack: its iterative SHA256 hashing has a smaller per-frame working set than ECC’s big-number Montgomery routines, and the verifier itself is more compact. The ~3KB ECC advantage in static RAM is a layout consequence: LMS forces 4KB logical sectors to fit its larger image header, which sizes wolfBoot’s NVM_CACHE buffer accordingly.

Try It

Documentation for the KL26 port is in docs/Targets.md under the “NXP Kinetis KL26Z” section, including SDK setup, OpenSDA-to-J-Link reflash instructions, and a full firmware-update walkthrough. For questions, custom integration work, or other targets, please contact us at facts@wolfssl.com or call us at +1 425 245 8247. Download wolfSSL Now

Post-Quantum Built In

wolfCOSE is the only embedded C COSE library with native post-quantum signatures. ML-DSA (FIPS 204) at all three security levels (ML-DSA-44, ML-DSA-65, ML-DSA-87) is built in, not patched on. The COSE ML-DSA draft is at the RFC Editor queue. Algorithm IDs -48, -49, -50 track toward standardization.

40 Algorithms, All Six COSE Types

• ChaCha20-Poly1305 is available in wolfCOSE but is not FIPS-approved. AES-GCM is the FIPS-compliant AEAD path.

The full algorithm set compiles at 25.6 KB .text. A minimal Sign1+ECC build is 7.5 KB, with zero .data and zero .bss.

Fits Embedded Targets

wolfCOSE uses no dynamic allocation. Every API takes caller-provided buffers. Stack crypto material is zeroized on every exit. A full COSE lifecycle (key decode, sign, encode, verify) runs in under 1 KB RAM. The library is MISRA C:2012 and C:2023 checked. CI runs Coverity, ASan, UBSan, and 15 workflows including a nightly wolfSSL-versions compatibility matrix. Code coverage is 99.3% on wolfcose.c and 100% on wolfcose_cbor.c.

Built on wolfCrypt

wolfCOSE’s sole dependency is wolfCrypt. That is the same FIPS 140-3 validated core (#4718) used across the wolfSSL product line. wolfCOSE firmware manifests can be verified by wolfBoot during secure boot. COSE-encrypted IoT messages can flow through wolfMQTT. The full stack sits within the Full Linux FIPS programme, all under the same wolfCrypt FIPS boundary. wolfCOSE includes a purpose-built CBOR engine (502 lines, 2.7 KB .text). No second CBOR library is needed.

Build Instructions

wolfCOSE requires wolfSSL 5.8.0 or later. Build wolfSSL first:

# wolfSSL with ECC + AES-GCM + SHA-384/512 + keygen
./configure --enable-ecc --enable-aesgcm \
            --enable-sha384 --enable-sha512 --enable-keygen
make && sudo make install

For PQC support, add –enable-mldsa. Then build wolfCOSE:

git clone https://github.com/wolfSSL/wolfCOSE

Get wolfCOSE on GitHub at github.com/wolfSSL/wolfCOSE. The library is GPLv3 or commercial. Contact facts@wolfssl.com for production support or an official wolfSSL product commitment.

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

A TPM for Environments Without Hardware TPM Support

The fTPM is a full software TPM 2.0 built on wolfCrypt. It exists for the systems where a discrete TPM chip is not an option: spacecraft and aerospace avionics, under-hood and high-vibration automotive electronics, and other thermal, radiation, or mechanical extremes that fall outside the ratings of a packaged TPM, as well as devices that simply ship without TPM silicon. In those systems, the TPM runs as software on a qualified SoC or companion MCU.

An Authenticated, Encrypted Link to the TPM

When the TPM is software reachable over an internal bus or socket, SPDM (DMTF DSP0274) authenticates the endpoint and wraps every command and response in an encrypted, integrity-protected session. For a firmware TPM in a safety-critical system, that raises the assurance level of the link: the TPM answers an authenticated session rather than anything that can reach the bus. SPDM layers on top of the TPM’s own protections rather than replacing them.

TCG Certificate and PSK Modes

The responder is exposed through the wolfSPDM_Resp* API and driven by the fTPM server. It negotiates SPDM 1.3 with Algorithm Set B (P-384, SHA-384, AES-256-GCM) and implements the full handshake in both modes: version, capability, and algorithm negotiation; the TCG certificate KEY_EXCHANGE / FINISH using a P-384 identity key generated at startup; the DSP0274 PSK exchange; the encrypted secured envelope; and VENDOR_DEFINED tunneling of TPM 2.0 commands. Vendor wire-format adapters for Nuvoton and Nations are available, with a runtime –vendor switch for dual-vendor builds.

Once SPDM-only mode is locked, the responder rejects plaintext TPM 2.0 frames with TPM_RC_DISABLED, matching how real Nuvoton and Nations silicon behave, so no unauthenticated command reaches the TPM.

Building and Testing

./configure --enable-fwtpm --enable-spdm --enable-tcg --enable-psk
# optional vendor wire-format adapters:
#   --enable-nuvoton  --enable-nations   (runtime --vendor switch)

CI exercises the responder in software and on hardware. spdm-test.yml runs 8 build-only configurations plus 2 end-to-end modes, and the responder unit tests drive the requester and responder back-to-back across PSK, TCG, TCG+PSK, Nuvoton, and Nations. hw-spdm-test.yml keeps coverage on real silicon, so the same handshake runs in software and against hardware.

wolfTPM is dual-licensed (GPLv2+ or commercial); the source is in the public wolfSSL/wolfTPM repository.

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

This brings wolfSSL’s portable, open-source HSM framework to Infineon’s next-generation AURIX platform, the successor to the widely deployed TC3xx family.

Why AURIX TC4xx?

Infineon’s AURIX™ TC4xx is the next generation of the TriCore family, purpose-built for the most demanding automotive and industrial workloads — from electrification and ADAS to next-generation ECUs and gateways. It pairs high-performance multicore TriCore processing with functional safety and a dedicated, hardware-isolated HSM core for security. That combination of performance, safety, and built-in secure processing makes the TC4xx an ideal foundation for a modern, hardware-backed HSM application — and a natural next home for wolfHSM.

Built on a Proven Foundation

The TC4xx port is aligned with our field-proven TC3xx port. That means the same client-server architecture, the same wolfCrypt-backed cryptography, and the same developer experience teams already know from TC3xx — now carried forward to the new silicon.

If you’re familiar with wolfHSM on the AURIX TC3xx, you’ll feel right at home. The wolfHSM server runs on the secure HSM core, and your TriCore application links against the wolfHSM client library to offload all sensitive cryptographic operations to the HSM core as remote procedure calls — with no additional logic required in your application. Sensitive data never leaves the HSM’s isolated memory.

Why wolfHSM on TC4xx?

**Automotive HSM use cases:** secure boot, key storage, secure diagnostics, and OTA updates.

**Industrial HSM environments:** factory provisioning, secure communications, and machine authentication.

**Crypto agility and post-quantum readiness:** leverage any algorithm wolfCrypt supports, including post-quantum options like ML-DSA, ML-KEM, LMS, and XMSS — all under the protection of the HSM core.

**No vendor lock-in:** an open-source foundation you can tailor to your exact use case, with a roadmap toward FIPS 140-3 and CNSA 2.0 compliance.

What’s Next: wolfBoot

The wolfHSM port is just the first step. Next up, we’re bringing wolfBoot to the TC4xx, mirroring the complete solution we already deliver on the TC3xx. With wolfBoot and the wolfHSM server running together on the AURIX HSM core, the entire boot chain gains a hardware-backed root of trust — only cryptographically authenticated firmware runs, across both the HSM and TriCore domains.

Want In?

With wolfHSM support for the AURIX TC4xx and wolfBoot on the way, we’d love to hear from teams building their next platform on it. Interested in early access or collaboration?

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

Download wolfSSL Now