wolfSSL SSL/TLS Support for NXP SE050

The wolfSSL lightweight SSL/TLS library and underlying wolfCrypt cryptography library have included support for the NXP SE050 module since November 2021. Since that time we have been increasing compatibility with SE050 along with usage of SCP03 (Secure Channel Protocol 03) authentication. To help users get started with TLS usage, we also have two example client applications available for use and reference.

wolfSSL TLS users can use the wolfSSL_CTX_use_PrivateKey_Id() API to instruct wolfSSL to use a private key located in the SE050 at a specific key ID. This would replace calls to wolfSSL_CTX_use_PrivateKey_file() or wolfSSL_CTX_use_PrivateKey_buffer(), giving applications enhanced security by allowing the private key to be stored (and optionally generated) inside the SE050 module.

#include <wolfssl/ssl.h>
int wolfSSL_CTX_use_PrivateKey_Id(WOLFSSL_CTX* ctx, const unsigned char* id,
    long sz, int devId);

For access to wolfSSL_CTX_use_PrivateKey_Id(), wolfSSL needs to be compiled with WOLF_PRIVATE_KEY_ID defined. This can be passed through configure via CFLAGS, for example:

cd wolfssl-X.X.X
./configure <options> CFLAGS=”-DWOLF_PRIVATE_KEY_ID”
make
sudo make install

TLS Client Demos Using SE050

wolfSSL has two example SSL/TLS client applications that demonstrate how users can leverage SE050 underneath wolfSSL’s SSL/TLS implementation. These examples are set up to be easily run on a Raspberry Pi environment with attached NXP EdgeLock SE050 Development Kit.

Available examples are included in the “wolfssl-examples” GitHub repository under the SE050 subdirectory and include:

  1. wolfSSL SSL/TLS Client Example

    This example demonstrates a simple SSL/TLS client, using hardware-based cryptography supported inside the SE050. It loads and uses a certificate and private key from C arrays/buffers. For a more advanced demo which uses the private key directly from the SE050, see the following example. For details, see the example README.md, or wolfssl_client.c file.

  2. wolfSSL SSL/TLS Client Example with Cert and Private Key in SE050

    This example demonstrates a simple SSL/TLS client, using hardware-based cryptography supported inside the SE050. It loads and uses a certificate and private key from C arrays/buffers into the SE050, then does all private key operations inside the SE050 for the TLS private key, based on a key ID. For details, see the example README.md or wolfssl_client_cert_key.c.

Resources

For more details on using wolfSSL or wolfCrypt with the NXP SE050, see one of the following links or email us at facts@wolfSSL.com. The wolfSSL embedded SSL/TLS library supports up to the most current TLS 1.3 and DTLS 1.3 protocol standards, has been optimized for performance and footprint size, and also provides easy paths forward for validation and certification requirements (FIPS 140-3, FIPS 140-3 (in progress), CAVP, DO-178C).

Blog: wolfSSL NXP SE050 Support and Benchmarks
Blog: wolfSSL Support for NXP SE050 with SCP03
Documentation: wolfSSL NXP SE050 Support (README_SE050.md)
Examples: wolfSSL NXP SE050 Examples (README.md)
Dev Kits: NXP EdgeLock SE050 Development Kits
SE050 Product Page: EdgeLock SE050: Plug & Trust Secure Element Family

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

Download wolfSSL Now

Skipping the Cookie Exchange in DTLS 1.3

wolfSSL 5.6.6 introduces the option for DTLS 1.3 servers to skip the cookie exchange on a session resumption. The cookie exchange is a security mechanism employed during the resumption of a DTLS 1.3 session. When a client wants to resume a previous DTLS 1.3 session, it sends a session ticket to the server, which may respond by issuing a “cookie” to the client. This cookie serves as a challenge-response mechanism, requiring the client to present it during the resumption attempt. The purpose of this exchange is for the client to demonstrate reachability at their apparent network address. In some cases, you may choose to skip the cookie exchange if the client presents a valid ticket or pre-shared key (PSK).

