RECENT BLOG NEWS

wolfSSL FIPS Ready

Along with the recent release of wolfSSL v4.1.0, wolfSSL has updated its support for the wolfCrypt FIPS Ready version of the wolfSSL library. wolfCrypt FIPS Ready is our FIPS enabled cryptography layer included in the wolfSSL source tree that can be enabled and built. To elaborate on what FIPS Ready really means: you do not get a FIPS certificate and you are not FIPS approved. FIPS Ready means that you have included the FIPS code into your build and that you are operating according to the FIPS enforced best practices of default entry point, and Power On Self Test (POST).

FIPS Ready with curl

(modified from Daniel Stenberg) 

The integration of wolfSSL and curl means that the curl library can also be built using the wolfCrypt FIPS ready library. The following outlines the steps for building curl with FIPS Ready:

1. Download wolfSSL fips ready

2. Unzip the source code somewhere suitable:

$ cd $HOME/src
$ unzip wolfssl-4.1.0-gplv3-fips-ready.zip
$ cd wolfssl-4.1.0-gplv3-fips-ready

3. Build the fips-ready wolfSSL and install it somewhere suitable:

$ ./configure --prefix=$HOME/wolfssl-fips --enable-harden --enable-all
$ make -sj
$ make install

4. Download curl, the normal curl package.

5. Unzip the source code somewhere suitable:

$ cd $HOME/src
$ unzip curl-7.66.0.zip
$ cd curl-7.66.0

6. Build curl with the just recently built and installed FIPS ready wolfSSL version:

$ LD_LIBRARY_PATH=$HOME/wolfssl-fips/lib ./configure --with-wolfssl=$HOME/wolfssl-fips --without-ssl
$ make -sj

7. Now, verify that your new build matches your expectations by:

$ ./src/curl -V

It should show that it uses wolfSSL and that all the protocols and features you want are enabled and present. If not, iterate until it does!

wolfSSL FIPS ready is open source and dual-licensed. More information about building FIPS ready can be found in the FIPS Ready user guide.
More information about wolfSSL and curl can be found on the curl product page.
Details on wolfSSL support for curl is also located on the support page.

For more information regarding wolfSSL, wolfCrypt, cURL, support packages, or any additional questions, please contact facts@wolfssl.com.

The C# wrapper bundled with wolfSSL can be used in conjunction with Mono to run C# projects on platforms other than Windows! Mono provides users with an easy way to cross platforms with C# applications. To get things started when using wolfSSL, first compile the easy to use Visual Studio example in the wolfssl-X.X.X/wrapper/CSharp directory, then transport the “DLL Debug” folder, that gets created after a successful build, to any platform with Mono. After compiling and transporting the folder the executable can be run with the command “mono wolfSSL-TLS-Server.exe” from inside the “DLL Debug” folder.

Server Using wolfSSL C# Wrapper with Mono on MacOS:

$ mono wolfSSL-TLS-Server.exe
Calling ctx Init from wolfSSL
Finished init of ctx .... now load in cert and key
Ciphers : TLS13-AES128-GCM-SHA256:TLS13-AES256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES128-CCM-SHA256:TLS13-AES128-CCM-8-SHA256:TLS13-SHA256-SHA256:TLS13-SHA384-SHA384
…
…
Started TCP and waiting for a connection
Connection made wolfSSL_accept 
SSL version is TLSv1.3
SSL cipher suite is TLS13-AES128-GCM-SHA256
hello wolfssl!
freeing ssl handle
freeing ctx handle

Client Connecting to Server:

$ ./examples/client/client -v 4
peer's cert info:
 issuer : /C=US/ST=Montana/L=Bozeman/O=Sawtooth/OU=Consulting/CN=www.wolfssl.com/emailAddress=info@wolfssl.com
 subject: /C=US/ST=Montana/L=Bozeman/O=wolfSSL/OU=Support/CN=www.wolfssl.com/emailAddress=info@wolfssl.com
 serial number:01 
