RECENT BLOG NEWS

So, what’s new at wolfSSL? Take a look below to check out the most recent news, or sign up to receive weekly email notifications containing the latest news from wolfSSL. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support questions.

Unlocking the Power of Secure Boot for AMD/Xilinx UltraScale+ MPSoC Systems

With the release of WolfBoot version v2.4.0, we have made significant improvements to our secure boot support for Xilinx UltraScale+ MPSoC systems. This major update brings several key enhancements that make it easier and more efficient to deploy wolfBoot on this target.

UltraScale+ enhancements in wolfBoot v2.4.0

To see the complete list of improvements see wolfBoot PR #499.

  1. Standalone build

    The latest release adds support for building without any dependencies from the Vitis/Xilinx SDK. This shift allows developers to bypass traditional SDK-based workflows, making it easier to integrate secure boot into their projects.

  2. Expanded Exception Level (EL) Support

    We now support all ARMv8-A exception levels, enhancing security, virtualization, and OS management:

    • Exception Level 3 (EL3) – Trusted Firmware
    • Exception Level 2 (EL2) – Hypervisor
    • Exception Level 1 (EL1) – Operating System
  3. Flattened Image Tree (FIT) Format

    We have also introduced support for the FIT format, which combines a Flattened Device Tree (FDT) with embedded binaries. FIT images are widely used in embedded Linux systems, providing a flexible and efficient way to package and deploy software.

  4. Enhanced QSPI Bare-Metal Driver

    The latest release includes significant improvements to the QSPI bare-metal driver, enhancing its capabilities for DMA and clock speed configuration. For example using DMA vs IO mode reduced the read of 154MB from 18,228ms to 2,607ms.

  5. ARMv8 Crypto Extensions

    wolfBoot now supports the wolfCrypt ARM crypto assembly speedups for SHA2 and SHA3, which greatly improves hashing performance on the integrity checking during boot.

    6. AMD/Xilinx UltraScale+ MPSoC (ZCU102) Features

    The AMD/Xilinx Zynq UltraScale+ MPSoC ZCU102 is a powerful evaluation board that provides a platform for system designers to develop and prototype applications:

    • Processing System (PS):
      • Quad-core ARM Cortex-A53 (Application Processing Unit – APU)
      • Dual-core ARM Cortex-R5 (Real-time Processing Unit – RPU)
      • ARM Mali-400 MP2 GPU for graphics acceleration
    • Programmable Logic (PL):
      • Integrated UltraScale+ FPGA fabric for custom hardware acceleration
      • Supports Partial Reconfiguration (PR)
      • High-performance DSP slices for signal processing applications
    • Configuration Security Unit (CSU):
      • The CSU is responsible for secure boot and system configuration.
      • It ensures secure key storage, authentication, and decryption for secure boot processes.
      • Supports Root of Trust (RoT) for secure application execution.
      • Manages bit-stream authentication and encryption for FPGA security.
    • Platform Management Unit (PMU):
      • The PMU is a triple-redundant MicroBlaze processor system, ensuring high reliability and fault tolerance.
      • Handles power sequencing, system monitoring, and fault detection.
      • Manages dynamic power and thermal control, optimizing energy efficiency.
      • Provides error handling and recovery mechanisms for mission-critical applications.

    Note: The wolfBoot support for using the CSU and hardware based Root of Trust is in development now. You can follow the progress here.

    Getting Started

    To get started with wolfBoot on your Xilinx UltraScale+ MPSoC system, please refer to the official documentation docs/Targets.md.

    The Xilinx hardware uses a First Stage BootLoader (FSBL) and requires assembly of a BOOT.BIN image using bootgen and .bif file. Detailed instructions can be found in IDE/XilinxSDK.

    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

The Risks of 3DES in FIPS Certificates

When it comes to securing data, cryptographic algorithms are the backbone of many systems. 3DES (Triple Data Encryption Standard) was once a FIPS (Federal Information Processing Standards) algorithm but is no longer supported by NIST as of 1 Jan 2024 (over 1 year ago!) Having 3DES in a FIPS module today could spell trouble on the near horizon, not only for security but also for compliance.

Early Expiration of Certificates

A FIPS certificate comes with an expiration date, but the CMVP has the authority to move a certificate to the “historical list” before that date or to “Revoke” a certificate if a non-compliance issue is found. Either action makes the certificate no longer valid for new procurements or for use in certain scenarios if already deployed in the field. The CMVP exercised this authority during the transition from SP 800-56Arev[1,2] to SP 800-56Arev3, which tightened the standards for key establishment methods. Modules that did not meet the updated criteria by July of 2022 were moved to the historical list ahead of their expected expiration dates.

