TLS Hardening with wolfSSL

Another new addition in our 5.6.2 release of wolfSSL is our TLS hardening option. This TLS hardening feature secures your TLS connections according to the recommendations in RFC 9325. When enabled, wolfSSL will:

  • disable TLS versions older than 1.2
  • disable cipher suites based on ephemeral finite-field Diffie-Hellman key agreement finite-field Diffie-Hellman key agreement (i.e., “TLS_DHE_*” suites)
  • disable NULL ciphers
  • disable anonymous ciphers
  • disable legacy ciphers
    • RC4
    • static RSA
    • static DH
  • disable the truncated HMAC extension
  • for TLS 1.2, send the secure renegotiation extension and reject connections that don’t negotiate secure renegotiation

It is also possible to select either 112 or 128 bits of security. When 112 bits of security are enabled, wolfSSL will:

  • require at least 2048 bit Diffie-Hellman keys
  • require at least 2048 bit RSA keys
  • require at least 224 bit Elliptic Curve keys

When 128 bits of security are enabled, wolfSSL will:

  • disable 3DES ciphersuites
  • require at least 3072 bit Diffie-Hellman keys
  • require at least 3072 bit RSA keys
  • require at least 256 bit Elliptic Curve keys

This feature may be enabled in wolfSSL by using the –enable-harden-tls flag.

RFC 9325 also has many recommendations for application and protocol developers. Some of these include:

  • use ALPN to make sure that the traffic sent is interpreted by the correct application
  • use a TLS-only channel instead of enabling dynamic upgrade from an unencrypted to an encrypted channel
  • avoid the use of zero round-trip time (0-RTT) data in TLS 1.3 unless “an explicit specification exists for the application protocol in question to clarify when 0-RTT is appropriate and secure”

We highly recommend reading through the RFC and checking how you can make your project as secure as possible.

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 bare-metal and non-blocking cryptography

One of the unique wolfSSL features is the ability to run wolfSSL on bare-metal without any Real-Time Operating System (RTOS). Supporting bare-metal has always been a requirement for our libraries from initial development. Having a pure C code base, no external dependencies, portable design and modular build options enables this feature and provides a tiny build size. This is a huge differentiator compared to libraries like OpenSSL that won’t even build without a POSIX layer. The build options to enable bare-metal are (–disable-filesystem –enable-singlethreaded) or (SINGLE_THREADED and NO_FILESYSTEM).

Another unique feature of wolfSSL is our support for managing and handling longer asymmetric math computations, which may have non-deterministic execution times. We achieve this by dividing the workload into smaller chunks, allowing the CPU time to perform other tasks concurrently. We call this feature non-blocking cryptography. We support it for RSA, ECC (256/384/521) and Curve25519. Our goal is to limit any blocking on an embedded target to a maximum of 1ms. We used a generic Cortex M4 at 100MHz as our reference. This functionality, for example, allows you to service real-time events while performing a TLS handshake or signature validation. We take pride in being the only open source TLS/Cryptographic library supporting this non-blocking cryptography feature.

From the caller’s perspective, non-blocking cryptography appears much like a non-blocking socket, where the API will return a FP_WOULDBLOCK status and requires being called again. This capability is supported both through the TLS API’s and wolfCrypt directly.

For additional information, please consult the related documentation links and pull request provided below:

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

Converting Between PEM and DER made Easy!

At wolfSSL we are always trying to make the security developer’s job easier. We’ve found that a common problem facing our customers is the need to convert between PEM and DER.

PEM is a Base64, ASCII encoding that is used for X.509 certificates, certificate requests and cryptographic keys. DER is a binary encoding and is much more compact.

CAs commonly supply X5.09 certificates in PEM format. For embedded applications, a DER formatted version is stored for use instead. The new PEM example makes this easy.

The example is compiled as part of the standard distribution, assuming the required features are built into wolfSSL. To convert a PEM file to DER, use the following command line:

./examples/pem/pem -in <file.pem> -out <file.der>

