Month: September 2024

Deprecation and Removal of TLS 1.0 / 1.1 Support from wolfSSL

As part of our quality control and review process, wolfSSL is planning removal of obsolete and deprecated TLS protocol support from our mainline TLS library. TLS 1.0 and 1.1 were introduced in 1999 and 2006 respectively, and both versions were formally deprecated by RFC 8996 in 2021. As noted in the deprecation RFC, TLS 1.0 requires support for an obsolete and insecure cipher suite based on 3DES, an algorithm that dates to 1981. Moreover, the security guarantees of both version 1.0 and version 1.1 depend on the SHA-1 algorithm introduced in 1995, already considered vulnerable in 2005, and formally retired by NIST in 2022. TLS 1.0 and 1.1 have been disabled by default in wolfSSL since release 3.13.0 (2017) and 5.6.6 (2023) respectively.

Modern TLS implementations use either TLS 1.2 or 1.3, both of which avoid dependence on obsolete and deprecated algorithms and mechanisms. Version 1.2 was introduced in 2008, is currently considered secure when configured properly, and is supported by all modern TLS implementations. Version 1.3 is the latest version, finalized in 2018, with the highest inherent security, supported by wolfSSL since release 3.11.1 (2017).

While support for obsolete and insecure protocols is useful in some specialized analytic and forensic applications, we believe that continuation of this support in our mainline products does more harm than good, due to the associated complexity, and the inherent risk of misconfiguration, with potentially critical implications for system security.

While we have not yet determined a timeline for removal of code in wolfSSL specific to TLS 1.0 and 1.1, all API support for them should be considered deprecated, consistent with RFC 8996.

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

Download wolfSSL Now

Live Webinar: Everything You Ever Wanted to Know About How wolfSSL Runs on Xilinx

Explore how wolfSSL enhances security on Xilinx Devices in an upcoming webinar.

Join wolfSSL software Developer Jacob Barthelmeh in our live webinar, Everything You Ever Wanted to Know About How wolfSSL Runs on Xilinx, on October 2nd at 10am PT. Dive into the world of secure embedded systems and discover how to optimize wolfSSL for Xilinx platforms, including Versal, MPSoC UltraScale, and MicroBlaze.

Register today: Everything You Ever Wanted to Know About How wolfSSL Runs on Xilinx
Date: October 2nd | 10am PT

Jacob will guide you through building wolfSSL for Xilinx devices, highlighting the integration of wolfCrypt’s FIPS 140-3 mode, hardware acceleration ports with XilSecure, and using ARM assembly optimizations for performance improvements.

You’ll also explore how to incorporate wolfSSL into PetaLinux environments for maximum security, utilize wolfBoot on Xilinx/AMD devices, and understand how wolfSSL ports to various environments. Additionally, Jacob will showcase the use of wolfHSM with Xilinx/AMD platforms, offering valuable insights into implementing robust cryptographic security for your Xilinx devices.

This webinar will cover (agenda subject to change):

  • Building wolfSSL for Xilinx devices (Versal, MPSoC UltraScale, MicroBlaze)
  • Leveraging FIPS 140-3 mode for security compliance
  • Integrating hardware acceleration, including XilSecure
  • ARM assembly optimizations for performance
  • Using wolfSSL with PetaLinux
  • wolfBoot on Xilinx/AMD devices
  • Porting wolfSSL to other environments
  • Using wolfHSM with Xilinx/AMD

Don’t miss this opportunity to learn how wolfSSL can enhance security on your Xilinx systems. Register today to secure your spot and deepen your understanding of embedded security with wolfSSL on Xilinx platforms!

As always, our webinars will include Q&A sessions throughout. If you have questions on any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Post-Quantum wolfHSM on Aurix Tricore

The title says it all!! If you have been paying any attention at all to us here at wolfSSL, you will know that we are very proud of our wolfHSM product that already runs on the Aurix Tricore. What we have not been focusing on is the post-quantum algorithms that work with wolfHSM. Let’s use this blog post to fix that oversight.

In this post we will be focusing on ML-KEM, ML-DSA, and especially LMS and XMSS as they are all implemented in wolfCrypt and are therefore available in wolfHSM to protect you from the oncoming quantum threat.

