RECENT BLOG NEWS

With the release of wolfSSL 4.7.0, we now support Keying Material Exporters for TLS as defined in RFC 5705! This new functionality allows applications to establish common secrets using the underlying (D)TLS connection. A popular project that makes use of exported keying material is OpenVPN (which wolfSSL supports!). It uses the user provided label, in the --keying-material-exporter option, to generate secure shared secrets for use by plugins from the (D)TLS connection.

To export keying material in wolfSSL, use the new API:

int wolfSSL_export_keying_material(WOLFSSL *ssl,
    	unsigned char *out, size_t outLen,
    	const char *label, size_t labelLen,
    	const unsigned char *context, size_t contextLen,
    	int use_context);

This API outputs outLen data to out. The label and context match those defined in the RFC:

label – “a disambiguating label string”
context – “a per-association context value provided by the [wolfSSL user]”

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

At wolfSSL we have found more and more customers choosing to use TLS 1.3. That’s great! More businesses are taking advantage of the improved security in the new protocol. These customers are finding that they need to use session tickets for resumption for the first time in their applications. In the latest release of wolfSSL, 4.7.0, we’ve made this easier than ever.

Encryption Algorithm

Session tickets require the implementation of a callback that encrypts and decrypts them on the server. There is a great example of how in wolfssl/test.h. Take a look at myTicketEncCb(). Previously the callback encrypted with ChaCha20-Poly1305 but now we include using AES-GCM instead. Choose the one that suites your application!

Default Encryption Callback

At wolfSSL we decided that a default callback was a valuable addition. wolfSSL 4.7.0 now includes a default session ticket encryption callback. Understanding how it works will inform you as to whether to use the default or write your own.

The callback is encrypting and decrypting the session ticket. You can choose which encryption algorithm to use by defining one of the following:

• WOLFSSL_TICKET_ENC_CHACHA20_POLY1305 – use ChaCha20-Poly1305
• WOLFSSL_TICKET_ENC_AES128_GCM – use AES-GCM with 128-bit key
• WOLFSSL_TICKET_ENC_AES256_GCM – use AES-GCM with 256-bit key

Otherwise, the default will be ChaCha20-Poly1305. If that algorithm is not compiled in then it will use AES-GCM with a 128-bit key.

There are two keys that are generated in the callback: primary and secondary. The primary key is generated, with a private random number generator, at first use and which point it is given a lifetime. By default, this is one hour. It can be customized at the second resolution by defining WOLFSSL_TICKET_KEY_LIFETIME. The lifetime must be larger than the lifetime of a session ticket which is 5 minutes by default. This too can be changed at the second resolution by defining SESSION_TICKET_HINT_DEFAULT. The longer the key lifetime the longer the exposure time if a key is compromised.

There are two lifetimes for a key: encryption and decryption. A key used to encrypt a ticket must be kept for the life of the ticket. Therefore the encryption lifetime is shorter than the total key lifetime, or decryption lifetime, by the ticket lifetime. See the diagram below:

If the primary key is expired for encryption but not for decryption, i.e is in the shaded area above, then a secondary key is generated on the next encrypt request. See below.

The secondary key is used until it expires for encryption and only then will a new primary key be generated. Note that in the scenario where session tickets are not commonly used, the primary key may expire for decryption before a new call for encryption. In this case, a new primary key will be generated. In a threaded environment, the generation of the global keys are protected by a mutex to ensure no overwriting.

Exporting and importing keys is also possible using: wolfSSL_CTX_get_tlsext_ticket_keys() and wolfSSL_CTX_set_tlsext_ticket_keys(). These APIs are useful for sharing keys across processes or server machines and expiration times are included in the blob.

The default session ticket encryption callback will cover most use cases. If you want to use another encryption algorithm, have very limited memory, or need an advanced sharing strategy between servers then define WOLFSSL_NO_DEF_TICKET_ENC_CB and set your own callback.

TLS 1.3 and TLS 1.2 Session Ticket Use

Finally, customers that haven’t been using session tickets for TLS 1.2 connections and now are for TLS 1.3, wanted to prevent session tickets being used with TLS 1.2. A reasonable request that we now support with the functions:

wolfSSL_CTX_NoTicketTLSv12()
wolfSSL_NoTicketTLSv12()

Calling these functions sets a flag against the context or object that results in the handshake ignoring session tickets on the client and server when the protocol version negotiated is TLS 1.2 or lower.

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

Did you know that wolfSSL is transport agnostic, and can run on bare metal? Did you know that we have DO-178 artifacts for our software? Are you aware of MITM attacks or spoofing attacks that could compromise your network?

Let us know if you need help with security for your ARINC 664 transmissions. We can make a world of difference for you!

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 has a major new product in development — wolfSentry, the universal, dynamic, embeddable IDPS (intrusion detection and prevention system). At a high level, wolfSentry is a dynamically configurable logic hub, arbitrarily associating user-defined events with user-defined actions, contextualized by connection attributes, tracking the evolution of the client-server relationship. At a low level, wolfSentry is a firewall engine (both static and fully dynamic), with O(log n) lookup of known hosts/netblocks.

wolfSentry will be fully integrated into wolfSSL, wolfMQTT, and wolfSSH, with optional in-tree call-ins and callbacks that give application developers turnkey IDPS across all network-facing wolfSSL products, with a viable zero-configuration option. These integrations will be available via simple --enable-wolfidps configure options in wolfSSL sibling products.