SSL version is TLSv1.3
SSL cipher suite is TLS_AES_128_GCM_SHA256
SSL curve name is SECP256R1
Session timeout set to 500 seconds
Client Random : C10258AEC4862BD98BC6E3DEFB59A1BBBC28FA064FA571515A367DEE4FC61DBE
ERROR: Unable to print out session
Hello, this is the wolfSSL C# wrapper

Using the C# wrapper from wolfSSL provides access to FIPS certified code, DTLS, TLS 1.3, and many crypto performance improvements such as AES-NI and ARM hardware accelerations. For questions or assistance with using wolfSSL contact facts@wolfssl.com.

Secure boot and remote updates are becoming a mandatory requirement in the market of IoT connected and secured embedded systems.

wolfSSL offers multiple solutions to update your remote embedded systems connected to the Internet. The core component that authenticates the firmware and regulates the installation of a new version is wolfBoot, the secure bootloader for all 32-bit microcontrollers.

wolfBoot follows the IETF SUIT group recommendations to validate the authenticity and the integrity of any firmware, before allowing it to run on the target. To do so, wolfBoot uses public key based authentication mechanisms provided by wolfCrypt.

In this short tutorial, we have developed a TLS 1.3 web server that can receive authenticated updates and interact with the bootloader to begin the installation once the received firmware is successfully verified and authenticated. wolfBoot will only allow genuine firmware images, generated by the device’s owner, to be installed and run on the target. The updates are signed with the owner’s private key, and can be deployed on the target from a web interface (or using a curl one-liner!).

What are the Key Differences Between wolfBoot and the Others?

wolfBoot is independent of any silicon vendor, IP designer or system vendor’s approach to the problem of secure boot and secure firmware updates. As such we support heterogeneity in keystores, like TPM 2.0, PKCS#11, STSafe, CAAM, ATECC608A, ST33, etc. In terms of hardware encryption, we support a wide variety of hardware encryption drivers such that your firmware update and re-boot will be performant. Unlike our gaggle of competitors, we also support multiple traditional, RTOS, and bare metal environments. Our heterogeneity also extends to a variety of transport mechanisms, including, SSH, cURL, TLS 1.3, HTTPS, all with a variety of TCP/IP options. Need certifications like FIPS 140-2, DO-178, MISRA or ASPICE? No problem, we do that too!

In short, we can support you in your real world application! If you have questions, then please contact us at facts@wolfssl.com.

The Base System

Our system of choice for this example is the NXP Kinetis K64 freedom board. The hardware manufacturer provides drivers and board support software, which is compiled within the running application or OS. The simplest application does not contain any operating system, and executes all the tasks in a single-threaded main loop. This approach is often referred to as ‘bare metal’, and is simple enough to implement for most embedded systems that are dedicated to a single specific task, or where the entire functionality of the device can be easily developed within a single, global state machine.

A different approach consists in integrating a real-time operating system (RTOS). FreeRTOS is one of the most popular choices for multitasking embedded systems. Our base system in this scenario runs FreeRTOS, and uses a TCP/IP stack to provide network access to its threads. FreeRTOS supports several TCP/IP stacks. We decided to use picoTCP in this case, but any embedded TCP/IP implementation would work as well.

Securing the Connections

By default, all the socket connectivity in our system will not be encrypted or secured in any way. Luckily, wolfSSL is a SSL/TLS implementation that is capable of running in small, microcontroller based systems and providing the latest and greatest security mechanisms that are recommended by international standards. wolfSSL is designed to easily be integrated with any combination of RTOS and TCP/IP stacks out there, and it provides secure socket communication using the same level of security as the rest of the IT infrastructure while being generally smaller in size and faster than all its competitors. All threads in the system are able to create secure sockets to communicate with the remote endpoint. In this case we create a simple embedded HTTPS server, only allowing TLS 1.3 connections, which is running in a thread on the target. The only purpose of our demo server is to accept a transfer request, via a HTTP POST, to upload a new version of the running firmware.

