Month: March 2022

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

Please join us March 31st at 9AM Pacific (US and Canada) for our upcoming 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

Register here.

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) 

To find out more or get an evaluation bundle please email facts@wolfssl.com.

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/

Email us at facts@wolfssl.com

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 about the OE addition process, current CMVP wait times or anything else FIPS related, please do not hesitate to reach out to fips@wolfssl.com anytime!

 

 

Today we have some exciting news! We here at wolfSSL would like to announce that we have achieved a TLS 1.3 connection where the group used for key establishment was KYBER_LEVEL1 and the connection was between an Ubuntu Linux x86_64 machine and an STM32 NUCLEO-F446ZE with an ARM Cortex M4 chip running on bare-metal. We used a generic UART TTL to USB cable.  On the x86_64 side we plugged the cable into the USB port while on the ARM Cortex M4 side we connected to the UART headers. Either side can be the server or the client. 

Some might be wondering how this was achieved as wolfSSL integrates with liboqs for its post-quantum algorithm implementations, but liboqs does not support being built for STM32. The answer is that wolfSSL has a new integration with the OQS team’s sister project, MUPQ team’s pqm4 project. Since the algorithm artifacts interoperate between liboqs and pqm4 and wolfSSL is on both sides, there is full interoperability.  Notably, this should also interoperate with the OQS team’s fork of OpenSSL.

So, does this really matter? In our opinion, yes! A lot of great work has been done showing the impact that post-quantum algorithms will have on The Internet. There are several academic papers and at-scale experiments with some very interesting results that, generally speaking, show that the Internet is ready for post-quantum algorithms. But what about constrained and low-resource devices?  What about IoT? With larger cryptographic artifact sizes and for some operations, more need for processor power, these algorithms have potential to heavily impact constrained and low-resource devices.

Experimentation in these domains has been less forthcoming, likely due to the lack of a TLS stack integrated with post-quantum algorithm implementations for embedded platforms. Now that changes.  Now, you can start experimenting with post-quantum algorithms using TLS 1.3 to understand the impact on your embedded projects.

In the coming weeks, you can look forward to an example STM32CubeIDE project and a recorded webinar about how you can get started with post-quantum key establishment over TLS 1.3 on STM32 devices.

Currently, only KYBER_LEVEL1 is supported. Want other algorithms and variants? Want hybrids? Want to know when the example project and webinar will be released? Get in touch with your sales representative or email us at facts@wolfssl.com to start a discussion.

 Secure shell and file access for embedded systems

Unlike embedded Linux, or rich CPU-based systems, embedded systems running on a microcontroller rarely have support for file systems. Most often these devices run a firmware stored on a flash memory. However, more advanced microcontroller-based systems designed for edge computing offer the possibility to connect non-volatile storage devices, such as SD or MMC cards, non-volatile random-access memories and solid-state drives. In these cases, a bare-metal or RTOS-based system may benefit from a lightweight filesystem implementation, for standard read/write file access and directory management.

wolfSSH offers all the functionality of a SSH server and client in a compact and microcontroller friendly library. It implements SSH protocol v.2 with both password and public key based authentication. The SSH protocol is mostly famous for the secure shell feature on UNIX-like systems, used by administrators to control and automate process execution on remote systems. SSH however provides file transfer support via SCP, and more advanced file system access via SFTP.

wolfSSH implements SCP and SFTP for any embedded system, giving the possibility to customize the actions associated with remote filesystem access operations. A system with no filesystem support can still implement rudimentary operations on hardcoded file paths very easily, by defining use-case specific callbacks. Even without any actual filesystem, it is still possible to respond in a custom way to specific SFTP or SCP commands. A common usage, like the one shown in this FreeRTOS based example,  is using SSH for remote secure firmware updates, uploading a new version of the firmware binary image as a file, e.g. via SCP. The embedded target does not actually have a file system but it receives the content of the remote file and stores it in a flash memory partition. Afterwards the application can delegate the secure bootloader, e.g. wolfBoot, to consider and process the update package for installation.

Customizing file I/O operations on non-POSIX systems can be done by defining WOLFSSH_USER_FILESYSTEM at compile time, and then assigning callbacks to I/O operations. A minimal set of calls for file management may include WFOPEN, WFCLOSE, WFWRITE, WFREAD, WFSEEK; although the full set of POSIX operations for subdirectory handling, file statistics, permission management and more are supported when running wolfSSH with SFTP on POSIX machines.

FatFS support

Using a lightweight FatFS implementation to store data in embedded systems has several advantages. Removable memory supports such as SD or MMC cards can be accessed offline by any PC host if required. On those microcontrollers supporting USB-OTG, internal block devices can appear as USB drives when the device is connected to a USB host.

