Author: Kajal Sapkota

What is CT (Certificate Transparency)? 

Certificate Transparency is from RFC 6962 and is an extension on certificates to create a Merkle Tree (hash tree like with blockchain). The purpose of the tree is to help spot misuses of certificates and to provide a public way to audit the log of certificates issued. It was first implemented by Google in 2013 and required by google in 2017 which was then pushed back to 2018. Google has now been requiring all new certificates that are issued to have CT. The SCT (signed certificate timestamp) for CT can be sent in a TLS extension too, or with OCSP.

This is something we are thinking of adding to our library just to make it easier for users to parse out the information and view it with wolfSSL. Currently, users can get the extension by getting the peer certificate after a connection is complete and using one of the available checkers (google/cloudflare have checkers). It obviously gets more involved if adding the TLS extension (signed_certificate_timestamp) or if implementing a Monitor (application that goes out and does the audit on the certificate).

What are we doing about it?

To make this process easier we are planning on leaving it up to the certificate to contain the SCT and parse it from there.

To get there we are planing on making sure it includes:

– API to get the certificate extension information (people using this will want the hash / signature / timestamp to perform an audit on certificates)

– Checks on the timestamp (must be rejected by client if it is in the future)

– Code in our certificate extension parsing to read the OIDs and store the hash / signature / timestamp

– Testing and documentation (more time on testing since affecting certificate parsing code)

Love it? Star wolfSSL 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.

If you pop over to the OpenWrt project site, you’ll stumble upon some excellent news:

“TLS support is now provided by default in OpenWrt images including the trusted CA certificates from Mozilla. It means that wget and opkg now support fetching resources over HTTPS out-of-the-box. The opkg download server is accessed through HTTPS by default. OpenWrt switched from mbed TLS to wolfSSL as the default SSL library, mbed TLS and OpenSSL are still available and can be installed manually.”

This means OpenWrt users can easily benefit from everything keeping wolfSSL ahead of the pack, including our early adoption of TLS 1.3 for top-tier security, uncompromised performance benchmarks, and certifications such as FIPS 140-2 and 3. Learn more about wolfSSL’s advantages over OpenSSL and write to us (facts at wolfSSL.com) to tell us about your OpenWrt projects with wolfSSL!

Love it? Star wolfSSL on GitHub.

Find the OpenWrt announcement 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.

With our new release of wolfSentry people might wonder how it compares to Suricata. Suricata is an open source IDS / IPS / NSM engine. While it seems that Suricata is in rivalry with wolfSentry, our embedded IDPS; they actually have a synergy, it would make sense for sophisticated users to deploy both of them.

Suricata:

• The distribution tarball is 29 MB
• The build tree with minimal featureset is 536 MB
• The binary installation image is 35 MB, of which 34.5 MB is the Suricata binary executable (dynamically linked)
• The main executable depends on 18 special purpose libraries not included in the distribution.
• Suricata depends on Python
• It only runs on Unix-like and Windows OSs, and its firewalling (host protection) depends on host OS facilities.

Suricata is a heavyweight, infrastructural IDS platform.  It has to duplicate the logic, and a lot of the processing, of the protocols/libraries/applications that it is monitoring and protecting.

Suricata can do a lot of powerful things, including protecting endpoints that can’t protect themselves, and protecting endpoints before they’re attacked, by blocking bad actors at the first opportunity, when they’ve only had time to attack a first protected endpoint.

wolfSentry

By comparison, wolfSentry has a much smaller footprint. 

• The distribution tarball is 36 K.
• The build tree is 2.5 MB, with all features and debugging symbols enabled.
• libwolfsentry.a is 339 K, and the biggest example executable is 443 K, or 84 K stripped, and uses no libraries beyond libc (which it barely uses).
• It is designed to integrate directly with network-facing applications/libraries to block bad traffic, and it can optionally integrate with host firewall facilities, via plugins.
• It can run on bare metal, in which case the firewall functions can be directly integrated into the network stack of the application.