The picture below shows the architectural components of the running application.

Figure 1: Architecture of secure IoT multithreading system

Secure Bootloader

Integrating wolfBoot into an existing system is easy. First of all, we create a configuration for the target device. The configuration can be generated step-by-step by running

make config

from the wolfBoot directory. The configuration also contains the information needed by the bootloader to partition the internal flash in order to accommodate two firmware images at the same time in the FLASH memory. In our scenario, we opt for the following geometry:

• A 40KB partition for wolfBoot. wolfBoot itself will be about 26KB in size, but we allow some extra space in case we want to change the public key algorithm, or if we decide to enable debugging symbols in wolfBoot to check what it is doing at boot. Adding debugging symbols will result in a larger wolfBoot image.
• Two partitions of the same size (499712 bytes). These are the partitions used to store the current firmware and the update image received through a secure connection later, which is the candidate for a new installation if the bootloader allows that.
• One single-sector (4KB) swap partition, used by wolfBoot when replacing the current firmware with an updated version, to make all the swapping operations fail-safe, and to guarantee that a copy of the old firmware is kept in the second partition after an update. This mechanism provides a reliable way to step back after a failed boot into a buggy firmware (although verified and genuine).

The setup above corresponds to the following values in wolfBoot configuration:

WOLFBOOT_PARTITION_SIZE?=0x7A000
WOLFBOOT_SECTOR_SIZE?=0x1000
WOLFBOOT_PARTITION_BOOT_ADDRESS?=0xA000
WOLFBOOT_PARTITION_UPDATE_ADDRESS?=0x84000
WOLFBOOT_PARTITION_SWAP_ADDRESS?=0xff000

Which in turn reflects the flash geometry in the figure below:

Figure 2: FLASH memory geometry chosen for this example

To sign the partition, we could use DSA or ECDSA algorithms provided by wolfCrypt. In this case, we opt for ECDSA with ECC256. A manifest header is attached at the beginning of each image: it contains the signature, the version number and other important information about the original firmware. Because of the manifest header, the actual entry point of the application has a fixed offset from the start of the BOOT partition. When using ECC256, this offset is 256 Bytes, so the actual starting point for the application code will be at address 0x0A100.

Because the code of the application is not position-independent, the linker script (.ld) must be adjusted so all the symbols addresses are relative to its new entry point. The MEMORY section in our original linker script contained the following line:

FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 1M

Which we replace with:

FLASH (rx) : ORIGIN = 0x0000A100, LENGTH = 0x7A000

In order to accommodate the bootloader at the beginning of the FLASH.

Sign and Install the Initial Firmware

In the example code provided, all the operations to create the initial image are automated, and executed by simply running make. However, all the steps are explained here to understand what is going on under the hood.

When the bootloader is compiled for the first time, the key pair is generated. The public key can be safely included in the wolfboot image (wolfboot.bin), while the corresponding private key (ecc256.der in our case) must be safely stored and never distributed. The private key is very important, as it is used to sign the firmware image that we are about to upload to the target, and all the future updates that we shall want to upload in the future via the device HTTPS interface, simply using our web browser. When the application is compiled and linked via our modified linker script, we sign it and assign a version number. This is accomplished using the python script sign.py, included in wolfBoot:

sign.py --ecc256 image.bin ../wolfBoot/ecc256.der 1

which will create a new image image_v1_signed.bin containing the manifest header for the verification required to run on the target.

The two images wolfboot.bin and image_v1_signed.bin are then combined into the final image factory.bin, taking into account the partitions offset. If the image has been created correctly and uploaded to the device, the system will boot into wolfboot, which takes a few milliseconds to validate the image.

HTTPS-based Firmware Updates

