RECENT BLOG NEWS
wolfBoot support for the STM32C0
We are adding wolfBoot support for the new STM32C0. This is a low cost MCU similar to the STM32G0 based on a Cortex-M0 (48MHz). It is a very low cost general purpose 32-bit MCU with up to 32KB flash and 12KB RAM.
Our wolfBoot secure bootloader is the only solution available for this platform thanks to our small code size. Most STM32 parts are supported with wolfBoot out of the box. See our video series with ST for a tutorial on using wolfBoot: https://www.wolfssl.com/st-wolfboot-video-series/
See the STM32C0 announcement from ST: https://www.st.com/en/microcontrollers-microprocessors/stm32c0-series.html
We will be demonstrating this at our booth during Embedded World 2023 in Nuremberg, Germany March 14-16.
- Written in C for bare-metal use
- Small footprint to run on small embedded devices
- Memory safety (no malloc/free)
- Support for on-board or external SPI flash
- Simple partitioning and header scheme
- Abstracted HAL design for CPU speed and flash
- Bootloader handles swapping and loading of partitions
- Key tools for key generation/import and signing
- Encrypted updates
- Delta updates (only differences)
Signature algorithms supported:
- ECC (SECP256R1,SECP384R1)
- RSA (2048/3072/4096)
Firmware image integrity using hash digest:
Flexible partition scheme determined at build-time:
- Bootloader (10-30KB)
- Swap (1 sector)
- And custom partition ID's
Reliable Firmware update mechanism:
- Independent from the update transport mechanism
- Fallback to a previous version when the update fails
- Resume interrupted swap operations during update, in case of power failure
Support for STM hardware crypto acceleration:
- STM32 HASH/AES/PKA
- ST33TP* TPM 2.0 using wolfTPM
If interested in trying our wolfBoot on the STM32C0 or curious about post-quantum signature support in wolfBoot please contact email@example.com.
KEMTLS Experimentation Via wolfSSL
A new, exciting paper has been released by Ruben Gonzalez from Neodyme AG and Thom Wiggers from Radboud University. They compare post-quantum algorithms in TLS 1.3 and KEMTLS. KEMTLS is a newly proposed modification to the TLS 1.3 protocol that would eliminate the need for signing operations during a handshake protocol. Note that a long term KEM public key would be embedded into a leaf certificate so the certificate chain would still need to be verified with a signature scheme. The team did the work of modifying wolfSSL to support KEMTLS in their own fork of wolfSSL. Their paper can be found at https://eprint.iacr.org/2022/1712 .
The paper concludes that KEMTLS would allow for lower memory consumption. However, there was no clear winner with regards to handshake times. In some situations, post-quantum TLS 1.3 was faster, while in other cases KEMTLS did better. If you are curious about it, please do download the paper.
We would like to thank the authors for the following words:
"WolfSSL is designed to be memory efficient and fast on embedded systems. On top, it already supports TLS 1.3 and has a clean implementation of TLS’s state machine. ...WolfSSL’s crypto provider, called WolfCrypt, has a clean API that can be extended easily."
Here at wolfSSL, we appreciate it when our code quality is noticed.
Are you curious about any other protocols? Our wolfSSL library also supports DTLS 1.2 and recently support for DTLS 1.3 was added. We support SSH, MQTT and SCEP via our wolfSSH, wolfMQTT and wolfSCEP products. If you are curious, don't be shy! The full source code for all of these products are available for download under open source licenses at https://www.github.com/wolfSSL/. You can also reach out to us for more details at firstname.lastname@example.org.
wolfEngine 1.3.0 Released
We’re happy to announce that wolfEngine 1.3.0 has been released! wolfEngine is an OpenSSL engine implementation that helps users migrate to a FIPS-validated cryptography library (wolfCrypt) all while continuing to use OpenSSL.
Version 1.3.0 includes support for RPM packaging, support and tests for OpenSSL HMAC operations to be called with a -1 key length, and updated examples which are compatible with OpenSSL 1.0.2. You can read the full list of changes in the ChangeLog.md on GitHub. For documentation and usage instructions for wolfEngine, visit the wolfEngine User Manual.
If you are interested in a commercial version of wolfEngine or using the wolfCrypt FIPS 140-2 or upcoming 140-3 module in your project, please contact wolfSSL at email@example.com with any questions or for more details!
Rust Crate for Post-Quantum TLS 1.3 and wolfSSL
Are you on the bleeding edge of software development and cryptographic protocols? Then you'll appreciate the work that our friends at ExpressVPN have done by creating a rust crate for wolfSSL with bindings into our API. They have even created a special feature flag called "postquantum" which enables our integration with liboqs. In fact, this feature will automatically bring in the oqs-sys rust crate making the whole setup as simple as could be!
For more details and instructions on how to proceed, please see https://crates.io/crates/wolfssl-sys/ .
Are you interested in more rust bindings? Are you thinking of using wolfSSL in your rust application? Then we would love to have a conversation with you! Please reach out to us by sending a message to firstname.lastname@example.org or your local wolfSSL business director.
DTLS 1.3 support for Post-Quantum Cryptography
Do you want to start using wolfSSL’s DTLS 1.3 implementation? Want to go even further?
A great reason to start using our DTLS 1.3 stack is that it also supports post-quantum KEMs, Hybrid KEMs and post-quantum signature schemes. When it comes time to move to post-quantum standards, support for them will likely come in the newest protocol standards only, so you might as well go to DTLS 1.3 as soon as you can and make sure that post-quantum algorithms and artifacts won’t be a challenge for your system.
Got questions about the DTLS 1.3 or post-quantum cryptography? Don’t be shy! Send a message to email@example.com or reach out to your local wolfSSL business director.
wolfSSL: Hardened By Default
In cryptography when we talk about hardening a library, we mean enabling resistance to timing attacks and cache attacks, using RSA blinding and protecting against glitching.
Enabling and Disabling
Our code has many related macros which can be controlled via configure script flags such as the harden flag and maxstrength flag. When hardening is enabled, the following flags are defined:
TFM_TIMING_RESISTANT ECC_TIMING_RESISTANT WC_RSA_BLINDING
When it is disabled, the following flags are defined:
NOTE: hardening is enabled by default and in most cases should NOT be disabled. Later in this post, we will discuss some guidance on this matter.
The “maxstrength” flag is disabled by default because it only allows AEAD-PFS (Authenticated Encryption with Associated Data - Perfect Forward Secrecy) cipher suites which can cause interoperability issues. However, when it is enabled, it defines WOLFSSL_CIPHER_TEXT_CHECK, which protects against glitching attacks. If you want other cipher suites to be available, but also want glitching protection for the relevant ciphersuites, you can add -DWOLFSSL_CIPHER_TEXT_CHECK to your CFLAGS environment variable.
This requires the adversary to precisely time the logical operations performed by a CPU or other device. By measuring these times the adversary is able to uncover the private data that was used to perform these operations. These kinds of attacks are even practical against well known, generally secure algorithms including RSA and ECC. Such attacks are thwarted by making cryptographic operations run in a constant amount of time independent of the private key. More information on timing attacks can be found at: https://en.wikipedia.org/wiki/Timing_attack
Modern processors perform speculative execution and can leave observable side effects due to execution of branches not taken. This can be in the form of memory access patterns which can be seen in the state of the memory cache. These patterns can indicate information about the private key. The adversary would use nefarious means to make a program access arbitrary locations in the program's memory space to get these patterns. This attack can be mitigated by eliminating branching in cryptographic operations involving the private key.
This involves transforming the input just before the RSA private key operations using some random data. After the operation, the reverse of the transform is performed giving the desired output. This prevents an adversary from gaining knowledge about the private key as they don't know the random data that was used to determine the transform and therefore do not know the true input into the RSA private key operation.
Glitching is when the adversary can feed in modified input data into an algorithm and then observe the error behavior to deduce information about the private key. This requires the adversary to have physical access and intimate knowledge of the software and hardware. They would modify the input into the algorithm by physically changing the values of the input in physical memory. This attack can be detected by copying the input to a separate buffer before a cryptographic operation and comparing the input buffer with that separate buffer after the cryptographic operation to ensure it has not changed.
Generally speaking, you should always leave the “harden” flag enabled, however disabling it can give some performance gains. Here are some factors to consider whether it is appropriate to disable it:
- Are you only dealing with public data and public keys?
- Do you really need the performance gains?
- Are you only doing off-line operations where cryptographic operation timings cannot be observed?
- Are restrictions in place to ensure no physical access to the hardware?
- Do you have very simple and audited application code and operating system to minimize nefarious code execution?
- Did you minimize external interaction (ie network, user interface) to prevent nefarious inputs?
- Do you sanity check all input data?
If you are still not sure about whether you want to enable hardening, then reach out to your wolfSSL business director or send a message to firstname.lastname@example.org and let’s start a conversation.
wolfSSL + nuttX initial testing success!
wolfSSL is pleased to announce initial run-time testing of wolfCrypt + NuttX was successfully completed (Crypto algorithm tests and benchmarking) on both BL602 (RISC-V) and NUCLEO-L552ZE-Q (Cortex-M33) targets! wolfSSL engineers are now working on making a publically available drop-in for the NuttX-apps directory that users can take for a spin! The wolfSSL team is very excited about next steps which include but are not limited to:
- Testing wolfCrypt post-quantum algorithms in NuttX
- Testing client/server TLS 1.2 and TLS 1.3 connections in NuttX
- Testing FIPS functionality in NuttX
- Publishing benchmark results to our website
Console output from tests run on the RISC-V BL602 target:
NuttShell (NSH) nsh> wolfcrypt_test ------------------------------------------------------------------------------ wolfSSL version 5.5.4 ------------------------------------------------------------------------------ error test passed! MEMORY test passed! base64 test passed! asn test passed! RANDOM test passed! MD5 test passed! SHA test passed! SHA-256 test passed! Hash test passed! HMAC-MD5 test passed! HMAC-SHA test passed! HMAC-SHA256 test passed! DES test passed! DES3 test passed! AES test passed! AES192 test passed! AES256 test passed! RSA test passed! DH test passed! PWDBASED test passed! ECC test passed! ECC buffer test passed! logging test passed! time test passed! mutex test passed! memcb test passed! Test complete Exiting main with return code: 0
Have any other ideas or Proof of Concepts you would like us to consider? Please don’t hesitate to reach out to email@example.com with suggestions for our team!
“Get Up to Speed with WolfSSL in 2023: Join Our Webinar Series”
Happy New Year! As we kick off 2023, wolfSSL is excited to announce a series of webinars to help you get started with our software.
First up is our webinar on January 5th at 10 AM (PST) on getting started with the wolfSSL TLS library. This webinar will cover a range of topics including an overview of TLS 1.3, how to build and use the wolfSSL library, and tips on debugging. There will also be a Q&A session to answer any questions you may have. Register here: https://us02web.zoom.us/webinar/register/WN_bkptS_9fRF2W1aV-zGFjsg
On January 19th, join wolfSSL engineer Eric Blankenhorn for a webinar on our wolfMQTT library. This multi-platform, space-conscious and extensible library is a client implementation of MQTT written in C for embedded use, and supports SSL/TLS via the wolfSSL library. Bring your questions for the Q&A session to follow. Register here: https://us02web.zoom.us/webinar/register/WN_iep1f_sfQq6NDEo6irQANQ
Finally, on January 26th, we’ll be hosting a webinar on getting started with wolfSSH, a lightweight SSHv2 client and server library. This webinar will cover topics such as the wolfSSH package structure, how to build and use the library, and debugging tips. As always, there will be a Q&A session to answer any questions you may have. Register here: https://us02web.zoom.us/webinar/register/WN_kaAs6wWTS7Ct2FXo6pr5oA
We hope to see you at one or all of these webinars!
Heard of NuttX?
Heard of NuttX? Fresh out of the Apache incubator, it’s a small RTOS with a focus on POSIX and ANSI standards compliance, scales from 8 to 64-bit microcontrollers, is extensively documented, ported to many platforms, and is very easy to get started with!
Here at wolfSSL we are hard at work testing wolfSSL with NuttX. The flexible, efficient nature of NuttX makes it a natural fit for a lean, embedded SSL/TLS implementation like wolfSSL.
Interested? Let us know!
For questions please email firstname.lastname@example.org
wolfSSH v1.4.12 Release
wolfSSL are proud to announce a new incremental update to wolfSSH: v1.4.12!
In this release, we have wolfSSHD running. It seamlessly fits in where other SSHDs are, and is able to parse and make use of existing sshd_config files that are in place.
We are also proud to announce that wolfSSH builds and runs in the Green Hills Software INTEGRITY environment. It takes advantage of INTEGRITY’s POSIX API. You can run a shell through it, or upload files to the local filesystem using SFTP.
For the cutting edge, wolfSSH adds Hybrid ECDH-P256 Kyber-Level1 for post-quantum hybrid key exchange.
The release information from the change log is reposted below:
New Feature Additions and Improvements
- Support for Green Hills Software's INTEGRITY
- wolfSSHd Release (https://github.com/wolfSSL/wolfssh/pull/453 rounds off testing and additions)
- Support for RFC 6187, using X.509 Certificates as public keys
- OCSP and CRL checking for X.509 Certificates (uses wolfSSL CertManager)
- Add callback to the server for reporting userauth result
- FPKI profile checking support
- chroot jailing for SFTP in wolfSSHd
- Permission level changes in wolfSSHd
- Add Hybrid ECDH-P256 Kyber-Level1
- Multiple server keys
- Makefile updates
- Remove dependency on wolfSSL being built with public math enabled
- Fixes for compiler complaints using GHS compiler
- Fixes for compiler complaints using GCC 4.0.2
- Fixes for the directory path cleanup function for SFTP
- Fixes for SFTP directory listing when on Windows
- Fixes for large file transfers with SFTP
- Fixes for port forwarding
- Fix for building with QNX
- Fix for the wolfSSHd grace time alarm
- Fixes for Yocto builds
- Fixes for issues found with fuzzing
- The vulnerability fixed in wolfSSH v1.4.8 finally issued CVE-2022-32073
For any questions about using wolfSSH contact us at email@example.com
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (9)
- September 2022 (7)
- August 2022 (12)
- July 2022 (11)
- June 2022 (15)
- May 2022 (11)
- April 2022 (14)
- March 2022 (12)
- February 2022 (22)
- January 2022 (13)
- December 2021 (13)
- November 2021 (29)
- October 2021 (15)
- September 2021 (15)
- August 2021 (13)
- July 2021 (21)
- June 2021 (19)
- May 2021 (12)
- April 2021 (13)
- March 2021 (27)
- February 2021 (29)
- January 2021 (22)
- December 2020 (21)
- November 2020 (14)
- October 2020 (7)
- September 2020 (22)
- August 2020 (11)
- July 2020 (8)
- June 2020 (14)
- May 2020 (15)
- April 2020 (14)
- March 2020 (4)
- February 2020 (24)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (24)
- August 2019 (21)
- July 2019 (8)
- June 2019 (13)
- May 2019 (35)
- April 2019 (31)
- March 2019 (20)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (10)
- October 2018 (18)
- September 2018 (18)
- August 2018 (8)
- July 2018 (15)
- June 2018 (29)
- May 2018 (15)
- April 2018 (11)
- March 2018 (19)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (7)
- September 2017 (8)
- August 2017 (6)
- July 2017 (11)
- June 2017 (8)
- May 2017 (10)
- April 2017 (5)
- March 2017 (7)
- February 2017 (1)
- January 2017 (8)
- December 2016 (3)
- November 2016 (2)
- October 2016 (18)
- September 2016 (8)
- August 2016 (5)
- July 2016 (4)
- June 2016 (10)
- May 2016 (4)
- April 2016 (5)
- March 2016 (4)
- February 2016 (12)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (6)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (13)
- January 2015 (6)
- December 2014 (7)
- November 2014 (3)
- October 2014 (2)
- September 2014 (11)
- August 2014 (6)
- July 2014 (9)
- June 2014 (11)
- May 2014 (11)
- April 2014 (9)
- March 2014 (3)
- February 2014 (3)
- January 2014 (5)
- December 2013 (9)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (8)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (9)
- December 2012 (13)
- November 2012 (5)
- October 2012 (7)
- September 2012 (4)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (5)
- April 2012 (7)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (6)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (8)
- May 2011 (12)
- April 2011 (4)
- March 2011 (12)
- February 2011 (8)
- January 2011 (13)
- December 2010 (17)
- November 2010 (12)
- October 2010 (14)
- September 2010 (11)
- August 2010 (20)
- July 2010 (14)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)