RECENT BLOG NEWS

wolfSSL is always adding new ports to our highly portable wolfCrypt library! We’re continuing our series on the latest open source project ports—this week, we’re featuring tcpdump.

We have integrated wolfSSL with tcpdump, a powerful command-line packet analyzer. This update allows for the use of tcpdump with our FIPS-validated crypto library, wolfCrypt. Tcpdump is a versatile tool with many options and filters, and is commonly used to capture or filter TCP/IP packets that are received or transferred over a network on a specific interface. Its long-running history ensures that there are many resources available for learning how to use this tool (See the tcpdump Wikipedia page for more info). 

Through the OpenSSL compatibility layer, tcpdump is able to call into wolfSSL. Visit the GitHub page here: https://github.com/wolfSSL/osp/tree/master/tcpdump/4.9.3

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!

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

News to look forward to—wolfSSL plans to integrate wolfTPM, our portable TPM 2.0 library, into U-Boot! This would extend the TPM 2.0 capabilities in U-Boot to include signature verification and measured boot.

For many platforms, we can replace U-Boot such as on the Xilinx UltraScale+ MPSoC.

wolfBoot is a portable secure bootloader solution that offers firmware authentication and firmware update mechanisms. Thanks to its minimalistic design, wolfBoot is completely independent from any OS or bare-metal application. Some of its key features include:

• Partition signature verification using ED25519, RSA and ECC
• Encryption of partitions
• Updating of partitions in the boot loader
• Measured boot with TPM 2.0 PCR registers
• Offloading to crypto coprocessors like the TPM 2.0 modules
• Version checking for updates
• Rollback on failed updates

For information on our wolfBoot TPM integration, visit https://www.wolfssl.com/curious-learn-wolfboot-tpm/.

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

Connect with wolfSSL!
Twitter
LinkedIn
GitHub