The wolfSentry engine will be dynamically configurable programmatically through an API, or from a textual input file supplied to the engine. Callback and client-server implementations will also be supplied that deliver advanced capabilities including remote logging through MQTT or syslog, and remote configuration and status queries, all cryptographically secured.

Notably, wolfSentry is designed from the ground up to function well in resource-constrained, bare-metal, and realtime environments, with algorithms to stay within designated maximum memory footprints and maintain deterministic throughput. wolfSentry with dynamic firewalling can add as little as 64k to the code footprint, and 32k to the volatile state footprint, and can fully leverage the existing logic and state of applications and sibling libraries.

The first beta release of wolfSentry is planned for April 2021, with turnkey product integrations to follow.

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

It is not always easy to tell if your TLS vendor is legitimate. They might have great slide decks, a list of supported ciphers, and a smooth talking salesperson, but do they have what it takes to keep you secure? Here’s how you tell: Ask them if they do fuzz testing. If you get a blank stare, it is time to move on. If they mumble a yes, then you should ask them about their overall testing infrastructure. If it doesn’t look like this: https://www.wolfssl.com/overview-of-testing-in-wolfssl/, then you might want to reconsider that vendor.

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 software expansion package for STM32Cube is among the first to be MadeForSTM32 certified with V2 label! Having gone through the evaluation process, we’re pleased to announce that I-CUBE-WOLFSSL V4.6.0 is granted MadeForSTM32 V2, a new quality label introduced by STMicroelectronics for the STM32 microcontrollers ecosystem. 

wolfSSL offers support for STM32Cube Expansion Package enhanced for STM32 toolset, adding on to previous support for the STM32 Standard Peripheral Library as well as the STM32Cube HAL (Hardware Abstraction Layer). We’re making it easy for users to pull wolfSSL directly into STM32CubeMX and STM32CubeIDE projects.

Check out our product page for more information on the package. If you missed the webinar, watch the recording and demo here to learn how to use wolfSSL software expansion for STM32Cube.

wolfSSL focuses on providing lightweight and embedded security solutions with an emphasis on speed, size, portability, features, and standards compliance. With its SSL/TLS products and crypto library, wolfSSL is supporting high security designs in automotive, avionics and other industries. In avionics, wolfSSL supports complete RTCA DO-178C level A certification. In automotive, we support MISRA-C capabilities. For government consumers, wolfSSL has a strong history in FIPS 140-2, with upcoming FIPS 140-3. wolfSSL supports industry standards up to the current TLS 1.3 and DTLS 1.2, is up to 20 times smaller than OpenSSL, offers a simple API, an OpenSSL compatibility layer, is backed by the robust wolfCrypt cryptography library, 24×7 support and much more. Our products are open source, giving customers the freedom to look under the hood. 

Get the latest version of wolfSSL 4.7.0 from our download page!

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

Follow wolfSSL on Twitter: @wolfSSL

Follow ST: @ST_World

Benchmark values of the wolfSSL embedded SSL/TLS library running on Xilinx boards, including the ZCU102, have been collected and are up for viewing. Our friends over at Xilinx have a white paper posted that goes into detail about the benchmark values here: https://www.xilinx.com/support/documentation/white_papers/wp512-accel-crypto.pdf. This shows how much faster applications can perform secure operations when incorporating the hardware acceleration available on Xilinx devices. It also gives a demonstration of the performance trade-offs when choosing FreeRTOS versus an embedded Linux OS.

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

Most bootloaders do not use hardware acceleration and cryptography.

wolfSSL’s wolfBoot is an exception.

wolfBoot can use Secure Elements, such as ATECC508A. Thanks to integration with wolfTPM, wolfBoot can also leverage TPM 2.0, such as STMicroelectronics ST33, Infineon SLB9670, Nuvoton NPC750 and other TPM modules.

Thanks to wolfSSL’s cryptographic engine, wolfBoot can take advantage of the hardware acceleration for cryptography operations of many embedded and server platforms. Here are highlights of our platforms support list:

wolfBoot is a solution for firmware update and authentication that can take advantage of your platform’s hardware acceleration and cryptography. This way we achieve a small memory footprint and high performance during secure updates over the air(OTA).

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

Hi! We continue to make progress on our upcoming FIPS 140-3 certification. We have now completed code review, and are working with our lab on operational testing. The process will be in NIST’s hands after that. Our goal is to be the first software cryptographic library with a FIPS 140-3 certification, and that looks like it is on track!

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

For more information on wolfCrypt’s previous 140-2 certificates, visit our FIPS page here.

In wolfSSL release 4.7, the Linux kernel module implementation has been enhanced to use kvmalloc() and kvfree() for heap-based storage. The typical approach using kmalloc() allocates physically contiguous memory, with meaningful limitations on the maximum size of allocation and the impact of those allocations on other system components. kvmalloc(), by contrast, uses vmalloc() internally to make non-contiguous use of memory for large allocations, which is more efficient and less contentious. The wolfSSL kernel module now leverages this capability when targeted to Linux kernel 4.12 or newer, relaxing potential resource constraints and minimizing the likelihood of interference in the kernel.

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