Another common customer situation is that they have an encrypted private key and want to get the unencrypted key as DER. To decrypt a PEM encoded private key:

./examples/pem/pem -in <enckey.pem> —pass <password> -out <key.der>

On the other hand, you may want to encrypt a private key before putting in a public place. To encrypt a DER encode private key into PEM:

./examples/pem/pem -in <key.der> —pass <password> -out <enckey.pem>

There are a number of options you can pass in to choose the algorithms you want to use.

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 5.6.2 and 5.6.3 Release Vulnerabilities

wolfSSL release 5.6.2 and 5.6.3 contained 6 vulnerability fixes. The listed issues were found by external researchers (thanks to their efforts! you can see them mentioned on each of the reports).

  • In cases where a malicious agent could analyze cache timing at a very detailed level, information about the AES key used could be leaked during T/S Box lookups. One such case was shown on RISC-V hardware using the MicroWalk tool (https://github.com/microwalk-project/Microwalk). A hardened version of T/S Box lookups was added in wolfSSL to help mitigate this potential attack and is now on by default with RISC-V builds and can be enabled on other builds if desired by compiling wolfSSL with the macro WOLFSSL_AES_TOUCH_LINES. Thanks to Jan Wichelmann, Christopher Peredy, Florian Sieck, Anna Pätschke, Thomas Eisenbarth (University of Lübeck): MAMBO-V: Dynamic Side-Channel Leakage Analysis on RISC-V. Fixed in the following GitHub pull request #6309
  • In previous versions of wolfSSL if a TLS 1.3 client gets neither a PSK (pre shared key) extension nor a KSE (key share extension) when connecting to a malicious server, a default predictable buffer gets used for the IKM value when generating the session master secret. Using a potentially known IKM value when generating the session master secret key compromises the key generated, allowing an eavesdropper to reconstruct it and potentially allowing surreptitious access to or meddling with message contents in the session. This issue does not affect client validation of connected servers, nor expose private key information, but could result in an insecure TLS 1.3 session when not controlling both sides of the connection. We recommend that TLS 1.3 client side users update the version of wolfSSL used. Thanks to Johannes from Sectra Communications and Linköping University for the report. Fixed in the following GitHub pull request #6412
  • 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 output buffer.

Release 5.6.2 and 5.6.3 have been developed according to wolfSSL’s development and QA process (see link below) and successfully passed the quality criteria.
https://www.wolfssl.com/about/wolfssl-software-development-process-quality-assurance

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

wolfEngine Works with the Final OpenSSL 1.1.1 Branch Release

As mentioned in a previous post, OpenSSL 1.1.1 branch of releases will hit End of Life (EoL) by September 11th, 2023.  That’s right, it’s not a typo!  It’s about 3 months away! It’s already listed as an old release branch here:  https://www.openssl.org/source/old/ . Are you sure you are ready to tackle the migration to their new LTS branch of releases?

In that post (https://www.wolfssl.com/openssl-1-1-1-eol/) we listed 3 ways that wolfSSL could help. One of them was wolfEngine. You can continue using OpenSSL, but under the hood the wolfCrypt implementations of the cryptographic algorithms will be used. This might be especially useful if you are looking for an accelerated path to FIPS certification.

We have put in extra testing against 1.1.1s (which is likely to be the final release on that branch of releases) and can confirm that wolfEngine backed by wolfCrypt will work smoothly with it. Its as easy as setting the OPENSSL_CONF environment variable and adding the following to openssl.conf: 

engine_id = libwolfengine
dynamic_path = /path/to/libwolfengine.so
init = 1

The other option is to set the OPENSSL_ENGINES environment variable to the directory containing libwolfengine.so and then calling the ENGINE_by_id() function. 

And just like that, you will have meticulously optimized, well-supported, regularly updated and best-tested cryptographic implementations working for you; no changes to your code required!

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 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:

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.

Posts navigation

1 2 3 4 5 6 22 23 24