Public key infrastructure or PKI is important term used to define everything that is used to “create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.” (https://en.wikipedia.org/wiki/Public_key_infrastructure) As RSA and ECC are one of the main algorithms used for PKI key generation, we are wondering if anyone is interested in RSA 3k or ECC 384 support in wolfBoot?

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

You can download the latest release here: https://www.wolfssl.com/download/
Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfBoot
While you’re there, show us some love and give the wolfBoot project a Star!

wolfSSL has long been aware of the quantum threat to modern cryptography. Though quantum computing currently exists on small scales, research has determined enough to know that once full-scale quantum computing is available, all modern cryptography (RSA, ECC, etc.) will no longer be secure. Furthermore, the proven usage model of Quantum Computing as a Service (QCaaS) via the Cloud means that quantum capabilities will be more widely available, posing a greater security threat. This risk is why wolfSSL provides support for integration with the NTRU cryptosystem and an implementation of the QSH TLS extension. 

With NIST already having announced the Round 3 finalists of the Post-Quantum Cryptography Competition, we thought it was time to update our quantum-safe offerings. WolfSSL will soon support integration with the Open Quantum-Safe project’s libOQS. Initial support will be for Key Exchange only using all parameter sets of Crystals-Kyber, NTRU, and SABER for TLS 1.3. With perfect forward secrecy, these algorithms can protect you from the “Harvest and Decrypt” threat model.

“Harvest and Decrypt”

If encrypted sensitive data is stolen (harvested) today, it will be accessible (decrypted) once a sufficiently-powered quantum computer is available. If the sensitive information has a secrecy requirement that extends beyond the time it will take to develop large-scale quantum computing, then that data should be considered at risk today. The quantum threat to current confidential data demonstrates the importance of migrating to quantum-safe solutions as soon as possible. For more details, you can look up “Mosca’s Inequality”.

Next Steps

To continue future-proofing encrypted data streams, wolfSSL plans to hybridize key construction algorithms with NIST-standardized ECDSA components. These hybridized algorithms will continue to be FIPS compliant under the current NIST standards. In addition, wolfSSL is developing a test for post-quantum cURL, coming in the next 4 to 6 weeks.

wolfSSL is attending ICMC (International Cryptographic Module Conference) this week, where we will be talking more about post-quantum computing—come visit us there! 

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

One of the highlights of our wolfCrypt library is its exceptional portability, which allows wolfSSL’s team of engineers to frequently add new ports! Stay tuned for the rest of our blog series on the latest open source project ports over the next few weeks.

This week, we’re showcasing libssh2! We have integrated wolfSSL with the libssh2 project, which allows for the use of libssh2 with our FIPS-validated crypto library, wolfCrypt. Libssh2 is a client-side C library designed to implement the SSH2 protocol for embedding specific SSH (Secure Shell) capabilities into other tools. The project includes hundreds of functions that allow specific activities and components to be selected and added to an application, while still remaining small in size.

We’ve enabled libssh2 to be able to call into wolfSSL through the OpenSSL compatibility layer. You can access the GitHub page here: https://github.com/wolfSSL/osp/tree/master/libssh2/1.9.0

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!

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

lighttpd has added support for wolfSSL in version 1.4.51! lighttpd is a fast and lightweight web server designed with a very low memory footprint. These design goals make wolfSSL an excellent choice as the SSL/TLS implementation, as it’s built to be lightweight, portable, and very fast. wolfSSL targets embedded and IoT devices but works just as well on desktop, enterprise, and cloud environments. Configuring wolfSSL as the SSL/TLS backend for lighttpd is simple and can provide you with the immediate benefit of a lower memory footprint and faster cryptography!

Compile wolfSSL with:

./configure --enable-lighty
make
make install

Compile lighttpd with:

./configure --with-wolfssl
make 
make install

To learn about how to setup your lighttpd instance to use wolfSSL, please visit https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL.

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

Love it? Star us on GitHub!

Because of the exceptional portability of our wolfCrypt library, plus our fantastic team of engineers, we’re able to frequently add new ports. We’ll be showcasing a few of the latest open source project ports over the next ten weeks, so tune in!

First, we just integrated wolfSSL with the NTP (Network Time Protocol) project. This port allows for the use of NTP with our FIPS-validated crypto library, wolfCrypt. NTP is designed to synchronize the clocks of computers over packet-switched, variable-latency data networks. For more information on NTP, you can also visit the project’s website at ntp.org.

We’ve enabled NTP to be able to call into wolfSSL through the OpenSSL compatibility layer. You can access the GitHub page here: https://github.com/wolfSSL/osp/tree/master/ntp/4.2.8p15

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!

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

The wolfSSL library has for a long time supported encryption and decryption using ECC with an implementation of ECIES (Elliptic Curve Integrated Encryption Scheme). Recently the ECIES code was updated to support the SEC.1 and ISO/IEC 18033 variants.

ECIES is the elliptic curve equivalent of the RSA encryption algorithm and is useful as a key encapsulation mechanism (KEM). KEMs are used to established shared keys between two parties that have never communicated before. By securing, say, a symmetric key with the EC public key, only the owner of the EC private key can derive it.

Unlike RSA encryption, ECIES can also be used for sending a message securely to the owner of the private key (i.e. data encapsulation mechanism (DEM)). The integration of a symmetric cipher in the ECIES algorithm allows it to encrypt any amount of data.

In the real world, ECIES is used by standards like the Intelligent Transport Systems (ETSI TS 103 097) and is part of Android Pay and Apple’s iMessage and Find My.

In the wolfSSL library, the default algorithm is now as described in SEC.1. If you require the original wolfSSL algorithm then configure with -–enable-ecies=old or define WOLFSSL_ECIES_OLD. Alternatively, if the ISO/IEC 18033 algorithm is required then configure with -–enable-ecies=iso18033 or define WOLFSSL_ECIES_ISO18033.

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

The wolfSSL library includes a useful tool for sniffing TLS traffic. This can be used to capture and decrypt live or recorded PCAP traces when at least one of the keys is known. Typically a static RSA ciphersuite would be used, however with TLS v1.3 only Perfect Forward Secrecy (PFS) ciphers are allowed. For TLS v1.3 all cipher suites use a new ephemeral key for each new session.

In order to solve this we added a “static ephemeral” feature, which allows setting a known key that is used for deriving a shared secret. The key can be rolled periodically and synchronized with the sniffer tool to decrypt traffic. This feature is disabled by default and is only recommended for internal or test environments.

As a proof of concept we added this support to Apache httpd to demonstrate real-time decryption of web traffic. We are also working on a key manager to assist with key rolling and synchronization.

A use case that might be interesting is a company internal web server that requires auditing.

The TLS v1.3 sniffer support was added in PR 3044 and officially supported in v4.8.1.
The Apache httpd branch with sniffer and FIPS ready support is 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.

The wolfSSL embedded SSL/TLS library supports many popular hardware secure elements from several suppliers using different technologies.

Some of these hardware elements are specifically designed to enable end-to-end security in IoT devices, by providing a hardware ‘Root of Trust’, and by providing asynchronous cryptography functionality and key vaults.

GSMA is an alliance representing mobile operators, manufacturers and companies focusing on the mobile communication industry. The alliance has published the guidelines to implement  a Root-of-trust mechanism, IoT SIM Applet For Secure End-to-End Communication, also known as IoT-SAFE. This technology promotes the use of SIM cards as Root-of-Trust to secure applications and services running on embedded systems connected through the mobile network. IoT-SAFE opens new possibilities for key provisioning through a component that is, in fact, already designed to support end-to-end security within different layers of the protocol.

wolfSSL, in collaboration with partners in the mobile industry, has recently developed an IoT-SAFE module for the wolfSSL embedded TLS library.

The code is portable and it’s designed to be used on an embedded board, equipped with an LTE modem and an IoT-SAFE capable SIM card, but can be easily adapted to run on any environment that has access to a communication channel with an IoT-SAFE capable SIM card.

The module includes several features, such as the possibility to use IoT-SAFE as true random number generator, access asymmetric key operations on the SIM, as well as generate, store and retrieve keys in the secure vault. The most important feature though, is the possibility to equip wolfSSL sessions with IoT-SAFE support, so that all the operations during the TLS handshake for that session are executed through IoT-SAFE commands. 

To demonstrate a full TLS endpoint using IoT-SAFE API to complete the handshake and establish a TLS session, we have prepared an example that uses a SIM card pre-provisioned with our test ECC certificate and keys. Both TLS 1.3 and 1.2 are supported.

Securing Device-to-Cloud communication with a robust end-to-end strategy is of course the main priority of this module. However, we are looking forward to seeing wolfSSL IoT-SAFE support used in different applications and use cases.

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

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!