RECENT BLOG NEWS

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

Love it? Star wolfSSL on GitHub!

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

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

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

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

This webinar will highlight wolfSSL’s Microchip partnership and our support for their microcontrollers and secure elements. We will discuss best practices for securing IoT devices using wolfSSL and Microchip. Join us to learn about using Microchip MPLABX and Harmony for embedded projects and use of the ATECC608 secure element with wolfSSL for TLS and MQTT.

Watch the webinar here: Securing loT Devices with Microchip Security Solutions and wolfSSL

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

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

Further to our previous announcement about bringing post-quantum KEMs in TLS 1.3 on STM32, we have also brought PQM4’s KYBER Level1 KEM into our benchmarking infrastructure. Note that we do not build PQM4 with optimizations as a bug fix is soon to come for optimization flags. You can monitor the progress of the issue here.

Once that is fixed, we’ll re-post our results on this blog. We run the benchmarks together with conventional algorithms so you can compare the results. Please see below:

[NUCLEO-F446ZE at 168MHz using SP Math with Assembly]

Running wolfCrypt Benchmarks…
wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
RNG                  1 MB took 1.004 seconds,    1.070 MB/s
AES-128-CBC-enc      1 MB took 1.000 seconds,    1.172 MB/s
AES-128-CBC-dec      1 MB took 1.008 seconds,    1.187 MB/s
AES-192-CBC-enc      1 MB took 1.000 seconds,    1.001 MB/s
AES-192-CBC-dec      1 MB took 1.004 seconds,    0.997 MB/s
AES-256-CBC-enc    900 KB took 1.007 seconds,  893.744 KB/s
AES-256-CBC-dec    900 KB took 1.004 seconds,  896.414 KB/s
AES-128-GCM-enc     75 KB took 1.094 seconds,   68.556 KB/s
AES-128-GCM-dec     75 KB took 1.094 seconds,   68.556 KB/s
AES-192-GCM-enc     75 KB took 1.118 seconds,   67.084 KB/s
AES-192-GCM-dec     75 KB took 1.117 seconds,   67.144 KB/s
AES-256-GCM-enc     75 KB took 1.134 seconds,   66.138 KB/s
AES-256-GCM-dec     75 KB took 1.130 seconds,   66.372 KB/s
GMAC Small          75 KB took 1.008 seconds,   74.405 KB/s
CHACHA               4 MB took 1.004 seconds,    4.426 MB/s
CHA-POLY             3 MB took 1.000 seconds,    2.905 MB/s
POLY1305            12 MB took 1.000 seconds,   12.183 MB/s
SHA-256              3 MB took 1.000 seconds,    2.832 MB/s
HMAC-SHA256          3 MB took 1.000 seconds,    2.808 MB/s
RSA     2048 public         78 ops took 1.016 sec, avg 13.026 ms, 76.772 ops/sec
RSA     2048 private         4 ops took 1.836 sec, avg 459.000 ms, 2.179 ops/sec
DH      2048 key gen         5 ops took 1.196 sec, avg 239.200 ms, 4.181 ops/sec
DH      2048 agree           6 ops took 1.439 sec, avg 239.833 ms, 4.170 ops/sec
ECC   [      SECP256R1]   256 key gen       113 ops took 1.000 sec, avg 8.850 ms, 113.000 ops/sec
ECDHE [      SECP256R1]   256 agree          54 ops took 1.008 sec, avg 18.667 ms, 53.571 ops/sec
ECDSA [      SECP256R1]   256 sign           78 ops took 1.019 sec, avg 13.064 ms, 76.546 ops/sec
ECDSA [      SECP256R1]   256 verify         38 ops took 1.012 sec, avg 26.632 ms, 37.549 ops/sec
kyber_level1-kg         62 ops took 1.004 sec, avg 16.194 ms, 61.753 ops/sec
kyber_level1-ed         28 ops took 1.043 sec, avg 37.250 ms, 26.846 ops/sec
Benchmark complete

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

Watch our webinar with Sr. Engineer and Security Expert Daniele Lacamera!

Connected embedded systems that support remote updates of different artifacts must take into account the security risks involved. A secure boot mechanism is the best way to prevent the execution of unauthorized code. Our universal, open-source, secure bootloader, wolfBoot, takes care of authenticating and installing new valid firmware images. Due to its transport-agnostic update management, it can be combined with any secure transfer implementation to provide secure and reliable firmware updates.

