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.

wolfSSL expands capabilities with ISO 26262 documentation for ASIL compliance

If you’re developing safety-critical automotive systems, chances are you’ve encountered the stringent requirements of ISO 26262, the standard governing functional safety for road vehicles. Achieving Automotive Safety Integrity Level (ASIL) compliance can be a daunting process, but wolfSSL has taken a significant step to support developers: the library now includes ISO 26262 documentation to aid in certification.

This development marks a major milestone for teams integrating wolfSSL to build secure and safe automotive systems. Here’s why.

What is ISO 26262 and ASIL?

ISO 26262 defines a structured approach for ensuring safety in automotive systems, from design to decommissioning. It includes ASIL levels (A-D) to assess risk, with ASIL D representing the highest safety requirements.

For cryptographic libraries like wolfSSL, demonstrating compliance requires detailed documentation, including failure mode analysis, software development lifecycle processes, and verification evidence.

How Does wolfSSL’s ISO 26262 Documentation Help?

With the provided ISO 26262 documentation, wolfSSL assists customers during the compliance process for automotive developers by offering:

  1. Pre-validated Artifacts: Access to the documentation allows developers to directly reference wolfSSL’s safety processes and testing in their safety case.
  2. Reduced Certification Time: By leveraging wolfSSL’s compliance resources, developers can focus on their application logic without reinventing the wheel for cryptographic layers.
  3. Confidence in Security and Safety: The inclusion of ISO 26262 ensures that wolfSSL adheres to rigorous safety and quality standards, providing a secure foundation for automotive systems.

Use Cases for WolfSSL in Automotive

WolfSSL’s compact size and high performance make it an excellent fit for embedded systems like:

  • Secure Vehicle-to-Everything (V2X) communication
  • In-car infotainment systems
  • Advanced driver-assistance systems (ADAS)
  • Electric vehicle (EV) battery management systems

Taking the Next Step

Whether you’re retrofitting cryptography into an existing system or building a new solution from the ground up, wolfSSL’s new ISO 26262 documentation reduces the friction for compliance while delivering the performance and security you trust.

Whether you’re integrating cryptography into an existing system or developing a new solution, wolfSSL’s ISO 26262 documentation simplifies the path to compliance, ensuring that your project can meet functional safety standards while maintaining robust performance and security.

Get in touch with the team

Contact us at facts@wolfSSL.com or +1 425 245 8247 to learn more about ISO26262 compliance, or if you are interested to hear more about our support for safety certifications.

Download wolfSSL Now

Deprecation Notice: ARC4

The wolfSSL team is announcing the deprecation of the ARC4 cipher. This decision is part of our ongoing effort to simplify the wolfSSL codebase and focus on supporting the most secure and widely-used ciphers.

The ARC4 cipher has been shown to have significant weaknesses, including:

  • Key biases and correlations
  • Plaintext recovery attacks
  • Increased risk of data breaches

Removing ARC4 will allow us to reduce the complexity of our codebase and devote more resources to maintaining and improving our supported ciphers.

Recommendations:

  • Begin transitioning away from ARC4 and towards more secure ciphers, such as AES or ChaCha20.
  • Consult the wolfSSL documentation and support resources for guidance on migrating away from ARC4.

We will provide additional information on the removal timeline in the future. If you have any questions or concerns about this deprecation, please don’t hesitate to reach out to the wolfSSL support team.

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

Download wolfSSL Now

wolfMQTT Releases v1.19.2

In the realm of lightweight MQTT (Message Queuing Telemetry Transport) implementations, wolfMQTT maintains its commitment to reliability and performance. With the release of version 1.19.2, wolfMQTT strengthens its core functionality through targeted improvements and enhanced testing infrastructure.

