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.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.

wolfCrypt-py and wolfSSL-py 5.3.0 Released

wolfSSL has released version 5.3.0 of the Python wrappers for wolfCrypt and wolfSSL called wolfCrypt-py and wolfSSL-py.

This is a significant release because the build system has been completely refactored to make it easier to build and install the Python wrappers.

In addition, wolfCrypt-py now works in Windows and has several new APIs to support some of the newer features of wolfCrypt.

For more information the release notes for wolfCrypt-py can be found here, and wolfSSL-py can be found here. In addition the releases can be found on PyPi to be installed using `pip` here for wolfCrypt-py and here for wolfSSL-py. Contact facts@wolfssl.com for more information about using the wolfSSL embedded SSL/TLS library in your Python applications!

Check out this week’s schedule!

It’s a BUSY week! Check out all the trade shows we are attending below:

Cyber Physical Systems Security Summit in Troy, Michigan

IoT Solutions World Congress in Barcelona, Spain

Forum 78 in Fort Worth, Texas

CyberLEO in Los Angeles, California

Upcoming Webinar: Why everyone is using cURL and you should too

Join Daniel Stenberg, founder and maintainer of cURL and libcurl, as he goes through some basic curl fundamentals about what cURL is, who uses cURL, why use cURL etc. As well as giving information on how to customize your configuration, and other features that may be useful.

As always bring your questions for the Q&A following the presentation.

When: 9AM Pacific, May 12th, 2022

Register in advance here.

wolfTPM 2.4.0 Released!

We are excited to announce our wolfTPM v2.4 release. This includes improvements for Windows including support for cmake, C# wrappers, and c++ compiler fixes. This expands the wolfTPM cross platform API that is easy to use and supports Linux, Windows and embedded platforms. C# wrappers have been tested on Linux and Windows. These changes enable support for vcpkg for wolfSSL, wolfTPM, and wolfMQTT (see PR).

