RECENT BLOG NEWS

The summer release of wolfSSL, v4.5.0, is now available! This release has many new features, optimizations, and bug fixes. Some of the new features we added to the wolfSSL embedded SSL/TLS library include:

• TLS v1.3 is now enabled by default
• Building FIPS 140-2 code and test on Solaris
• Secure renegotiation with DTLS 1.2
• Additional OpenSSL compatibility layer functions added
• Added certificate parsing and inspection to C# wrapper layer
• Added Xilinx Vitis 2019.2 example and README updates
• Update RSA calls for hardware acceleration with Xilsecurew
• Cypress PSoC6 wolfCrypt driver added
• Added STM32CubeIDE support
• TSIP v1.09 for target board GR-ROSE support added
• Added support for the Renesas RX72N “X72N Envision Kit” evaluation board

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

wolfBoot is wolfSSL’s universal secure bootloader. It was initially designed to bring secure boot technology to small 32-bit microcontrollers following the guidelines of the IETF SUIT group. But nowadays, it’s used on a large number of heterogeneous devices, from IoT connected systems with limited resources, to faster, more powerful 64-bit embedded Linux systems. Examples of systems which wolfBoot has been successfully used with include STM32, SiFive HiFive, LPC5406, Cortex-A54, ARMv8, Xilinx Zynq UltraScale+, NXP Kinetis, TI CC26x2, and Atmel SAMR21.

One of the most evident strengths of our implementation is the flexibility to integrate secure boot and remote updates with any Operating System. This aspect, combined with the drivers and the support available for large numbers of target platforms in continuous expansion, gives us the possibility to bring secure boot technologies and reliable firmware updates to various embedded projects.

Secure Firmware Updates

One of the aspects that allows wolfBoot to interoperate with the existing infrastructure in every IoT project is given by its unique “transport-agnostic and highly reliable remote firmware update mechanism”.

wolfBoot in fact doesn’t rely on specific protocols or data link interfaces used to transfer the updated images from the infrastructure to the firmware consuming devices. We know that every project uses different communication links and protocol families to reach the device fleet from the back-end server responsible to distribute the firmware updates. The communication between the infrastructure and the device itself is usually already implemented in the software running on the system, and used to exchange assets and data over some project-specific transport layer.

We always recommend using secure socket communication whenever possible, and rely on the existing standards such as MQTT-over-TLS, SSH or HTTPS and other REST services, offered by the major cloud service providers (Microsoft Azure, AWS, Google Cloud, etc.). wolfSSL provides a range of libraries, implementing the latest standards available, to access these services from embedded systems.

In smaller systems, there is rarely the possibility to replicate the software stack needed to
realize data transfers in both the application and the bootloader contexts. For this reason, transferring the firmware image to the target device is a task that is left as responsibility for the application itself. The only requirement for the application is to use any existing communication channel to transfer the signed firmware update image from the back-end to the device, and store it to a local non-volatile memory at a predefined address. Upon the next reboot,
wolfBoot will take care of validating, authenticating and installing the update if all the necessary checks are successful.

How to implement remote transport-agnostic updates using wolfBoot

Alongside with the bootloader itself, wolfBoot provides tools and mechanisms to integrate with the process of uploading and distributing signed firmware images.

The first step consists in creating a valid firmware image, containing all the elements necessary for wolfBoot to identify, validate and authenticate the update. The most important tool is a host application, “sign”, provided in two versions (python and portable C) in the wolfBoot distribution. This tool is used to compose the manifest header and attach it to the actual firmware. wolfBoot uses the information contained in this header to verify the integrity and the authenticity of the firmware before starting the installation of the update on the device.

In a typical scenario, the “sign” tool needs a version number to associate to the current release, and a file containing the private key, which can be created by the owner of the firmware, or derived from more complex operations when a specific provisioning system is used.

Given a firmware update in its original binary format, e.g. “firmware.bin”, a version number (say “2”) and a previously generated private key (e.g. ecc256.der), the signed image can be obtained by running:

sign.py --ecc256 --sha256 firmware.bin ecc256.der 2

The resulting image `firmware_v2_signed.bin` can be transferred to the target, using any protocol. We always recommend to transfer any sensitive data, such as firmware updates, through a secure connection, by using wolfSSL, wolfSSH, curl, or wolfMQTT. However, any custom transfer mechanism can be adopted to distribute the firmware updates through the application.

libwolfBoot: Interact with the bootloader from the application

LibwolfBoot is a library provided within the wolfBoot package which is used to interact with the bootloader, in particular to notify wolfBoot that a new firmware update has been stored on the designed NVM partition, and it is ready to be checked by the bootloader at next reboot, and to confirm that the current image is running properly.

