Category: wolfSSL/ wolfCrypt

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

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

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

In an effort to improve our Thumb2 support for Cortex-M4 and the like, wolfSSL 5.6.4 includes assembly code for the AES-ECB/CBC/CTR/GCM, SHA-256 and SHA-512 algorithms.

Of particular interest is the AES-CBC and AES-GCM performance improvements you will see when changing from the C code implementations in wolfSSL 5.6.3. Take for example running wolfSSL on a Cortex-M4 at 80MHz. With wolfSSL 5.6.3 the performance numbers for the AES-CBC and AES-GCM algorithms are:

AES-128-CBC-enc            425 KiB took 1.000 seconds,  425.000 KiB/s
AES-128-CBC-dec            450 KiB took 1.024 seconds,  439.453 KiB/s
AES-192-CBC-enc            375 KiB took 1.039 seconds,  360.924 KiB/s
AES-192-CBC-dec            375 KiB took 1.008 seconds,  372.024 KiB/s
AES-256-CBC-enc            325 KiB took 1.027 seconds,  316.456 KiB/s
AES-256-CBC-dec            325 KiB took 1.000 seconds,  325.000 KiB/s
AES-128-GCM-enc            325 KiB took 1.062 seconds,  306.026 KiB/s
AES-128-GCM-dec            325 KiB took 1.063 seconds,  305.738 KiB/s
AES-192-GCM-enc            275 KiB took 1.012 seconds,  271.739 KiB/s
AES-192-GCM-dec            275 KiB took 1.015 seconds,  270.936 KiB/s
AES-256-GCM-enc            250 KiB took 1.024 seconds,  244.141 KiB/s
AES-256-GCM-dec            250 KiB took 1.023 seconds,  244.379 KiB/s

Add the following defines so the assembly code is compiled in:

#define WOLFSSL_ARMASM
#define WOLFSSL_ARMASM_INLINE
#define WOLFSSL_ARMASM_NO_HW_CRYPTO
#define WOLFSSL_ARMASM_NO_NEON
#define WOLFSSL_ARM_ARCH 7

And now, with wolfSSL 5.6.4, the performance is:

AES-128-CBC-enc           1000 KiB took 1.008 seconds,  992.063 KiB/s
AES-128-CBC-dec            850 KiB took 1.007 seconds,  844.091 KiB/s
AES-192-CBC-enc            850 KiB took 1.020 seconds,  833.333 KiB/s
AES-192-CBC-dec            825 KiB took 1.023 seconds,  806.452 KiB/s
AES-256-CBC-enc            725 KiB took 1.008 seconds,  719.246 KiB/s
AES-256-CBC-dec            700 KiB took 1.000 seconds,  700.000 KiB/s
AES-128-GCM-enc            425 KiB took 1.000 seconds,  425.000 KiB/s
AES-128-GCM-dec            425 KiB took 1.004 seconds,  423.307 KiB/s
AES-192-GCM-enc            400 KiB took 1.020 seconds,  392.157 KiB/s
AES-192-GCM-dec            400 KiB took 1.019 seconds,  392.542 KiB/s
AES-256-GCM-enc            375 KiB took 1.032 seconds,  363.372 KiB/s
AES-256-GCM-dec            375 KiB took 1.027 seconds,  365.141 KiB/s

AES-CBC encryption is more than double the C code performance while decryption is 90% better! AES-GCM gets an impressive 35-50% boost.

The SHA-256 and SHA-512 see modest improvements but are worthwhile in order to get the best out of wolfSSL for your embedded device.

Let us know if there are other cryptographic algorithms on Thumb2 for which you would like to see better performance.

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

In the latest release of wolfSSL, version 5.6.4, a significant effort has been put into improving the performance of public key algorithms for 32-bit ARM chips.

wolfSSL now has arguably the best performance for P256 ECC, Curve25519 and Ed25519 for Cortex-M4 and Cortex-A32. With highly optimized assembly implementations of multiplication and squaring operations you now get about twice the number of operations performed!