wolfSentry isn’t infrastructural, it’s on the endpoints, and it’s intended to be integrated with the endpoint applications/libraries to leverage them to the fullest.

Comparison and Synergy

The synergy between wolfSentry and Suricata infrastructural IDPSs is to have wolfSentry (via a plugin) notify the external IDPS when it detects bad traffic that the external IDPS might not be able to detect.  This can enable clever stuff like blocking the bad traffic inside the network, before it even reaches the endpoint, and of course blocking the bad traffic for all the protected endpoints at once.

This raises an obvious worry about Suricata being compromised, because by nature it is directly exposed to the network, and is highly privileged.  Suricata addresses this by doing lots of fuzz testing etc. to build confidence.  However, because they have a 29 MB distribution tarball, there is a higher likelihood for things to fall through the cracks.

An advantage of wolfSentry is wolfSentry doesn’t require the endpoint to trust anyone else, nor anyone else to trust the endpoint.  It’s a freestanding, high-efficiency self-defense system.

Ultimately, while there are some comparisons and different uses between the two, the best course of action would be to use wolfSentry and Suricata together for the best secure IDPS.

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 is implementing MIKEY-SAKKE!

MIKEY-SAKKE is a standard created by the UK government’s National Cyber Security Center (NCSC). MIKEY-SAKKE is a standard designed to enable secure, cross-platform multimedia communications. It is highly scalable, requiring no prior setup between users or distribution of user certificates. It is designed to be centrally-managed, giving a domain manager full control of the security of the system. But even so, it maintains high-availability, as calling does not require interaction with centralized architecture.

wolfSSL is a lightweight TLS/SSL library that is targeted for embedded devices and systems. It has support for the TLS 1.3 protocol, which is a secure protocol for transporting data between devices and across the Internet. In addition, wolfSSL uses the wolfCrypt encryption library to handle its data encryption.

Secure communications are needed across all governments. As a result governments create policies encouraging the development of security solutions. MIKEY-SAKKE is the answer to the security requirements from the UK government to specify secure, open and patent free cryptographic methods in order to empower private industry to provide UK government interoperable secure communication solutions. As a result many private and commercial organizations perceive a sizable advantage being MIKEY-SAKKE compliant.

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 sensor network sub-specification of MQTT does not designate a method for securing the communication between the clients and the gateway. We here at wolfSSL think that is unacceptable! Using the DTLS library of wolfSSL, we would like to protect the sensor data all the way from the client to the gateway, and then from the gateway on to the broker using standard TLS (also from wolfSSL).

Who else is interested in a completely secure, all-in-one solution for MQTT-SN?

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/wolfMQTT
While you’re there, show us some love and give the wolfMQTT project a Star!

Stay tuned for an MQTT embeddable broker coming soon. We are going to be expanding our wolfMQTT library to include a lightweight, embeddable broker. The wolfMQTT embedded broker will allow for a low cost, low power, MQTT enabled network, all implemented in a C-based library.

wolfMQTT secures MQTT communication using the wolfSSL embedded SSL/TLS library for SSL/TLS support. wolfSSL provides support for many different features such as TLS 1.3, TCP, UDP, DTLS etc.