While the firmware is being received on the target, it must be stored into the UPDATE partition. This can be done using existing drivers and support in the application or, alternatively, by using the same driver that wolfBoot uses to access non-volatile memory supports, which is made available through libwolfboot.

For an overview of the libwolfboot API, check out the documentation here.

Updating the process and automatic backup of last known working image

Once the image is stored at the designated position in the NVM of the target, the application calls the `wolfboot_update()` function to trigger the verification and the installation upon the next reboot. If the verification succeeds, a swap operation is initiated, which will replace the current running firmware with the newly received update and, at the same time, “will store a backup copy of the old firmware in the update partition”.

The swap operations implemented in wolfBoot are highly reliable and fail-safe. If the power is interrupted in the middle of the swap operation, wolfBoot will resume the swap from the last position. That is the reason behind the need of a SWAP partition in this process: two copies of the same page are always present during the swap, and the progress is tracked through flags indicating the last-known successful operation when moving the content across the two partitions.

Every time that the application starts properly, it should communicate to the bootloader that the execution of the firmware is successful. This is done by calling the `wolfBoot_success()` function after the initialization of the services in the application. If it’s the first time that this function is called for that specific version, the library will set a flag in a special position on the internal flash (only once). This way the bootloader knows that the update procedure is complete and that specific version is valid. If the `wolfBoot_success` function is never reached for any reasons, the bootloader will automatically perform a roll-back, restoring the backup of the previously working image that is stored in the NVM during the installation process.

If the new version is not confirmed by the application itself, or whenever the image installed is damaged or corrupt, the bootloader will restore the state of the system before the most recent
update.

Optional firmware image encryption on external FLASH

wolfBoot offers the possibility to encrypt the content of the entire UPDATE partition, by using a pre-shared symmetric key which can be temporarily stored in a safer non-volatile memory area.
SWAP partition is also temporarily encrypted using the same key, so a dump of the external flash won’t reveal any content of the firmware update packages to a potential attacker.

This feature requires to encrypt the firmware image by passing an extra option to the “sign” tool, specifying a temporary symmetric key used for encrypting the update bundle at the source.

On the device side, an additional function is available in the libwolfBoot API, `wolfBoot_set_encrypt_key()`, which must be used to set the temporary key used by wolfBoot to decrypt the content of the UPDATE partition stored on an external NVM.

Detailed information on this feature can be found in the wolfBoot documentation here.

Conclusion

Reliable and secure remote firmware updates are a requirement for modern embedded systems that must take into account vulnerability management and use the correct procedures to keep the target systems updated.

The highly-reliable, transport-agnostic firmware update mechanism implemented using wolfBoot is portable across different operating systems and target platforms from different vendors. The procedure described in this article is just one of the possibilities available to implement a custom secure boot and firmware update mechanism based on wolfBoot. At wolfSSL we are constantly working to improve our solutions and we can provide customizations and adaptations to a wide range of more complex scenarios, including specific NVM configurations, hardware crypto accelerators, secure trust anchors and key provisioning mechanisms that involve third party trusted providers.

We understand how important security is in your IoT project, and we are the only company to offer 24×7 support on secure boot solutions for remote firmware updates.

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 has support for several of the STM32 microcontrollers and for the hardware-based cryptography and random number generator offered by them as well.

Our most recent update is that wolfSSL now offers support for STM32Cube Expansion Package enhanced for STM32 toolset, adding on to previous support for the STM32 Standard Peripheral Library as well as the STM32Cube HAL (Hardware Abstraction Layer). wolfSSL also maintains and makes available this STM32Cube Expansion Package for wolfSSL to make it easy for users to pull wolfSSL directly into STM32CubeMX and STM32CubeIDE projects. To check out specific support for ST microcontrollers read below.

Don’t forget to check out a replay of our STM32CubeMXv6 Partner Webinar hosted by engineer David Garske on October 1st!

wolfSSL STMicroelectronics Support

The wolfSSL and wolfCrypt library support the following STMicroelectronics microcontrollers:

• STM32F-Series: STM32F1, STM32F2, STM32F4, STM32F7
• STM32L-Series: STM32L4, STM32L5
• STM32H-Series: STM32H7
• STM32WB-Series: STM32WB55
• STM32G-Series: STM32G0

For STM32 microcontrollers that have hardware crypto acceleration we fully support it.

• RNG Hardware:
  • All of the STM32’s support hardware based RNG.
• PKA Hardware Acceleration for ECC:
  • STM32WB55 and STM32L562.
• AES ECB/CBC/GCM:
  • STM32F437, STM32H753, STM32F777, STM32H753, STM32L4A6, STM32WB55