One FreeRTOS thread is responsible for responding to HTTPS requests. In the example code, the system responds on the Ethernet interface to IP address 192.168.178.211 on port 443. A web browser that supports TLS 1.3 can access the web interface at that address. The example code that manages the HTTPS requests from the client is very simple: it responds to GET requests with a form page, where a new signed firmware update can be uploaded, and to POST request by storing the firmware in the UPDATE partition and initiate the shutdown.

When we create a new version of the software, we can simply sign the new image using the sign.py script, and increase the version number in the command invocation:

sign.py --ecc256 image.bin ../wolfBoot/ecc256.der 2

The new application image can be simply uploaded from a web browser the embedded HTTPS on the board.

When the transfer is complete, the device informs the bootloader that an update is available, and reboots to complete the installation of the new version. The page should reload automatically after about 30 seconds, to show that the updated firmware has been authenticated and it is now running.

Source Code

The source code for this demo is available at:

https://github.com/wolfSSL/wolfBoot-examples/tree/master/freeRTOS-Freescale-K64F-https-TLS1.3

The system analyzed in this tutorial represents an example of just one of the many possibilities of integration of wolfSSL solutions for securing the boot process of embedded micro controllers. Different products (wolfMQTT, wolfSSH) may be combined with the secure boot mechanism provided with wolfBoot to secure the entire firmware update process.

Do not hesitate to contact us at facts@wolfssl.com if you want to learn more, we can help you to integrate secure boot and secure remote firmware updates in your IoT Device.

The embedded TLS/SSL library wolfSSL has a C# wrapper, making it easy to incorporate into C# projects. Recently we have made some updates and expansions to what was currently supported by the wrapper. Including adding in TLS 1.3 API, wrapping of the set verify functions to support choosing to verify the peer or not, examples for multithreaded and client connections, and some refactoring to internal code. The wrapper currently supports .NET framework and .NET core. Some of the benefits of using the wolfSSL C# wrapper are the ability to use FIPS certified code, access to superior support with integration and technical questions, and many performance optimizations. The C# wrapper is constantly being expanded and maintained, if there is a feature that you would like to see added, contact facts@wolfssl.com.

wolfSSL is excited to announce wolfBoot support for Aarch64 platforms with out-of-the box examples for Xilinx ZynqMP and Raspberry Pi 3+.

On the Xilinx Zynq UltraScale+ MPSoC wolfBoot can replace U-Boot to provide enhanced support for feature such as:

• Boot failure detection and use of alternate secondary image.
• Update swapping of partitions.
• Image integrity checking SHA256 or SHA3-384.
• Validation of the signature using ECC P256, ED25519 or RSA (2048-bit or 3072-bit).
• Root of trust options:
  • Key embedded in wolfBoot image partition
  • Key from TPM 2.0 module using wolfTPM (ST33 / SLB95670 / ATTPM20)
  • Key from secure elements such as ST-SAFEA100 and ATECC608A

New Features:

• Added Aarch64 boot/startup support
• Added configuration templates for Raspberry Pi 3 and Xilinx ZynqMP UltraScale+
• Added Xilinx Zynq QSPI bare-metal Driver
• Added NO_XIP option for full ext_flash_* API on all partitions
• Added Xilinx SDK Project Template
• Added support for DTS image partitions
• Added Aarch64 GICv2 initialization code
• Added wolfBoot signing tool in Native C (tools/keytools/sign.c) (and Visual Studio project)
• Added libwolfboot functions:
• int wolfBoot_fallback_is_possible(void);
• int wolfBoot_dualboot_candidate(void);
• Performance improvement to only hash application firmware image once

wolfBoot: https://github.com/wolfSSL/wolfboot/

• Secure element and hardware encryption agnostic
• Support for all operating systems and bare metal configurations
• 24×7 support available

Pull Requests:

• wolfBoot Aarch64 support (Xilinx Zynq and Raspberry Pi)
• Fixes for Zynqmp with BL31 and C signing tool padding

Author: Daniel Stenberg (cross posted from daniel.haxx.se)

This is not a command line option of the week post, but I feel a need to tell you a little about our brand new addition!