Key Improvements:

  1. Enhanced Connection Reliability
    The implementation of improved error handling in the “mqttsimple” client ensures more robust connection management, particularly beneficial for embedded applications where connection stability is crucial.
  2. Optimized Keep-Alive Mechanism
    A significant enhancement to the ping response handling improves the reliability of MQTT keep-alive functionality, ensuring more stable long-term connections and better resource management.
  3. Strengthened Testing Infrastructure
    • Modernized continuous integration workflow with Ubuntu 22.04
    • Enhanced artifact testing procedures for more comprehensive quality assurance
    • Improved Zephyr platform compatibility through targeted build fixes

Release 1.19.2 has been developed according to wolfSSL’s development and QA process and successfully passed the quality criteria.

Check out the ChangeLog for a full list of features and fixes, or contact us at facts@wolfssl.com with any questions.

While you’re there, show us some love and give the wolfMQTT project a Star!

You can download the latest wolfMQTT release from our website or clone directly from our GitHub repository.

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

Download wolfSSL Now

Using wolfCLU To Verify a Certificate Chain of More than 2 Certificates

With the release of wolfCLU 0.1.7, you can now verify long certificate chains! Our way of doing it is a bit unique.

You will need to verify the certificates in your chain one by one. For example, suppose you have a certificate chain where there is a root, intermediate, another intermediate and leaf certificate. If they are named first.pem, second.pem, third.pem and fourth.pem you will need to verify like this:

$ ./wolfssl verify -CAfile first.pem second.pem
$ ./wolfssl verify -partial_chain -CAfile second.pem third.pem
$ ./wolfssl verify -partial_chain -CAfile third.pem fourth.pem

This will work for short chains as well as long chains.

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: Getting Stater with wolfSSL Using Visual Studio 2022

Learn how to integrate wolfSSL with Visual Studio 2022 for secure development.

Are you looking to level up your development skills and implement secure communication in your applications? Join our webinar, “Getting Started with wolfSSL Using Visual Studio 2022,” on February 19th at 10 AM PT. Discover how to seamlessly integrate wolfSSL’s powerful TLS library with Visual Studio 2022 for secure, high-performance applications.

Register today: Getting Started with wolfSSL Using Visual Studio 2022
Date: February 19th | 10 AM PT

This webinar will cover:

  • What is wolfSSL?
    Discover the power of the TLS library and how it supports secure communications.
  • What is Visual Studio 2022?
    Explore the capabilities of this world-class IDE for application development.
  • Where are wolfSSL and Visual Studio used?
    Explore practical applications in Windows apps, embedded systems, and beyond.
  • How is wolfSSL Customized?
    Learn to tailor wolfSSL for your specific project needs.

Gain hands-on experience with wolfSSL and Visual Studio 2022 while mastering best practices for integrating TLS encryption into your projects. Register now to access exclusive resources and take the first step toward mastering secure development.

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 245 8247.

Download wolfSSL Now

wolfSSL Inc. SP800-140C and Post-Quantum efforts update!

This is an update to previous post Everything wolfSSL is Preparing for Post-Quantum as of Spring 2024 and an extension to post wolfSSL Support for Post-Quantum.

The National Institute of Standards and Technology (NIST) has recently updated its guidelines, enabling the certification of several post-quantum cryptographic algorithms through the Cryptographic Module Validation Program (CMVP). Notably, the digital signature algorithms ML-DSA (CRYSTALS-Dilithium), LMS, and XMSS are now fully certifiable under the updated SP800-140C standards.

In response to these developments, wolfSSL Inc. is proactively planning submissions to the CMVP for these algorithms. wolfSSL Inc. has a strong track record in cryptographic module validation, having previously achieved FIPS 140-3 Certificate #4718 for its wolfCrypt Module, the world’s first SP 800-140Br1 validated certificate.

While ML-KEM (CRYSTALS-Kyber) is not yet included in the approved security function list of SP 800-140C, wolfSSL is taking a forward-thinking approach by incorporating ML-KEM into its offerings. This strategic inclusion ensures that once ML-KEM receives approval and is certifiable, wolfSSL will be prepared to submit all four algorithms, ML-DSA, LMS, XMSS, and ML-KEM, for certification.