Release Details:

  • Fixes for c++ compiler (PR #206)
  • Adding a C# wrappers (PR #203)
  • CMake support (PR #202, #204, #205)
  • Add support for ST33 vendor specific command TPM_CC_GetRandom2 (PR #200)
  • Fix writing PEM in wolfTPM2_RsaKey_TpmToPemPub (PR #201)
  • Improve TPM2_SetupPCRSel (multiple calls) (PR #198)
  • Fix for a few spelling errors and whitespace cleanup (PR #199)
  • v2.3.1 updates (PR #197)
  • Fix make install by renaming pcr example read.c (PR #196)

For a full list of changes, check out the updated ChangeLog.md bundled with wolfSSL or view our page on GitHub here. For questions please email facts@wolfssl.com

wolfBoot 1.11 Released!

wolfBoot 1.11 has been released. This release introduces new algorithms for signature verification (Ed448, Ecc384), for integrity check (Sha2-384) and for external storage encryption (Aes128 and 256). Encryption support for external storage has been improved.

Our team introduced mitigation against glitching attacks. Find out more in this post.

Support for new targets has been included: NXP i.MX-RT1050 and STM32U5.

For the full list of changes, please see our Github page.

You can download the latest release here: https://www.wolfssl.com/download/
Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfBoot

Contact us at facts@wolfssl.com with any questions!

wolfSSL 5.3.0 Release!

wolfSSL has released a new version! 5.3.0.

This contains some exciting new additions and fixes. A full list can be found in the ChangeLog.md (https://www.wolfssl.com/docs/wolfssl-changelog/) but some of the highlights are:

  • SP performance enhancements and fixes
    • wolfSSL’s Single Precision (SP) Math Library bring the best implementations to insure the best performance of Public Key Algorithms 
  • Compatibility layer enhancements and function additions
    • The wolfSSL OpenSSL compatibility layer is a means to switch applications designed for OpenSSL over to use wolfSSL.
  • Embedded post quantum port on an STM32 device and benchmarks
  • CAAM support for i.MX8 on Linux
    • CAAM (Cryptographic Accelerator and Assurance Module) is hardware that can be found on many i.MX NXP devices. When used it speeds up the cryptographic algorithms such as ECC and AES. 
  • Updates to Renesas TSIP support, Stunnel, Bind and other ports…
  • Additions and improvements to testing including use of Wycheproof
    • Project Wycheproof is a test suite developed and maintained by the Google Security Team. Their unit tests use Java security packages (java.security and javax.crypto) to allow for multiple JCA/JCE provider implementations to be tested, including wolfJCE.

A full list of what was changed can be found in the wolfSSL ChangeLog (https://www.wolfssl.com/docs/wolfssl-changelog/).

For questions about wolfSSL or about the latest release contact us at facts@wolfssl.com

Upcoming Webinar : Everything you need to know about Securing Medical Devices!

Story time with wolfSSL! Join us for a comprehensive presentation on how to leverage wolfSSL for all of your Medical Device needs as we go through a variety of different use cases and example with the specific engineering details for each story.

As always bring your questions for the Q&A following the presentation.

When: Apr 28, 2022 09:00 AM Pacific Time (US and Canada)
Topic: Everything you need to know about Securing Medical Devices!

Register in advance for this webinar:
https://us02web.zoom.us/webinar/register/WN_a7LU9jA_SMmhSZo5oxz87Q

After registering, you will receive a confirmation email containing information about joining the webinar.

If you have any questions or comments contact us at facts@wolfssl.com

 

Constant Time Testing

It is no secret that wolfSSL makes every effort to provide the best tested cryptographic and SSL/TLS solution available on the market.

To that end, wolfSSL is proud to announce that as of today there is a suite of Constant Time Tests evaluating two of the three big integer math libraries wolfCrypt offers that have support for constant time execution.

Big integer math libraries natively available in wolfSSL are:

    1. sp_int.c
      1. Use setting –enable-sp=yes to use this library
      2. For non-Autoconf builds use setting(s)
        1. WOLFSSL_SP
        2. WOLFSSL_HAVE_SP_RSA
        3. WOLFSSL_HAVE_SP_ECC
        4. WOLFSSL_HAVE_SP_DH
        5. (optional) WOLFSSL_SP_SMALL (reduced footprint)
      3. Stack based math library with optimized math, faster than tfm.c

 

  • Constant time support for all algorithms: RSA, DH, and ECC

 

    1. tfm.c
      1. Default on Linux (no setting needed to use)
      2. For non-Autoconf builds use setting USE_FAST_MATH to enable this library
      3. Stack based (large static buffer), enjoys better performance

 

  • Constant time for only two algorithms (RSA and ECC)

 

    1. integer.c
      1. Use setting –disable-fastmath on Linux to use this library
      2. Avoid the setting USE_FAST_MATH to use this library when building with non-Autoconf solutions (IDEs’, Makefiles, whenever user_settings.h is used etc.)
      3. Heap based, suffers overhead of alloc/free at the benefit of only the needed resources.

 

  • Not-constant time, avoid if concerned about timing attacks

 


Note: None of the above applies to externally implemented hardware and/or software solution(s). IE when using the crypto callbacks to offload operations to an external cryptographic module or using external quantum safe solutions such as liboqs etc.

wolfSSL is also evaluating constant time execution for the following algorithms that do NOT depend on any of the three big integer math options: AES-CBC, AES-GCM, ChaCha20, Poly1305, SHA2-256, SHA2-512 and X25519 (AKA “Curve25519”)

If you would like to know more please do not hesitate to reach out to wolfSSL anytime by contacting facts@wolfssl.com or support@wolfssl.com.

Doing Crypto Without Malloc’s

wolfSSL has easy options for building and running without any malloc’s! Avoiding the use of all dynamic memory can be important in many environments, including safety critical ones and the use with satellites, being one of NASA’s 10 rules to not use any dynamic memory after initialization. The easy build options for no system malloc’s helps wolfSSL be used under these stringent requirements. Along with being able to do crypto operations with the no malloc build, wolfSSL can also support full TLS handshakes with no malloc’s!
To build wolfSSL with no dynamic memory –enable-staticmemory could be used. Examples and tests with setting aside the memory pools for the staticmemory build can be seen in the wolfcrypt/test/test.c file bundled with wolfSSL. By default this falls back to malloc when no static memory is available, to avoid this fallback mechanism to system malloc’s the macro WOLFSSL_NO_MALLOC must also be defined. In addition to the staticmemory enable option there is a nomalloc version with our SP (single precision) asymmetric performance speed ups too! This could be enabled with –enable-sp=nomalloc when using autoconf.

For more information about porting wolfSSL and using the no malloc build contact us at facts@wolfssl.com.

Secure Boot and Glitching Attacks

In general, a “glitch” is a momentary fault that may happen on a system, preventing it from working properly, for a brief amount of time. The effects of a single glitch on proper software execution may be multiple, including catastrophic consequences that may prevent the system from continuing the execution.

Glitching attacks are complex and expensive to execute, but can be a real issue for secure boot mechanisms, and often very hard to prevent or mitigate. They aim at exploiting predictable consequences of single glitches in order to take control of the execution or the data contained in the system. The glitch can be injected using different techniques, which often rely on well known weaknesses of the specific microcontroller or CPU. The most common glitch injection consists in varying the voltage supplied to the chip at a specific time, or modifying the profile of the clock signal to mangle the timing of the execution of the instructions. More advanced attacks can rely on irradiating the device with strong electromagnetic interference.

In the specific context of secure boot, the goal for an attacker is to circumvent the security checks in those critical sections of the code, e.g. the code that performs verifications on the firmware authenticity, integrity or versioning. These attacks could eventually defeat the security checks, and take control of the system by uploading an unauthorized firmware image. While they require an accurate synchronization and several attempts, these attacks will eventually succeed in injecting a fault in the hardware at the required time in order to skip the verification.

Our secure bootloader, wolfBoot, follows the indication of RFC9019 to provide a secure, public key based verification of the integrity and authenticity of the firmware and its updates. It runs on several different architectures, from small microcontrollers up to x86_64 systems. wolfBoot is OS-agnostic and provides best-in-class security thanks to the FIPS 140-2 certified algorithms implemented in the wolfCrypt security engine. 

wolfBoot already comes with plenty of unique features. Now it is also the first open source secure bootloader to implement mitigations against glitching attacks. Our development team has recently added an optional feature that can be activated at compile time, to reinforce the security of the critical variables and decision points in the code. This has required an evaluation of the code flow of wolfBoot from a point of view that includes the possibility for an attacker to skip single specific instructions. Introducing these mitigations has been tricky, because redundant code written in C is usually discarded by the compiler. For this reason the countermeasures must be programmed in assembly, which makes this code architecture specific.

The upcoming release of wolfBoot will contain a first version of these countermeasures, but glitching support mitigation already made it to our main branch on github, and it can be freely compiled and used in GPL projects for evaluation and auditing purposes.

To compile wolfBoot with glitching and side-channel attack mitigations turned on, it is sufficient to add ARMORED=1 to the configuration options (i.e. via command line when invoking make, or through the .config file). The ARMORED option is currently supported on ARM Cortex-M architecture. Support for other architectures will be added in the future.

You can download wolfBoot today from our download page or from our github repository

What is the next feature that you want to see implemented in wolfBoot? Is there any architecture or platform that we don’t yet support that could benefit from our glitch-resistant secure boot mechanism? Let us know! Drop us a line at facts@wolfssl.com.

wolfCrypt-py and wolfSSL-py 5.3.0 Released

wolfSSL has released version 5.3.0 of the Python wrappers for wolfCrypt and wolfSSL called wolfCrypt-py and wolfSSL-py.

This is a significant release because the build system has been completely refactored to make it easier to build and install the Python wrappers.

In addition, wolfCrypt-py now works in Windows and has several new APIs to support some of the newer features of wolfCrypt.

For more information the release notes for wolfCrypt-py can be found here, and wolfSSL-py can be found here. In addition the releases can be found on PyPi to be installed using `pip` here for wolfCrypt-py and here for wolfSSL-py. Contact facts@wolfssl.com for more information about using the wolfSSL embedded SSL/TLS library in your Python applications!

Check out this week’s schedule!

It’s a BUSY week! Check out all the trade shows we are attending below:

Cyber Physical Systems Security Summit in Troy, Michigan

IoT Solutions World Congress in Barcelona, Spain

Forum 78 in Fort Worth, Texas

CyberLEO in Los Angeles, California

Upcoming Webinar: Why everyone is using cURL and you should too

Join Daniel Stenberg, founder and maintainer of cURL and libcurl, as he goes through some basic curl fundamentals about what cURL is, who uses cURL, why use cURL etc. As well as giving information on how to customize your configuration, and other features that may be useful.

As always bring your questions for the Q&A following the presentation.

When: 9AM Pacific, May 12th, 2022

Register in advance here.

wolfTPM 2.4.0 Released!

We are excited to announce our wolfTPM v2.4 release. This includes improvements for Windows including support for cmake, C# wrappers, and c++ compiler fixes. This expands the wolfTPM cross platform API that is easy to use and supports Linux, Windows and embedded platforms. C# wrappers have been tested on Linux and Windows. These changes enable support for vcpkg for wolfSSL, wolfTPM, and wolfMQTT (see PR).

Release Details:

  • Fixes for c++ compiler (PR #206)
  • Adding a C# wrappers (PR #203)
  • CMake support (PR #202, #204, #205)
  • Add support for ST33 vendor specific command TPM_CC_GetRandom2 (PR #200)
  • Fix writing PEM in wolfTPM2_RsaKey_TpmToPemPub (PR #201)
  • Improve TPM2_SetupPCRSel (multiple calls) (PR #198)
  • Fix for a few spelling errors and whitespace cleanup (PR #199)
  • v2.3.1 updates (PR #197)
  • Fix make install by renaming pcr example read.c (PR #196)

For a full list of changes, check out the updated ChangeLog.md bundled with wolfSSL or view our page on GitHub here. For questions please email facts@wolfssl.com

wolfBoot 1.11 Released!

wolfBoot 1.11 has been released. This release introduces new algorithms for signature verification (Ed448, Ecc384), for integrity check (Sha2-384) and for external storage encryption (Aes128 and 256). Encryption support for external storage has been improved.

Our team introduced mitigation against glitching attacks. Find out more in this post.

Support for new targets has been included: NXP i.MX-RT1050 and STM32U5.

For the full list of changes, please see our Github page.

You can download the latest release here: https://www.wolfssl.com/download/
Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfBoot

Contact us at facts@wolfssl.com with any questions!

wolfSSL 5.3.0 Release!

wolfSSL has released a new version! 5.3.0.

This contains some exciting new additions and fixes. A full list can be found in the ChangeLog.md (https://www.wolfssl.com/docs/wolfssl-changelog/) but some of the highlights are:

  • SP performance enhancements and fixes
    • wolfSSL’s Single Precision (SP) Math Library bring the best implementations to insure the best performance of Public Key Algorithms 
  • Compatibility layer enhancements and function additions
    • The wolfSSL OpenSSL compatibility layer is a means to switch applications designed for OpenSSL over to use wolfSSL.
  • Embedded post quantum port on an STM32 device and benchmarks
  • CAAM support for i.MX8 on Linux
    • CAAM (Cryptographic Accelerator and Assurance Module) is hardware that can be found on many i.MX NXP devices. When used it speeds up the cryptographic algorithms such as ECC and AES. 
  • Updates to Renesas TSIP support, Stunnel, Bind and other ports…
  • Additions and improvements to testing including use of Wycheproof
    • Project Wycheproof is a test suite developed and maintained by the Google Security Team. Their unit tests use Java security packages (java.security and javax.crypto) to allow for multiple JCA/JCE provider implementations to be tested, including wolfJCE.

A full list of what was changed can be found in the wolfSSL ChangeLog (https://www.wolfssl.com/docs/wolfssl-changelog/).

For questions about wolfSSL or about the latest release contact us at facts@wolfssl.com

Upcoming Webinar : Everything you need to know about Securing Medical Devices!

Story time with wolfSSL! Join us for a comprehensive presentation on how to leverage wolfSSL for all of your Medical Device needs as we go through a variety of different use cases and example with the specific engineering details for each story.

As always bring your questions for the Q&A following the presentation.

When: Apr 28, 2022 09:00 AM Pacific Time (US and Canada)
Topic: Everything you need to know about Securing Medical Devices!

Register in advance for this webinar:
https://us02web.zoom.us/webinar/register/WN_a7LU9jA_SMmhSZo5oxz87Q

After registering, you will receive a confirmation email containing information about joining the webinar.

If you have any questions or comments contact us at facts@wolfssl.com

 

Constant Time Testing

It is no secret that wolfSSL makes every effort to provide the best tested cryptographic and SSL/TLS solution available on the market.

To that end, wolfSSL is proud to announce that as of today there is a suite of Constant Time Tests evaluating two of the three big integer math libraries wolfCrypt offers that have support for constant time execution.

Big integer math libraries natively available in wolfSSL are:

    1. sp_int.c
      1. Use setting –enable-sp=yes to use this library
      2. For non-Autoconf builds use setting(s)
        1. WOLFSSL_SP
        2. WOLFSSL_HAVE_SP_RSA
        3. WOLFSSL_HAVE_SP_ECC
        4. WOLFSSL_HAVE_SP_DH
        5. (optional) WOLFSSL_SP_SMALL (reduced footprint)
      3. Stack based math library with optimized math, faster than tfm.c

 

  • Constant time support for all algorithms: RSA, DH, and ECC

 

    1. tfm.c
      1. Default on Linux (no setting needed to use)
      2. For non-Autoconf builds use setting USE_FAST_MATH to enable this library
      3. Stack based (large static buffer), enjoys better performance

 

  • Constant time for only two algorithms (RSA and ECC)

 

    1. integer.c
      1. Use setting –disable-fastmath on Linux to use this library
      2. Avoid the setting USE_FAST_MATH to use this library when building with non-Autoconf solutions (IDEs’, Makefiles, whenever user_settings.h is used etc.)
      3. Heap based, suffers overhead of alloc/free at the benefit of only the needed resources.

 

  • Not-constant time, avoid if concerned about timing attacks

 


Note: None of the above applies to externally implemented hardware and/or software solution(s). IE when using the crypto callbacks to offload operations to an external cryptographic module or using external quantum safe solutions such as liboqs etc.

wolfSSL is also evaluating constant time execution for the following algorithms that do NOT depend on any of the three big integer math options: AES-CBC, AES-GCM, ChaCha20, Poly1305, SHA2-256, SHA2-512 and X25519 (AKA “Curve25519”)

If you would like to know more please do not hesitate to reach out to wolfSSL anytime by contacting facts@wolfssl.com or support@wolfssl.com.

Doing Crypto Without Malloc’s

wolfSSL has easy options for building and running without any malloc’s! Avoiding the use of all dynamic memory can be important in many environments, including safety critical ones and the use with satellites, being one of NASA’s 10 rules to not use any dynamic memory after initialization. The easy build options for no system malloc’s helps wolfSSL be used under these stringent requirements. Along with being able to do crypto operations with the no malloc build, wolfSSL can also support full TLS handshakes with no malloc’s!
To build wolfSSL with no dynamic memory –enable-staticmemory could be used. Examples and tests with setting aside the memory pools for the staticmemory build can be seen in the wolfcrypt/test/test.c file bundled with wolfSSL. By default this falls back to malloc when no static memory is available, to avoid this fallback mechanism to system malloc’s the macro WOLFSSL_NO_MALLOC must also be defined. In addition to the staticmemory enable option there is a nomalloc version with our SP (single precision) asymmetric performance speed ups too! This could be enabled with –enable-sp=nomalloc when using autoconf.

For more information about porting wolfSSL and using the no malloc build contact us at facts@wolfssl.com.

Secure Boot and Glitching Attacks

In general, a “glitch” is a momentary fault that may happen on a system, preventing it from working properly, for a brief amount of time. The effects of a single glitch on proper software execution may be multiple, including catastrophic consequences that may prevent the system from continuing the execution.

Glitching attacks are complex and expensive to execute, but can be a real issue for secure boot mechanisms, and often very hard to prevent or mitigate. They aim at exploiting predictable consequences of single glitches in order to take control of the execution or the data contained in the system. The glitch can be injected using different techniques, which often rely on well known weaknesses of the specific microcontroller or CPU. The most common glitch injection consists in varying the voltage supplied to the chip at a specific time, or modifying the profile of the clock signal to mangle the timing of the execution of the instructions. More advanced attacks can rely on irradiating the device with strong electromagnetic interference.

In the specific context of secure boot, the goal for an attacker is to circumvent the security checks in those critical sections of the code, e.g. the code that performs verifications on the firmware authenticity, integrity or versioning. These attacks could eventually defeat the security checks, and take control of the system by uploading an unauthorized firmware image. While they require an accurate synchronization and several attempts, these attacks will eventually succeed in injecting a fault in the hardware at the required time in order to skip the verification.

Our secure bootloader, wolfBoot, follows the indication of RFC9019 to provide a secure, public key based verification of the integrity and authenticity of the firmware and its updates. It runs on several different architectures, from small microcontrollers up to x86_64 systems. wolfBoot is OS-agnostic and provides best-in-class security thanks to the FIPS 140-2 certified algorithms implemented in the wolfCrypt security engine. 

wolfBoot already comes with plenty of unique features. Now it is also the first open source secure bootloader to implement mitigations against glitching attacks. Our development team has recently added an optional feature that can be activated at compile time, to reinforce the security of the critical variables and decision points in the code. This has required an evaluation of the code flow of wolfBoot from a point of view that includes the possibility for an attacker to skip single specific instructions. Introducing these mitigations has been tricky, because redundant code written in C is usually discarded by the compiler. For this reason the countermeasures must be programmed in assembly, which makes this code architecture specific.

The upcoming release of wolfBoot will contain a first version of these countermeasures, but glitching support mitigation already made it to our main branch on github, and it can be freely compiled and used in GPL projects for evaluation and auditing purposes.

To compile wolfBoot with glitching and side-channel attack mitigations turned on, it is sufficient to add ARMORED=1 to the configuration options (i.e. via command line when invoking make, or through the .config file). The ARMORED option is currently supported on ARM Cortex-M architecture. Support for other architectures will be added in the future.

You can download wolfBoot today from our download page or from our github repository

What is the next feature that you want to see implemented in wolfBoot? Is there any architecture or platform that we don’t yet support that could benefit from our glitch-resistant secure boot mechanism? Let us know! Drop us a line at facts@wolfssl.com.

Posts navigation

1 2 3 4 5 6 152 153 154

Weekly updates

Archives

Latest Tweets