RECENT BLOG NEWS

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

This is a 4 part video series showing how to use wolfBoot on various STM32 microcontrollers.

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: wolfBoot for STM32, Part 4: STM32U5 https://youtu.be/dzcmscEyrKM

• “How to configure, build, run and debug wolfBoot on STM32U5 (B-U585I-IOT02A) development board”

Please contact us at facts@wolfssl.com if you would like to receive a copy of the slides.

Additional Resources

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

• https://www.wolfssl.com/products/wolfboot/

Please contact us at facts@wolfssl.com or call us at +1 425 245 8247 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.

One of the features that makes wolfSSL stand out from other SSL/TLS libraries is its wide range of support for many hardware cryptographic accelerators. In particular, wolfSSL leverages the cryptographic accelerators built into the NXP i.MX6 and i.MX8 processors. How it uses the CAAM with i.MX6 and i.MX8 is dependent on the OS being used, varying from our own drivers to making use of existing drivers. With MCUEXPRESSO the use of NXP’s CAAM driver is leveraged and expanded on.

Recently, wolfSSL added support for the NXP i.MX RT1170 processor. The i.MX RT1170 is a powerful microcontroller that is designed for use in a wide range of applications, including industrial automation and medical devices. This new port of wolfSSL to the i.MX RT1170 takes advantage of the processor’s built-in cryptographic acceleration features, using the CAAM to perform fast and secure cryptographic operations.

Overall, the addition represents a significant improvement to the wolfSSL library for users of the i.MX RT1170 processor. By taking advantage of the CAAM hardware accelerator on the i.MX RT1170, wolfSSL is able to offload cryptographic operations and make ECC operations more secure with the use of black encrypted keys, making it an ideal choice for applications that require high performance and strong security. With the continued development of these features, wolfSSL is poised to remain a leading SSL/TLS library for resource-constrained environments.

If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247