• SHA256:
  • STM32F437, STM32F777, STM32H753, STM32L4A6, STM32L552

Downloading STM32Cube Expansion Bundle

The STM32CubeIDE and STM32CubeMX tools enable quick adoption of the wolfSSL library using the STM32Cube Expansion bundle, which can be downloaded here:
https://www.wolfssl.com/files/ide/I-CUBE-wolfSSL.pack

To install the package:

1. Run the “STM32CubeMX” tool.
2. Under “Manage software installations” click “INSTALL/REMOVE” button.
3. From Local and choose “I-CUBE-wolfSSL.pack”.

To create a Cube project with wolfSSL:

1. Create or open an STM32Cube Project based on your hardware.
2. Under “Software Packs” choose “Select Components”.
3. Find and check all components for the wolfSSL.wolfSSL packs (wolfSSL / Core, wolfCrypt / Core and wolfCrypt / Test). Close
4. Under the “Software Packs” section click on “wolfSSL.wolfSSL” and configure the basic parameters.
5. For Cortex-M recommend “Math Configuration” -> “Single Precision Cortex-M Math”
6. Generate Code

For more information on the package see:
https://github.com/wolfSSL/wolfssl/tree/master/IDE/STM32Cube

STM32 Benchmarks

A full list of STM32 benchmarks can be found here:
https://github.com/wolfSSL/wolfssl/tree/master/IDE/STM32Cube/STM32_Benchmarks.md

STM32F777 Cortex-M7 at 216 MHz:

STM32L562E Cortex-M33 at 110 MHz

Additional STM32 Benchmarks

A full list of STM32 benchmarks can be found here:
https://github.com/wolfSSL/wolfssl/tree/master/IDE/STM32Cube/STM32_Benchmarks.md

About STMicroelectronics

At ST, we are 46,000 creators and makers of semiconductor technologies mastering the semiconductor supply chain with state-of-the-art manufacturing facilities. An independent device manufacturer, we work with our 100,000 customers and thousands of partners to design and build products, solutions and ecosystems that address their challenges and opportunities, and the need to support a more sustainable world. Our technologies enable smarter mobility, more efficient power and energy management, and the wide-scale deployment of the Internet of Things and 5G technology.

In 2019, the Company’s net revenues were $9.56 billion. Find out more at www.st.com.

References

wolfSSL Product Page
STM32 Product Page
STM32CubeMX

Check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL. 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 working hard with our lab to make wolfCrypt be the first cryptography library to have FIPS 140-3 validation. We are very excited about the changes that are a part of FIPS 140-3. We can fit our FIPS validated library into just about any embedded operating environment.

wolfSSL currently maintains two FIPS 140-2 certificates for the wolfCrypt Cryptographic Module: #2425 and #3389. Certificate #3389 includes algorithm support required for TLS 1.3 and can be used in conjunction with the wolfSSL embedded SSL/TLS library for full TLS 1.3 client and server support. wolfSSL intends to continue to serve our customers by taking wolfCrypt through the FIPS 140-3 validation 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.

FIPS 140-2 requirements for CAVP testing have been deprecated in favor of the cutting edge ACVP test requirements! wolfSSL is currently working on (to our knowledge) the first ever embedded validation that will use the new ACVP test requirements!

References
https://csrc.nist.gov/Projects/Automated-Cryptographic-Validation-Testing
https://github.com/usnistgov/ACVP

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

Now, with the Azure Sphere OS 20.07 release, Microsoft has licensed and exposed a subset of wolfSSL, the first commercial implementation of TLS 1.3, for use on Azure Sphere devices. This strategic pairing allows software developers to create client TLS connections directly using the Azure Sphere SDK. Software developers no longer need to package their own TLS library for this purpose. Utilizing the best-tested, high-performance wolfSSL TLS support in Azure Sphere can save device memory space and programming effort, freeing developers to build new, cutting-edge IoT solutions.

Microsoft Azure Sphere and wolfSSL have been long-time partners, striving for the very best in security. The Azure Sphere OS has long used wolfSSL for TLS connections to Microsoft Azure services. Azure Sphere also uses wolfSSL’s versatile technology to enable secure interactions from developer apps to customer-owned services.

Partnerships with embedded security leaders like wolfSSL play an important role in Azure Sphere’s mission to empower every organization to connect, create, and deploy highly secured IoT devices. The unique Azure Sphere approach to security is based on years of vulnerability research, the findings of which Microsoft published in the seminal paper “Seven Properties of Highly Secure Devices.” These seven properties are the minimum requirement for any connected device to be considered highly secured. Azure Sphere implements all seven properties, providing a robust foundation for IoT devices. This level of consideration is not lost on an engineering team like wolfSSL’s, known for producing the best-tested crypto on the market and consistently supporting the latest developments in TLS protocol, like TLS 1.3.