First of all, ML-KEM is a Key Encapsulation Mechanism and generally used for key establishment. In most protocols this means it is used ephemerally, but because of the security properties inherent in the algorithm, it can also be used statically. That means it is fine for wolfHSM to generate an ML-KEM private key and use it multiple times under the protection of the HSM core.

Naturally, as MLDSA is a general purpose post-quantum signature scheme, wolfHSM has an opportunity to help just like in the case of ECDSA or RSA.

Now, where wolfHSM provides a unique offering is LMS and XMSS. These are stateful hash-based signature schemes which are great for firmware and software signing. That said, there is a state associated with the private key and that state MUST be properly managed. A consequence of improper management is that the key pair must be revoked and all signatures encountered after the point of revocation cannot be trusted.

Software libraries that implement signing by stateful hash-based signature schemes, such as wolfSSL, must trust the application developer to properly manage the state. In the case of wolfHSM, the wolfSSL team’s expertise can come into play to ensure proper management of the state. The application developer no longer needs to be an expert in post-quantum algorithms; simply a user of them.

If you’d like to learn how wolfHSM can support your post-quantum migration or have any questions, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSH with X.509 Certificates

Did you know wolfSSH can use X.509 certificates in place of SSH public keys? wolfSSH supports RFC 6187, “X.509v3 Certificates for Secure Shell Authentication”. This uses wolfSSL’s certificate management for TLS, so the certificates may be checked against CRLs and OCSP.

wolfSSH has been used in applications as a server where it needed to validate some FPKI (Federal Public Key Infrastructure) profiles. It is used with clients that authenticate the user’s credentials accessed via a card reader. wolfSSH’s client can be given an X.509 certificate to authenticate the user with the server.

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

Download wolfSSL Now

FIPS vs FedRAMP Compliance and Requirements

The wolfSSL team has noticed an uptick in questions about FedRAMP requirements. Today, we want to cover the differences between FIPS and FedRAMP.

FIPS:

The Federal Information Processing Standards (FIPS) stipulate security requirements for cryptographic modules, which wolfSSL Inc. meets with our wolfCrypt FIPS module. NIST and the CMVP then encourage all federal programs using cryptography to follow these standards. Federal Procurement Officers (at the urging of NIST and the CMVP) then require FIPS compliance for solutions that consume cryptography and are used within the scope of their federal program(s).

FEDRAMP:

The Federal Risk and Authorization Management Program (FedRAMP) focuses on the security assessment, authorization, and continuous monitoring of cloud products and services. A prerequisite for FedRAMP is the proper implementation of a FIPS-validated cryptographic module by the cloud service provider.

Both programs aim to enhance data security but differ in scope. While FIPS focuses on cryptographic module validation and cryptography, FedRAMP ensures the overall security of cloud services, one part of which is proper implementation of FIPS validated cryptography for all cryptography running in the cloud. Beyond checking for proper FIPS implementations, FedRAMP also ensures the cloud service provider is fully compliant with NIST SP 800-53 IE: Security Controls, a NIST Risk Management Framework (RMF), service is monitored continuously, data protection methods are robust, incidents can be detected, responded to and recovered from, and more. For a complete list please refer to SP 800-53 at this [LINK].

To support wolfSSL customers, wolfSSL Inc. offers a service to fully validate any Operational Environment (OE) (IoT, embedded, FPGA, Digital Signal Processor (DSP), laptop, desktop, server blade, or cloud system). wolfSSL Inc (the vendor) will fully test and validate the OE of choice using a third-party NVLAP accredited FIPS lab (or CSTL) and get the OE listed as a CMVP-validated OE on the wolfCrypt FIPS Certificate. This is a CMVP-backed OE addition which is guaranteed to be acceptable by any federal program with a FIPS requirement, as opposed to vendor affirmation or user affirmation which often fall short of the mark. Additionally, once the primary certificate is updated with the OE of choice, a rebranded cert with the customer’s logo and letterhead can be offered including that new OE.