The same could happen with certificates that include 3DES now. Should the CMVP decide to enforce a hard transition on 3DES, any certificate with that algorithm could be revoked or made historical sooner than its listed expiration date. This means one could suddenly lose compliance, disrupting operations and requiring urgent updates to systems which can take many months or years to complete as anyone in the FIPS space is well aware.

An Example of Future-Proofing

An excellent example of future-proofing is the wolfSSL FIPS 140-3 module certificate #4718. Unlike many competing solutions, wolfSSL ensured that 3DES was not included in the boundary of this module. This proactive decision protects users of the wolfSSL Inc. wolfCrypt FIPS 140-3 module from the risks associated with 3DES and potential early certificate invalidation by the CMVP. By contrast, most of the competition did not do this future planning and still include 3DES in their boundary. This leaves users of those modules exposed to potential compliance issues and security risks.

What Should You Do?

  1. Avoid 3DES in New Designs: Choose FIPS modules that use stronger algorithms like AES. Ensure your vendors are aware of the risks and are providing compliant solutions.
  2. Audit Your Current Systems: If you’re already using a FIPS-certified module with 3DES, plan to migrate to a more secure alternative or re-validate that module without 3DES included in the boundary. Don’t wait for the CMVP to force your hand.
  3. Stay Informed: Keep an eye on updates from NIST and the CMVP. Understanding upcoming changes can help one with planning and preparing before CMVP decisions impact their systems.
  4. Test Your Transition Plans: Ensure that moving away from deprecated algorithms like 3DES won’t cause unexpected issues. Test thoroughly in a controlled environment.

Conclusion

3DES served its purpose in its time, but it is simply a liability now. If your systems rely on a FIPS certificate that includes 3DES, it’s time to act. By planning ahead and staying informed, you can ensure your systems remain secure and compliant, no matter what changes the CMVP enforces. Choosing solutions like wolfSSL’s FIPS 140-3 module, which proactively excludes outdated algorithms, can give you peace of mind and protect you from future disruptions.

If you have any questions or would like to talk with one of our team about this subject please send an email to fips@wolfssl.com or support@wolfssl.com. For general inquiries, you can also reach out to facts@wolfssl.com or +1 425 245 8247. Our staff are more than happy to help any way they can.

Download wolfSSL Now

Deprecation Notice: liboqs Integration

Soon wolfSSL will no longer utilize the liboqs library. This change is intended to simplify the maintenance of the wolfSSL codebase by reducing the line count.

The wolfSSL library already provides its own implementations of post-quantum algorithms, including Kyber and Dilithium. To enable these algorithms, users can simply configure wolfSSL with the following options:

--enable-kyber --enable-dilithium

Note that the --with-liboqs configure option will no longer be present.

The wolfSSL team would like to extend our gratitude to the Open Quantum Safe (OQS) team for their hard work and dedication to promoting quantum-safe cryptography. Their efforts have been invaluable to the community.

If you have any questions or concerns about this deprecation, please don’t hesitate to reach out to facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Why Transition to DTLS 1.3 is Crucial for CNSA 2.0 Compliance and Cybersecurity

As we advance towards stronger cybersecurity measures, adhering to the latest security standards is crucial. Transitioning to DTLS 1.3 is becoming a necessity for anyone still using DTLS 1.2. Here are four compelling reasons why now is the perfect time to make the switch:

  1. Full Control over the Migration Process
    Typically, you control both the server and client, giving you complete control over the DTLS 1.3 migration. This flexibility allows for a smoother transition without disruption to your existing systems.
  2. Support for Post-Quantum Cryptography
    The upcoming enhancements to TLS and DTLS include support for ML-DSA (post-quantum authentication) and ML-KEM (key exchange algorithms), but these cryptographic advancements will only be available in TLS 1.3 and DTLS 1.3. Migrating now future-proofs your system against quantum threats.
  3. NSA’s CNSA 2.0 Guidance
    According to the NSA’s CNSA 2.0, these post-quantum algorithms should have already been implemented by 2024 in cloud services, with a mandate for their use by 2025. DTLS 1.3 is the only version that supports these algorithms, migrate now to ensure compliance with CNSA 2.0 standards.
  4. Competitive Advantage for Vendors
    If your software still uses DTLS 1.2 and is sold to government agencies in the U.S., transitioning to DTLS 1.3 is becoming urgent. This ensures your products meet the necessary security standards and helps you maintain a competitive edge in the market.