Azure Sphere can be used with any customer cloud service, not just Microsoft’s own Azure. By providing a highly secured ecosystem, Microsoft and wolfSSL make security features more accessible and easier to use and can extend unmatched security to new frontiers in IoT where security has historically been sparse.

For information on how to use these wolfSSL APIs on Azure Sphere, please reference the Azure Sphere documentation on wolfSSL. We will be publishing a sample to go along with this, available at a later date. Check back here—we will update this post with the link to the sample once it is available.

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 are exited to announce wolfSSL‘s support for the Renesas RX72N Envision Kit with TSIP v1.09. The RX72N MCU is the flagship model of RX series, using a 32-bit RX72N 240 MHz microcontroller. The board just entered the market this spring and wolfSSL can now support secure connections on it via TLS!

If you have an interest in using wolfSSL with this MCU or the RX72N Envision Kit, we encourage you to give it a try with one of our sample applications.

wolfSSL provides TLS source code, sample programs, and project files that make your evaluation quick and easy. Our wolfCrypt benchmark sample application shows the performance of cryptography operations accelerated by the H/W accelerator (TSIP) and allows for an easy comparison to software cryptography performance.

Sample Applications Provided

1. Cryptography test
2. Cryptography benchmark
3. TLS Client
4. TLS Sever
5. Linux server application which can communicate with #3

Board and Environment Support

Board: Renesas RX72N Envision Kit (R5F572NNHxFB)
IDE: Renesas e2Studio v7.8.0
Compiler: CCRX Tool Chain V.3.02.00
TSIP: V.1.09

Benchmarks

Here are the benchmark results gathered during testing, comparing algorithm performance with and without TSIP.

Resources

wolfSSL package including this RX72N Envision Kit support, is available from the wolfssl repository on GitHub:

https://github.com/wolfSSL/wolfssl/archive/master.zip

Unzip the package then refer to “wolfssl-master/IDE/Renesas/e2studio/RX72NEnvisionKit/README” for more details.

The README describes how to build and execute the sample programs.

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.

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.

Are you a user of Deos? If so, you will be happy to know that wolfSSL supports the Deos Safety Critical RTOS for FAA Certifiable Avionics Applications and has added TLS client/server examples to the wolfSSL embedded SSL/TLS library for Deos!

Deos is an embedded RTOS used for safety-critical avionics applications on commercial and military aircraft. Certified to DO-178C DAL A, the time and space partitioned RTOS features deterministic real-time response and employs patented “slack scheduling” to deliver higher CPU utilization. DO-178C DAL A refers to a specification that is required for software to be used in aerospace software systems.

The Deos port in wolfSSL is activated by using the “WOLFSSL_DEOS” macro. For instructions on how to build and run the examples on your projects, please see the “/IDE/ECLIPSE/DEOS/README” file.

wolfSSL provides support for the latest and greatest version of the TLS protocol, TLS 1.3! Using the wolfSSL port with your device running Deos will allow your device to connect to the Internet in one of the most secure ways possible.

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

Resources:

• The most recent version of wolfSSL can be downloaded from our download page, here: https://www.wolfssl.com/download/
• wolfSSL GitHub repository: https://github.com/wolfssl/wolfssl.git
• wolfSSL support for TLS 1.3: https://www.wolfssl.com/docs/tls13/
• Deos RTOS homepage: https://www.ddci.com/category/deos/

Two weeks ago, Apple announced a transition from Intel-based Macs to their very own ‘world-class custom silicon’ chip. This marks a new era for Apple, as they further establish a common architecture throughout their product ecosystem, making it easy for developers to write, update and optimize applications.

Underlying this recent development is Apple’s Universal App Quick Start Program that includes the ‘limited use of a Developer Transition Kit (DTK), a Mac development system based on Apple’s A12Z Bionic System on a Chip (SoC)’ among other services like forums support, beta version of macOS Big Sur and Xcode 12.

So why is this important? 

wolfSSL is a direct partner with ARM, the architecture A12Z Bionic is based upon, and we fully support all the crypto extensions that are built into the new chip. We aim to have the first FIPS certificate for A12Z and will be pushing out benchmarks on the A12Z soon, so stay tuned!

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

Additional Resources:
The most recent version of wolfSSL can be downloaded from our download page, here: https://www.wolfssl.com/download/
wolfSSL GitHub repository: https://github.com/wolfssl/wolfssl.git
Check out the latest addition of the wolfSSL ARM mbed-os Port of the wolfSSL embedded SSL/TLS library!