wolfSSL’s wolfCrypt FIPS module supports the latest FIPS 140-3 standards and holds the world’s first SP800-140Br1 FIPS 140-3 validated certificate (#4718). Our expert support team is available to assist with the proper implementation of the module on your target OE, a critical step for achieving a successful FedRAMP effort.

Beyond getting proper OE’s for FEDRAMP initiatives, wolfSSL can support customers that are either:

  1. Using an alternative OS within AWS, Azure, or Oracle cloud, or,
  2. If you are standing up your own cloud, support you with meeting the FedRAMP FIPS requirements for the operating system of your choice.

For more information on how wolfSSL can help with your FIPS or FedRAMP compliance needs, shoot us an email at fips@wolfSSL.com today!

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

Download wolfSSL Now

Introducing rustls-wolfcrypt-provider: wolfCrypt for Rustls

rustls-wolfcrypt-provider integrates the wolfCrypt cryptographic library as a backend for Rustls, allowing developers to use wolfCrypt’s secure cryptographic functions with Rustls’ modern TLS stack. Currently in alpha, this library offers flexibility for those needing an alternative crypto provider, especially for projects requiring FIPS 140-3 readiness.

Other reasons to consider wolfCrypt as your Rustls provider include the following:

  1. Hardware encryption support, wolfCrypt supports hardware encryption and assembly optimizations for systems big and small. See our list of supported hardware encryption schemes.
  2. Support: we will support Rustls when used in conjunction with wolfCrypt.
  3. Consulting: If you need help making all of this work in your environment, we’ll help!

Supported Cipher Suites

TLS 1.3:

  • TLS13_CHACHA20_POLY1305_SHA256
  • TLS13_AES_128_GCM_SHA256
  • TLS13_AES_256_GCM_SHA384

TLS 1.2:

  • TLS12_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS12_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS12_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS12_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS12_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS12_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

With rustls-wolfcrypt-provider, developers can combine the cryptographic strengths of wolfCrypt with the modern TLS capabilities of Rustls, supporting Rustls version 0.23.9. This integration is ideal for projects that require both strong security and the flexibility of wolfCrypt’s cryptography.

Are you interested in Rust solutions with wolfSSL integration?

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

Download wolfSSL Now

Live Webinar: Everything You Need to Know about FIPS 140-3

Join us on September 25th at 10 AM PT for an in-depth look at FIPS 140-3 with wolfSSL Senior Software Engineer, Kaleb Himes. This is your chance to get the inside scoop on how FIPS 140-3 can enhance your security!

Register Now: Everything You Need to Know about FIPS 140-3
Date: September 25th at 10am PT

This webinar will cover:

  • Basic & Benefits: Discover why FIPS 140-3 is essential for secure systems and what makes it a must-have.
  • Difference Between FIPS 140-2 and FIPS 140-3: Understand the key distinctions and improvements from FIPS 140-2.
  • wolfCrypt’s Achievement: Learn about wolfCrypt’s milestone as the first to receive the SP800-140Br1 FIPS 140-3 validated certificate (#4718).
    And much more…

Whether you’re new to FIPS 140-3, looking to deepen your knowledge or seeking FIPS 140-3 support, this webinar will provide valuable insights and practical information.

Don’t miss out on this opportunity to enhance your understanding and stay ahead in cybersecurity. Register now and secure your spot!

As always, our webinars will include Q&A sessions throughout. If you have questions on any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Strengthening RSA default minimum to 2048 bits

wolfSSL helps make the internet secure. Part of this task is continually updating our default settings to keep up with adversarial advancements. A recent article detailed the use of default RSA key sizes by an IoT manufacturer, which resulted in a 512 bit key being used for authentication. “The factoring required $70 in cloud computing costs and less than 24 hours.”

Since wolfSSL also had the default minimum set to 512 bits, we decided to update the default minimum to 2048 bits. The decision to use 2048 bit for the minimum was based on NIST recommendations and security industry best practices. This affects key generation using wc_MakeRsaKey. Testing infrastructure was also updated to be sure the smaller key sizes are still being covered by CI tests. The default RSA key size minimum can be overridden in the configuration using the RSA_MIN_SIZE macro.

For more information about using RSA in wolfSSL or have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Azure Removing TLS 1.0 & TLS 1.1

Are you prepared for the upcoming security enhancements in Azure, which will remove support for TLS 1.0 and TLS 1.1? By the end of October, Azure will no longer accept connections using TLS 1.0 and TLS 1.1 (Azure announcement). This is great news! The older TLS protocols are less secure compared to the newer TLS 1.2 and TLS 1.3 standards. wolfSSL supports both TLS 1.2 and TLS 1.3, and can assist in upgrading your product’s security to prepare for the deprecation of TLS 1.0 and TLS 1.1 in Azure.

For more information and upgrade assistance contact facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Posts navigation

1 2 3