Plan your migration to DTLS 1.3 today. The migration to DTLS 1.3 isn’t just a technical upgrade. It is a strategic move to ensure CNSA 2.0 compliance and enhance your system’s security. Start planning your migration strategy today to stay ahead of future cryptographic challenges.

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

Live Webinar: Post Quantum Cryptography Update

Secure Your Future: NIST PQC Standards and CNSA 2.0

Quantum computing is on the horizon, bringing new challenges to traditional cryptographic methods. To address these, NIST’s Post-Quantum Cryptography (PQC) standards and CNSA 2.0 guidelines provide essential tools for ensuring data protection in the quantum era.

Join wolfSSL Senior Software Developer Anthony Hu in this exclusive webinar to explore quantum-resistant solutions and practical strategies for preparing your systems.

What you’ll learn:

  • NIST PQC Standards and CNSA 2.0 Updates: Understand their importance for securing critical systems.
  • Key Exchange Mechanisms: Compare NIKE and KEM in the context of quantum resistance.
  • Performance Insights: Benchmark ECC against ML-DSA and ML-KEM.
  • wolfSSL’s PQC Readiness: Discover migration strategies and collaborative efforts to adopt quantum-resistant solutions.
    And more..

Register Now: Post Quantum Cryptography Update
Date: February 5th | 10 AM PT

Secure your spot today to gain actionable insights and stay ahead of quantum threats.
Register here

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 +1 425 245 8247.

Download wolfSSL Now

wolfTPM Release v3.8.0

We are pleased to announce the release of wolfTPM 3.8.0, our latest version with several important enhancements.

What’s New

This release includes a range of fixes and improvements that enhance the overall quality and reliability of wolfTPM. These changes are designed to support the delivery of high-quality production-grade products that meet the needs of our customers.

Key Changes

  • Session Auth Improvements: We’ve fixed an issue with bound session authentication, ensuring that TPM 2.0 authenticated sessions with binding work correctly. Additionally, we’ve added comprehensive test cases to verify the functionality.
  • Bus Protection: Our implementation of the TCG “bus protection guidance” now includes a comprehensive example, making it easier for developers to ensure their applications meet these critical security standards. For more information on our bus protection guidance, please refer to the TCG’s bus protection guidance document.
  • Build Support: We’ve improved support for building wolfTPM against older wolfCrypt versions, including updated CI tests.
  • HAL IO Improvements: We’ve added HAL IO support for Microchip I2C bit-bang driver

TPM 2.0 Use Cases

wolfTPM is designed to provide a robust and secure foundation for a wide range of applications, from IoT devices to high-end servers. Here are some examples of how wolfTPM 3.8.0 can help:

  • Secure Boot: wolfTPM provides a robust secure boot mechanism, ensuring that only authorized firmware can be loaded on the platform.
  • Platform Firmware Updates: Our implementation of bus protection guidance includes support for secure firmware updates, making it easier to keep platforms up-to-date and secure.
  • Key Management: wolfTPM can be used to manage cryptographic keys securely, providing a reliable and efficient way to handle sensitive data.
  • Hardware-Level Isolation: wolfTPM’s hardware-level isolation features provide a robust security foundation for applications that require high levels of isolation.
  • Trusted Execution Environments (TEEs): wolfTPM is designed to work seamlessly with TEEs, providing a secure environment for executing critical functions.

Getting Started

Download the latest version of wolfTPM 3.8.0 today! Check out the complete ChangeLog for full details.

As always, we appreciate your contributions and feedback. If you have any questions or suggestions, please email facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfBoot release: v.2.4.0

We are excited to announce the release of wolfBoot 2.4.0, the latest version of our universal secure bootloader. This update brings enhanced platform support, new features, and performance improvements to keep offering the best secure boot solution for all embedded systems.

Integration with wolfHSM and Improved delta updates

A major highlight of this release is the integration with wolfHSM, enabling secure key management through an externally-managed HSM. This integration allows for the transparent management and revocation of the stored public key, as well as support for post-quantum algorithms (ML-DSA).

Delta update detection mechanism has been improved and is now more reliable, with the addition of extra procedures for identifying base image versions.

New hardware targets and platform enhancements

wolfBoot 2.4.0 adds support for the NXP Layerscape LS1028A platform, extending compatibility with high-performance devices.