In this short webinar, we explore some of the possibilities of real-life secure firmware update solutions, designed using the latest standards and best cryptography algorithms.

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

Watch the webinar here: Secure Boot and Remote Firmware Updates

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 wolfSSL / wolfCrypt libraries support asynchronous (non-blocking) crypto using external hardware acceleration with the Intel QuickAssist and Cavium Nitrox III/V adapters. These are PCIe devices that accelerate crypto operations. Use of the asynchronous hardware acceleration support significantly increases performance for server platforms requiring high connection rates and throughput.

For some performance numbers see this page: https://www.wolfssl.com/docs/intel-quickassist/

We also support asynchronous offloading to custom asymmetric hardware or a keystore using our PK callbacks (–enable-pkcallbacks). This is supported with all versions of TLS. Examples can be found in https://github.com/wolfSSL/wolfssl-examples/blob/master/tls (see server-tls-pkcallback.c and client-tls-pkcallback.c).

For the software based asymmetric math, wolfCrypt supports a non-blocking mode for RSA and ECC crypto operations. This is useful in a bare-metal environment to allow wolfSSL to split heavy math operations into smaller chunks of work allowing you to interleave servicing of real-time events. For ECC see –enable-ecc=nonblock or WC_ECC_NONBLOCK (doc). For RSA see WC_RSA_NONBLOCK (docs) 

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 was at Satellite again this year to engage in a key conversation in the Satellite community: ensuring that satellite devices are as secure as possible. In a world where attackers are more motivated and more sophisticated, the core cybersecurity technologies that wolfSSL provides can give users the assurance that they’re device won’t get bricked, hacker parlance for a useless device, which just happened last month.

The story goes like this: American company providing high-speed satellite internet coverage in Europe was the target of a cyberattack on the morning of February 24. The attack caused an outage of services in Ukraine, and other European countries, including Germany. Commander General Michel Friedling confirmed that this indeed was a cyberattack that had originally targeted KA-SAT SATCOM terminals in Ukraine. It is suspected that the attack targeted the ground stations by being able to exploit a misconfiguration of a management section of the satellite network to gain access and subsequently ‘brick’ the receivers by either mangling or replacing their firmware. This is an example of an attack that could have been mitigated by wolfBoot secure boot and FIPS 140-2 cryptography.

The above referenced company is not the only satellite internet provider being targeted. Starlink activated their service in the Ukraine and has already faced multiple malicious attempts to disrupt the service which prompted this tweet from Elon Musk:

“Important warning: Starlink is the only non-Russian communications system still working in some parts of Ukraine, so probability of being targeted is high. Please use with caution.”

Cybersecurity experts warn of a spillover effect in which these repeated attacks stemming from the Ukraine and Russia conflict could impact global infrastructure. Although the details of the recent attacks are still under investigation, it is in your best interest to consider how wolfSSL fortifies cybersecurity efforts. Our TLS, secure boot and cryptography libraries are used by every branch of the US military, which means we are deployed in everything from tanks and missile systems to satellites and aircraft.

wolfBoot, our secure bootloader, secures satellites by ensuring that any firmware update is signed and verified by our wolfCrypt FIPS 140-3 cryptography library. We also support TLS 1.3 or SSH for secure delivery of the updated firmware, should you be concerned about the security of your network connection and potentially subject to man in the middle attacks. wolfSSL can run ‘over the top’ of the various satellite communications standards.

Help us to help you keep your device from becoming a “Billion Dollar Brick” and contact us to hear more about our wolfSSL library, the wolfCrypt encryption engine, wolfBoot Secure Bootloader, wolfSSL Support for DO-178C DAL A, or to simply meet the wolfSSL team.

Connect with wolfSSL on LinkedIn: https://www.linkedin.com/company/wolfssl/

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 Inc. is pleased to let our customers know that the CMVP has approved 22 new operating environment (OE)  additions to the wolfSSL 3389 FIPS certificate in February and March!

2021 saw long delays and excessive wait times from the CMVP that had many near the limits of their patience. However, the CMVP has now approved 10 OE additions that were submitted by wolfSSL in July of 2021 (yes it was a LONG wait) on Valentines’ day and another 12 OE additions were approved less than 30 days later on March 15th for a total of 22 OE additions to round out Q1 of 2022!

After the frustrations of 2021 this has been a nice turnaround at the start of 2022 and wolfSSL staff will continue to work feverishly on customer OE additions as they are needed and demand arrises!

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