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.

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

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

Posts navigation

1 2 3 … 7 8 9 10 11 12 13 … 202 203 204

Weekly updates

Archives