To resume a DTLS 1.3 session without the cookie exchange:

  • Compile wolfSSL with WOLFSSL_DTLS13_NO_HRR_ON_RESUME defined. Either:
    • When compiling with configure add CPPFLAGS=-DWOLFSSL_DTLS13_NO_HRR_ON_RESUME
    • When compiling with user settings add #define WOLFSSL_DTLS13_NO_HRR_ON_RESUME
  • Call wolfSSL_dtls13_no_hrr_on_resume(ssl, 1) on the WOLFSSL object to disable the cookie exchange on resumption
  • Continue like with a normal connection

If you have any questions about using DTLS 1.3 in wolfSSL, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSL Adds Support for 0.5-RTT Data in (D)TLS 1.3

(D)TLS 1.3 support for 0.5-RTT (round trip time) data has been introduced to wolfSSL in the latest release (5.6.6). 0.5-RTT data is an optimization in (D)TLS 1.3 that significantly reduces latency and improves overall performance of application data. The full handshake requires two full round trips to start sending data while this functionality allows the server to send application data along with its final flight of handshake messages. This new addition works well with our support for early data (also known as 0-RTT data). An embedded device is able to resume a connection, send early data with its connection request, and receive a response immediately within one RTT.


    	Client                                           	Server

    	ClientHello         	-------->
                                                    	ServerHello
                                          	EncryptedExtensions
                                          	CertificateRequest
                                                 	Certificate
                                           	CertificateVerify
                                                     	Finished
                            	<--------   	0.5-RTT Application Data
    	Certificate
    	CertificateVerify
    	Finished           	-------->
    	Application Data  	<------->    	Application Data

Diagram showing 0.5-RTT data in a full TLS 1.3 handshake

If you would like to learn more about (D)TLS 1.3 in wolfSSL, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Handshake Message Coalescing Vulnerability

wolfSSL prior to version 5.6.6 had a vulnerability where the (D)TLS key boundaries were not properly checked. As a result, it was possible to combine (D)TLS messages using different keys into one (D)TLS record. The most extreme edge case is that, in (D)TLS 1.3, it was possible that an unencrypted (D)TLS 1.3 record from the server containing first a ServerHello message and then the rest of the first server flight would be accepted by a wolfSSL client. In (D)TLS 1.3 the handshake is encrypted after the ServerHello but a wolfSSL client would accept an unencrypted flight from the server. This does not compromise key negotiation and authentication so it is assigned a low severity rating.

We would like to thank Johannes Wilson for the report (Sectra Communications and Linköping University). The fix for this issue is located in the following GitHub Pull Request: #7029.

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

Download wolfSSL Now

Sniffing TLS Traffic

Do you have a need to capture and/or analyze TLS traffic? The wolfSSL library includes a useful tool that you can leverage. The wolfSSL sniffer can be used to capture TLS packets and even decrypt them when at least one of the keys is known. This can be done with both live and recorded PCAP traces.

This could be useful for several reasons, including:

  • Analyzing Network Problems
  • Detecting network misuse by internal and external users
  • Monitoring network usage and data in motion
  • Debugging client/server communications

The sniffer supports both TLS v1.2 and TLS v1.3. It can be integrated into any application using our sniffer API’s and it even comes with a complete working example!

See here for more detailed documentation.

Have any questions, comments, or suggestions? Contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSL Rust Wrapper coming soon

Rust support is coming to wolfSSL this year! The wolfSSL embedded TLS library is a lightweight, portable, C-language-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. This year, we’re planning to add Rust to that list.

Similar to C, Rust is a low-level programming language with direct access to hardware and memory, which will make our wolfSSL Rust Wrapper a great SSL/TLS solution for embedded and IoT development for Rust projects. The wrapper will also service Rust users with performance and/or FIPS requirements.

Are you interested in a Rust wrapper?

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

Download wolfSSL Now

