Secure Boot and TLS 1.3 Firmware Update with FreeRTOS and wolfSSL on NXP “Freedom Board” K64

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.

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

strongSwan + wolfSSL + FIPS!

As some may be aware, wolfSSL added support for strongSwan in April of 2019. The upstream commit can be reviewed here: https://github.com/strongswan/strongswan/pull/133

Users can test the latest development master of wolfSSL with the latest version of strongSwan using the following setup:

wolfSSL Build and Installation Steps

$ git clone https://github.com/wolfSSL/wolfssl.git

$ cd wolfssl
$ ./autogen.sh

$ ./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA"

$ make
$ make check
$ sudo make install

strongSwan Build and Installation Steps

# if the following packages are not already installed:
$ sudo apt-get install flex bison byacc libsoup2.4-dev gperf

$ git clone https://github.com/strongswan/strongswan.git
$ cd strongswan
$ ./autogen.sh

# if packages are missing autogen.sh must be re-run

$ ./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem
$ make
$ make check
$ sudo make install

wolfSSL has had interest in enabling FIPS 140-2/140-3 support with strongSwan so our engineers verified everything is working with the wolfCrypt FIPS 140-2 validated Module!

The steps wolfSSL used for testing are as follows:

Testing was done using the wolfSSL commercial FIPS release v4.7.0 which internally uses the wolfCrypt v4.0.0 FIPS 140-2 validated Crypto Module. It was located in the /home/user-name/Downloads directory on the target test system, Linux 4.15 Ubuntu 18.04 LTS running on Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz.

  1. wolfSSL was configured and installed with these settings:
./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA -DFP_MAX_BITS=8192" --enable-ed25519 --enable-curve25519 --enable-fips=v2 --enable-intelasm --prefix=$(pwd)/../fips-install-dir
 make
 make install
  1. A custom install location was used which equated to /home/user-name/Downloads/fips-install-dir and the configuration for strongSwan accounted for this.
  2. strongSwan was cloned to /home/user-name/Downloads with “git clone https://github.com/strongswan/strongswan.git
  3. StongSwan was configured and installed with these settings:
./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem --prefix=$(pwd)/../strongswan-install-dir wolfssl_CFLAGS="-I$(pwd)/../fips-install-dir/include" wolfssl_LIBS="-L$(pwd)/../fips-install-dir/lib -lwolfssl"
 make
 make install
 make check
  1. In the make check stage of the test, it was observed that 1 test was failing.
 Passed 34 of 35 'libstrongswan' suites
 FAIL: libstrongswan_tests
 ==================
 1 of 1 test failed
 ==================
  1. Reviewing the logs it was apparent one of the RSA tests was failing.
  2. Upon further debugging it turned out the failure was a test in strongSwan that was attempting to create an RSA key size of 1536-bits.
Running case 'generate':
 DEBUG: key_sizes[_i] set to 1024
 + PASS
 DEBUG: key_sizes[_i] set to 1536
 - FAIL
 DEBUG: key_sizes[_i] set to 2048
 + PASS
 DEBUG: key_sizes[_i] set to 3072
 + PASS
 DEBUG: key_sizes[_i] set to 4096
 + PASS

wolfSSL has a function RsaSizeCheck() which in FIPS mode will specifically reject any non FIPS RSA key sizes so this failure was not only expected, but it is a good thing for those wanting to use strongSwan in FIPS mode and ensure only FIPS-validated RSA key sizes will be supported!

wolfSSL is pleased that with the latest release of wolfSSL v4.7.0 and the wolfCrypt FIPS 140-2 module validated on FIPS certificate 3389, strongSwan support is working splendidly and wolfSSL engineers will be making efforts to ensure continued support into the future!

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 and MIKEY-SAKKE

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.

FIPS certificate #2425 is being added to NIST sunset list: wolfSSL customers can achieve effortless transition to FIPS cert #3389

