RECENT BLOG NEWS
wolfSSL Support for eCos
With its abstraction layers, OpenSSL compatibility layer, small size, and low runtime memory usage, the wolfSSL embedded SSL/TLS library is an excellent choice when porting to a new device or when looking to use TLS functionality in embedded environments and operating systems. One of the operating systems is the real-time eCos! eCos is a free open source real-time operating system intended for embedded applications, and is highly configurable.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Introducing micropython-wolfssl
wolfSSL is excited to announce micropython-wolfssl, an external module for MicroPython that enables wolfSSL to be used for TLS and cryptographic operations.
MicroPython is a lean and efficient implementation of the Python 3 programming language that includes a small subset of the Python standard library and is optimized to run on microcontrollers and in constrained environments.
micropython-wolfssl replaces the built-in module implementations of SSL/TLS, encryption, and hashing, and implements its own API-compatible version built on top of wolfSSL. It also provides MicroPython users with TLS 1.3 capability, which currently does not exist in the upstream TLS implementation. Currently, the module supports both the Unix and STM32 MicroPython ports, the latter of which has been tested on both the STM NUCLEO-F446RE and PyBoard-v1.1 development boards.
Users can now combine the ease of development and rich high-level abstractions provided by the MicroPython ecosystem with the rock-solid performance and security of wolfSSL.
You can find micropython-wolfssl in wolfSSL’s open source projects repository and follow the documentation to get started. 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 now available in Espressif Component Registry
Serious, commercial-grade encryption tools are essential in every developer’s programming toolbox. We at wolfSSL continue to embrace the exciting new technologies at Espressif for the ESP32 SoC chipsets. Today, we announce the first availability of the wolfSSL embedded encryption libraries in the ESP Registry located at components.espressif.com.
Add wolfSSL to your project:
This new capability makes it easier than ever to get started with wolfSSL in the ESP-IDF environment. On the wolfSSL component page, just click the “Copy to Clipboard” icon:
Paste that “add-dependency” command in the root of your project directory, run it, and voila! You now have wolfSSL available in your project. Through the magic of the new Managed Components, simply run the idf.py build command for your project as usual:
idf.py build
After the dependency was added as described above, the wolfSSL library will be automatically downloaded and installed into your project at build time.
Want something even easier to get started with wolfSSL? We’ve included examples! The examples can be automatically installed with the “create-project-from-example” parameter:
See an example in 4 easy steps:
Here’s an example using the wolfSSL benchmark app. From scratch, nothing else needed other than these 4 steps to:
(1) setup the ESP-IDF environment.
(2) fetch the wolfSSL benchmark example.
(3) change directory to the downloaded project.
(4) compile, upload, and view output.
Like this:
. ~/esp/esp-idf/export.sh
idf.py create-project-from-example "wolfssl/wolfssl^5.6.0-stable:wolfssl_test"
cd wolfssl_test
idf.py -b 115200 flash monitor
Additional details:
To check which version of the Component Manager is currently available, use the command:
python -m idf_component_manager -h
The Component Manager should have been installed during the installation of the ESP-IDF. If your version of ESP-IDF doesn’t come with the IDF Component Manager, you can install it:
python -m pip install --upgrade idf-component-manager
For further details on the Espressif Component Manager, see the GitHub idf-component-manager repo.
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 Releases v1.16.0
The latest release of wolfMQTT, v1.16.0, is now available! This release has several bug fixes and optimizations including:
- Add testing for TLS mutual auth, and fsanitize gh test by @lealem47 in #321
- Add support for pkcs8 keys to mqtt client by @lealem47 in #322
- Fix null ptr deref in MqttClient_WaitType by @embhorn in #323
- Cleanup enum last entry to not have comma by @dgarske in #324
- Cleanup the AWS example by @dgarske in #326
- Fix for multi-threaded non-blocking use of sockRc, which could collide between read and write by @dgarske in #328
- Add API to check if message is active (non-blocking only) by @dgarske in #329
- Fix configure warnings by @embhorn in #330
- Support MQTTv5 in AWS example by @embhorn in #332
- Zephyr port by @julek-wolfssl in #333
- Improve example headers and small sanitizer fixes by @lealem47 in #334
- Adding in STM32CubeIDE support by @lealem47 in #335
- Add dynamic property support by @embhorn in #336
Check out the changelog from the download for a full list of features and fixes, or If you have questions on any of the above, contact us at facts@wolfssl.com, or call us at +1 425 245 8247: https://github.com/wolfSSL/wolfMQTT/blob/master/ChangeLog.md
While you’re there, show us some love and give the wolfMQTT project a Star!
You can download the latest release here: https://www.wolfssl.com/download/
Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT
How wolfSSL Protects Your Data – TLS Overview
What attacks does TLS mitigate?
Transport Layer Security (TLS) is used worldwide to protect the integrity and privacy of financial and other commercial transactions, operational communications by governments, medical and other private data interchange, space-borne data and telemetry links, email and personal correspondence, and other information that needs protection from disclosure or meddling while in transit. The trend in recent years is to cryptographically protect nearly all data on the public Internet, and increasingly on private intranets, mostly using TLS.
wolfSSL TLS is a best-in-class implementation of both the TLS protocol and the underlying cryptographic algorithms. It is commonly used to protect Internet connections, but because it is transport-agnostic, it is also used to protect traffic on local links and buses (e.g. UART, CAN, SPI, I2C), wireless networks (e.g. Bluetooth and BTLE, Zigbee, Zwave), and various other transports capable of bidirectional communications.
When properly deployed, wolfSSL TLS, with full support for (D)TLS 1.3, provides state of the art performance with comprehensive protection against all known network-borne attack vectors, and additionally protects against many known vectors targeting the physical endpoint.
Protection from Data Corruption and Replay:
(D)TLS uses an authenticating cipher (AEAD) or a Message Authentication Code (MAC) to guarantee that message contents are authentic and unchanged. In TLS 1.3, an AEAD such as AES-GCM is always used, simultaneously providing maximum performance and maximum security.
TLS provides firm guarantees that messages cannot be replayed, inserted, or omitted, by including single-use random data during connection establishment, and an internal message counter within each connection so that each message is guaranteed unique and in order.
wolfSSL DTLS 1.3 additionally includes a full implementation of RFC 9147 replay prevention, so that even in connectionless sessions, an adversary cannot generally inject replayed messages. Adversarial message insertion is always prevented.
Protection of Confidentiality:
TLS includes a fundamental guarantee that the contents of messages exchanged between endpoints are safe from eavesdropping over the network. This guarantee is founded on two criteria: (1) the encryption algorithm is strong, i.e. the contents are only accessible if the key is known, and (2) the key is known only to the two endpoints. When mutual authentication (a client certificate) is used, the guarantee is strongest, with each endpoint able to identify the other end with practical certainty.
TLS also protects contents from disclosure of internal statistical patterns, when used correctly. By default, wolfSSL builds without support for TLS-layer payload compression, making it immune to the CRIME and BREACH side-channel attacks. Using TLS on all traffic further protects against the VORACLE attack on compressing VPNs, by eliminating plaintext payloads.
TLS can also provide Perfect Forward Secrecy (PFS). In this mechanism, ephemeral asymmetric keys are used during session establishment, protecting users from the possibility of coerced disclosure in adversarial store-and-decrypt scenarios, even if server or user private keys are compromised. In TLS 1.3, key negotiation always provides PFS.
Protection from Spoofing:
By default, wolfSSL TLS validates server certificates to a locally stored root of trust using the loaded list of authorities, and aborts if the server certificate can’t be fully validated. Some other common TLS implementations have different default behaviors and require that the application explicitly enable the validation requirement.
Additionally, use of a Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP) allows protection from certificates that have been revoked due to compromise. Of these, the most powerful and efficient mechanism is OCSP with stapling and a MustStaple certificate extension, whereby the endpoint can and must prove to its peer that its certificate is valid according to recent vetting by the issuing authority.
Client identity can be verified internal to the TLS protocol using client certificates, or the application can use its own mechanism within the secure TLS session to determine client identity.
As long as at least one certificate is validated — either server by the client, or client by the server — TLS protects the connection from man-in-the-middle (MITM, double impersonation) attacks.
Protection from Timing and Padding Attacks:
Timing attacks: wolfCrypt, the cryptographic algorithm library underlying wolfSSL, implements full protection against timing analysis, protecting secret keys and data from leakage even when attackers have unrestricted local network or bus access to the device. Internal operations that use secret key data are structured to complete in a constant number of instructions. Memory cache attacks, which exploit predictable differences in instruction completion time as a function of secret key data, are blinded with techniques that assure that affected operations complete in constant time.
Padding attacks: Certain private key operations can reveal private key data if the message is not correctly encapsulated in cryptographic padding to prevent exploitation by adversarial crafted inputs. Correct standard padding is always used in TLS to defeat these attacks.
When wolfSSL is configured with -–enable-maxstrength, additional checks are performed to defeat endpoint attacks based on injection of carefully timed electromagnetic impulses. Sibling product wolfBoot features similar defenses when built on ARM Cortex-M with the ARMORED=1 option. These defenses are an area of active research, and additional mitigations are continually in development.
Protection from Protocol Attacks:
Downgrade attacks: Earlier and ancestral versions of the TLS protocol, particularly SSLv2 and SSLv3, are now known to be vulnerable to attacks such as POODLE, BEAST, and various man-in-the-middle attacks. wolfSSL has SSLv3 disabled by default, eliminating these vulnerabilities.
TLS 1.0 and 1.1 were formally deprecated by RFC 8996 (March 2021), due to their dependence on obsolete (DSS, 3DES) and insecure (SHA-1) cryptography. wolfSSL disables TLS 1.0 by default, and TLS 1.1 can be disabled with the configure options –disable-oldtls or –enable-harden-tls. If TLS 1.1 is needed, wolfSSL allows SHA-1 to be globally disabled with –disable-sha, assuring that only secure hash algorithms will be used.
Renegotiation attacks: historic versions of TLS before 1.1 suffered from a protocol defect allowing adversarial content injection. wolfSSL is not vulnerable to these attacks. RFC 5746 secure renegotiation in TLS 1.2 and earlier is optional in wolfSSL, and TLS 1.3 omits in-session renegotiation entirely, eliminating the exposure.
The Heartbleed vulnerability and other implementation flaws specific to OpenSSL have never affected wolfSSL, as wolfSSL is an entirely independent implementation with no ancestral relationship to any current or historicOpenSSL release.
Protection from Cryptographic Obsolescence:
Several algorithms once commonly used in SSL/TLS are now known to be insecure, notably the ciphers RC4 and DES, and the digests MD5 and SHA-1. Of these, RC4 is disabled in wolfCrypt by default, DES is omitted entirely, and the digest algorithms are enabled by default but can be globally disabled. None of these algorithms are included in the TLS 1.3 protocol definition, thus any client or server configured to use only TLS 1.3 is inherently protected from deprecated cryptography.
The future of cryptography is quantum-resistant, providing best protection from store-and-decrypt (harvest now, decrypt later) and signature forgery threats. wolfCrypt supports all 3 lattice-based algorithms on the NIST standards track. The Kyber key agreement algorithm, and the Dilithium and Falcon digital signature algorithms, each offer security levels up to AES-256 equivalent strength. All 3 are fully integrated into wolfSSL TLS 1.3, and are usable today. The future is now!
Protection from Non-Cryptanalytic Attacks:
The wolfSentry embedded firewall/IDPS can be used to harden endpoints against denial of service attacks. Through integration with server applications and the wolfSSL TLS library, wolfSentry can be configured to dynamically block abusive clients, preventing resource attacks and brute force penetration attacks on constrained endpoints.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Blue sUAS and How wolfSSL Can Help
wolfSSL exhibited at Xponential last month in Denver. While there, our team met some very kind and knowledgeable talent from “Dark Wolf Solutions” (Shout out, we love the name!)
We discussed with Dark Wolf personnel how the unmanned drone industry is currently in its wild west days and there are many gaps to fill when it comes to cyber security. Given a want for cyber security, there are steep barriers to entry into military and government applications. Many unmanned vehicles are still broadcasting video and telemetry data unencrypted and in the clear for any adversary to pull down off the air waves! We all agree this should be fixed before someone’s drone gets turned against them, or before their expensive drones get bricked by motivated adversaries.
The Defense Innovation Unit (DIU) is part of the Department of Defense (DoD) and they are helping companies to take that next step turning their commercial technology into useful assets for national defense. One avenue to get from commercial only to defense is called “Blue sUAS” which stands for “small Unmanned Aerial Systems”. One can read more about Blue sUAS here: https://www.diu.mil/blue-uas and other projects available for commercial to DoD in their catalog: https://www.diu.mil/solutions/portfolio/catalog
wolfSSL is now interacting with Dark Wolf who specializes in reviewing drones for submission readiness to the Blue sUAS project. Dark Wolf assists their customers in identifying gaps that need to be addressed before they can pass and be approved for use by the DoD. Disqualifiers are things like “foreign tech” (i.e. chips or other components manufactured outside the US) in addition to insecure comms and data channels. wolfSSL can easily help with the comms and data channels!
wolfSSL is a U.S. based software company that implements NSA Suite B (and soon NSA 2.0 Suite) and NIST approved algorithms in software. Algorithms are all certifiable through the FIPS 140-2 and 140-3 program or NIAP (NSA) for use in CSfC should that be a requirement. The wolfSSL teams’ understanding was that many certifications are not currently a barrier to entry only that the solutions have to be capable of being certified if and when the time comes and that is absolutely the case with all wolfSSL solutions. wolfSSL implements several communication protocols including SSL/TLS up to the latest standards (TLS 1.3 and DTLS 1.3), MQTT (including v5 of the protocol) and SSH (all of these protocols are future-proofed with post-quantum algorithm support!).
wolfSSL offers consulting services and has the engineering-power and know-how to implement any other communication/transport protocols that may be needed or desired for use in UAS. wolfSSL can run on any processor and if a processor is not already supported, the wolfSSL team will add support for it! wolfSSL can encrypt sensitive data at rest in the event a UAS were to be lost on a battlefield and wolfSSL can secure your video, telemetry data, and comms links between the UAS and ground stations!
What is more, wolfSSL will tie into any on-board available hardware cryptography to accelerate performance and security if the software implementations of the algorithms are not yielding the desired performance. A list of existing supported chips is available on our website here: https://www.wolfssl.com/products/wolfcrypt-2/ (just scroll down to “Supported Chipmakers”) Benchmark numbers for various supported chipmakers can be found here: https://www.wolfssl.com/docs/benchmarks/
In summary, if you need Cyber Security solutions as an unmanned drone maker be it a surface maritime, submersible maritime or aerial drone platform, wolfSSL can help. Also be sure to reach out to Dark Wolf for a review if considering using one of the DIU projects to take your drone from commercial to DoD ready!
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Live Webinar: Everything you Need to Know About DTLS 1.3
DTLS 1.3 is here! wolfSSL is the first to have DTLS 1.3 implementation and this is your chance to get all your questions answered! wolfSSL engineer, Marco Oliverio, will be hosting a live webinar on June 29th at 10am to share every information you need to know about DTLS 1.3.
If you are looking for enhanced security in your applications and interested in learning how wolfSSL’s cutting-edge technology can enhance your security infrastructure. Marco will give you in depth details about benefits and features of using wolfSSL DTLS 1.3. Join the wolfSSL team to learn how wolfSSL can protect your data and provide seamless integration with your existing systems.
Watch the webinar here: Everything You Need to Know About DTLS 1.3
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
How Much Battery Power Does TLS Use?
Power consumption on IoT devices can be a big concern. Especially when adding in the latest security and using DTLS 1.3 / TLS 1.3 connections to secure communication. Here at wolfSSL we minimize power consumption and work with EEMBC to measure how much power wolfSSL is consuming when adding security to battery powered designs. Benchmarks of wolfSSL power consumption on an STM32L476G device are available here (https://www.eembc.org/viewer/?benchmark_seq=13436). These benchmarks prove that wolfSSL is the perfect security solution for Ultra Low-Power WiFI designs.
ULP WiFI is a great solution for battery connected devices, but cryptography and TLS can be computationally expensive, so we’ve optimized wolfSSL to minimize energy usage. What we have found is that using wolfSSL’s SP (Single Precision) math with assembly speed ups is superior and has a positive impact on both performance and power consumption. More recently, we are exploring additional energy saving optimizations for the Talaria Two ULP and NXP i.MX ULP WiFi parts.
wolfSSL also supports TLS over BLE for maximum security on sensitive designs. Here is an example of using wolfSSL with Bluetooth Low Energy (BTLE) (https://github.com/wolfSSL/wolfssl-examples/tree/master/btle). In the example directory there is a TLS 1.3 over Bluetooth example too! (https://github.com/wolfSSL/wolfssl-examples/tree/master/btle/tls).
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.3 Available!
wolfSSL release 5.6.3 is available. This is a minor release version that resolves an issue found when building with autoconf in release 5.6.2. Included in this release are 3 other improvements and fixes that increase the quality of code and ease of use of wolfSSL. The following is a list of all 4 items in wolfSSL 5.6.3:
- 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 the output buffer.
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 Available!
wolfSSL release 5.6.2 is now available! wolfSSL 5.6.2 brings many new features, exciting enhancements, fixes, and vulnerability fixes. Here at wolfSSL the developers are working diligently to achieve the highest level of security for users. Release 5.6.2 provides quality fixes which we were able to find and address by working quickly with independent researchers who file reports of potential issues.
Some of the notable changes in this release are:
* Adding in support for STM32H5, Renesas TSIP v1.17, Renesas SCE RSA crypto-only support, NXP IMX6Q CAAM port with QNX
* An ASN.1 syntax parsing utility located in ./examples/asn1/ directory
* Memory usage optimizations and code size reduction with lean builds
* Documentation, benchmark app, and unit test app improvements
* Fixes for use with STM32 and code quality improvements including a potential out of buffer access fix
Two vulnerabilities were addressed in this release dealing with TLS 1.3 client side behavior and another with AES side channel issue on RISC-V. More details about the vulnerabilities can be found in the wolfSSL ChangeLog along with special thanks to the researchers who reported them.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Weekly updates
Archives
- December 2024 (17)
- November 2024 (29)
- October 2024 (18)
- September 2024 (21)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- 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)