By staying ahead of regulatory changes and actively engaging in the certification process, wolfSSL continues to demonstrate its commitment to providing robust and compliant cryptographic solutions in the evolving landscape of post-quantum security.

Please don’t hesitate to contact us at support@wolfSSL.com or fips@wolfSSL.com anytime to share your feedback or input on this subject!

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

SPAKE and wolfSSL in Kerberos 5

In today’s digital landscape, the need for robust authentication mechanisms has never been more crucial. Among the various methods available, SPAKE (Simple Password-Authenticated Key Exchange) stands out as an enhanced security solution for authenticating users.

SPAKE represents a significant advancement over traditional password-based authentication, which often relies on static hashes. By leveraging a shared secret key, SPAKE ensures that passwords are never directly exposed during the authentication process, thereby mitigating risks associated with compromised credential storage.

The integration of wolfSSL into the Kerberos 5 implementation further elevates security by providing FIPS 140-3 certified cryptography. This compliance ensures that cryptographic modules meet stringent security standards, crucial for organizations prioritizing data protection and regulatory adherence.

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

Download wolfSSL Now

IPsec vs TLS: what are the differences

IPsec (Internet Protocol Security) and TLS (Transport Layer Security) are both used to protect data in transit between devices, and to secure network traffic over public or private internet. Both have cryptographic mechanisms for encryption, integrity checking, mutual authentication, replay protection, key exchange, etc. However, they operate at different network layers, and have different strengths and security goals in mind. The purpose of this blog post is to help our readers understand the differences.

IPsec

IPsec operates at the IP (Internet Protocol) network layer, and has reserved IP protocol numbers of 50 for ESP (Encapsulating Security Payload) and 51 for AH (Authentication Header) security protocols. AH provides integrity checks and data origin authentication, while ESP provides confidentiality, integrity checks, and authentication. IPsec supports both IPv4 and IPv6 protocol versions.

At the most basic level IPsec protects traffic between a pair of src and dst IP addresses that share security associations (SA). For example, if Alice and Bob use ip xfrm to provision shared SAs between their linux computers with ESP rfc4106(gcm(aes)), then all IP traffic between their two computers would be protected with authenticated encryption, regardless of whether they were carrying TCP or UDP, or some higher level application protocol. Thus IPsec provides blanket security guarantees that can be useful for large organizations and for constructing private networks. Furthermore, legacy applications that don’t support modern TLS can be protected.

The disadvantages of IPsec are that it can be complicated to configure and maintain, and in the embedded space the network stack may not support IPsec at all.

TLS

In contrast, TLS is agnostic of the underlying transport mechanism, and is not tied to a specific network abstraction layer. While the most common use case is over TCP (TLS) and UDP (DTLS), TLS can be implemented over UART or I2C in embedded devices. Therefore TLS is really about securing application layer communication: e.g. protecting data in transit between a web browser and an email server, or between remote sensors in the field and a hub collecting data.

The value of TLS is in its individualized and flexible nature. A user of TLS can know that their communication is protected even over an untrusted network. Furthermore, TLS can be used on bare metal devices that lack an operating system and only have a minimal network stack. Finally, TLS is the true standard of the bulk of public internet communications. As such, it is the most widely tested security protocol available.

IPsec vs TLS, and Zero Trust

In short, TLS and IPsec are simply two different models for solving the same problem, with unique strengths and tradeoffs. If you need to secure a device in the field that connects back to servers, then TLS is likely the better fit. If you need to build a large secure network, or create a secure tunnel between networks, then IPsec may make more sense.

If your use case combines aspects of both (a remote worker’s device connecting to a corporate VPN), then likely both TLS and IPsec will be needed. The reality is that modern networks are increasingly heterogeneous and distributed, and both IPsec and TLS will be needed for complementary layers of security in a Zero Trust posture. Thus IPsec and TLS should be considered synergistic rather than antagonistic security models.

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