ChaN’s FatFS (http://elm-chan.org/fsw/ff/00index_e.html) is a popular lightweight Open Source FAT implementation suitable for microcontrollers and distributed along with many BSP provided by hardware manufacturers, often as optional middleware package. FatFS exposes two interfaces: the API to be used by the application to access the filesystem, and the MAI (media access interface) to attach the I/O to any block-based storage system. Many embedded developers use this library even if there is no specific need for FAT format, simply because it is a complete filesystem implementation with a small footprint, provides a friendly, POSIX-inspired, well documented API,  and it is easy to integrate with any physical storage medium.

Since version 1.4.7, wolfSSH offers a fully featured, pre-packaged integration with ChaN’s FatFS. By adding the compile-time option WOLFSSH_FATFS, wolfSSH will automatically map the file and directory callbacks to the corresponding function in the filesystem implementation. This means that there is no additional ‘glue code’ needed to integrate wolfSSH to provide remote secure file access and directory management.

wolfSSH is the easiest way to implement SFTP and SCP on embedded targets. Adding wolfSSH to an existing connected system simply consists in providing send and recv callback functions to communicate over a TCP socket. For SFTP and SCP support a filesystem implementation, real or emulated, is required as well to respond to remote file and directory access requests, and wolfSSH offers a flexible interface to integrate with any filesystem implementation.

On those platforms where FatFS support is already included with the board support package or the real time operating system in use (e.g. ST CubeMX, NXP MCUXpresso), the integration of wolfSSH with the existing filesystem has now been made even easier. Setting up a thread in a RTOS with a SSH daemon providing SFTP access is a matter of a few lines of code, needed to set up SSH certificate, passwords and public keys. The target system will start accepting SSH connections and exchanging files from any compatible SFTP client.

If you would like to see more filesystems supported in wolfSSH, or see it ported to other platforms, or if you have any questions or suggestions, please send us a note at support@wolfssl.com or visit the product github page https://github.com/wolfssl/wolfssh

We are excited to tell you about our partner collaboration with STMicroelectronics! This collaboration is a video series about wolfBoot, a secure bootloader and the STM32, a family of 32-bit microcontrollers.

This will be at least a 4 part video series with the third release 

Video 1: wolfBoot for STM32, Part 1: Overview https://www.youtube.com/watch?v=9R4Gl0qrzZ0

• “Overview of the wolfSSL products and the wolfBoot support for STM32 devices. The wolfBoot product features such as secure boot, measured boot, encrypted partitions and root of trust (in the bootloader, TPM or secure element). Comparison of the SBSFU, TFM and wolfBoot options for STM32 micro-controllers. Implementation details for design of wolfBoot and how the partitions are defined.”

Video 2: wolfBoot for STM32, Part 2: Getting Started https://www.youtube.com/watch?v=e5VwYA5kknA

• “How to download wolfBoot, where to find files and documentation. The wolfBoot product features such as secure boot, measured boot, encrypted partitions and root of trust (in the bootloader, TPM or secure element).”

Video 3:wolfBoot for STM32, Part 3: Out of the Box Experience https://youtu.be/VrgooHCoUNk

• “How to configure, build, run, and debug wolfBoot on NUCLEO-G071RB board.”

Video 4: How to expand the wolfBoot HAL support for a new target.

Stay tuned for more information on when the next part of this video series goes live.

Additional Resources

• https://www.st.com/en/embedded-software/wolfboot.html
• https://www.wolfssl.com/products/wolfboot/

Please contact us at facts@wolfssl.com with any questions about the webinar.

For technical support, please contact support@wolfssl.com or view our FAQ page.

In the meanwhile, check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL.

wolfLCU 0.0.8 is available! wolfCLU is the wolfSSL (Command Line Utility) and is meant to be used for simple key generation, certificate operations, and more. It is being developed to also be an alternative for the commonly used OpenSSL command line utility. There were vast feature enhancements over the last release. Support for several new commands were added in.

• rand
• pkcs12
• s_client
• verify
• rsa
• crl
• ca
• dsaparam
• sha256, sha384, sha512
• dhparam

This release also included some fixes. A running list of changes can be found in the bundled ChangeLog.md. Visit our alternatives download page or https://github.com/wolfssl/wolfclu for downloading the bundle. Email us at facts@wolfssl.com with any questions.

Great news, wolfSSL is thinking about adding a Rust wrapper this year! The wolfSSL embedded TLS library is a lightweight, portable, C-language-based SSL/TLS library known for its low footprint, speed, and feature set. Users have been able to take advantage of our library not only in C but also in their Java, C#, Python, and JavaScript projects using the various wrappers we provide. And in 2022, we’re interested in adding Rust to that list.

Similar to C, Rust is a low-level programming language with direct access to hardware and memory, which will make our wolfSSL Rust Binding/Wrapper a great SSL/TLS solution for embedded and IoT development for Rust projects.

Are you interested in a Rust wrapper?

Contact us at facts@wolfssl.com with any questions, comments, or suggestions.