wolfSSL Support for the Espressif ESP-IDF v5.2 Beta

Recently Espressif announced their ESP-IDF v5.2 Beta 1 on GitHub. The same day we found out about this exciting new version, we confirmed that all the wolfSSL Espressif ESP32 Examples are working in that environment. So far the “beta” looks to be well polished from our perspective. Last week, we learned about the ESP-IDF v5.2 Beta 2 on GitHub. The final release should be quite nice.

We have both core performance, benchmark, and client-server examples as well as additional examples for the ESP32.

Incorporating wolfSSL in your Espressif project has never been easier. As announced in the summer of 2023 – wolfSSL is now available in the Espressif ESP Registry of managed components: this one line adds wolfSSL to your project:

# Add wolfSSL component to existing ESP-IDF project
idf.py add-dependency "wolfssl/wolfssl"

Get Started with wolfSSL

Additional information on getting Started with wolfSSL on the Espressif environment is available on the wolfSSL GitHub repository as well as this YouTube recording:

Find out more

If you have any feedback, questions, or require support, please don’t hesitate to reach out to us via facts@wolfSSL.com or call us at +1 425 245 8247, or open an issue on GitHub.

Download wolfSSL Now

Protecting wolfSSL against the Marvin attack

About the Marvin Attack

Recently a new variation of a timing Bleichenbacher RSA-decryption attack, termed the Marvin Attack, was reported by Hubert Kario of the RHEL Crypto team. Its name – a nod to a certain android – is a reference to the unending nature of the ROBOT attack.

The vulnerability allows an attacker to decrypt ciphertexts and forge signatures. However the server’s private key is not exposed. In principle the Marvin Attack could enable a Man-in-the-middle attack, but it is not considered likely due to the difficulties involved.

The RHEL team released a paper on the Marvin Attack, along with a tlsfuzzer test suite to detect Marvin and other timing side-channels. The idea of their test suite is that with new statistical techniques (described in their supplementary paper) they can detect timing side-channels much smaller than previously expected. Hence many implementations previously thought to be resilient against timing side-channels are in fact vulnerable to the Marvin Attack.

The wolfSSL Vulnerability

The RHEL Crypto team reported to us that wolfSSL was vulnerable to the Marvin Atack, when built with the following options:
–enable-all CFLAGS=”-DWOLFSSL_STATIC_RSA”
The define “WOLFSSL_STATIC_RSA” enables static RSA cipher suites, which is not recommended, and has been disabled by default since wolfSSL 3.6.6 (even with –enable-all). Therefore the default configuration, even with –enable-all, is not vulnerable to the Marvin Attack. The vulnerability is specific to static RSA cipher suites, and expected to be padding-independent. Additionally, these static RSA cipher suites were removed in TLS 1.3, and are only present in TLS 1.2 and below.

We coordinated with the RHEL Crypto team, and using their tlsfuzzer were able to reproduce the issue. With further testing, we found the vulnerability was not present when building with –enable-sp or –enable-sp-asm (both of which were designed to be constant time). The vulnerability was specific to the SP Math All handling of RSA.

This was a surprising result, as wolfSSL by default includes RSA blinding. The reason is that, even with blinding, the unblinding operation and conversion from big integer to binary array with SP Math All can leave small timing signals that can be resolved by statistical analysis when applied to very many observations (which is what the tlsfuzzer achieves).

We have created a CVE for this issue, [Medium] CVE-2023-6935.

With that said, let’s go through what we did to harden wolfSSL against the Marvin Attack.

The Fixes

These two pull requests were merged to fix the Marvin Attack vulnerability:

  1. https://github.com/wolfSSL/wolfssl/pull/6896
  2. https://github.com/wolfSSL/wolfssl/pull/6955/

The first fix was to make the conversion from a multi-precision integer to padded binary buffer a constant time operation. This fix went into the 5.6.4 release. Following the release we continued to test the issue, and we found that while the fix mitigated the side-channel, it was not sufficient.

