Ever had a device in the field reject a firmware update or roll back to an older image, with no clue why? wolfBoot can now tell you. With the new WOLFBOOT_PERSIST_FAILURE_STATUS option, wolfBoot records the cause of every update, self-update and rollback failure into a dedicated flash region, so your application can read it back […]
Read MoreMore TagCategory: Uncategorized
wolfIP Comes to NXP QorIQ Bare-Metal
NXP QorIQ is a family of networking-focused processors built on PowerPC and ARM Layerscape cores, ranging from dual-core parts up to many-core SoCs. Each integrates Ethernet, packet acceleration, and hardware security, and they ship in networking, aerospace, defense, and industrial systems. We have brought wolfIP, our compact TCP/IP stack, to the NXP QorIQ family running […]
Read MoreMore TagwolfBoot as the Xilinx ZynqMP FSBL: a full-featured secure first-stage replacement
wolfBoot can now run as the First Stage Boot Loader (FSBL) on Xilinx ZynqMP, replacing the stock Xilinx FSBL entirely. On a ZCU102 (xczu9eg) the BootROM hands control straight to wolfBoot in on-chip memory (OCM) at EL3; wolfBoot brings up the processing system, verifies a signed image with its own keys, and boots Linux to […]
Read MoreMore TagPost-Quantum Signatures for Signed Messages: ML-DSA in PKCS#7
wolfSSL’s PKCS#7/CMS implementation has long produced and verified SignedData with the signature algorithms you’d expect — RSA and ECDSA. It now speaks post-quantum as well: PKCS#7 SignedData can be signed and verified using ML-DSA, the Module-Lattice-Based Digital Signature Algorithm standardized by NIST in FIPS 204 (formerly CRYSTALS-Dilithium). The encoding follows the conventions the IETF LAMPS […]
Read MoreMore TagwolfSSH now supports X.509 host certificates with TPM-backed keys: Certificate-based host authentication with private keys sealed in hardware
The problem When an SSH client connects to a server, it needs to know it is talking to the real server and not an attacker in the middle. Classic SSH handles this with a raw host key that the client remembers on first connection. That works for a single machine, but it does not scale […]
Read MoreMore TagHow To Build wolfSSL + CAAM on i.MX7 with Yocto Linux?
The NXP CAAM (Cryptographic Accelerator and Assurance Module) supports offloading cryptographic operations for acceleration along with heightened security. wolfSSL supports accessing the hardware acceleration in many different operating environments, such as with QNX or NXP’s Yocto Linux builds. For QNX builds wolfSSL has targeted specific i.MX devices, check with our manual or support channel to […]
Read MoreMore TagwolfSSL Intel QuickAssist (QAT) Performance Improvements
wolfSSL’s asynchronous crypto offloads public-key, cipher, and hashing work to Intel QuickAssist (QAT) hardware. This update (PR #10772) makes that offload use every QAT device in a multi-adapter system, and hardens it for multi-process and CI use. The problem: idle devices Each worker thread binds to one QAT crypto instance, and the driver hands back […]
Read MoreMore TagwolfSSL TLS with Hardware-Bound Keys on the RealTek RTL8735B (AmebaPro2)
The RealTek RTL8735B (AmebaPro2) is an Arm Cortex-M33 AIoT SoC with a hardware crypto engine and, importantly, a per-device Hardware Unique Key (HUK) fused into the silicon. The HUK never leaves the chip and cannot be read by software. That makes it an ideal root from which to derive keys that are bound to one […]
Read MoreMore TagAnnouncing wolfTPM v4.1.0
wolfTPM v4.1.0 delivers the post-quantum upgrade path we promised in v4.0.0, alongside a major round of firmware TPM (fwTPM) hardening. It delivers three headline capabilities: TPM 2.0 v1.85 Post-Quantum Cryptography: ML-DSA and ML-KEM native and in the fwTPM. fwTPM Hardening: Dictionary Attack protection to the TCG spec, SPDM secured transport, and session, policy, and NV […]
Read MoreMore TagTightening OCSP Responder Authorization for RFC 6960 Compliance
wolfSSL has removed CheckOcspResponderChain(), a non-compliant chain walk that authorized any OCSP responder certificate issued by any ancestor of the target certificate’s issuer as of version 5.9.2. RFC 6960 §4.2.2.2 requires that an OCSP response be signed directly by the CA that issued the certificate in question or a delegated responder appointed by that exact […]
Read MoreMore Tag