Support for existing platforms, including ARMv7-M/ARMv8-M, x86-FSP and Xilinx UltraScale+, has been updated with enhanced ARMASM integration, and improved QSPI DMA for efficient memory interaction. Support for Intel TigerLake has improved, with the addition of GDT table support.

New assembly optimizations introduced in latest wolfCrypt have introduced a significant improvement in boot time performance across all ARM family, from Cortex-M devices such as STM32 microcontroller up to the most powerful microprocessors supported.

Bug fixes and updated modules

Key fixes address potential issues in flash write-once mode. Moreover, the core modules have been updated to the latest versions, including wolfSSL 5.7.6 and wolfTPM 3.8.0.

wolfBoot security is powered by wolfCrypt. This means that the secure boot process can be certified to meet FIPS 140-3 requirements and DO-178C safety regulations.

Looking Ahead: Exciting Roadmap for 2025

This year, we’re setting our sights on expanding wolfBoot’s capabilities even further. Planned features include support for running wolfBoot as a supervisor in TrustZone-A, platform support for i.MX-8, and integration with the STM32 MP1 series. Stay tuned for these and more as we continue to innovate and enhance secure boot for all embedded systems.

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

wolfSSL JNI/JSSE 1.15.0 Now Available

wolfSSL JNI/JSSE 1.15.0 is now available for download! This release contains a number of bug fixes and changes to the JNI and JSSE layers.

wolfSSL JNI/JSSE allows for easy use of the native wolfSSL SSL/TLS library from Java. The thin JNI wrapper can be used for direct JNI calls into native wolfSSL, or the JSSE provider (wolfJSSE) can be registered as a Java Security provider for seamless integration underneath the Java Security API. wolfSSL JNI/JSSE provides TLS 1.3 support and can also support running on top of the wolfCrypt FIPS 140-3 validated cryptography module.

Changes in this release are summarized below, but please see ChangeLog.md for a full list.

JSSE System/Security Property Support:

  • wolfssljni.debug – a new System property that enables JNI-level debug logging. This will add debug logs for the lower-level “com.wolfssl.*” classes that are part of the thin wolfSSL JNI wrapper. This is helpful for those users who are using the thin wolfSS JNI wrapper, or for JSSE-level users who need additional low-level debug logging support.

JSSE Changes:

  • Close the underlying Socket when SSLSocket startHandshake() fails before an exception is thrown and returned to the caller.
  • Fix a potential NullPointerException in SSLSocket Input/OutputStream that could happen in a threaded environment with some threads blocked in select()/poll().
  • Add support for SSLSession.getRequestedServerNames() to return the client’s SNI (Server Name Indication) request on the server side.
  • Add checks for legacy DHE keys for cipher suites using keys less than 1024 bits.
  • Optimize Java byte array creation in SSLEngine objects when receiving app data. This has a positive impact on performance by reducing garbage collector pressure.
  • Add the ability for SSLSocket.close() to interrupt read()/write() operations waiting in select()/poll(). This can speed up the return of threads blocked in read or write operations when the socket is closed, instead of waiting for the socket timeout to occur.

JNI Changes:

  • Always call wolfSSL_get1_session() inside WolfSSLSession.getSession() for more consistent native memory handling and cleanup.
  • Call wc_RunAllCast_fips() with wolfCrypt FIPS builds if available. This will run all FIPS Conditional Algorithm Self Tests (CAST) up front when the wolfJSSE provider is registered.
  • Add the ability to pass CFLAGS to java.sh (ie: CFLAGS=”-DTEST_DEFINE” ./java.sh)
  • Remove incorrect ATOMIC_USER preprocessor gate around native wolfSSL_GetSide() inside JNI glue code.

Example Changes:

  • Updates the example Android Studio project, defining WOLFSSL_CERT_REQ and WOLFSSL_CUSTOM_CONFIG. These defines are either not needed, or automatically set when building native wolfSSL on a Linux/Unix platform with “./configure –enable-jni”.

Testing Changes:

  • Add GitHub Actions PRB test for Maven (Linux, macOS) builds
  • Add JUnit tests for SSLSession state at various points throughout the handshake
  • Add GitHub Actions PRB test for native wolfSSL with NO_SESSION_CACHE_REF defined
  • Add GitHub Actions PRB test for WOLFJNI_USE_IO_SELECT

wolfSSL JNI/JSSE 1.15.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfSSL JNI/JSSE User Manual can be found here. 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

wolfCrypt JNI/JCE 1.8.0 Now Available