wolfMQTT is available from github (https://github.com/wolfSSL/wolfMQTT) and is distributed under the terms of the GNU General Public License (GPL). Alternative proprietary licenses, technical support (up to 24/7 worldwide) and customization services are available via wolfSSL Inc.

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

As many in the FIPS world are aware NIST retired CAVP (Cryptographic Algorithm Validation Protocol) testing on June 30th of 2020, permanently replacing CAVP with ACVP (Automated Cryptographic Validation Protocol), also referred to as ACVTS (Automated Cryptographic Validation Test System).

In order to prepare for this transition NIST offered a “demo server” that Vendors like wolfSSL and FIPS Labs could utilize in standup of the new protocol. Once the transition was completed NIST also setup “production servers” which only FIPS Labs with a trusted certificate issued by NIST can connect to; Production Vectors passing are now the gateway to Algorithm Certification (IE certs like the ones wolfSSL just received!).

Algorithm Certification is a prerequisite to CMVP FIPS 140-2 (and 140-3) validations. This design keeps in place the need for a FIPS lab to achieve algorithm certification but it now allows for Vendors such as wolfSSL to pre-test in advance of requesting production vectors for certification! wolfCrypt has been listed on the CMVP IUT List for FIPS 140-3! We are currently working with our testing lab to get validated as quickly as possible with the new FIPS standard from the NIST. wolfSSL is the first software library on the FIPS 140-3 IUT list for embedded development.

Concurrently wolfSSL is also in the process of developing our own ACVP client based off of the current draft (draft-fussell-acvp-spec-01). Having many algorithms already completing the validation process through the NIST operated ACVP Demo server. Where our test vendor information can be seen publicly listed on the demo site here (https://demo.acvts.nist.gov/home).

More on ACVP’s

ACVP stands for (Automated Cryptographic Validation Protocol) and it is the upcoming protocol that will be used for FIPS validation. This is going to be a prerequisite certificate for the CMVP(Cryptographic Module Validation Program) and CAVP(Cryptographic Algorithm Validation Program) certificates.

ACVP makes testing cryptographic algorithms and modules more efficient than the current method and more automated. There are three main parts to ACVP – a server, a proxy, and a client.

• The server side handles requests for test vectors and requests for validation among other requests. This side is operated by a FIPS lab or by NIST themselves.
• A proxy with ACVP can be used to communicate to offline systems and handle transferring information from the system being tested to the server. Often an ACVP client is used instead.
• The last part being a client, which is most relevant to users who are wanting to get their cryptography FIPS validated. An ACVP client is directly hooked up to the module to be tested and then communicates with the ACVP server to send requests for test vectors, responses of the results from running those tests, and requests for algorithm validation. There are multiple pieces required to build a ACVP client in order to complete a validation process, some of the large portions of the effort go into
  • JSON parsing / creation for communication with a ACVP server
  • HTTPS GET / POST / PUT / DELETE messages used for securely transporting information
  • 2 factor authentication with TOTP (Time-Based One-Time Password Algorithm)
  • Plugging in the test harness that runs crypto operations

Ultimately an ACVP client communicates with the server to validate cryptographic operations. This includes creating, or referencing meta data such as; vendor, OE, and module information. A simplified message flow for getting an algorithm validated is as follows:

We can assist with your FIPS needs.

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

More information from NIST’s website about the ACVP project can be found here:
https://csrc.nist.gov/Projects/Automated-Cryptographic-Validation-Testing.

From the early days of the wolfSSL library, we have provided example clients and servers with wolfSSL. These examples have shown how easy it is to use wolfSSL in various configurations. We also use them to help test the library. Over the years we’ve added new features available with TLS to our examples, and our examples have grown a little complicated.

Enter the wolfSSL Examples GitHub repository. We tasked some of our interns, with little to no experience with the wolfSSL library, to write some example clients and servers that set up and test various types of connections. They give you a bare-bones simple demonstration on how to set up a client or server using wolfSSL. We also have examples showing off how to use some features of the library like the certificate manager. 

The repository contains example applications, written in C, which demonstrate how to use the wolfSSL lightweight SSL/TLS library for secure communication. Each directory represents a unique topic (SSL/TLS, DTLS, PSK, etc.) and contains a Makefile as well as a simple tutorial on the given topic.

Current Examples:

• utasker (uTasker wolfSSL Example Tasks)

This directory contains example uTasker client and server tasks that demonstrate using wolfSSL with the uTasker stack. These have been tested on the uTasker Simulator.

Please see the utasker/README.md for further usage and details.

• android (Android NDK Examples)

This directory contains examples that demonstrate using wolfSSL and wolfSSLJNI on the Android platform, using the Android NDK toolchain.

Please see the android/README.md for further usage and details.

• certfields (X509 field extraction)

This directory contains an example that demonstrates using the wolfSSL to read a DER encoded certificate and extract the public key and subject name information.

Please see the certfields/README.md for further usage and details.

• certmanager (wolfSSL CertManager)

This directory contains examples that demonstrate using the wolfSSL CertManager (Certificate Manager) functionality.

Please see the certmanager/README.md for further usage and details.

• wolfCLU (wolfSSL Command Line Utility)

This is a tool to provide command line access to wolfcrypt cryptographic libraries. wolfSSL command line utility will allow users to encrypt or decrypt a user specified file to any file name and extension.

Please see the clu/README.md for further usage and details.

Unique feature to wolfSSL CLU

The decision to allow for unique file extensions was prompted by automated tools available for brute forcing files. It will not provide extra security cryptographically however it will force attackers to check the header information on every single brute force attempt. This will provide further frustration and an extra step in any attempt to brute force a file encrypted with our utility.

• DTLS (Datagram TLS)

This directory contains examples of using DTLS, with client and server examples demonstrating UDP, DTLS, non-blocking, session resumption, and multi-threading.

When compiling wolfSSL for use with these examples, wolfSSL will need to be compiled with DTLS support:

cd wolfssl-[version]
./configure --enable-dtls

Examples in this directory may be compiled using:

cd ./dtls
make

• PSK (Pre-Shared Keys)

This directory contains examples of using PSK, with client and server examples demonstrating TCP/IP, PSK, non-blocking, session resumption, and multi-threading.

When compiling wolfSSL for use with these examples, wolfSSL will need to be compiled with PSK support:

cd wolfssl-[version]
./configure --enable-psk

Examples in this directory may be compiled using:

cd ./psk
make

• SSL/TLS

This directory contains examples of using SSL/TLS, with client and server examples demonstrating TCP/IP, SSL/TLS, non-blocking, session resumption, and multi-threading.

Examples in this directory may be compiled using:

cd ./tls
make

• BTLE

This directory contains examples for securing a Bluetooth Low Energy Link (BTLE). BTLE packets are small and throughput is low, so these examples demonstrate a way to exchange data securely without BTLE pairing.

Notes

When necessary, examples will use the example certificates and keys located in the ./certs directory. These certificates and keys have been pulled in from the main wolfSSL repository.

Support

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

We see a continuing adoption of wolfTPM and TPM 2.0 modules in IoT and Edge embedded systems. In addition, there is a new trend of adding wolfTPM to safety-critical systems, such as aerospace and medical products. For many years, there was no TPM 2.0 stack designed for baremetal and RTOS systems and wolfTPM changed this.

Today, we can announce that wolfTPM is also the first TPM 2.0 stack to support Physical Presence (PP). This feature allows the user to confirm TPM 2.0 operations by asserting physical input to the TPM chip and increase the level of security assurance for critical operations.

For example, TPM2_Clear is a command that returns the TPM to a factory state, destroying existing primary and storage keys, and can be safeguarded by a PP request. TPM2_Clear is typically used when onboarding a new owner of a system, e.g. second market or internal change of ownership equipment.

PP requests are satisfied by controlling a dedicated I/O pin on the TPM chip and now wolfTPM has the capability to extend the list of commands that require it. This could be used to restrict certain operations. It could also be used in existing designs to replace a mechanical switch previously used for Physical Presence.

Another new feature of wolfTPM is the ability to control extra I/O pins available on TPM modules, such as the STMicroelectronics ST33 TPM 2.0 module. The developer can use a single wolfTPM call to control additional I/O pins and pass physical signals, as sign of security or system events, to other subsystems.

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

Some of our users have been wondering if we were doing benchmarks of our SSL/TLS and cryptography performance. Here are the results we have gathered so far: wolfSSL / wolfCrypt Benchmarking.  This page includes several reference benchmarks as well as comparisons of software versus hardware cryptography.

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