Post-quantum cryptography
The headline feature in 2.1.0 is post-quantum support. wolfPKCS11 now supports both ML-DSA, the FIPS 204 signature scheme formerly known as Dilithium, and ML-KEM, the FIPS 203 key encapsulation mechanism formerly known as Kyber. ML-DSA support includes CKA_SEED based private key import, and the mechanism and identifier naming has been finalised to match the standardised algorithms.

With these additions, applications using wolfPKCS11 as their PKCS#11 provider can begin moving signing and key-establishment workflows onto quantum-resistant algorithms through the same standard interface they already use, with no change to the underlying integration model.

CMake build support and API documentation
Building wolfPKCS11 is now easier to fit into modern toolchains. This release adds a full CMake build system alongside the existing Autotools setup, and ships the CMake package configuration in the Debian -dev package so downstream projects can consume it cleanly.

We have also added Doxygen API documentation covering the PKCS#11 interface, giving developers a browsable reference for the supported functions, mechanisms, and attributes.

PKCS#11 specification compliance
A large part of this release is dedicated to closing compliance gaps against the PKCS#11 specification, many of them surfaced through negative testing and static analysis. Highlights include correct handling of CKR_OPERATION_ACTIVE, enforcement of CKA_EXTRACTABLE when wrapping a key, fixes to the SHA-512 truncated forms (SHA-512/224 and SHA-512/256), and a correction to CK_ULONG length truncation in C_GenerateRandom and C_SeedRandom. Several attribute defaults were also corrected to match the specification, along with the related C_DeriveKey, C_CopyObject, C_DestroyObject, encapsulation, and C_Login enforcement behaviour.

Upgrading from 2.0
Because some of these corrections change default attribute values, applications and stored tokens created against 2.0 may see different behaviour after upgrading. The pre-2.1 behaviour can be restored at build time using the following defines:

