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.

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

Webinar Alert: Kernel Mode

Watch our webinar about Kernel Mode presented by wolfSSL engineer Daniel Pouzzner tomorrow at 10AM Pacific.

In December 2020, wolfSSL 4.6.0 featured initial support for building as a Linux kernel module, supplying the entire native wolfCrypt and wolfSSL APIs directly to other kernel modules.

We have support with in-kernel FIPS 140-3, additional accelerated cryptography options on x86, and substantial improvements in stack usage.

Porting a library as large and complex as wolfSSL to the Linux kernel has been a multi-phase undertaking, guided by three key objectives:

A build process that is completely turnkey on supported kernel lines, via configure –enable-linuxkm and –with-linux-source=/source/tree/top.

A source tree that remains unified: the library and the kernel module are built from the same codebase, and differ only in various settings, and in kernel-specific glue logic.

Module builds that use the Linux in-tree Kbuild toolchain, rather than a bespoke out-of-tree build system, to facilitate simultaneous and continuing support for a wide variety of old and new kernel releases.

The Linux kernel is not a POSIX target, and many facilities commonly available to libraries and applications are unavailable (e.g. stack red zones, the C library, thread-local storage) or severely restricted (e.g. stack depth and vectorized instructions). Additionally, each minor kernel version and hardware target has peculiarities that cannot be ignored.

In this presentation, we will chronicle some of the challenges we encountered porting wolfSSL to this unusual target, and the solutions we developed.

As always we will have a Q&A Session following the webinar.

Watch the webinar here: Linux Kernel Mode

New wolfSSL Documentation Launched

Over the past few months the engineering team at wolfSSL have been working on a new reference documentation system for all of the wolfSSL products. The first fruits of this can be found in the form of the wolfSSL library documentation which is also available in PDF form.

This project had several goals:

  • Update the documentation as much as possible
  • Unify documentation locations and standards
  • Reduce the barrier of entry to getting new edits into the documentation
  • Reduce the barrier of entry to consuming the documentation
  • Create methods of automatically building and deploying the documentation

The documentation source itself is in two parts, the first is the long form documentation pages which were previously shared documents to be edited. These are now Markdown documents in a GitHub repository. The second part is the Doxygen reference you can find in the repository with the code. Our new build system dynamically converts the Doxygen to Markdown, merges it with the long form pages, does some other minor cleanups and manipulations and then generates HTML and PDF outputs.

There are now fully working cross-links in the documentation to learn more about specific options and the formatting has been standardized across the entire documentation.

Over the coming weeks we will be automating the build and deployment of the documentation so it is always up-to-date every day. We will also be releasing documentation using the same system for the full suite of wolfSSL products. We will also be making edits over time to refine and improve the documentation that is there. We welcome any feedback to support@wolfssl.com!

For other questions about the wolfSSL embedded SSL/TLS library, TLS 1.3, or other products, contact us at facts@wolfssl.com.

wolfCrypt Submitted for FIPS 140-3!

After much work, wolfSSL is proud to announce that wolfCrypt v5 has been submitted to the CMVP and wolfCrypt is on the Modules in Process list for FIPS 140-3 Approval.

We’ve added more algorithms to our testing. We have AES-OFB mode. We added the TLSv1.2 and TLSv1.3 KDFs, including the extended master secret, and the SSH KDF. We’ve also testing 4096-bit RSA and ECDSA with SHA-3.

If you need to use TLSv1.3 in a FIPS environment, we have you covered! wolfCrypt FIPS also works with our other products including wolfBoot, wolfEngine, and wolfSSH.

More about FIPS 140-3

FIPS 140-3 is an incremental advancement of FIPS 140-2, which now standardizes on the ISO 19790:2012 and ISO 24759:2017 specifications. Historically, ISO 19790 was based on FIPS 140-2, but has continued to advance since that time. FIPS 140-3 will now point back to ISO 19790 for security requirements. Keeping FIPS 140-3 as a separate standard will still allow NIST to mandate additional requirements on top of what the ISO standard contains when needed.

Among the changes for FIPS 140-3 are conditional algorithm self-tests, where the algorithm self-tests are only performed if used. The pre-operational self-test is now faster, as all the algorithms are not tested until needed. This helps with startup times as the public key self-testing can be time consuming. The self tests can be run at appropriate times for your application startup. Also, there is additional testing of the DRBG entropy sources.

For more information, please visit our FIPS page here.

If you want an up to date cryptography library and TLS stack that is ready for FIPS 140-3, contact us at fips@wolfssl.com.

Love it? Star wolfSSL on GitHub!

Webinar Alert: Looking Under the Hood – wolfSSL Automotive Stories and Examples!

Story time with wolfSSL! Join us for a comprehensive presentation on how to leverage wolfSSL for all of your Automotive Security 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.

Watch the webinar here: Looking Under the Hood – Everything about Automotive Security

wolfEngine 1.0.0 Released

We’re happy to announce the first major release of wolfEngine, version 1.0.0. This release brings several improvements to wolfEngine. Here are some notable ones:

– Improved Visual Studio support.

– Improvements to the initialization code to support our upcoming FIPS 140-3 module.

– A rework of the AES-GCM implementation to support all OpenSSL use cases.

– New control commands for enabling wolfSSL debug logging.

– Better logging around the failure of the FIPS integrity check.

– A set of examples in the examples/ subdirectory.

– Additional HMAC functionality.

If you’re interested in using wolfEngine to satisfy FIPS requirements, please reach out to facts@wolfssl.com and we can discuss getting you a commercial version!

 

wolfSSL Supports git

wolfSSL has added support for git 2.35.1. git is a version control system that handles projects of all sizes. It is capable of handling the version history of projects all the way up to the size of the Linux kernel. git uses SSL/TLS for its imap-send command. This command sends a collection of patches from stdin to an IMAP folder. git can also be configured to use the crypto library for all SHA-1 and SHA-256 hashing. wolfSSL supports all of this functionality in our port. (https://github.com/wolfSSL/osp/tree/master/git)

Compile wolfSSL with

./configure --enable-opensslextra

make

make install

Compile git with:

patch -p1 < /path/to/our/patch

make USE_WOLFSSL=1 OPENSSL_SHA1=1 OPENSSL_SHA256=1

make USE_WOLFSSL=1 OPENSSL_SHA1=1 OPENSSL_SHA256=1 install

git uses external dependencies for most of its communication protocols. The two more common protocols used within git are https and ssh. git builds and links against the system available curl for http and https support and uses the ssh utility that is available at runtime in $PATH for ssh support. To use only wolfSSL in git make sure that all dependencies are using wolfSSL. curl can be built to use wolfSSL using a configure option (https://everything.curl.dev/source/build/tls#wolfssl) while you can build OpenSSH against wolfSSL using our patches (https://github.com/wolfSSL/osp/tree/master/openssh-patches).

To find out more please email facts@wolfssl.com.

Posts navigation

1 2