The second fix was more involved. It made the blinding inversion multiplication be in Montgomery form, and made subsequent changes so that the Montgomery reduction would be constant time, and clamping and sub-modulo operations were also constant time. Following this second fix we have not detected the Marvin vulnerability, but will continue to test.

Conclusions

  • The wolfSSL SP Math All implementation of RSA was vulnerable to the Marvin Attack. If static RSA cipher suites were enabled on the server side, this meant an attacker could decrypt a saved TLS connection, or forge a signature, after probing with a very large number of test connections. This has been fixed in the current release by the aforementioned two pull requests.
  • Static RSA cipher suites have been disabled by default since wolfSSL 3.6.6. Therefore when using the default configuration of wolfSSL, TLS connections were not vulnerable to the Marvin Attack (even with –enable-all).
  • We found the –enable-sp and –enable-sp-asm RSA implementations are not vulnerable to the Marvin Attack. These implementations are constant time by design.
  • We recommend disabling static RSA cipher suites, and to upgrade the version of wolfSSL used.

References

  1. https://people.redhat.com/~hkario/marvin/
  2. Everlasting ROBOT: the Marvin Attack. https://eprint.iacr.org/2023/1442
  3. Out of the Box Testing. https://eprint.iacr.org/2023/1441.pdf
  4. tlsfuzzer suite. https://github.com/tlsfuzzer/tlsfuzzer

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

Download wolfSSL Now

wolfSSL 5.6.6 Now Available!

Merry Christmas! The Christmas release of wolfSSL is here, version 5.6.6!

Version 5.6.6 brings with it fixes for 4 vulnerabilities, bug fixes, new features, and some enhancements as well! For a description of vulnerabilities fixed, please see our vulnerability page. New features in this release include support for additional hardware devices (STM32WL55), new hardware encryption support for ESP32 devices (ESP32-C3, ESP32-C6, ESP32-S2), improved DTLS 1.3 session resumption support, new implementation of SRTP-KDF and SRTCP-KDF, a cache-attack safe bitslice implementation of AES, and support for memcached.

We also have a nice round of enhancements which range from better testing, disabling TLS 1.1 by default, expanded CMake build support, optimizations and new assembly for our speedy SP math library, and more!

A list of new features and enhancements from our ChangeLog is listed below. For a full list of fixes see our complete ChangeLog on GitHub.

New Feature Additions

  • Build option for disabling CRL date checks (WOLFSSL_NO_CRL_DATE_CHECK) (PR 6927)
  • Support for STM32WL55 and improvements to PKA ECC support (PR 6937)
  • Add option to skip cookie exchange on DTLS 1.3 session resumption (PR 6929)
  • Add implementation of SRTP KDF and SRTCP KDF (–enable-srtp-kdf) (PR 6888)
  • Add wolfSSL_EXTENDED_KEY_USAGE_free() (PR 6916)
  • Add AES bitsliced implementation that is cache attack safe (–enable-aes-bitsliced) (PR 6854)
  • Add memcached support and automated testing (PR 6430, 7022)
  • Add Hardware Encryption Acceleration for ESP32-C3, ESP32-C6, and ESP32-S2 (PR 6990)
  • Add (D)TLS 1.3 support for 0.5-RTT data (PR 7010)

