RECENT BLOG NEWS
Or sign up to receive weekly email notifications containing the latest news from wolfSSL.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.
wolfSSL 4.6.0 Now Available
The Christmas release of wolfSSL is available! Get your version 4.6.0 copy by visiting the downloads page on wolfSSL’s website or checking out the release sections on our GitHub repository. A lot of engineering and exciting additions happened in this release. Some of our recent blogs have touched on the new features, this release had our Linux kernel module support, Apache httpd TLS 1.3 support, hardware acceleration additions for the NXP DCP (i.MX RT1060/1062) crypto co-processor, Silicon Labs hardware support and many more new features.
A full list of items in the release can be found in the bundled README.md but the following are a few of the notable changes:
- Linux Kernel Module! wolfSSL now enables Linux kernel module support with FIPS! Big news for Linux kernel module developers with crypto requirements! wolfCrypt and wolfSSL are now loadable as modules in the Linux kernel, providing the entire libwolfssl API natively to other kernel modules. For the first time on Linux, the entire TLS protocol stack can be loaded as a module, allowing fully kernel-resident TLS/DTLS endpoints with in-kernel handshaking. (
--enable-linuxkm
,--enable-linuxkm-defaults
,--with-linux-source
). Read more in our blog. - New Apple A12Z Benchmarks! Build tests and updated instructions for use with Apple’s A12Z chipset. Read more and see benchmarks in our blog!
- wolfSSL Math Library! Expansion of wolfSSL Single Precision math implementation and addition of a new
--enable-sp-math-all
build option — includes broader assembly support and is faster. - TLS 1.3 fixes and additions! A couple of the additions have been with Sniffer support and adding Apache httpd TLS 1.3 support. We are leading the way with TLS 1.3 sniffing, which is important to a small subset of users such as schools that wish to protect what young kids can view in computer labs.
- New Hardware Acceleration! Added support for NXP DCP (i.MX RT1060/1062) crypto co-processor and added Silicon Labs hardware acceleration using SL SE Manager.
Fixes
- Math Library
- Fix
mp_to_unsigned_bin_len
out of bounds read with buffers longer than maximum MP - Fix for
fp_read_radix_16
out of bounds read - Fix to add wrapper for new timing resistant
wc_ecc_mulmod_ex2
function version in HW ECC acceleration - Handle an edge case with RSA-PSS encoding message to hash
- Fix
- Compatibility Layer Fixes
- Fix for setting serial number
wolfSSL_X509_set_serialNumber
- Fix for setting ASN1 time not before / not after with WOLFSSL_X509
- Fix for order of components in issuer name when using
X509_sign
- Fix for compatibility layer API
DH_compute_key
- EVP fix incorrect block size for GCM and buffer up AAD for encryption/decryption
- EVP fix for AES-XTS key length return value and fix for string compare calls
- Fix for mutex freeing during RNG failure case with EVP_KEY creation
- Non blocking use with compatibility layer BIOs in TLS connections
- Fix for setting serial number
- Build Configuration
- Fix for custom build with WOLFSSL_USER_MALLOC defined
- ED448 compiler warning on Intel 32bit systems
- CURVE448_SMALL build fix for 32bit systems with Curve448
- Fix to build SP math with IAR
- CMake fix to only set ranlib arguments for Mac, and for stray typo of , -> ;
- Build with
--enable-wpas=small
fix - Fix for building FIPS Ready using openssl extra
- Fixes for building with Microchip (min/max and undef SHA_BLOCK_SIZE)
- Fix for NO_FILESYSTEM build on Windows
- Fixed SHA-256 support for IMX-RT1060
- Fix for ECC key generation with NO_TFM_64BIT
- Sniffer
- Fixes for sniffer when using static ECC keys. Adds back TLS v1.2 static ECC key fallback detection and fixes new ECC RNG requirement for timing resistance
- Fix for sniffer with SNI enabled to properly handle WOLFSSL_SUCCESS error code in ProcessClientHello
- Fix for sniffer using HAVE_MAX_FRAGMENT in “certificate” type message
- Fix build error with unused “ret” when building with WOLFSSL_SNIFFER_WATCH.
- Fix to not treat cert/key not found as error in
myWatchCb
and WOLFSSL_SNIFFER_WATCH. - Sniffer fixes for handling TCP `out-of-range sequence number`
- Fixes SSLv3 use of ECDH in sniffer
- PKCS
- PKCS#11 fix to generate ECC key for decrypt/sign or derive
- Fix for resetting internal variables when parsing a malformed PKCS#7 bundle with
PKCS7_VerifySignedData()
- Verify the extracted public key in
wc_PKCS7_InitWithCert
- Fix for internal buffer size when using decompression with PKCS#7
- Misc
- Pin the C# verify callback function to keep from garbage collection
- DH fixes for when public key is owned and free’d after a handshake
- Fix for TLS 1.3 early data packets
- Fix for STM32 issue with some Cube HAL versions and STM32 example timeout
- Fix mmCAU and LTC hardware mutex locking to prevent double lock
- Fix potential race condition with CRL monitor
- Fix for possible malformed encrypted key with 3DES causing negative length
- AES-CTR performance fixed with AES-NI
Improvements/Optimizations
- SP and Math
mp_radix_size
adjustment for leading 0- Resolve implicit cast warnings with SP build
- Change
mp_sqr
to return an error if the result won’t fit into the fixed length dp - ARM64 assembly with clang improvements, clang doesn’t always handle use of x29 (FP or Frame Pointer) in inline assembly code correctly – reworked
sp_2048_sqr_8
to not use x29 - SP mod exp changed to support exponents of different lengths
- TFM div: fix initial value of size in q so clamping doesn’t OOB read
- Numerous stack depth improvements with
--enable-smallstack
- Improve cache resistance with Base64 operations
- TLS 1.3
- TLS 1.3
wolfSSL_peek
want read return addition - TLS 1.3: Fix P-521 algorithm matching
- TLS 1.3
- PKCS
- Improvements and refactoring to PKCS#11 key look up
- PKCS #11 changes for signing and loading RSA public key from private
- Check PKCS#7 SignedData private key is valid before using it
- Check PKCS#7 VerifySignedData content length against total bundle size to avoid large malloc
- Compatibility Layer
- EVP add block size for more ciphers in
wolfSSL_EVP_CIPHER_block_size()
- Return long names instead of short names in
wolfSSL_OBJ_obj2txt()
- Add additional OpenSSL compatibility functions to update the version of Apache httpd supported
- Add “CCM8” variants to cipher_names “CCM-8” ciphers, for OpenSSL compat
- EVP add block size for more ciphers in
- Builds
- Cortex-M SP ASM support for IAR 6.70
- STM Cube pack support (IDE/STM32Cube)
- Build option
--enable-aesgcm=4bit
added for AES-GCM GMULT using 4 bit table - Xilinx IDE updates to allow XTIME override for Xilinx, spelling fixes in Xilinx README.md, and add Xilinx SDK printf support
- Added ED448 to the “all” options and ED448 check key null argument sanity check
- Added ARC4, 3DES, nullcipher, BLAKE2, BLAKE2s, XChaCha, MD2, and MD4 to the “all” options
- Added an
--enable-all-crypto
option, to enable only the wolfCrypt features of--enable-all
, combinable with--enable-cryptonly
- Added the ability to selectively remove features from
--enable-all
and--enable-all-crypto
using specific--disable-
options - Use Intel intrinsics with Windows for RDSEED and RDRAND (thanks to dr-m from MariaDB)
- Add option to build with WOLFSSL_NO_CLIENT_AUTH
- Updated build requirements for wolfSSH use to be less restrictive
- lighttpd support update for v1.4.56
- Added batch file to copy files to ESP-IDF folders and resolved warnings when using v4.0 ESP-IDF
- Added
--enable-stacksize=verbose
, showing at a glance the stack high water mark for each subtest in the wolfCrypt test app (testwolfcrypt)
- ECC
- Performance increase for ECC verify only, using non constant time SP modinv
- During ECC verify add validation of r and s before any use
- Always use safe add and dbl with ECC
- Timing resistant scalar multiplication updated with use of Joye double-add ladder
- Update
mp_jacobi
function to reduce stack and increase performance for base ECC build - Reduce heap memory use with
wc_EccPrivateKeyDecode
, Improvement to ECCwc_ecc_sig_to_rs
andwc_ecc_rs_raw_to_sig
to reduce memory use (avoid the mp_int) - Improve
StoreECC_DSA_Sig
bounds checking
- OCSP
- OCSP improvement to handle extensions in singleResponse
- Support for OCSP request/response for multiple certificates
- OCSP Must Staple option added to require OCSP stapling response
- Add support for id-pkix-ocsp-nocheck extension
- Misc
- Additional code coverage added for ECC and RSA, PKCS#7, 3DES, EVP and Blake2b operations
- DTLS MTU: check MTU on write
- Refactor hash sig selection and add the macros WOLFSSL_STRONGEST_HASH_SIG (picks the strongest hash) and WOLFSSL_ECDSA_MATCH_HASH (will pick the hash to match the ECC curve)
- Strict certificate version allowed from client, TLS 1.2 / 1.3 can not accept client certificates lower than version 3
- wolfSSL_get_ciphers_compat(), skip the fake indicator ciphers like the renegotiation indication and the quantum-safe hybrid
- When parsing session ticket, check TLS version to see whether they are version compatible
- Additional sanity check for invalid ASN1 padding on integer type
- Adding in ChaCha20 streaming feature with Mac and Intel assembly build
- Sniffer build with
--enable-oldtls
option on
For questions contact us at facts@wolfssl.com. Merry Christmas, Happy New Year, and love to all from wolfSSL!
wolfSSL Math Library Comparison Matrix
The wolfSSL embedded SSL/TLS library includes three different math libraries which can be used to support wolfCrypt’s cryptographic operations – the Normal Math library, the fastmath library, and SP math. To help our users decide which math library is right for them, we have put together a helpful comparison matrix!
The wolfSSL Math Library Comparison Matrix, included below, shows the strengths and weaknesses of the 3 math options offered by wolfSSL. If you have any commentary or feedback please reach out to our team at facts@wolfssl.com or support@wolfssl.com!
wolfTPM v2.0 Release
A major release for wolfTPM came out at the end of 2020 and is now available for download from our website. This release brings many new features:
- Native support for using TPM2.0 hardware with wolfTPM under Microsoft Windows
- TPM simulator support for even easier development with wolfTPM and MacOS users
- Protection from MITM (man-in-the-middle) attacks using TPM2.0 Parameter Encryption. wolfTPM supports both TPM2.0 options for MITM protection, XOR encryption and AES CFB.
- HMAC Session support for verification of peer authenticity and integrity.
This release also adds multiple new examples: TPM key generation and key loading examples with options to store the key to disk and use parameter encryption to protect from MITM. Added is support for importing external private keys and easy re-loading. And for those who use the internal TPM clock for reference, there is now a TPM clock increment example.
Among the other enhancements of our portable TPM2.0 library are the use of HMAC sessions and new wolfTPM wrappers for easier work with TPM sessions and authorization of TPM objects.
Please contact us at facts@wolfssl.com for more information and help for taking advantage of the new wolfTPM features to better protect your systems.
wolfSSL Use With Signal
Back in January of 2018 wolfSSL added support for use with the Open Whisper Systems Signal Protocol C Library! This means that you can now develop Signal applications using wolfCrypt as the underlying cryptography provider.
For those unfamiliar with the Signal Protocol, it is described on their GitHub page as “A ratcheting forward secrecy protocol that works in synchronous and asynchronous messaging environments.”
wolfSSL also has a JSSE provider that can be used with Android. This can seamlessly replace the default provider, giving all the benefits that come with using wolfSSL. Such as; extra performance boosts, access to our stellar support, and FIPS certifications to name a few items. Instructions on using the wolfSSL JSSE with Android can be found here https://www.wolfssl.com/docs/installing-a-jsse-provider-in-android-osp/.
wolfCrypt Signal Protocol Integration
By design, the Signal Protocol C Library does not depend on any SSL/TLS or cryptography library. Instead, Signal allows the application to register a crypto provider at runtime. We recently ported the wolfCrypt cryptography library into the “libsignal-protocol-c” test code and added a CMake configuration to build the libsignal-protocol-c test programs using cryptography from wolfSSL.
With this build option and wolfCrypt integration, Signal application developers can choose to use cryptography from wolfSSL instead of OpenSSL. Thanks to wolfSSL’s small footprint size, low memory usage, and broad platform support, application developers can more easily use the Signal Protocol C Library on small resource-constrained platforms and embedded systems.
For more information on using wolfCrypt with Signal, contact us at facts@wolfssl.com!
New Sparkplug example in wolfMQTT
The team here at wolfSSL is putting together a Sparkplug example that we’d like to share with you! The Sparkplug specification is useful for Industrial IoT system developers building on top of MQTT. Sparkplug defines a set of device states, adds topic naming structures, and defines payload formats. The wolfMQTT client library is perfectly suited to help secure your IIoT project since it is already integrated with wolfSSL!
For more information send a quick note to facts@wolfssl.com
You can download the latest release here: https://www.wolfssl.com/download/
Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT
While you’re there, show us some love and give the wolfMQTT project a Star!
wolfSSL Vulnerabilities In 2020
Last year wolfSSL fixed 8 vulnerabilities and documented them in the wolfSSL embedded SSL/TLS library release notes. Thanks to all of the researcher reports, and to the dedicated wolfSSL team, the fixes were identified and resolved rapidly. How rapidly you may ask? The average time to get a fix submitted for review on the vulnerabilities listed in 2020 was just over 26 hours.
Thanks to the researchers that submitted reports!
- Gerald Doussot from NCC group
- Lenny Wang of Tencent Security Xuanwu LAB
- Ida Bruhns from Universität zu Lübeck and Samira Briongos from NEC Laboratories Europe
- Alejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley from the Network and Information Security Group (NISEC) at Tampere University
- Paul Fiterau of Uppsala University and Robert Merget of Ruhr-University Bochum
- Pietro Borrello at Sapienza University of Rome
If you have a vulnerability to report or would like more information, contact us at facts@wolfssl.com, the wolfSSL development team takes vulnerabilities seriously.
Distribution of Crypto Operations
wolfSSL is developing a library to handle the location of where crypto operations run amongst multiple cores. For large systems that have many sign/verify operations happening at once this library would be able to distribute those sign/verify requests based on a user’s input. In addition to managing where the operation runs it can be used to plug in hardware acceleration for handling requests that come in. An example use case would be having 3 cores for generic lower priority operations and saving 1 core that has hardware acceleration for fast, real time responses, that would run high priority operations.
Contact us at facts@wolfssl.com with any questions, or for more details! The wolfSSL embedded SSL/TLS library also supports TLS 1.3, FIPS 140-2/3, and DO-178.
Upcoming Webinar: Securing the IoT from the End Point (or Edge) to the Cloud
We would like to personally invite you to a webinar presented by wolfSSL Partner Microchip!
If you are developing IoT systems, this webinar will help you learn how to use TLS/MQTT to ensure secure endpoint-to-cloud communication and employ hardware roots of trust to enable strong security. We will also explain how to use wolfSSL, with its secure software suite integrated within our MPLAB® Harmony Framework, to secure endpoint communication.
Title: SHIELDS UP! Webinar #29: Securing the IoT from the Endpoint to the Cloud
Date: Wednesday, January 13, 2021
Time: 08:00 AM Pacific Standard Time
Duration: 45 minutes
Register for the webinar here: https://event.on24.com/eventRegistration/EventLobbyServlet?target=reg20.jsp&referrer=&eventid=2862875&sessionid=1&key=0AE813D5055E821C7E8E12C6546B44F2®Tag=&V2=false&sourcepage=register
Learn more about Microchip’s webinar series here:
https://www.microchip.com/training/webinars/security/shields-up-webinar-series
We hope to see you there!
Additional Resources
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.
Sniffing traffic with TLS v1.3
The wolfSSL library includes a useful tool for sniffing TLS traffic. This can be used to capture and decrypt live or recorded PCAP traces when at least one of the keys is known. Typically a static RSA ciphersuite would be used, however with TLS v1.3 only Perfect Forward Secrecy (PFS) ciphers are allowed. For TLS v1.3 all cipher suites use a new ephemeral key for each new session.
In order to solve this we added a “static ephemeral” feature, which allows setting a known key that is used for deriving a shared secret. The key can be rolled periodically and synchronized with the sniffer tool to decrypt traffic. This feature is disabled by default and is only recommended for internal or test environments.
As a proof of concept we added this support to Apache httpd to demonstrate real-time decryption of web traffic. We are also working on a key manager to assist with key rolling and synchronization.
A use case that might be interesting is a company internal web server that requires auditing.
The TLS v1.3 sniffer support was added in PR 3044 and officially supported in v4.6.0.
The Apache httpd branch with sniffer and FIPS ready support is here.
Contact us at facts@wolfssl.com to learn more!
wolfSSL Use With Hexagon Toolchain
The Qualcomm Hexagon SDK is used for building code to run on DSP processors. Use of the Hexagon toolchain to offload ECC verify operations has been added to wolfSSL. This can free up the main CPU for other operations or lead to future optimizations with HVX on some algorithms that use vector operations. The Makefile for building with the Hexagon toolchain and a README with more information can be found in the directory wolfssl-4.6.0/IDE/HEXAGON.
For questions about wolfSSL contact facts@wolfssl.com.
What is TPM parameter encryption?
Trusted Platform Modules (TPM) give us a secure vault for storing keys and secrets. We could also use a TPM as root-of-trust for reporting the health and integrity of our servers or bare metal systems (e.g. IoT). However, TPMs are physical devices. The communication between our software and the TPM happens over a physical interface, typically a SPI bus. This physical interface could be attacked maliciously. For example, IoT and Edge devices are exposed at this risk, because they are deployed in the field. An attacker might physically open the device and try to interfere with the communication between our software and the TPM. To protect from this risk, a TPM offers the capability of parameter encryption.
TPM has the ability to receive commands with their first parameter encrypted. If requested, the TPM could also respond with an encrypted first parameter. Usually, the first parameter is where the most sensitive data of a TPM command is stored. For example, during a TPM2_Create for generating a new key pair, the authValue used as password for the new key is stored in a structure called inSensitive that is the very first parameter of a TPM2_Create command request. All of this should be handled by the TPM stack. Because in order to use parameter encryption a TPM session must be set.
wolfTPM recently added parameter encryption support for protection of man-in-the-middle (MITM) attacks and offers new API wrappers to simplify its use. There is now the wolfTPM2_StartSesssion
wrapper to start TPM sessions for parameter encryption and wolfTPM2_SetAuth
to make use of this session. Regardless, if you want to use this extra layer of protection or not, the wolfTPM2_CreateKey
wrapper accepts the same number of parameters. This way the development cycle is not affected, if you want to add MITM protection to your secure application by using wolfTPM.
TPM supports AES CFB and XOR method for parameter encryption, and wolfTPM supports both. All the encryption and decryption of command parameters is handled by the stack. The secure exchange of secrets for setting up the TPM session for parameter encryption also happens seamlessly from the developer’s perspective.
If you have questions about adding wolfTPM to your project, or need tips on getting started with using a TPM, email us at facts@wolfssl.com.
Weekly updates
Archives
- January 2021 (10)
- 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)
Latest Tweets