–write-out [format]

This option takes a format string in which there are a number of different “variables” available that let’s a user output information from the previous transfer. For example, you can get the HTTP response code from a transfer like this:

curl -w 'code: %{response_code}'
https://example.org >/dev/null

There are currently 34 different such variables listed and described in the man page. The most recently added one is for JSON output and it works like this:

%{json}

It is a single variable that outputs a full json object. You would for example invoke it like this when you get data from example.com:

curl --write-out '%{json}' https://example.com -o saved

That command line will spew some 800 bytes to the terminal and it won’t be very human readable. You will rather take care of that output with some kind of script/program, or if you want an eye pleasing version you can pipe it into jq and then it can look like this:

{
    "url_effective": "https://example.com/",
    "http_code": 200,
    "response_code": 200,
    "http_connect": 0,
    "time_total": 0.44054,
    "time_namelookup": 0.001067,
    "time_connect": 0.11162,
    "time_appconnect": 0.336415,
    "time_pretransfer": 0.336568,
    "time_starttransfer": 0.440361,
    "size_header": 347,
    "size_request": 77,
    "size_download": 1256,
    "size_upload": 0,
    "speed_download": 0.002854,
    "speed_upload": 0,
    "content_type": "text/html; charset=UTF-8",
    "num_connects": 1,
    "time_redirect": 0,
    "num_redirects": 0,
    "ssl_verify_result": 0,
    "proxy_ssl_verify_result": 0,
    "filename_effective": "saved",
    "remote_ip": "93.184.216.34",
    "remote_port": 443,
    "local_ip": "192.168.0.1",
    "local_port": 44832,
    "http_version": "2",
    "scheme": "HTTPS",
    "curl_version": "libcurl/7.69.2 GnuTLS/3.6.12 zlib/1.2.11 brotli/1.0.7 c-ares/1.15.0 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) nghttp2/1.40.0 librtmp/2.3"
}

The JSON object

It always outputs the entire object and the object may of course differ over time, as I expect that we might add more fields into it in the future.

The names are the same as the write-out variables, so you can read the –write-out section in the man page to learn more.

Ships?

The feature landed in this commit. This new functionality will debut in the next pending release, likely to be called 7.70.0, scheduled to happen on April 29, 2020.

Credits

This is the result of fine coding work by Mathias Gumz.

wolfSSL now provides support for complete RTCA DO-178C level A certification! wolfSSL will offer DO-178 wolfCrypt as a commercial off -the-shelf (COTS) solution for connected avionics applications. Adherence to DO-178C level A will be supported through the first wolfCrypt COTS DO-178C certification kit release that includes traceable artifacts for the following encryption algorithms:

• SHA-256 for message digest
• AES for encryption and decryption
• RSA to sign and verify a message.
• Chacha20_poly1305 for authenticated encryption and decryption.

The primary goal of this initial release is to provide the proper cryptographic underpinnings for secure boot and secure firmware update in commercial and military avionics. wolfSSL brings trusted, military-grade security to connected commercial and military aircraft. Avionics developers now have a flexible, compact, economical, high-performance COTS solution for quickly delivering FIPS 140-2 validated crypto algorithms can be used in DO-178 mode for combined FIPS 140-2/DO-178 consumption. The wolfCrypt cryptography library FIPS 140-2 validation certificates can be applied to DO-178 uses. 

Optimization Support

We understand that securely rebooting avionic systems has rigorous performance requirements. As such, we’re here to help with cryptographic performance optimizations through our services organization. 

To download and view the most recent version of wolfSSL, the wolfSSL GitHub repository can be cloned from here: https://github.com/wolfssl/wolfssl.git, and the most recent stable release can be downloaded from the wolfSSL download page here: https://www.wolfssl.com/download/.

wolfSSL DO-178 product page: https://www.wolfssl.com/wolfssl-support-178-dal/.

For more information, please contact facts@wolfssl.com.