FIPS 140-2 requires the use of validated cryptography in the security systems implemented by federal agencies to protect sensitive information. The wolfCrypt Module is a comprehensive suite of FIPS Approved algorithms. All key sizes and modes have been implemented to allow flexibility and efficiency.

The National Institute of Standards and Technology (NIST) is sending FIPS cert #2425 into sunset June 2021. For customers who will be impacted, the wolfCrypt Cryptographic Module maintains its #3389 certificate and can be used in conjunction with the wolfSSL embedded SSL/TLS library for full TLS 1.3 client and server support. Upgrade your FIPS cert with wolfSSL to stay afloat and benefit from: 

  • Algorithm support for TLS 1.3!
  • New algorithms such as AES (CBC, GCM, CTR, ECB), CVL, Hash DRBG, DSA, DHE, ECDSA (key generation, sign, verify), HMAC, RSA (key generation, sign, verify), SHA-3, SHA-2, SHA-1, and Triple-DES
  • Hardware encryption support for NXP’s Cryptographic Assistance and Assurance Module (CAAM), NXP Memory-Mapped Cryptographic Acceleration Unit (mmCAU), Intel’s AES-NI, and more
  • Support for secure elements and TPM’s
  • Interoperability with wolfBoot, wolfSSH, and wolfTPM
  • Integration support for third party libraries such as strongswan, nginx, python and more

Contact us to upgrade to FIPS cert #3389 at fips@wolfssl.com

Additional Resources 

Learn more about wolfSSL support for FIPS cert #3389: https://www.wolfssl.com/wolfcrypt-fips-certificate-3389-3/ 

For a list of supported Operating Environments for wolfCrypt FIPS, check our FIPS page: https://www.wolfssl.com/license/fips/ 

Our FIPS Story

wolfSSL is currently the leader in embedded FIPS certificates. We have a long history in FIPS starting with wolfCrypt FIPS 140-2 Level 1 Certificate #2425 as well as wolfCrypt v4 FIPS 140-2 Level 1 Certificate #3389. wolfSSL partners with FIPS experts KeyPair to bring you FIPS consulting services, and high assurance along each step of your FIPS certification process. Additionally, wolfSSL will be the first implementation of FIPS 140-3.

wolfSSL also provides support for a wolfCrypt FIPS Ready version of the library! wolfCrypt FIPS Ready is our FIPS enabled cryptography layer code included in the wolfSSL source tree that you can enable and build. You do not get a FIPS certificate, you are not FIPS approved, but you will be FIPS Ready. 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.

wolfCrypt FIPS Ready can be downloaded from the wolfSSL download page located here: https://www.wolfssl.com/download/. More information on getting set up with wolfCrypt FIPS Ready can be found in our FIPS Ready User guide here: https://www.wolfssl.com/docs/fips-ready-user-guide/

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

Secure wolfMQTT SN with wolfSSL DTLS

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!

MQTT Embeddable Broker

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.

wolfSSL Support for DO-178 DAL A

wolfSSL is adding 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.
  • ECC to sign, verify and share secrets.
  • HMAC  for keyed-hashing for message authentication.

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 enhanced, secure communications that can be readily certified to DO-178. In addition, any of the 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 has been FIPS 140-2 validated (Certificate’s #2425 and #3389).

If you have questions on any of the above, please contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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. 

Release Plan

  • Basic crypto for secure boot and secure firmware updates – Available Now!
  • wolfBoot Secure Boot – Q1, 2022
  • wolfSSL – Q2, 2022
  • wolfDTLS – Q2, 2022

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/.

For more information, please visit the wolfSSL DO-178 product page: https://www.wolfssl.com/wolfssl-support-178-dal/.

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

ACVP and FIPS 140-3

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.

wolfSSL Examples Repository

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.

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

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

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

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.

wolfTPM brings TPM Physical Presence and IO Support to Embedded Systems

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.

Posts navigation

1 2 3 79 80 81 82 83 84 85 196 197 198