DHE Vulnerability of CVE 2022-40735

Customers have asked about CVE 2022-40735 (https://nvd.nist.gov/vuln/detail/CVE-2022-40735) and whether they are vulnerable as users of wolfSSL. The short is answer is: No. But, there are ways that you can put yourself at risk. Let’s delve into the CVE and how best to protect yourself from attacks like this.

First of all, a description of the CVE is in order to be able to have a proper discussion. The attack centres on the use of DHE in a protocol like TLS where the server uses a large private or large parameters. The actual attack is not clear as we haven’t seen the corresponding paper at time of writing. Despite a minimal description, we can make some good security decisions to protect ourselves.

The attack has a client sending one or more messages to the server to initiate a DHE key exchange. In TLS 1.2, this means the client starts a handshake and negotiates a DHE cipher suite. In TLS 1.3, the client sends a DH key share and only lists support for DH named groups (not named curves). The attack come from the client having to do very little work while the server needs to generate a key pair.

In TLS 1.2, the server generates a key pair first and sends the DH parameters and public key to the client. The client at this point can drop the connection and start again. In TLS 1.3 the client can send the same key share over and over again and drop the connection when the server sends its public DH key.

The amount of work the server has to perform for DHE can be quite large. DHE operations are known to be quite slow and there are ways it can be even slower.

Generating a key pair for the exchange involves generating a random private key and calculating a public key. A private key can be as big as the order - the number of distinct values that can be reached by exponentiating the generator (g). The order is about the same size as the prime modulus.

Wisdom past was that you generate a private key large enough to cover the order. But this is a waste! A 2048-bit DH key has only 112 bits of security. Given that it is very hard computationally to find private key from public key, it turns out 224-bits of private key will suffice. Modular exponentiation with a 2048-bit exponent (private key) will be about 8 times slower than with a 224-bit exponent!

wolfSSL will use a small, but secure, private key when the order is not known and when using named groups.

The CVE describes the attack as a Denial of Service (DoS). That is, the server is too busy generating DH keys to do anything else. But how powerful is the server? How many connections can it handle concurrently? These are questions that you should answer based on your setup.

If a server thread is only expected to handle tens of connections a seconds and the number of DHE operations per second is significantly more, then there is no issue! But if the number of DHE operations per second is close to the required number of connections then some changes need to be made.

Another part of the attack is forcing the server to use larger parameters. For reasons of enhanced security, a server may configured to be able to use the named groups of 2048, 3072 and 4096 bits. On a modern Intel x64 server, say, 4000 2048-bit DHE key generations can be completed in a second. But for 3072-bit DHE only 2000 and for 4096-bit key generations only 1000. Therefore understanding how many connections you want to support compared to how many DHE operations that can be performed per second is important.

So using appropriate sized parameters is an important mitigation if you are to use DHE cipher suites with TLS. Ensure the server is only configured to support parameters of a size that you can handle.

An alternative mitigation is to not use DHE in your TLS handshakes. ECDHE is quite commonly supported and popular. Using X25519 can be 5 times faster than 2048-bit DHE.

There are other mitigations that involve detecting and protecting against DoS attacks. One mechanism is to detect malicious clients and block them or time them out. These protections are considered best practice and should be implemented even when not protecting against this CVE.

In summary, wolfSSL is not vulnerable to the issue of long private keys in DHE key generation as described in CVE 2022-40735. Consider carefully, though, the size of the DHE parameters you allow on you server. The relative performance of DHE operations to connection requirements may mean you should be switching to ECDHE anyway.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Benchmarks for Kyber Level 1 PQM4 Integration on STM32 ARM Cortex-M4

Recently the PQM4 project fixed a bug that was preventing us from turning on optimizations. Please see https://github.com/mupq/pqm4/issues/229 . Naturally, this means we can run benchmarks now!  You can see the results on our benchmarking page at https://www.wolfssl.com/docs/benchmarks/#pq_kyber_kem_l1_pqm4_on_stm32. Here is an abbreviated and reformatted version of our results. We want to compare Kyber Level 1 against ECDSA over the SECP256R1 curve:

ECDHE [SECP256R1]  256 key gen 118 ops took 1.016 sec, avg  8.610 ms, 116.142 ops/sec

ECDHE [SECP256R1]  256 agree    56 ops took 1.016 sec, avg 18.143 ms, 55.118  ops/sec

Kyber_level1-kg                219 ops took 1.000 sec, avg  4.566 ms, 219.000 ops/sec

Kyber_level1-ed                 96 ops took 1.012 sec, avg 10.542 ms, 94.862  ops/sec

Note that Kyber does very well in that keygen on average takes 4.566 ms and an encapsulation and decapsulation cycle takes 10.542 ms which gives a total processing time to achieve a shared secret as 15.108 ms. For ECDHE a similar calculation yields 26.753 ms.  So it would seem that Kyber is marginally faster.  However, ECDHE is a NIKE (Non-Interactive Key Exchange) while Kyber is a KEM so in the context of TLS 1.3, these numbers can be somewhat misleading.

For KEMs, only the client does key generation and sends the public key to the server.  Then only the server does the encapsulation operation and sends the ciphertext back to the client. Then only the client does the decapsulation operation.

For NIKEs, both the server and the client must do the key generation operation.  Then both the server and the client must also do the key agreement step.  Since there are double the number of operations to achieve a shared secret, for a fair comparison, we need to double the average time for ECDHE.  

This gives us 15.108 ms versus 53.506 ms for Kyber and ECDHE respectively.  This makes Kyber the clear winner in processing time. That said, since Kyber has considerably larger artifacts than ECDHE, depending on your method of transmission, this margin can easily be lost if your transmission speeds are slow. 

Want benchmarks for Kyber at levels 3 and 5? What about Kyber hybridized with the NIST curves? Let us know and we’d be happy to help! 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 on Green Hills INTEGRITY RTOS

wolfSSH now runs on Green Hills Software's INTEGRITY RTOS. Rejoice! wolfSSH will build and run almost out of the box. You will have to do a little integration work to get INTEGRITY to start the server appropriately, but at that point it plays nice with the shell application and allows for SFTP. Users can log in using password or public key authentication. Because Green Hills' compiler is more strict about certain code constructs, wolfSSH has been updated to build cleanly without warnings. We look to make wolfSSH the most portable SSH solution for any platform, even bare metal. wolfSSH takes advantage of AEAD ciphers like AES-GCM and maintains a small code size.

 

wolfSSH is lovingly crafted by wolfSSL Inc in the Pacific Northwest.

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 Support for NXP SE050 with SCP03

wolfSSL has supported the NXP SE050 since wolfSSL 5.0.0 (November 1, 2021), giving wolfSSL and wolfCrypt users the ability to use cryptography and secure key generation/storage inside the SE050 while using wolfSSL’s own APIs from the application level. We recently made some substantial additions and enhancements to wolfSSL’s SE050 support, including the following.  These are currently in our master branch on GitHub, and will be included in the next stable release of wolfSSL.

  • SE050 RSA support (sign/verify/encrypt/decrypt, PKCS#1v1.5/PSS/OAEP padding, up to 4096-bit)
  • Allowing use of larger key IDs, fully utilizing SE050’s key ID range
  • Ability to get or set SE050 key IDs to/from wolfCrypt RsaKey or ecc_key structures
  • New APIs to store and get binary objects from SE050
  • New API to erase SE050 objects at a specified key ID
  • New API to get the object size at a specified key ID
  • New define WOLFSSL_SE050_NO_TRNG to fall back to usage of /dev/random and /dev/urandom instead of SE050 TRNG
  • Additional documentation (README_SE050.md)
  • Install se050_port.h with make install for public API use on Linux hosts
  • Fix default library and include paths with “--with-se050” configure option
  • Fix for ECC P-521 where curve size can be larger than SHA-512 digest size
  • Fixes to SE050 message digest support
  • Fixes for wolfCrypt test compatibility with SE050 enabled

wolfSSL SE050 Examples

To help users get going easier and more quickly, we have published example applications designed to be integrated into the SE05x Middleware on Linux (tested on Raspbian with a Raspberry Pi). This examples are located in our wolfssl-examples repository on GitHub, along with documentation on how to integrate and build. Examples include:

  • wolfCrypt test application
  • wolfCrypt benchmark application
  • wolfCrypt SE050 key and certificate insertion and use
  • wolfCrypt CSR generation

wolfSSL HostCrypto support for SCP03 Authentication

wolfSSL can be used on the host side (HostCrypto) for secure SCP03 (Secure Channel Protocol ’03’) authentication, in place of either OpenSSL or mbedTLS. To make this possible, wolfSSL has written a HostCrypto layer that can be applied as a patch to the NXP SE05x Middleware.  Using wolfSSL HostCrypto will use wolfSSL’s software cryptography on the host side to establish the SCP03 channel.  After secure channel establishment, wolfSSL can then be used while offloading crypto and key operations to the SE050.

A patch for the SE05x Middleware for adding wolfSSL HostCrypto support can be found in our osp repository (Open Source Ports) on GitHub, along with documentation on how to patch and build on a Raspberry Pi / Raspbian environment.

Support and More Details

For more details on wolfSSL’s SE050 support, or 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 JSSE Provider and JNI Wrapper 1.11.0 Now Available

Version 1.11.0 of the wolfSSL JSSE Provider and JNI wrapper is now available for download!

wolfSSL JNI/JSSE provide Java-based applications with an easy way to use the native wolfSSL SSL/TLS library. The thin JNI wrapper can be used for direct JNI calls into native wolfSSL, or the JSSE provider (wolfJSSE) can be registered as a Java Security provider for seamless integration underneath the Java Security API. wolfSSL JNI/JSSE provides TLS 1.3 support and also can work with wolfCrypt FIPS 140-2 (and upcoming 140-3).

Release 1.11.0 has bug fixes and new features including:

JNI and JSSE Changes:

  • Add support for system properties: keyStore, keyStoreType, keyStorePassword (PR 74)
  • Add support for secure renegotiation if available in native wolfSSL (PR 75)
  • Fix compilation against newer wolfSSL versions that have dtls.c (PR 107)
  • Fixes and cleanup to SSLEngine implementation (PR 108)
  • Fixes for SSLEngine synchronization issues (PR 108)
  • Add non-standard X509TrustManager.checkServerTrusted() for use on Android (PR 109)
  • Add RPM packaging support (PR 110)
  • Fix SSLSocketFactory.createSocket() to allow for null host (PR 111)
  • Remove @Override on SSLEngine.getHandshakeSession() for older Java versions (PR 114)

Version 1.11.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfSSL JNI/JSSE User Manual can be found here. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Posts navigation

1 2