wolfSSL FIPS Ready

Along with the recent release of wolfSSL v4.1.0, wolfSSL has updated its support for the wolfCrypt FIPS Ready version of the wolfSSL library. wolfCrypt FIPS Ready is our FIPS enabled cryptography layer included in the wolfSSL source tree that can be enabled and built. To elaborate on what FIPS Ready really means: you do not get a FIPS certificate and you are not FIPS approved. FIPS Ready means that you have included the FIPS code into your build and that you are operating according to the FIPS enforced best practices of default entry point, and Power On Self Test (POST).

FIPS Ready with curl

(modified from Daniel Stenberg) 

The integration of wolfSSL and curl means that the curl library can also be built using the wolfCrypt FIPS ready library. The following outlines the steps for building curl with FIPS Ready:

1. Download wolfSSL fips ready

2. Unzip the source code somewhere suitable:

$ cd $HOME/src
$ unzip wolfssl-4.1.0-gplv3-fips-ready.zip
$ cd wolfssl-4.1.0-gplv3-fips-ready

3. Build the fips-ready wolfSSL and install it somewhere suitable:

$ ./configure --prefix=$HOME/wolfssl-fips --enable-harden --enable-all
$ make -sj
$ make install

4. Download curl, the normal curl package.

5. Unzip the source code somewhere suitable:

$ cd $HOME/src
$ unzip curl-7.66.0.zip
$ cd curl-7.66.0

6. Build curl with the just recently built and installed FIPS ready wolfSSL version:

$ LD_LIBRARY_PATH=$HOME/wolfssl-fips/lib ./configure --with-wolfssl=$HOME/wolfssl-fips --without-ssl
$ make -sj

7. Now, verify that your new build matches your expectations by:

$ ./src/curl -V

It should show that it uses wolfSSL and that all the protocols and features you want are enabled and present. If not, iterate until it does!

wolfSSL FIPS ready is open source and dual-licensed. More information about building FIPS ready can be found in the FIPS Ready user guide.
More information about wolfSSL and curl can be found on the curl product page.
Details on wolfSSL support for curl is also located on the support page.

For more information regarding wolfSSL, wolfCrypt, cURL, support packages, or any additional questions, please contact facts@wolfssl.com.

The wolfSSL embedded SSL/TLS library provides support for various open source projects, including Nginx. For those who are unfamiliar, Nginx is a high-performance, high-concurrency web server. Like wolfSSL, it is also compact, fast, and highly scalable. Additionally, wolfSSL also provides support for TLS 1.3 and features such as OCSP, so Nginx servers can be configured with the latest and most secure protocols.

Nginx and wolfSSL make a likely pairing because they are both lean, compact, fast, and scale well under high volumes of connections. wolfSSL + Nginx is available in a public GitHub repository.  The configure option --enable-nginx will compile the wolfSSL libraries with Nginx support.

wolfSSL also provides FIPS and FIPS ready versions of the wolfCrypt library, meaning Nginx can be built FIPS compliant. More information on wolfCrypt FIPS can be found on the wolfCrypt FIPS FAQ page.

For more information on wolfSSL + Nginx, TLS 1.3, OCSP, FIPS, or for any additional questions, contact facts@wolfssl.com.

The wolfMQTT client library has a Microsoft Azure IoT Hub example that demonstrates securely connecting over TLS provided by the wolfSSL embedded SSL/TLS library.

We setup a wolfMQTT IoT Hub on the Azure server for testing. We added a device called `demoDevice`, which you can connect and publish to. The example demonstrates the creation of a SasToken, which is used as the password for the MQTT connect packet. It also shows the topic names for publishing events and listening to `devicebound` messages.

Everyone deserves to have their IoT data secure, and wolfSSL provides the best libraries to accomplish that! Secure-IoT-Love from the wolfSSL team!

You can download the latest release here: https://www.wolfssl.com/download/

Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT

Don’t forget to add a star while you’re there!