Did you know that wolfSSL has been ported to and tested on Xilinx Versal hardware? There is support also in wolfSSL to make use of the Xilinx hardened crypto, enhancing both security and performance. Xilinx hardened crypto has accelerated crypto operations (SHA3-384 / AES-GCM / RSA / ECDSA) available on Ultrascale+ devices and is available for use with the latest and greatest Versal boards. wolfSSL makes these calls using the API from Xilinx’s XilSecure library (https://github.com/Xilinx/embeddedsw/tree/master/lib/sw_services/xilsecure) and with the addition of Versal there was minor changes to the existing calls to make use of the new features available (ECC / RNG / AES-GCM with AAD). When benchmarking we saw well over a Gigabyte per second with AES-GCM operations in our demo and improvements in performance of RSA, ECDSA, and SHA3-384 over software only implementations.

A previous white paper going into the setup and use of wolfSSL on older Ultrascale+ devices with Xilinx hardened crypto can be found here (https://docs.xilinx.com/v/u/en-US/wp512-accel-crypto). The support for Versal along with a README can be found in the wolfSSL bundle located in IDE/XilinxSDK/. 

If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247

Would you like to learn more about how SSL/TLS work, or more about the wolfSSL lightweight SSL library? If so, wolfSSL is offering a training course on SSL/TLS and wolfSSL. The FREE 2 day (4 hours each day) wolfSSL training course covers details of SSL/TLS as well as the wolfSSL embedded SSL library. Participants will have the opportunity to learn the inner workings of the SSL/TLS protocols as well as further their knowledge of the wolfSSL embedded SSL library. Topics covered will include library design, building and getting started with wolfSSL, features, portability/customizability, certificates and keys, debugging and troubleshooting SSL, wolfSSL best practices, and details about the wolfCrypt cryptography library

Course Objectives:
Upon completion of the wolfSSL training course, attendees will:

– Achieve a basic understanding of how SSL/TLS work
– Learn the package and design of wolfSSL
– Effectively build wolfSSL for target platforms
– Learn effective wolfSSL debugging strategies
– Add wolfSSL to different client and server applications
– Learn best practices for adding wolfSSL to embedded, desktop/enterprise, or cloud applications or devices
– Develop using wolfSSL’s underlying cryptography library

As always, our webinars will include Q&A sessions throughout the webinar. Please make sure to register for both days to get full access to the course.

Watch the 2-Day wolfSSL Training videos!

• Day 1
• Day 2

If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247

As many people know, Chinese government regulators are now mandating use of SM2, SM3 and SM4 in critical systems, including automobiles, avionics, power systems, and communication systems.  Since many of our customers are multi-nationals that do business in China, they have been requesting the addition of these algorithms in wolfSSL products.

Today we are about to release our supported versions of SM2, SM3, and SM4, with the intention to release the ZUC stream cipher at some point this year to completely satisfy SM9.  We are also in contact with labs regarding support of OSCCA certification at some point in the future.

This is really great news for our customers selling into Chinese markets!

For those readers considering using wolfSSL products, here’s some additional notes:

1. The SM Ciphers will be fully supported in wolfSSL’s TLS 1.3 implementation.
2. wolfSSH, wolfBoot and our other products will support ShangMi ciphers.
3. ARM, Intel, and RiscV assembly is in the works for our SM implementations for maximum performance.
4. We will continue to support bare metal for ZUC, SM2, SM3, and SM4.
5. True to form, we have maximized performance and minimized size, so the ShangMi algorithms will work well for embedded systems use cases on a wide variety of microcontrollers (MCU’s).  They will be available for all of the MCU silicon that we currently support, including STM32, NXP i.MX, RISC-V, Renesas RA, RX, and Synergy, Nordic NRF32, Microchip PIC32, Infineon Aurix, TI MSP, and many others.
6. Our GPLv2 licensed versions of the SM ciphers will be made available on GitHub and for download.

Commercially licensed versions are available.

If you have questions about our support for the ShangMi ciphers and algorithms, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSH 1.4.14 is now available for download! This is the next version of our lightweight, IoT friendly SSH implementation. There were some good fixes and improvements made to the code base for this release. A couple of the notable additions were:

• Adding user authentication support for RSA signing with SHA2-256 and SHA2-512 (Following RFC 8332)
• Support for FATFS on Xilinx targets
• Post quantum security enhancements and interoperability testing

Also something of note for SCP users is that now wolfSSH_accept will return WS_SCP_INIT once ready to start performing the SCP operation instead of going on. wolfSSH_accept will then need to be called again once your application is ready to perform the SCP operation. This change was made to help with things like chroot jailing when allowing SCP operations with wolfSSHd.

This release also had some fixes for issues with wolfSSHd

• Fix for calling chdir after chroot with wolfSSHd when jailing connections on unix environments
• Fix for support with secondary groups with wolfSSHd

And in the recent bundle we closed out an edge case with SFTP on LWiP. Improving the portability of wolfSSH when used on embedded environments. For a full list of changes and fixes please view the ChangeLog.md bundled with wolfSSH. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Another new addition in our 5.6.2 release of wolfSSL is our TLS hardening option. This TLS hardening feature secures your TLS connections according to the recommendations in RFC 9325. When enabled, wolfSSL will:

• disable TLS versions older than 1.2
• disable cipher suites based on ephemeral finite-field Diffie-Hellman key agreement finite-field Diffie-Hellman key agreement (i.e., “TLS_DHE_*” suites)
• disable NULL ciphers
• disable anonymous ciphers
• disable legacy ciphers
  • RC4
  • static RSA
  • static DH
• disable the truncated HMAC extension
• for TLS 1.2, send the secure renegotiation extension and reject connections that don’t negotiate secure renegotiation

It is also possible to select either 112 or 128 bits of security. When 112 bits of security are enabled, wolfSSL will:

• require at least 2048 bit Diffie-Hellman keys
• require at least 2048 bit RSA keys
• require at least 224 bit Elliptic Curve keys

When 128 bits of security are enabled, wolfSSL will:

• disable 3DES ciphersuites
• require at least 3072 bit Diffie-Hellman keys
• require at least 3072 bit RSA keys
• require at least 256 bit Elliptic Curve keys

This feature may be enabled in wolfSSL by using the –enable-harden-tls flag.

RFC 9325 also has many recommendations for application and protocol developers. Some of these include:

• use ALPN to make sure that the traffic sent is interpreted by the correct application
• use a TLS-only channel instead of enabling dynamic upgrade from an unencrypted to an encrypted channel
• avoid the use of zero round-trip time (0-RTT) data in TLS 1.3 unless “an explicit specification exists for the application protocol in question to clarify when 0-RTT is appropriate and secure”

We highly recommend reading through the RFC and checking how you can make your project as secure as possible.

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

One of the unique wolfSSL features is the ability to run wolfSSL on bare-metal without any Real-Time Operating System (RTOS). Supporting bare-metal has always been a requirement for our libraries from initial development. Having a pure C code base, no external dependencies, portable design and modular build options enables this feature and provides a tiny build size. This is a huge differentiator compared to libraries like OpenSSL that won’t even build without a POSIX layer. The build options to enable bare-metal are (–disable-filesystem –enable-singlethreaded) or (SINGLE_THREADED and NO_FILESYSTEM).

Another unique feature of wolfSSL is our support for managing and handling longer asymmetric math computations, which may have non-deterministic execution times. We achieve this by dividing the workload into smaller chunks, allowing the CPU time to perform other tasks concurrently. We call this feature non-blocking cryptography. We support it for RSA, ECC (256/384/521) and Curve25519. Our goal is to limit any blocking on an embedded target to a maximum of 1ms. We used a generic Cortex M4 at 100MHz as our reference. This functionality, for example, allows you to service real-time events while performing a TLS handshake or signature validation. We take pride in being the only open source TLS/Cryptographic library supporting this non-blocking cryptography feature.

From the caller’s perspective, non-blocking cryptography appears much like a non-blocking socket, where the API will return a FP_WOULDBLOCK status and requires being called again. This capability is supported both through the TLS API’s and wolfCrypt directly.

For additional information, please consult the related documentation links and pull request provided below:

• ECC (–enable-ecc=nonblock or WC_ECC_NONBLOCK):
  • https://www.wolfssl.com/documentation/manuals/wolfssl/group__ECC.html#function-wc_ecc_set_nonblock).

• RSA (WC_RSA_NONBLOCK):
  • https://www.wolfssl.com/documentation/manuals/wolfssl/group__RSA.html#function-wc_rsasetnonblock
  • https://github.com/wolfSSL/wolfssl-examples/tree/master/pk/rsa

• Curve25519 (WC_X25519_NONBLOCK):
  • https://github.com/wolfSSL/wolfssl/pull/5764

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

At wolfSSL we are always trying to make the security developer’s job easier. We’ve found that a common problem facing our customers is the need to convert between PEM and DER.

PEM is a Base64, ASCII encoding that is used for X.509 certificates, certificate requests and cryptographic keys. DER is a binary encoding and is much more compact.

CAs commonly supply X5.09 certificates in PEM format. For embedded applications, a DER formatted version is stored for use instead. The new PEM example makes this easy.

The example is compiled as part of the standard distribution, assuming the required features are built into wolfSSL. To convert a PEM file to DER, use the following command line:

./examples/pem/pem -in <file.pem> -out <file.der>

Another common customer situation is that they have an encrypted private key and want to get the unencrypted key as DER. To decrypt a PEM encoded private key:

./examples/pem/pem -in <enckey.pem> —pass <password> -out <key.der>

On the other hand, you may want to encrypt a private key before putting in a public place. To encrypt a DER encode private key into PEM:

./examples/pem/pem -in <key.der> —pass <password> -out <enckey.pem>

There are a number of options you can pass in to choose the algorithms you want to use.

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 release 5.6.2 and 5.6.3 contained 6 vulnerability fixes. The listed issues were found by external researchers (thanks to their efforts! you can see them mentioned on each of the reports).

• In cases where a malicious agent could analyze cache timing at a very detailed level, information about the AES key used could be leaked during T/S Box lookups. One such case was shown on RISC-V hardware using the MicroWalk tool (https://github.com/microwalk-project/Microwalk). A hardened version of T/S Box lookups was added in wolfSSL to help mitigate this potential attack and is now on by default with RISC-V builds and can be enabled on other builds if desired by compiling wolfSSL with the macro WOLFSSL_AES_TOUCH_LINES. Thanks to Jan Wichelmann, Christopher Peredy, Florian Sieck, Anna Pätschke, Thomas Eisenbarth (University of Lübeck): MAMBO-V: Dynamic Side-Channel Leakage Analysis on RISC-V. Fixed in the following GitHub pull request #6309
• In previous versions of wolfSSL if a TLS 1.3 client gets neither a PSK (pre shared key) extension nor a KSE (key share extension) when connecting to a malicious server, a default predictable buffer gets used for the IKM value when generating the session master secret. Using a potentially known IKM value when generating the session master secret key compromises the key generated, allowing an eavesdropper to reconstruct it and potentially allowing surreptitious access to or meddling with message contents in the session. This issue does not affect client validation of connected servers, nor expose private key information, but could result in an insecure TLS 1.3 session when not controlling both sides of the connection. We recommend that TLS 1.3 client side users update the version of wolfSSL used. Thanks to Johannes from Sectra Communications and Linköping University for the report. Fixed in the following GitHub pull request #6412
• Fix for setting the atomic macro options introduced in release 5.6.2. This issue affects GNU gcc autoconf builds. The fix resolves a potential mismatch of the generated macros defined in options.h file and the macros used when the wolfSSL library is compiled. In version 5.6.2 this mismatch could result in unstable runtime behavior.
• Fix for invalid suffix error with Windows build using the macro GCM_TABLE_4BIT.
• Improvements to Encrypted Memory support (WC_PROTECT_ENCRYPTED_MEM) implementations for modular exponentiation in SP math-all (sp_int.c) and TFM (tfm.c).
• Improvements to SendAlert for getting output buffer.

Release 5.6.2 and 5.6.3 have been developed according to wolfSSL’s development and QA process (see link below) and successfully passed the quality criteria.
https://www.wolfssl.com/about/wolfssl-software-development-process-quality-assurance

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