Author: Kajal Sapkota

McKinsey and Company have release the following report “When – and how – to prepare for post-quantum cryptography” https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/when-and-how-to-prepare-for-post-quantum-cryptography

In it they outline some options regarding how you can handle the coming migration to post-quantum cryptography. Here is a brief summary of their options our response:

Option 1: Adopt post-quantum cryptography solutions today

While adopting one of these solutions might seem to be the best path for any company that needs to act today, there are trade-offs and drawbacks to consider…

The wolfSSL library already has post-quantum algorithms integrated. Let us help you understand these new trade-offs. Don’t worry, speed and performance won’t be a major factor. Please see our benchmarks: https://www.wolfssl.com/docs/benchmarks/

Option 2: Retrofit systems with post-quantum cryptography solutions later

Finally, organizations should begin building long-term relationships with relevant suppliers, regulators, and peers within and outside of their industries as soon as possible. These relationships will be critical for staying up to date on emerging standards and solutions for PQC. … collectively developing solutions, for example, could cost less than if an organization devised solutions on its own.

The wolfSSL Team has a long and stable history of providing quality open-source software for security protocols and we are here to stay. We are here to help you find the right solution that will help you comply with industry standards and interoperate with your peers.

Option 3: Focus only on enhancing traditional encryption protocols

Decision makers should also begin planning for future updates to long-lasting systems by, for instance, evaluating the modularity of their technological architecture.

The wolfSSL Team also provides various consulting services. We can help you update to the latest standards while becoming more flexible and agile to prepare for the coming post-quantum migration.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

We’re happy to announce that wolfEngine 1.1.0 has been released! wolfEngine is an OpenSSL engine that helps users migrate to a FIPS-validated cryptography library (wolfCrypt) all while continuing to use OpenSSL. This new version fixes a couple bugs and adds support for RSA signatures with X9.31 padding. Additionally, the example OpenSSL configuration file, engine.conf, and the examples subdirectory are now part of releases.

If you are interested in a commercial version of wolfEngine or our wolfCrypt FIPS 140-2 or 140-3 modules!

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

The cURL Project and wolfSSL are sorry to inform you that Daniel Stenberg tested positive for COVID-19 this morning, and is unable to fly to the US for the cURL Up event. We have decided to cancel the cURL Up event happening June 6th. We are planning on rescheduling cURL Up for sometime in September.

Thank you for your understanding. Stay tuned for more news.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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.

Our latest release of wolfBoot contains these countermeasures. Glitching support mitigation 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! 

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

For a while now, wolfSSL has supported post-quantum algorithms in the TLS 1.3 protocol. Now, we also support it in the SSH v2.0 protocol as well!

Our wolfSSH library has long had support for SSH v2.0 both as a client and server.  Recently, we integrated the SABER NIST Level 1 KEM into wolfSSH allowing you to start experimenting with a post-quantum algorithm with wolfSSH. For instruction on how to try it out on Linux, please see the Post-Quantum section of wolfSSH’s README.md file which can be found at https://github.com/wolfSSL/wolfssh#post-quantum . This is done via an integration with the OpenQuantumSafe project’s liboqs.

Want other post-quantum algorithms? Want other security levels? Want to us hybridize with other algorithms?

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

We have added support for RISC-V hardware in our wolfBoot library. The reference example uses the SiFive HiFive1 FE310 board to demonstrate a secure bootloader and firmware upgrade.

The HiFive1 is a 32-bit E31 RISC-V core capable of running at 320MHz. It includes 4MB of external flash and 16KB of internal RAM.

The wolfBoot library provides:

• Boot validation of the firmware image using hash and signature
• Reliable firmware update (power fail safe).
• Rollback support if application does not report “success”
• Version checking to prevent downgrade attack
• Support for external flash on updates

This adds support for:

• RV32 Hardware Access Layer (HAL) support for:
  • PLL Clock configuration
  • Flash eSPI
  • UART
  • RTC
• Firmware update example using the serial interface

Full setup and installation instructions can be found in “docs/Targets.md”.

These new features can be found on GitHub here:

https://github.com/wolfSSL/wolfBoot/pull/14

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSH release version 1.4.10 is available! It includes many useful code additions including some fixes. To name a few the ESP–IDF use has been expanded on, small stack improvements made, some SFTP use fixes, fixes for warnings with older GCC compilers and more….

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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/).

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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.

Topic: Everything you need to know about Securing Medical Devices!

Watch the webinar here: Everything you need to know about Securing Medical Devices

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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. 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. 2. 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. 2. 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 have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.