wolfCrypt JNI/JCE 1.8.0 is now available for download! This release contains a number of bug fixes, changes and new features to help better support usage from applications and 3rd party frameworks that consume wolfJCE internally.

wolfCrypt JNI/JCE allows for easy use of the native wolfCrypt cryptography library from Java. The thin JNI wrapper can be used for direct JNI calls into native wolfCrypt, or the JCE provider (wolfJCE) can be registered as a Java Security provider for seamless integration underneath the Java Cryptography API. wolfCrypt JNI/JCE can also support running on top of the wolfCrypt FIPS 140-3 validated cryptography module.

Changes in this release are summarized below, but please see ChangeLog.md for a full list.

New JCE Functionality:

  • Support for two new Java Security properties designed for use in edge cases where wolfJCE is being used with wolfCrypt FIPS 140-2/3 and the wolfJCE WKS KeyStore is replacing JKS and/or PKCS12 type KeyStore usage from applications for more complete FIPS compliance. Setting these properties to “true” will result in wolfJCE fake registering support for JKS and/or PKCS12 KeyStore support, but will automatically map it down to WKS KeyStore support internally. This can be helpful if using wolfJCE underneath Java code that hard-codes JKS/PKCS12 KeyStore types which cannot be changed, but the actual KeyStore files on disk can be updated to WKS type.
    • wolfjce.mapJKStoWKS
    • wolfjce.mapPKCS12toWKS

JNI and JCE Changes:

  • FIPS Conditional Algorithm Self Tests (CASTs) are now run once up front if wolfJCE is used with wolfCrypt FIPS 140-3, to prevent threaded app errors.

Example Changes:

  • Updated Android Studio example project CMakeLists.txt, defining WOLFSSL_CUSTOM_CONFIG
  • Addition of a JCE cryptography benchmark app (examples/provider/CryptoBenchmark.java). Basic AES-CBC/GCM benchmarks are in place now, but will be expanded to other algorithms in the near future.

Testing Changes:

  • Addition of GitHub Action testing for Maven (pom.xml) builds on macOS and Linux

wolfCrypt JNI/JCE 1.8.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfCrypt JNI/JCE User Manual can be found here. 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

TLS vs. SSH: When To Use Which

TLS and SSH are both widely used protocols used for creating secure connections between two systems over a secure network. But, they are designed for different use cases, so today we are going to take a quick dive into when you should use which.

About TLS

TLS (Transport Layer Security) is what is most commonly used to secure connections to the web, it is the successor to SSL (Secure Sockets Layer) to which wolfSSL gets part of its name. Today, almost all websites use TLS and most web browsers expect a website to use TLS when connecting. It has other use cases, such as email and VNC.

In general, TLS is designed so that a client can authenticate that the intended web server is where the data transfer is happening, and encrypt the data in transit.

About SSH

SSH (Secure SHell) is likely well known if you have used a Linux or Unix-based system before. It is typically used to remotely log into a server and execute commands on that server, as well as transfer files. It is ideal for remote shell or desktop access to machines over an unsecured network.

In addition to our namesake product, wolfSSL, we have a product called wolfSSH, which can provide lightweight SSH client and server support for embedded platforms.

Key Differences

Authentication

SSH allows for many different authentication methods, from basic passwords to keys and certificates. TLS typically relies on a trusted CA (Certificate Authority) for the authentication. Both TLS and SSH support OCSP for certificate revocation status.

Feature Set

SSH not only handles the basic authentication and encryption, but provides the next layer of features, such as shell access, file transfer and port forwarding. TLS is typically a secure wrapper around regular plain protocols.

Another feature SSH provides is the concept of channels. This allows multiplexing of multiple services over one SHH connection. For example, a single connection can have a shell, file transfer and multiple ports forwarded simultaneously.

Performance

TLS, particularly version 1.3, has a very low number of round trips required to handshake between the client and server. Whereas the handshake for SSH is a lot more involved, this can make a new connection a lot more expensive on a high-latency network.

Once the connection is established, the performance of each should be relatively similar, depending on the encryption algorithms used.

Ease Of Use

TLS is designed to be relatively easy to use, in particular, there is a low barrier to entry for the client user. SSH can be more difficult to configure and typically has more steps for the end user due to the mutual authentication.

Summary

Both TLS and SSH are essential parts of securing traffic over untrusted networks. TLS is very useful to wrap existing protocols with a layer of security, whereas SSH is ideal for remote command access to a system and network tunnels.

If you wish to learn more or have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Posts navigation

1 2 3 4 5 … 193 194 195

Weekly updates

Archives