By compiling in the high performance SP code and using the assembly versions you get the best performance for your embedded device.

Take for example running wolfSSL on a Cortex-M4 at 80MHz with the following defines:

#define WOLFSSL_HAVE_SP_ECC
#define WOLFSSL_SP_NO_MALLOC
#define WOLFSSL_SP_ARM_CORTEX_M_ASM
#define WOLFSSL_SP_SMALL

With wolfSSL 5.6.3 the performance numbers for the ECC and Curve25519/Ed25519 algorithms are:

ECC   [      SECP256R1]   256  key gen        32 ops took 1.000 sec, avg 31.250 ms, 32.000 ops/sec
ECDHE [      SECP256R1]   256    agree        16 ops took 1.098 sec, avg 68.625 ms, 14.572 ops/sec
ECDSA [      SECP256R1]   256     sign        24 ops took 1.019 sec, avg 42.458 ms, 23.553 ops/sec
ECDSA [      SECP256R1]   256   verify        12 ops took 1.141 sec, avg 95.083 ms, 10.517 ops/sec
CURVE  25519  key gen        32 ops took 1.020 sec, avg 31.875 ms, 31.373 ops/sec
CURVE  25519    agree        32 ops took 1.012 sec, avg 31.625 ms, 31.621 ops/sec
ED     25519  key gen        80 ops took 1.000 sec, avg 12.500 ms, 80.000 ops/sec
ED     25519     sign        64 ops took 1.031 sec, avg 16.109 ms, 62.076 ops/sec
ED     25519   verify        28 ops took 1.011 sec, avg 36.107 ms, 27.695 ops/sec

But with wolfSSL 5.6.4 the performance is massively improved:

ECC   [      SECP256R1]   256  key gen        72 ops took 1.027 sec, avg 14.264 ms, 70.107 ops/sec
ECDHE [      SECP256R1]   256    agree        34 ops took 1.036 sec, avg 30.471 ms, 32.819 ops/sec
ECDSA [      SECP256R1]   256     sign        44 ops took 1.020 sec, avg 23.182 ms, 43.137 ops/sec
ECDSA [      SECP256R1]   256   verify        24 ops took 1.082 sec, avg 45.083 ms, 22.181 ops/sec
CURVE  25519  key gen        80 ops took 1.000 sec, avg 12.500 ms, 80.000 ops/sec
CURVE  25519    agree        84 ops took 1.020 sec, avg 12.143 ms, 82.353 ops/sec
ED     25519  key gen       165 ops took 1.000 sec, avg 6.061 ms, 165.000 ops/sec
ED     25519     sign       110 ops took 1.000 sec, avg 9.091 ms, 110.000 ops/sec
ED     25519   verify        74 ops took 1.008 sec, avg 13.622 ms, 73.413 ops/sec

Most operations are twice as fast while the Curve25519 operations and Ed25519 Verify are more than 2.5 times faster!

RSA has seen more modest gains when compiling for small SP code. Before, 5.6.3:

RSA     2048   public        38 ops took 1.043 sec, avg 27.447 ms, 36.433 ops/sec
RSA     2048  private         2 ops took 2.016 sec, avg 1008.000 ms, 0.992 ops/sec

And after, 5.6.4:

RSA     2048   public        42 ops took 1.039 sec, avg 24.738 ms, 40.423 ops/sec
RSA     2048  private         2 ops took 1.329 sec, avg 664.500 ms, 1.505 ops/sec

But notably, the RSA private key operation, that corresponds to RSA signing, is 50% faster. (Watch the space for further improvements to these numbers!)

Equivalent improvements are seen with Arm32 CPUs that have the UMAAL instruction. This includes all CPUs implementing ARMv7-A and ARMv8-A.

Try it out and get the best public key cryptography performance for your device.

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