• WOLFPKCS11_LEGACY_COPYABLE_FALSE_DEFAULT restores the old behaviour where an unset CKA_COPYABLE reads back as CK_FALSE (the PKCS#11 default is CK_TRUE).

• WOLFPKCS11_LEGACY_PRIVATE_FALSE_DEFAULT restores the old behaviour where an unset CKA_PRIVATE reads back as CK_FALSE for private and secret keys, and disables the matching login-state check on object creation (the PKCS#11 default is CK_TRUE).

• WOLFPKCS11_LEGACY_WRAP_TRUE_DEFAULT restores the old behaviour where an unset CKA_WRAP or CKA_UNWRAP defaults to CK_TRUE (the PKCS#11 default is CK_FALSE).

We recommend testing against the new, spec-compliant defaults where possible, and reserving the legacy defines for cases where existing tokens or applications depend on the old values.

Memory safety and hardening
This release resolves a broad set of compliance and static-analysis findings identified by Fenrir, our internal code-scanning tooling, along with fixes for resource leaks and secure buffer erasing, as well as a number of smaller correctness issues.

Testing, CI, and interoperability
To keep these improvements locked in, we have expanded the test and CI coverage considerably. New work includes negative testing and validation across the API, a multi-call HMAC regression test, a C_VerifyRecover test, an interoperability test against wolfSSL master, and a wolfBoot integration test to catch regressions early. CI now also covers C++ builds, applies per-job timeouts across all workflows, and has been updated to track upstream dependency changes.

With thanks
Our thanks go to Denis Mingulov for contributing the C_GenerateRandom and C_SeedRandom length-truncation fix, and for reporting several of the issues addressed in this release.

Get the release
wolfPKCS11 2.1.0 is available now. You can find the full changelog and download the release from the wolfPKCS11 GitHub releases page, or clone the repository directly for source access and integration.

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

What is COSE?
COSE (CBOR Object Signing and Encryption) is the compact, binary counterpart to JOSE/JWT. Where JOSE secures JSON, COSE secures CBOR, the concise binary data format used across IoT, firmware update (SUIT), attestation (EAT), W3C WebAuthn, and digital credentials. COSE is the cryptographic message format of choice when every byte and every allocation counts, which makes it a natural fit for the constrained devices wolfSSL has always targeted.

A complete COSE implementation
wolfCOSE 1.0.0 implements all six COSE message types from RFC 9052, in both single-actor and multi-actor forms:

• COSE_Sign1 / COSE_Sign: single-signer and multi-signer signatures

• COSE_Encrypt0 / COSE_Encrypt: single-recipient and multi-recipient encryption

• COSE_Mac0 / COSE_Mac: single-key and multi-recipient authentication

It ships with its own dependency-free CBOR engine (RFC 8949) that enforces deterministic/preferred encoding and rejects non-preferred or trailing input on decode, plus full COSE_Key / COSE_KeySet serialization, including complete RFC 8230 RSA private keys.

40 algorithms, including post-quantum
wolfCOSE 1.0.0 supports 40 algorithms across signing, encryption, MAC, and key distribution (RFC 9053):

• Signing: ES256/384/512, EdDSA (Ed25519/Ed448), PS256/384/512

• Encryption: AES-GCM (128/192/256), AES-CCM variants, ChaCha20-Poly1305

• MAC: HMAC-SHA256/384/512, AES-MAC

• Key distribution: Direct, AES Key Wrap, ECDH-ES + HKDF

• Post-quantum: ML-DSA-44/65/87

Of particular note is standardized post-quantum signing: wolfCOSE implements ML-DSA (FIPS 204) at all three security levels, conformant to RFC 9964 (“ML-DSA for JOSE and COSE”), using the RFC 9964 AKP key type. This lets you sign and verify CBOR objects with quantum-resistant signatures today, using the canonical, standards-track encoding.

Built for embedded: zero allocation, tiny footprint
wolfCOSE was designed from the start for deeply embedded use:

• Zero dynamic allocation. Every operation uses caller-provided buffers, with no heap and no hidden .data or .bss. Memory use is deterministic, which matters for safety-critical and FIPS deployments.

• Tiny footprint. An ES256 COSE_Sign1 build is roughly 5.1 KB verify-only and 6.8 KB sign + verify for the wolfCOSE COSE + CBOR engine.

• Lean configuration layer. WOLFCOSE_LEAN, WOLFCOSE_HAVE_* feature gates, verify-only profiles, and a bounded-stack WOLFCOSE_MIN_BUFFERS mode let you compile in only what you need. Verify-only ECC images link cleanly against sign-disabled wolfCrypt.

Quality and standards

• Path to FIPS 140-3 through wolfCrypt FIPS Certificate #4718. wolfCrypt is wolfCOSE’s sole cryptographic dependency.

• MISRA C:2012 and C:2023 checked.

• Extensively tested: ~240 algorithm-combination round-trips, static analysis (cppcheck, Clang analyzer, GCC -fanalyzer, Coverity), CodeQL and Semgrep security scanning, ASan/UBSan sanitizers, and a wolfCOSE ? t_cose wire-interop conformance suite.

• Standards implemented: RFC 8949 (CBOR), RFC 9052/9053 (COSE), RFC 8230 (RSA keys for COSE), and RFC 9964 (ML-DSA for JOSE and COSE).

Getting wolfCOSE
wolfCOSE requires wolfSSL 5.8.0 or later as its crypto backend (post-quantum ML-DSA requires wolfSSL 5.9.2 or later). It is a Makefile-only project whose only dependency is wolfCrypt. Run make, make test, and you are running.

Source: https://github.com/wolfSSL/wolfCOSE
Release: https://github.com/wolfSSL/wolfCOSE/releases/tag/v1.0.0
Documentation: see the project README and wiki

wolfCOSE is dual-licensed under GPLv3 and a commercial license. If you are building a product and need commercial licensing, FIPS, or support, please reach out.

Have questions, or want to tell us about your COSE use case? Contact us any time at facts@wolfssl.com or support@wolfssl.com, or call +1 425 245 8247. We would love to hear what you are building.

Download wolfSSL Now

Vulnerabilities
This release addressed 32 CVEs in total, which is in line with the previously discussed trend of AI-driven CVE reporting. While this is an increase in absolute number over the previous release, it is important to note a few points:

• The number of [High] and [Critical] CVEs actually decreased.

• The time between releases 5.9.2 and 5.9.1 (~ 2 months) was larger than between 5.9.1 and 5.9.0 (< 1 month).

• The [High] CVEs this release were more narrow in scope, constrained mainly to specific OpenSSL compatibility API, or features that are disabled by default.

Use cases that are affected by [High] severity CVEs are: X509 verification with –enable-opensslextra with the API X509_verify_cert(), DTLS 1.3, the Renesas TSIP TLS port (WOLFSSL_RENESAS_TSIP_TLS) with TLS 1.3, X509 chain validation with Raw Public Key support (HAVE_RPK), and the OpenSSL compatibility API PKCS7_verify().

We would like to thank the many researchers from teams at NVIDIA Project Vanessa, Anthropic, UC Berkeley Sky Lab, as well as all the many independent contributors who responsibly disclosed these vulnerabilities.

See our wolfSSL Vulnerability page for the full list.

New Features

• wolfCrypt SRAM PUF (Physically Unclonable Function) support, deriving device-unique keys from SRAM power-on state using a BCH fuzzy extractor and HKDF (wc_PufInit, wc_PufEnroll, wc_PufReconstruct).

• wolfCrypt SHE (Secure Hardware Extension) support for the SHE key management standard.

Security Hardening / Behavior changes

• FIPS 205 SLH-DSA: The SLH-DSA sign/verify hash APIs now take a pre-hashed message digest instead of a raw message (callers must now hash the message before invoking these APIs). This brings SLH-DSA’s behavior in line with ML-DSA’s wc_dilithium_{sign,verify}_ctx_hash API, as well as NIST’s ACVP signature interface.

• FIPS 204 ML-DSA: We renamed the post-quantum signature implementation from its pre-standardization name Dilithium to its NIST-standardized name ML-DSA (mirroring the earlier Kyber to ML-KEM rename). The header wolfssl/wolfcrypt/dilithium.h remains for now as a temporary compatibility shim.

• Our CmacVerify APIs were hardened to more closely conform to NIST SP 800-38B MAC length guidance, and these verify functions will now correctly enforce bounds on tag length checks.

• RSA-PSS decoding was hardened to better conform to RFC 8017 A.2.3 guidance on trailer bits.

Crypto Callbacks

• Added WOLF_CRYPTO_CB_SETKEY and WOLF_CRYPTO_CB_EXPORT_KEY generic crypto callback utilities.

• Added wc_swdev, a software CryptoCb device used by our test programs to exercise WOLF_CRYPTO_CB_ONLY_* builds.

• Added WOLF_CRYPTO_CB_ONLY_SHA512 support.

• Added CryptoCb support for SLH-DSA.

• Added crypto callback support for LMS and XMSS (crucial to their stateful management!).

• Added support for zeroizing AES session keys in TLS 1.3 with WOLF_CRYPTO_CB_AES_SETKEY.

Post Quantum Cryptography

• Added SHA-512 DRBG and FIPS module-boundary wrappers for ML-KEM, ML-DSA, LMS, XMSS, and SLH-DSA as part of the upcoming post-quantum FIPS submission.

• Added support for RFC 9802 LMSS / XMSS in X.509 certificate and CSR generation.

• Added ML-KEM support for PKCS11.

Hardware and Embedded Ports

• Added NXP LPC55S69 hardware crypto support.

• Added STM32U3 hardware crypto support.

• Added Zephyr 4.3 default TLS-socket support.

Rust Wrapper

• Added Rust crate trait implementations for: rand_core, aead, and cipher, digest and signature, and password-hash, kem, and mac.

• Added scrypt KDF and RSA-OAEPsupport.

Pruning / Cleanup

• The liboqs integrations for ML-KEM and ML-DSA were removed.

• The liboqs SPHINCS+ implementation was replaced with our own SLH-DSA.

• The external liblms / libxmss integrations were removed (we’ve had our own more performant implementations for a while).

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

I'm testing wolfMQTT on an embedded device that uses a cellular connection. When the network drops briefly and the client reconnects, I occasionally receive duplicate MQTT messages that were originally published with QoS 1.

My application stores packet IDs and acknowledges messages correctly, but duplicates still appear after reconnection in some cases.

Does wolfMQTT provide any built-in mechanism or recommended approach for tracking and filtering duplicate QoS 1 messages across reconnect events, especially when using persistent sessions (clean session disabled)?

If anyone has implemented this successfully on resource-constrained devices, I'd appreciate hearing about your experience.

Thanks!

I can see this is something to do with wolfSSL_SetIOWriteCTX(), but I'm not entirely sure what value to use - I'm a novice with wolfSSL.

Are there specific values I should set to link the two components together?

Highlights:

• Chimera (dual-algorithm) certificates. wolfCLU can now generate Chimera certificates carrying both a conventional and a post-quantum signature on a single X.509 cert, so one certificate satisfies both classical and PQC-aware verifiers. (PR 182, @Yu-Ma28051503)

• OCSP client and responder. New OCSP client and responder, both with HTTP and SCGI transports. SCGI lets the responder be fronted by nginx in production. (PR 200, @julek-wolfssl)

• Cross-platform Python tests. The shell-based test suite was ported to Python (unittest), so it now runs on Windows in addition to Linux and macOS. (PR 215, @julek-wolfssl)

• Explicit key files for enc. The enc command now accepts an explicit key file instead of deriving the key from a password. (PR 224, @embhorn)

Security Hardening:
A large set of fixes from static analysis using wolfSSL internal Fenrir project: out-of-bounds writes in argv processing, a stack buffer overflow in encryption setup, a shell command injection, a use-after-free, a potential double-free, a heap buffer over-read, plus numerous null-pointer and sanity-check fixes across command and init paths. (PRs 202–223; @miyazakh, @aidangarske, @JacobBarthelmeh, @yosuke-wolfssl, and others)

Other Changes:
ML-DSA sign/verify now passes a context for OpenSSL interop (PR 195), the post-quantum groups list was updated to match the latest wolfSSL (PR 209), and there were assorted fixes to the enc, pkey, req, and ECC sign/verify paths along with expanded test coverage and README updates. See the full commit log for details.

Download wolfCLU now and contact facts@wolfssl.com for any 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

What is PSA?
PSA, or Platform Security Architecture, defines standard interfaces for security services used in embedded systems. In practice, PSA gives applications, RTOSes, secure firmware, and test frameworks a common way to request cryptography and attestation services without tying the application to one specific secure-world implementation.

wolfPSA provides this compatibility layer on top of wolfCrypt. It acts as a PSA Crypto engine interface for operations such as random generation, key management, hashing, MAC, cipher, AEAD, signatures, key agreement, and key derivation. It also exposes the PSA Initial Attestation interface expected by PSA-based systems, helping projects build against a standard API surface while relying on wolfSSL components underneath.

What is included in wolfPSA 5.9.1?
wolfPSA 5.9.1 is the initial public wolfPSA release and follows the wolfSSL 5.9.1 version numbering. This release includes:

• PSA Crypto API entry points implemented in C on top of wolfCrypt

• Static and shared builds: libwolfpsa.a and libwolfpsa.so

• PSA lifecycle, RNG, key management, persistent key storage, cipher, AEAD, hash, MAC, asymmetric crypto, key derivation, and TLS 1.3 PRF/HKDF support

• Algorithm coverage including AES, ChaCha20, ChaCha20-Poly1305, SHA-1/SHA-2/SHA-3, HMAC, CMAC, RSA, ECC/ECDSA/ECDH, Curve25519/Curve448, Ed25519/Ed448, and configured compatibility options

• Integration points for post-quantum and hash-based algorithms when enabled in wolfCrypt, including ML-KEM, ML-DSA, LMS, and XMSS

• Standalone tests and demos, including PSA API calls, PSA-backed wolfCrypt benchmarking, and TLS examples using PSA-managed keys

First demo use case: wolfBoot secure domain + Zephyr
One of the first application-side integration cases for wolfPSA is the wolfBoot TrustZone-M secure domain work for Zephyr.

In this model, wolfBoot runs in the ARMv8-M secure world and provides the secure boot, firmware update, and secure service boundary. wolfPSA is hosted inside that secure domain, while Zephyr runs in the non-secure world and calls PSA Crypto APIs through the wolfBoot-backed TEE/NSC interface.

This demonstrates wolfPSA as more than a standalone library: it becomes a compatibility layer for PSA-aware applications and RTOS environments, while allowing wolfBoot and wolfCrypt to anchor the cryptographic boundary in the secure domain.

Availability
wolfPSA 5.9.1 is available now. It is designed for teams building PSA-compatible embedded systems, Zephyr TrustZone designs, secure boot chains, and products that want wolfCrypt-backed cryptography behind a standard PSA-facing API.

For questions about wolfPSA, wolfBoot secure-domain integration, licensing, or commercial support, contact us at facts@wolfssl.com or call +1 425 245 8247.

Download wolfSSL Now

New JCE Functionality:

• Add Cipher RSA/ECB/OAEPWithSHA-256AndMGF1Padding support

• Add Cipher RSA/ECB/OAEPWithSHA-1AndMGF1Padding support

• Add Cipher WRAP_MODE and UNWRAP_MODE support for RSA-based key wrapping

• Add PKIX CertPathBuilder implementation using native wolfSSL X509_STORE

• Add jdk.certpath.disabledAlgorithms enforcement to CertPathBuilder and CertPathValidator

• Register default FIPS error callback in WolfCryptProvider for FIPS error debugging

• Enrich WolfCryptException with FIPS module status for FIPS_NOT_ALLOWED_E errors

• Add Java 9+ module support (JPMS) for jlink compatibility

New JNI Functionality:

• Add hex string conversion via WolfCrypt.toHexString() and WolfCrypt.hexStringToByteArray()

• Add PEM to DER conversion support for keys and certificates

• Add setFlags() and setVerificationTime() methods to WolfSSLX509StoreCtx

New Property Support:

• wolfssl.skipLibraryLoad System property – Skip automatic System.loadLibrary() calls for advanced embedding scenarios

• wolfjce.ioTimeout System property – Configure OCSP/CRL IO timeouts

Bug Fixes & Reliability Improvements
Beyond the new features, version 1.10.0 includes a substantial set of bug fixes and reliability improvements focused on FIPS error visibility, cryptographic correctness, input validation, and memory safety:

• Fixed FIPS error callback lifecycle (including proper deregistration in JNI_OnUnload)

• Corrected Ed25519 signature length handling, RSA public-key flattening/export, unsigned return values, and pointer casts

• Added HMAC/ByteBuffer/offset-length bounds validation, improved NULL checks, and missing releaseByteArray() calls across ECC, RSA, ChaCha, and AES-GCM

• Implemented defensive copies of IV arrays, constant-time GMAC tag verification, secure zeroization of keys and buffers, and proper cleanup for AES-CTR/AES-OFB/GMAC

• Fixed signed integer overflow risks in bounds checks, DH key export paths, ECC private-key import curve handling, and reduced unnecessary WC_RNG allocations

• Expanded FIPS-compliant SecureRandom sanitization and fixed threaded MessageDigest hangs on FIPS errors

Expanded Testing & CI Infrastructure
CI coverage has been expanded with new workflows and modern platform support:

• Java 24 and 25 tests added to GitHub Actions workflows

• Linux 32-bit testing with Java 17 via GitHub workflow

• UndefinedBehaviorSanitizer (UBSan) GitHub workflow

• SpotBugs static analysis target and dedicated GitHub Actions workflow

• Android FIPS Ready automated emulator testing via GitHub workflow

• Java 9+ module (JPMS) testing workflow

• Improved JUnit test reliability for FIPS mode and CI environments

New Examples

• Added CertPathBuilder and CertPathValidator example demonstrating PKIX path building and validation with disabledAlgorithms enforcement

• Updated Android example project: migrated from jcenter() to mavenCentral() and AndroidX, added Gradle wrapper with distributionSha256Sum, JKS-to-BKS KeyStore conversion script for testing, and CMakeLists.txt exclusion list updates

wolfCrypt JNI/JCE 1.10.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfCrypt JNI/JCE User Manual can be found here. Full details on this release can be seen in the ChangeLog.md on GitHub. For any questions, or to get help using wolfSSL products in your projects, contact us at support@wolfssl.com.

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

New JSSE Functionality

• Pre-Shared Key (PSK) support – Full JSSE-level PSK via WolfSSLParameters for SSLSocket and SSLEngine (client and server).

• Java 9+ Module System (JPMS) support – Conditional module-info.java compilation for jlink compatibility.

• Trust and KeyStore enhancements — CertPathTrustManagerParameters and KeyStoreBuilderParameters now supported in WolfSSLTrustManager.

New JNI Functionality & Certificate APIs

• Extract SNI directly from a raw ClientHello buffer with WolfSSL.getSNIFromBuffer()

• RSA-PSS sign/verify and RSA sign-check PK callback support.

• Basic Constraints pathLen parameter in WolfSSLCertificate / WolfSSLCertRequest.addExtension().

• Full CRL generation and decode wrappers in WolfSSLCRL.

• Extended X.509 support:
  

  • SKID, AKID, CRL Distribution Points, and Netscape Cert Type extensions.

  • Name Constraints via new WolfSSLNameConstraints / WolfSSLGeneralName classes.

  • Extended AIA interface for separate OCSP and CA Issuer URL retrieval.

  • WolfSSLAltName class with full SAN parsing (including otherName for MS AD UPN, iPAddress, and directoryName).

New Configuration Properties

• wolfjsse.skipFIPSCAST Security property – Skip automatic FIPS CAST execution during wolfJSSE initialization.

• wolfssl.skipLibraryLoad System property – Skip automatic System.loadLibrary() calls for advanced embedding scenarios.

Bug Fixes & Reliability Improvements
This release includes numerous stability and compatibility fixes, particularly for SSLEngine and SSLSocket:

• Improved SSLEngine buffer handling (BUFFER_UNDERFLOW/OVERFLOW), close/shutdown state transitions, and handshake status reporting.

• Better SNI handling, session timeout behavior, and principal return types (X500Principal).

• Spring Boot and Netty compatibility improvements (SSLHandshakeException on handshake errors, SSLEngine(host, -1) support).

• Multiple null-pointer, memory-leak, and thread-safety fixes in native callbacks and FIPS error handling.

• Cipher suite filtering aligned with jdk.tls.disabledAlgorithms and TLS version configuration.

• Various edge-case fixes for PSK, certificate loading, and high file descriptor handling.

Expanded Testing & CI Infrastructure

• Static analysis – New SpotBugs build target and GitHub Actions workflow.

• Android FIPS Ready – Automated Android emulator testing via GitHub workflow.

• Sanitizers – UndefinedBehaviorSanitizer (UBSan) GitHub workflow.

• Linux 32-bit testing with Java 17 via GitHub workflow.

• Expanded test matrix support for Java 24 and 25.

• Module system and build verification – JPMS (Java Module System) testing workflow.

New Examples & Testing

• PSK client/server examples for both SSLSocket and SSLEngine.

• DualProviderFIPSTest demonstrating wolfJSSE + wolfJCE dual-provider FIPS usage.

• Updated Android example with TLS connection and FIPS error callback support.

wolfSSL JNI/JSSE 1.17.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfSSL JNI/JSSE User Manual can be found here. Full details on this release can be seen in the ChangeLog.md on GitHub. For any questions, or to get help using wolfSSL products in your projects, contact us at support@wolfssl.com.

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

• Firmware TPM (fwTPM) – a portable TPM 2.0 built on wolfCrypt.

• SPDM Secured Transport – encrypted host-to-TPM communication.

• ST33 TPM 2.0 Firmware Update – new update tool for STMicro ST33KTPM2X.

All three are powered by the same wolfCrypt engine trusted in FIPS 140-3 and DO-178C DAL A deployments.

Feature 1: Firmware TPM (fwTPM)
The fwTPM is a portable TPM 2.0 command processor. It is implemented entirely on top of wolfCrypt. It covers 105 of 113 commands in the TPM 2.0 v1.38 specification (93%). The full object, session, policy, attestation, PCR, and NV families are included.

Use it as a drop-in replacement for a discrete TPM chip. Or use it in CI as a replacement for external simulators like the Microsoft TPM simulator and IBM swTPM.

Why It Matters

• Reduce BOM and physical attack surface. Parts that never shipped with a TPM can now gain TPM services. No extra chip. No exposed bus.

• Portability. The same fwTPM runs on a Cortex-M in TrustZone, a dedicated RPU on an MPSoC, a hardened RISC-V core, or an FPGA soft core.

• Supply-chain integrity. Your TPM becomes part of your signed firmware image. No separate silicon vendor in the trust path.

• Same crypto you already trust. RSA, ECC, SHA-2/3, AES, and HMAC all come from the FIPS 140-3 wolfCrypt module, qualifiable to DO-178C DAL A for avionics.

Where fwTPM Runs

fwTPM is designed to live in an isolated execution environment. Proven homes include:

• Microchip PolarFire SoC (MPFS250T) – Run in FPGA with Mi-V RISC-V soft-core or run in a dedicated core (E51 Monitor or U54)

• Arm TrustZone-M. Reference port on STMicro STM32H5 (NUCLEO-H563ZI). TrustZone-M gives isolated code, data, flash, and crypto peripherals.

• AMD/Xilinx Zynq UltraScale+ MPSoC and Versal Gen 1 / Gen 2. Multiple deployment options on the same part: Arm TrustZone on the APU, a dedicated Cortex-R5F (UltraScale+) or R52 (Versal Gen 2) on the RPU, or a MicroBlaze V (RISC-V) soft core.

• AMD Spartan UltraScale+ (MicroBlaze V or Cortex-M1 soft core)

• Altera Agilex 5 (Nios V soft core). TPM functionality entirely inside programmable logic.

Integration

• Transports: Socket mssim or swtpm (auto detected), shared memory IO and register-level TIS for bare-metal SPI, I2C or UART.

• NV storage: File-backed on hosted systems. HAL callback for embedded flash. TLV journal format suits wear-levelled flash.

• Footprint knobs: Features can be disabled if not required to reduce code size. Attestation, Policy, NV, Credential, Dictionary Attack.

Feature 2: SPDM Secured Transport
When a TPM speaks to its host over a PCB trace, that trace is attackable. SPDM closes the gap. Commands and responses ride over a vendor-defined TCG channel. The channel is encrypted with AES-256-GCM and integrity-checked on every packet.

What’s New

• Vendors: Nuvoton NPCT75x and Nations Technologies NS350. (More coming soon)

• Session modes:
  

  • Identity-key mode over ECDH P-384, on both NPCT75x and NS350.

  • PSK mode on NS350.

• Auto-connect with SPDM-only lock-down. Once locked, wolfTPM establishes the encrypted session on every open. Plaintext commands are rejected.

• New spdm_ctrl utility. Full lifecycle: enable, disable, provision PSK, clear PSK, lock, unlock.

Why It Matters
Anywhere the TPM is physically accessible – servers in colocation, defense platforms, medical devices, industrial controllers, in-vehicle ECUs – SPDM closes the last-inch attack surface.

Feature 3: ST33 TPM 2.0 Firmware Update
STMicro’s ST33KTPM2X introduced a new Generation 2 firmware format using LMS signing. wolfTPM v4.0.0 adds the st33_fw_update example tool for supporting firmware updates on older Gen 1 and newer Gen 2 firmware versions. See examples/firmware/README.md for usage.

Other v4.0.0 Release Improvements

New HALs

• Raspberry Pi 4 hardware SPI

• U-Boot (tpm_io_uboot.c)

• Espressif ESP-IDF SPI

• Linux auto-detection between /dev/tpmX and direct SPI

Hardening

• Fenrir and Coverity findings addressed across tpm2_wrap, tpm2_packet, tpm2_asn, NV, session auth, SPDM, and fwTPM paths.

• ForceZero on every sensitive stack buffer.

• Constant-time export for ECDH shared secrets and ECC signature r/s.

• Short-circuit OR removed from all auth paths.

• Bounds checks and NULL-deref guards across ASN.1, PCR, and key-load code.

CI

• ASan and UBSan sanitizer jobs.

• Pedantic gcc and clang matrices.

• macOS and Windows fwTPM builds.

• Weekly libFuzzer plus per-PR smoke.

Coming Soon: TPM 2.0 v1.85 Post-Quantum

Right behind this release. Post-quantum algorithms from TPM 2.0 v1.85 are landing in both the fwTPM server and the wolfTPM client library:

• ML-KEM (Kyber) for key encapsulation

• ML-DSA (Dilithium) for signatures

Why now? Harvest-Now-Decrypt-Later (HNDL) mitigation for long-lived device identity keys. Deploy fwTPM today. Get a drop-in PQC upgrade path without respinning silicon.

Getting Started

git clone https://github.com/wolfSSL/wolfTPM.git
cd wolfTPM
git checkout v4.0.0
./configure --enable-fwtpm
make && make check

• Source and tag: https://github.com/wolfSSL/wolfTPM (tag v4.0.0)

• Changelog: ChangeLog.md

• fwTPM deep-dive: src/fwtpm/README.md

• SPDM deep-dive: src/spdm/README.md

• ST33 firmware update: examples/firmware/README.md

For commercial licensing, FIPS 140-3 integration, DO-178C DAL A qualification kits, custom HAL ports, or early access to the v1.85 PQC branch, contact facts@wolfssl.com or +1 425 245 8247.

Download wolfSSL Now

This release stands out for the breadth of hardware now supported. wolfBoot 2.8.0 adds or extends support for AMD/Xilinx Versal Gen 1 VMK180, Microchip PolarFire SoC MPFS250, NXP MCXN, MCXW71, S32K14x, LPC55S69, NXP T1040 RDB, refreshed T2080 configurations, and Nordic nRF54L15. For product teams working across multiple silicon families, wolfBoot continues to prove itself as a highly portable and consistent secure boot solution.

Version 2.8.0 also brings an important step forward for PSA-based designs. New support for wolfPSA secure storage, TrustZone-backed PSA services, PSA crypto, PSA attestation, and DICE-based attestation flows makes wolfBoot an even stronger foundation for modern embedded security architectures. With new Zephyr integration replacing the TEE layer through PSA-facing interfaces, this release opens up new options for developers building secure RTOS-based systems.

wolfBoot is now also available as complete secure boot + TEE (PSA) replacement for TrustZone systems running Zephyr OS.

On the product integration side, wolfBoot 2.8.0 adds a new generic hook framework for pre-init, post-init, and boot customization, along with custom encryption-key hooks, PKCS11-backed encrypted partitions, improved status and image-inspection tooling, monolithic self-update builds, and reproducible-build support. These improvements make it easier to adapt wolfBoot to real deployment requirements while keeping the codebase compact and focused.

Existing targets also benefit from substantial work in this release. Highlights include improved STM32H5 TrustZone and PKCS11 integration, external flash dual-bank updates on PSoC6, expanded AURIX TC3xx self-update and wolfHSM configurations, refreshed Renesas RA6M4 and RX projects, and better clang/LLVM support with dedicated CI coverage.

As always, security and reliability remain central. wolfBoot 2.8.0 strengthens image parsing, signing, and update flows with tighter checks and safer handling across signatures, TLVs, delta images, partition layouts, and storage I/O. It also expands constant-time operations and zeroization in sensitive paths, adds stricter rollback and flash-protection behavior, and fixes a range of regressions across supported architectures and simulator targets.

Updated modules

• wolfSSL: latest stable

• wolfTPM: latest

• wolfPKCS11: latest stable

• wolfHSM: latest

With 2.8.0, wolfBoot continues to grow as a practical, production-ready secure bootloader for embedded systems that need strong authentication, reliable updates, and portability across a rapidly expanding hardware landscape.

To learn more about wolfBoot, or to discuss secure boot and firmware update strategies for your platform, contact us.

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

Please see the ChangeLog.md for full details.

New Features
The headline addition in v1.5.0 is post-quantum key exchange via ML-KEM hybrid algorithms — mlkem1024nistp384-sha384 and mlkem768x25519-sha256 — based on draft-ietf-sshm-mlkem-hybrid-kex, with interoperability testing against OpenSSH running in CI. This brings wolfSSH in line with the industry direction toward quantum-resistant SSH.

On the algorithm side, client-side rsa-sha2-512 signature support has been added. The key type is now separated from the signature type, so ssh-rsa keys can be used with ssh-rsa, rsa-sha2-256, or rsa-sha2-512 signatures, improving compatibility with modern SSH servers that have deprecated the older scheme.

Two handy SFTP client usability improvements also landed: lcd and lls commands for managing the local working directory without leaving an SFTP session.

Improvements
Several handlers that previously lacked proper callback validation have been tightened: host key acceptance, channel open requests, TCP/IP forwarding, and DH group exchange parameters are all now gated and validated. Additional defensive constant-time comparisons were also applied.

Beyond hardening, SFTP reliability saw meaningful attention – better non-blocking behavior, improved error path handling, and more robust multi-byte password support. CI coverage was expanded significantly with new sanitizer builds, multi-compiler testing, and automated Coverity scanning.

Fixes
This release contains a large number of bug fixes driven by static analysis and code review. Highlights include a non-blocking SFTP server hang on WS_WANT_WRITE, Windows authentication issues, missing hash cleanup in RSA/ECC paths, and a variety of null-dereference, bounds-check, and memory-leak fixes throughout the codebase.

Download wolfSSH v1.5.0 from our download page, or clone it from GitHub.

If you have questions about wolfSSH or any of our other products, feel free to reach out at facts@wolfssl.com or support@wolfssl.com, or give us a call at +1 425 245 8247.

Download wolfSSL Now

Security Vulnerabilities Addressed
This release addresses 22 CVEs across critical, high, medium, and low severity levels. Notably, we have received many quality AI-assisted vulnerability reports this cycle. Thanks to all the researchers who responsibly disclosed issues, including teams from Anthropic, KENTECH, Calif.io, eWalker Consulting, and several independent contributors.

For the full list of vulnerabilities addressed, visit the wolfSSL Vulnerability Page.

Default Build Changes

• ML-KEM (FIPS 203) enabled by default — Post-quantum key encapsulation is now on by default, making it easier than ever to adopt quantum-resistant cryptography.

• ECC curve validation is now enabled unconditionally in default builds, removing the previous dependency on USE_ECC_B_PARAM.

New Features

• Brainpool curve support added to wolfSSL_CTX_set1_sigalgs_list for broader European cryptographic standard compatibility.

• DTLS 1.3 / TLS 1.3 write-dup support — Duplicate SSL functionality allows read-side delegation of post-handshake tasks (KeyUpdate, ACK, post-handshake auth) to the write-side.

Post-Quantum Cryptography Updates

• The context-aware FIPS 204 ML-DSA (Dilithium) API is now the default, with the legacy non-context API gated behind WOLFSSL_DILITHIUM_NO_CTX.

• Sensitive memory buffers in the ML-DSA implementation are now zeroized to prevent leakage of cryptographic material.

• Private key validation checks added for Ed25519, Ed448, ML-DSA, and ML-KEM operations.

• Buffer size and callback validation added to wc_LmsKey_Sign.

• Fixed out-of-bounds shift and undefined behavior issues in ML-DSA and SLH-DSA implementations.

TLS and DTLS Improvements

• Fixed DTLS 1.3 ServerHello to comply with the specification by not echoing legacy_session_id.

• Fixed TLS 1.3 server to correctly reject mismatched ciphersuites in second ClientHello after HelloRetryRequest.

• Resolved multiple correctness issues in DTLS 1.3 and TLS 1.3 including missing bounds checks, PSK identity buffer overreads, and resource leaks.

• HPKE implementation fixes and refactoring with tests for all 24 algorithm combination variants.

Hardware and Embedded Ports

• SE050 hardware security module integration fixes for RSA-PSS and persistent key slot management.

• Broad correctness improvements across Espressif, Renesas, Silicon Labs, NXP, STM32, TI, Xilinx, and other hardware targets.

• Fixed buffer overflows, key material exposure, mutex leaks, and logic errors across hardware crypto backends.

Rust Wrapper

• Released version 1.2.0 of the wolfssl-wolfcrypt Rust crate.

• Updated build script to support cross-compiling and bare-metal targets including RISC-V architectures.

Get the Update
We recommend all wolfSSL users update to version 5.9.1. Dive into the full ChangeLog for a complete list of changes.

Download wolfSSL 5.9.1

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

I’ve been reviewing the wolfSSL documentation and have tested the hybrid TLS 1.3 examples in C. On the native side, I was able to successfully compile wolfSSL with PQC_Hybrids and run the client/server examples using hybrid TLS 1.3 without any issues.

I’m new to this area, and I would like to achieve the same from Java using wolfSSL JNI. However, when checking the JSSE provider documentation, I only see references to classical algorithms, although there is also mention of the QSH (quantum-safe handshake) extension.

My questions are:
Is wolfSSL_PQC_Hybrids currently supported through wolfssl-jni-jsse?
Is the QSH extension compatible with TLS 1.3 from Java?
If not, are there any plans to expose hybrid key exchange groups in the JNI wrapper?

Any guidance would be greatly appreciated.

Why wolfIP
Traditional TCP/IP stacks often bring in dynamic allocation, background processing, and broader feature sets than many embedded endpoints actually need. That flexibility can be useful in general-purpose systems, but it also makes worst-case timing, memory usage, and verification harder to bound. wolfIP takes a different approach. It is designed as a tiny, deterministic stack with compile-time configured resources, a fixed socket count, static RX/TX packet buffers, and no hidden runtime allocation. That makes it a strong fit for constrained devices, controlled deployments, and projects with demanding review, testing, or certification workflows.

What is included in 1.0.0
The 1.0.0 release delivers a solid IPv4 networking foundation for embedded endpoints. Core support includes Ethernet II, ARP, IPv4, ICMP, UDP, TCP, DHCP client, and DNS client, along with modern TCP capabilities such as MSS, timestamps, PAWS, window scaling, retransmission timeout handling, SACK, slow start, congestion avoidance, and fast retransmit. wolfIP 1.0.0 also includes HTTP/HTTPS server support, IPsec ESP transport mode, IP filtering with wolfSentry integration, native wolfGuard support, and optional IPv4 forwarding for multi-interface builds.

That combination is important because it gives developers more than just a packet pipe. wolfIP 1.0 starts with the network services many connected devices actually need, then adds security-focused integration points across the wolfSSL ecosystem. Developers can combine wolfIP with wolfSSL for TLS 1.3-protected applications, wolfSentry for filtering and policy enforcement, and wolfGuard where a tightly integrated secure tunnel model is needed. For teams building secure connected products, that means a more cohesive networking and security story from a single vendor and codebase family.

Small footprint, practical deployment model
wolfIP is positioned as a small embedded-first stack, and the official product material describes the core as roughly 4× smaller than lwIP’s core. Just as important, wolfIP’s architecture is intentionally narrow and easier to analyze: deterministic memory usage by default, fixed compile-time resources, and an endpoint-focused design rather than a broad general-purpose routing stack. For organizations thinking about code review effort, qualification scope, or long-term maintenance, reducing moving parts matters.

From POSIX testing to embedded targets
One of the most useful aspects of wolfIP 1.0 is its portability across development and deployment environments. The release includes integration layers for wolfSSL, wolfSSH, wolfMQTT, a POSIX LD_PRELOAD socket interception path via libwolfip.so, and a FreeRTOS BSD socket wrapper. The repo also documents host-side testing through TAP-style interfaces and lists host link driver support for Linux TAP/TUN, Darwin utun, FreeBSD TAP, and VDE2, alongside embedded ports for targets including STM32H753ZI, STM32H563, STM32N6, VA416xx, and Raspberry Pi Pico USB networking demos. That is a practical release story: developers can exercise the stack on desktop-class environments, then carry the same architecture into embedded deployment.

Built to Work Naturally with wolfSSL
wolfIP is especially compelling when paired with the rest of the wolfSSL portfolio. The product page highlights seamless TLS 1.3 integration with wolfSSL, and the repository documents HTTPS server support with wolfSSL TLS backing. For engineering teams that already trust wolfSSL in embedded and RTOS environments, wolfIP extends that same design philosophy down into the transport layer: compact code, explicit resource control, and predictable behavior. Instead of stitching together unrelated networking and crypto components, developers can build on a tightly aligned stack designed for constrained and security-conscious systems.

Available Now
wolfIP 1.0.0 is available now under the GPLv3 open source license. If you are building connected embedded devices and need a TCP/IP stack with bounded memory usage, deterministic behavior, and straightforward integration with wolfSSL security products, wolfIP is well worth a look. Download the latest release, review the changelog, and contact us to discuss commercial licensing, support, or how wolfIP fits into your next embedded networking design.

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