Download wolfSSL Now

When wolfSSL_UseKeyShare() is not Enough

Ladies and gentlemen, it’s story time!!

Once upon a time, there was a network administrator that only wanted to use the strongest NIST-approved ECC encryption available within the TLS 1.3 protocol. They picked ECDHE over the secp521r1 curve. When they went to code their application, they wanted the best TLS library available so they naturally picked wolfssl.

In order to let their peers know that they wanted to use ECDHE over the secp521r1 curve with TLS 1.3, they used the wolfSSL_UseKeyShare() API during the setup of the connection. With this addition they thought they were done. Like any good software developer, they then tested their application against many servers and found that it worked as expected. Happy with the results, our security conscious network administrator began using their new application.

A little while later, during a network security audit, the consultant found that the application was on some occasions using ECDHE over the secp256r1 curve!! Flabbergasted, the network administrator demanded proof and the consultant showed him the wireshark transcripts. Low and behold, the transcripts showed that the server had sent a HelloRetryRequest handshake message requesting secp256r1. This was because the SupportedGroups extension in the ClientHello had advertised support for secp256r1 and that was the only curve that this particular server supported.

In the end, the solution was simple. Our network administrator called wolfSSL_set_groups() specifying only secp521r1. The next time he connected to the offending server, it simply refused the connection. Then our administrator upgraded that server to support secp521r1. Our hero and their application and servers lived happily ever after.

– The End –

Note this parable does not constitute a bug nor vulnerability in the wolfssl library. What happened was exactly how TLS 1.3 is supposed to work. This is a case of unintended consequences due to insufficient configuration.

Another possible more bullet proof solution is to compile out support for weaker ECC curves during the configuration of the wolfssl library.

This parable is especially relevant in the era of post-quantum cryptography. If you are trying to thwart the “harvest now, decrypt later” threat model and you are willing to sacrifice some interoperability, then you do not want to advertise support for conventional algorithms.

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

Download wolfSSL Now

Deprecation Announcement: RC2

As part of our ongoing effort to maintain the highest level of security and performance, we are announcing the upcoming deprecation of RC2 from wolfCrypt. All of our products depend on wolfCrypt for their algorithm implementations so this could have consequences across our whole product line.

What is RC2?

RC2 is a symmetric-key block cipher that was widely used in the past for data encryption. Developed in 1987 by Ron Rivest, RC2 is now over 35 years old.

Why is RC2 being deprecated?

The main reasons for deprecating RC2 are:

  • Security vulnerabilities: RC2 has been shown to be vulnerable to certain attacks, such as brute-force attacks and side-channel attacks.
  • Limited key size: RC2’s key size is limited to 64 bits, which is considered too small for modern cryptographic purposes.
  • Better alternatives available: TLS 1.3 forbids RC2 and now there are more secure and efficient cryptographic algorithms available, such as AES and ChaCha20.
  • Regulatory requirements: The NSA has made it clear, RC2 is now obsolete. Learn more

What does this mean for our users?

We will soon be deprecating RC2 in our products and services. This means that:

  • New versions of wolfCrypt: RC2 will no longer be available in future version of wolfCrypt. Are you using protocols that require RC2? Does this break compatibility with peers you communicate with? Let us know by sending a message to support@wolfssl.com
  • Existing deployments: We will provide a transition period for existing deployments to migrate to a more secure algorithm.
  • Support: We will no longer provide support for RC2-related issues, but we will make suggestions to help ease your transition.

What are the recommended alternatives?

We recommend using more secure and efficient cryptographic algorithms, such as:

  • AES: A widely used and highly secure symmetric-key block cipher.
  • ChaCha20: A fast and secure stream cipher.

We encourage our users to start planning their migration to a more secure algorithm as soon as possible.

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

Download wolfSSL Now

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

Posts navigation

1 2 3 4 … 193 194 195

Weekly updates

Archives