wolfSSL is currently working on porting the use of the S32K388 and S32K389 dedicated AES Accelerator available in the NXP HSE Hardware. wolfSSL currently has support for the HSE found on the S32K3 family, If you have questions about the current status of the HSE AES Accelerator port, or have specific algorithms, features, or projects […]
Read MoreMore TagCategory: wolfSSL/ wolfCrypt
White Paper: Security Technology Trends in Industrial Automation Equipment
We are pleased to announce the publication of a white paper jointly developed by Renesas and wolfSSL. Security Technology Trends in Industrial Automation Equipment Secure industrial automation equipment for evolving cybersecurity demands with lifecycle-based design, regulatory readiness, secure boot, OTA updates, key management, PQC migration, and Renesas RA/RX/RZ hardware security with wolfSSL/wolfBoot stacks—use this guide […]
Read MoreMore TagwolfSSL Advances Functional Safety with ISO 26262 Documentation and ASIL-D Certification Roadmap
As automotive software continues to grow in complexity, functional safety has become just as important as cybersecurity. To help customers build safety-critical systems, wolfSSL now offers ISO 26262 documentation designed to simplify the integration of wolfSSL into products pursuing Automotive Safety Integrity Level (ASIL) certification. This documentation provides developers with the supporting materials needed to […]
Read MoreMore TagwolfCrypt Now Supports SRAM PUF for Device-Unique Keys
The problem Almost every connected device holds a secret key to sign firmware, authenticate a TLS session, or encrypt stored data. Keeping that key out of an attacker’s hands is the hard part, and it is not just a small-device problem. Store it in on-chip or external flash and anyone with JTAG, an exposed debug […]
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 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 TagwolfSSL Improves TLS 1.3 Alert Compliance for Missing SNI
wolfSSL now sends the correct alert when a TLS 1.3 server requires the Server Name Indication (SNI) extension and the client fails to include it. Previously, the server sent a generic handshake_failure alert; it now sends the missing_extension alert defined by RFC 8446 for exactly this case. TLS 1.2 and earlier keep the existing handshake_failure […]
Read MoreMore TagwolfSSL Relaxes Serial Number Validation for Root CA Certificates
wolfSSL has refined its X.509 serial number validation to better handle real-world trust stores. Previously, wolfSSL rejected any certificate with a serial number of 0. While RFC 5280 requires CAs to issue certificates with positive serial numbers, some long-standing self-signed root CA certificates in circulation were created with serial 0, and rejecting them caused otherwise […]
Read MoreMore Tag