TLS Glitch Resistance on Encrypt
We’ve had some recent interest in adding resistance for detection of encrypt issues due to glitching. A recent report for ESP32 AES HW showed it was possible to skip the encrypt operation with some timed glitching. The attack requires physical access to the hardware. The attack results in the HW encrypt operation being skipped and the data being sent unencrypted over the TLS transport.
As a result we’ve added a new build option WOLFSSL_CIPHER_TEXT_CHECK to enable checking of the encrypt to ensure the data changed (i.e. is not the same). It defaults to checking 64-bits of the buffer, but this can be enlarged by overriding the WOLFSSL_CIPHER_CHECK_SZ macro.
We enable this feature by default with our “max strength” build option `–enable-maxstrength`.
For details see PR https://github.com/wolfSSL/wolfssl/pull/5231 “Added sanity check on TLS encrypt to trap against glitching”.
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 Xilinx FreeRTOS
wolfSSL has easy options for using FreeRTOS with LwIP on Xilinx boards! The Xilinx SDK has support for FreeRTOS and LwIP with embedded projects, which wolfSSL has been ported to use both for some time! The directory containing some Xilinx IDE projects and information for a quick start when working with the Xilinx SDK is located here (https://github.com/wolfSSL/wolfssl/tree/master/IDE/XilinxSDK).
With Xilinx FreeRTOS there are also calls to hardware acceleration using the Xilinx hardened crypto which greatly speeds up AES-GCM, SHA3, and RSA operations (https://docs.xilinx.com/v/u/en-US/wp512-accel-crypto). Stay tuned for updated benchmark numbers and status on the hardware acceleration with the new Versal board.
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 Golang Wrapper
wolfSSL now has a very simple Golang wrapper! The wolfSSL embedded TLS library is a lightweight, portable, C-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. With this light Golang wrapper, GO users can do the same.
While GO has its own tls/crypto library, wolfSSL is a proven and optimized solution that could soon be a viable option for GO projects. For some insight on how it would work, follow the instructions in this README to view/build a simple server/client example secured by wolfSSL TLS.
Are you interested in a more complete Golang wrapper?
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
New Announcement! wolfSSL now supports DTLSv1.3!
wolfSSL’s DTLS 1.3 implementation is not ready for commercial use, but it’s fully functional and ready for being beta-tested! As usual, you can find the code at our GitHub repo or you can download the beta version here.
Since its first version, DTLS aims to bring the same security guarantees as TLS, but without requiring a reliable and order-preserving underlying protocol. This means that it’s much more suitable for latency-sensitive applications that can suffer from the overhead of TCP or similar protocols. The specifications of DTLSv1.3 were published just last April (RFC 9147) and DTLSv1.3 brings all the improvements of TLS v1.3 to DTLS: faster and more secure handshake, 0-RTT resumption, modern crypto algorithms, better downgrade protection and so on. We are the first to release a working implementation. If you are working on DTLS, or if you just have questions, don’t hesitate to contact us at facts@wolfssl.com. We’re more than happy to hear from you!
Want to talk to us face to face about DTLS 1.3 at Embedded World?
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
wolfSSH SSHD
We are in the process of developing an SSHD server with wolfSSH. This will be a fully featured application that can take in a typical OpenSSH style sshd_config file and handle incoming SSH connections. It’s backed by the progressive and well tested wolfCrypt library for all crypto operations. It is also developed with embedded devices in mind, having a reduced footprint size!
For early access to the SSHD server or questions contact us at facts@wolfssl.com.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
wolfMQTT with Post-Quantum KYBER and FALCON
Here at wolfSSL, we pride ourselves on keeping up to date with the various post-quantum developments related to the protocols we support. wolfMQTT is a client side library that supports the MQTT publish and subscribe protocol that is a very good fit for IoT applications.
Recently, the OpenQuantumSafe project got a pull request for a new demo which featured the mosquito MQTT broker operating on top of TLS 1.3 with post-quantum cryptographic algorithms. Naturally, we were very excited to try and run some interoperability tests against it!
This blog post is to announce that wolfMQTT now supports KYBER_LEVEL1 KEM group and P256_KYBER_LEVEL1 hybrid group for key exchange along with FALCON_LEVEL1 for signature authentication over TLS 1.3. Our implementation has been successfully tested for inter-operability with the OpenQuantumSafe project’s mosquito MQTT broker demo. If you would like to try it out, please follow the instructions athttps://github.com/wolfSSL/wolfmqtt#post-quantum-mqtt-support
Want different post-quantum groups for KEM key exchange? Want other post-quantum signature schemes? Want to see the wolfSSL team make a post-quantum MQTT broker? Want to see this setup working on STM32 devices?
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
When – and how – to prepare for post-quantum cryptography
McKinsey and Company have release the following report “When – and how – to prepare for post-quantum cryptography” https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/when-and-how-to-prepare-for-post-quantum-cryptography
In it they outline some options regarding how you can handle the coming migration to post-quantum cryptography. Here is a brief summary of their options our response:
Option 1: Adopt post-quantum cryptography solutions today
While adopting one of these solutions might seem to be the best path for any company that needs to act today, there are trade-offs and drawbacks to consider…
The wolfSSL library already has post-quantum algorithms integrated. Let us help you understand these new trade-offs. Don’t worry, speed and performance won’t be a major factor. Please see our benchmarks: https://www.wolfssl.com/docs/benchmarks/
Option 2: Retrofit systems with post-quantum cryptography solutions later
Finally, organizations should begin building long-term relationships with relevant suppliers, regulators, and peers within and outside of their industries as soon as possible. These relationships will be critical for staying up to date on emerging standards and solutions for PQC. … collectively developing solutions, for example, could cost less than if an organization devised solutions on its own.
The wolfSSL Team has a long and stable history of providing quality open-source software for security protocols and we are here to stay. We are here to help you find the right solution that will help you comply with industry standards and interoperate with your peers.
Option 3: Focus only on enhancing traditional encryption protocols
Decision makers should also begin planning for future updates to long-lasting systems by, for instance, evaluating the modularity of their technological architecture.
The wolfSSL Team also provides various consulting services. We can help you update to the latest standards while becoming more flexible and agile to prepare for the coming post-quantum migration.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
wolfEngine 1.1.0
We’re happy to announce that wolfEngine 1.1.0 has been released! wolfEngine is an OpenSSL engine that helps users migrate to a FIPS-validated cryptography library (wolfCrypt) all while continuing to use OpenSSL. This new version fixes a couple bugs and adds support for RSA signatures with X9.31 padding. Additionally, the example OpenSSL configuration file, engine.conf, and the examples subdirectory are now part of releases.
If you are interested in a commercial version of wolfEngine or our wolfCrypt FIPS 140-2 or 140-3 modules!
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
cURL Up Canceled
The cURL Project and wolfSSL are sorry to inform you that Daniel Stenberg tested positive for COVID-19 this morning, and is unable to fly to the US for the cURL Up event. We have decided to cancel the cURL Up event happening June 6th. We are planning on rescheduling cURL Up for sometime in September.
Thank you for your understanding. Stay tuned for more news.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
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.
Our latest release of wolfBoot contains these countermeasures. Glitching support mitigation 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!
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.