Enhancements and Optimizations

  • Better built in testing of “–sys-ca-certs” configure option (PR 6910)
  • Updated CMakeLists.txt for Espressif wolfSSL component usage (PR 6877)
  • Disable TLS 1.1 by default (unless SSL 3.0 or TLS 1.0 is enabled) (PR 6946)
  • Add “–enable-quic” to “–enable-all” configure option (PR 6957)
  • Add support to SP C implementation for RSA exponent up to 64-bits (PR 6959)
  • Add result of “HAVE___UINT128_T” to options.h for CMake builds (PR 6965)
  • Add optimized assembly for AES-GCM on ARM64 using hardware crypto instructions (PR 6967)
  • Add built-in cipher suite tests for DTLS 1.3 PQC (PR 6952)
  • Add wolfCrypt test and unit test to ctest (PR 6977)
  • Move OpenSSL compatibility crypto APIs into ssl_crypto.c file (PR 6935)
  • Validate time generated from XGMTIME() (PR 6958)
  • Allow wolfCrypt benchmark to run with microsecond accuracy (PR 6868)
  • Add GitHub Actions testing with nginx 1.24.0 (PR 6982)
  • Allow encoding of CA:FALSE BasicConstraint during cert generation (PR 6953)
  • Add CMake option to enable DTLS-SRTP (PR 6991)
  • Add CMake options for enabling QUIC and cURL (PR 7049)
  • Improve RSA blinding to make code more constant time (PR 6955)
  • Refactor AES-NI implementation macros to allow dynamic fallback to C (PR 6981)
  • Default to native Windows threading API on MinGW (PR 7015)
  • Return better error codes from OCSP response check (PR 7028)
  • Updated Espressif ESP32 TLS client and server examples (PR 6844)
  • Add/clean up support for ESP-IDF v5.1 for a variety of ESP32 chips (PR 7035, 7037)
  • Add API to choose dynamic certs based on client ciphers/sigalgs (PR 6963)
  • Improve Arduino IDE 1.5 project file to match recursive style (PR 7007)
  • Simplify and improve apple-universal build script (PR 7025)

Visit our download page or wolfSSL GitHub repository to download the release bundle. If you have questions about any of the above, feel free to email us at facts@wolfSSL.com or support@wolfSSL.com, or call us at +1 425 245 8247 regarding the wolfSSL embedded SSL/TLS library or any other products.

Download wolfSSL Now

wolfSSL on Pi5 Benchmarks

We at wolfSSL have worked hard to provide exceptional performance for our libraries across all platforms, but we’ve taken extra measures for Intel, ARM, RISC-V and PPC. For common key sizes and curves we’ve implemented inline assembly speedups for most algorithms.

For example on the new Raspberry Pi5 with a Cortex A57 at 2.4GHz (default) running on a single thread we achieve the following benchmark results on wolfSSL v5.6.4:

Algorithm key size operation avg ms ops/sec
RSA 2048 sign 3.387 295.244
RSA 3072 sign 9.984 100.159
RSA 4096 sign 21.742 45.995
RSA 2048 verify 0.079 12646.826
RSA 3072 verify 0.174 5744.265
RSA 4096 verify 0.293 3415.934
ECDHE 256 agree 0.158 6316.186
ECDHE 384 agree 0.561 1783.881
ECDHE 521 agree 1.296 771.642
ECDSA 256 sign 0.066 15179.234
ECDSA 384 sign 0.225 4436.137
ECDSA 521 sign 0.584 1712.349
ECDSA 256 verify 0.169 5925.511
ECDSA 384 verify 0.598 1672.345
ECDSA 521 verify 1.4 714.378
CURVE 25519 agree 0.146 6864.489
CURVE 448 agree 0.565 1770.784
ED 25519 sign 0.045 22223.907
ED 448 sign 0.232 4301.478
ED 25519 verify 0.166 6018.073
ED 448 verify 0.691 1448.119

Note: Above ECC curves are SECP256R1, SECP384R1 and SECP521R1.

Obtained using:

./configure --disable-shared --enable-sp=yes,asm --enable-armasm --enable-keygen --enable-curve25519 --enable-ed25519 --enable-curve448 --enable-ed448
make
./wolfcrypt/benchmark/benchmark -rsa -rsa_sign -ecc -p256
./wolfcrypt/benchmark/benchmark -rsa-sz 3072 -rsa_sign -ecc -p384
./wolfcrypt/benchmark/benchmark -rsa-sz 4096 -rsa_sign -ecc -p521
./wolfcrypt/benchmark/benchmark -x25519 -ed25519 -x448 -ed448

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

Download wolfSSL Now

Posts navigation

1 2 3 4 5 6