RECENT BLOG NEWS

Today we have some exciting news! We here at wolfSSL would like to announce that we have achieved a TLS 1.3 connection where the group used for key establishment was KYBER_LEVEL1 and the connection was between an Ubuntu Linux x86_64 machine and an STM32 NUCLEO-F446ZE with an ARM Cortex M4 chip running on bare-metal. We used a generic UART TTL to USB cable.  On the x86_64 side we plugged the cable into the USB port while on the ARM Cortex M4 side we connected to the UART headers. Either side can be the server or the client. 

Some might be wondering how this was achieved as wolfSSL integrates with liboqs for its post-quantum algorithm implementations, but liboqs does not support being built for STM32. The answer is that wolfSSL has a new integration with the OQS team’s sister project, MUPQ team’s pqm4 project. Since the algorithm artifacts interoperate between liboqs and pqm4 and wolfSSL is on both sides, there is full interoperability.  Notably, this should also interoperate with the OQS team’s fork of OpenSSL.

So, does this really matter? In our opinion, yes! A lot of great work has been done showing the impact that post-quantum algorithms will have on The Internet. There are several academic papers and at-scale experiments with some very interesting results that, generally speaking, show that the Internet is ready for post-quantum algorithms. But what about constrained and low-resource devices?  What about IoT? With larger cryptographic artifact sizes and for some operations, more need for processor power, these algorithms have potential to heavily impact constrained and low-resource devices.

Experimentation in these domains has been less forthcoming, likely due to the lack of a TLS stack integrated with post-quantum algorithm implementations for embedded platforms. Now that changes.  Now, you can start experimenting with post-quantum algorithms using TLS 1.3 to understand the impact on your embedded projects.

In the coming weeks, you can look forward to an example STM32CubeIDE project and a recorded webinar about how you can get started with post-quantum key establishment over TLS 1.3 on STM32 devices.

Currently, only KYBER_LEVEL1 is supported. Want other algorithms and variants? Want hybrids? Want to know when the example project and webinar will be released? 

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 shell and file access for embedded systems

Unlike embedded Linux, or rich CPU-based systems, embedded systems running on a microcontroller rarely have support for file systems. Most often these devices run a firmware stored on a flash memory. However, more advanced microcontroller-based systems designed for edge computing offer the possibility to connect non-volatile storage devices, such as SD or MMC cards, non-volatile random-access memories and solid-state drives. In these cases, a bare-metal or RTOS-based system may benefit from a lightweight filesystem implementation, for standard read/write file access and directory management.

wolfSSH offers all the functionality of a SSH server and client in a compact and microcontroller friendly library. It implements SSH protocol v.2 with both password and public key based authentication. The SSH protocol is mostly famous for the secure shell feature on UNIX-like systems, used by administrators to control and automate process execution on remote systems. SSH however provides file transfer support via SCP, and more advanced file system access via SFTP.

wolfSSH implements SCP and SFTP for any embedded system, giving the possibility to customize the actions associated with remote filesystem access operations. A system with no filesystem support can still implement rudimentary operations on hardcoded file paths very easily, by defining use-case specific callbacks. Even without any actual filesystem, it is still possible to respond in a custom way to specific SFTP or SCP commands. A common usage, like the one shown in this FreeRTOS based example,  is using SSH for remote secure firmware updates, uploading a new version of the firmware binary image as a file, e.g. via SCP. The embedded target does not actually have a file system but it receives the content of the remote file and stores it in a flash memory partition. Afterwards the application can delegate the secure bootloader, e.g. wolfBoot, to consider and process the update package for installation.

Customizing file I/O operations on non-POSIX systems can be done by defining WOLFSSH_USER_FILESYSTEM at compile time, and then assigning callbacks to I/O operations. A minimal set of calls for file management may include WFOPEN, WFCLOSE, WFWRITE, WFREAD, WFSEEK; although the full set of POSIX operations for subdirectory handling, file statistics, permission management and more are supported when running wolfSSH with SFTP on POSIX machines.

FatFS support

Using a lightweight FatFS implementation to store data in embedded systems has several advantages. Removable memory supports such as SD or MMC cards can be accessed offline by any PC host if required. On those microcontrollers supporting USB-OTG, internal block devices can appear as USB drives when the device is connected to a USB host.

ChaN’s FatFS (http://elm-chan.org/fsw/ff/00index_e.html) is a popular lightweight Open Source FAT implementation suitable for microcontrollers and distributed along with many BSP provided by hardware manufacturers, often as optional middleware package. FatFS exposes two interfaces: the API to be used by the application to access the filesystem, and the MAI (media access interface) to attach the I/O to any block-based storage system. Many embedded developers use this library even if there is no specific need for FAT format, simply because it is a complete filesystem implementation with a small footprint, provides a friendly, POSIX-inspired, well documented API,  and it is easy to integrate with any physical storage medium.

Since version 1.4.7, wolfSSH offers a fully featured, pre-packaged integration with ChaN’s FatFS. By adding the compile-time option WOLFSSH_FATFS, wolfSSH will automatically map the file and directory callbacks to the corresponding function in the filesystem implementation. This means that there is no additional ‘glue code’ needed to integrate wolfSSH to provide remote secure file access and directory management.

wolfSSH is the easiest way to implement SFTP and SCP on embedded targets. Adding wolfSSH to an existing connected system simply consists in providing send and recv callback functions to communicate over a TCP socket. For SFTP and SCP support a filesystem implementation, real or emulated, is required as well to respond to remote file and directory access requests, and wolfSSH offers a flexible interface to integrate with any filesystem implementation.

On those platforms where FatFS support is already included with the board support package or the real time operating system in use (e.g. ST CubeMX, NXP MCUXpresso), the integration of wolfSSH with the existing filesystem has now been made even easier. Setting up a thread in a RTOS with a SSH daemon providing SFTP access is a matter of a few lines of code, needed to set up SSH certificate, passwords and public keys. The target system will start accepting SSH connections and exchanging files from any compatible SFTP client.

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 excited to tell you about our partner collaboration with STMicroelectronics! This collaboration is a video series about wolfBoot, a secure bootloader and the STM32, a family of 32-bit microcontrollers.

This will be at least a 4 part video series with the third release 

Video 1: wolfBoot for STM32, Part 1: Overview https://www.youtube.com/watch?v=9R4Gl0qrzZ0

• “Overview of the wolfSSL products and the wolfBoot support for STM32 devices. The wolfBoot product features such as secure boot, measured boot, encrypted partitions and root of trust (in the bootloader, TPM or secure element). Comparison of the SBSFU, TFM and wolfBoot options for STM32 micro-controllers. Implementation details for design of wolfBoot and how the partitions are defined.”

Video 2: wolfBoot for STM32, Part 2: Getting Started https://www.youtube.com/watch?v=e5VwYA5kknA

• “How to download wolfBoot, where to find files and documentation. The wolfBoot product features such as secure boot, measured boot, encrypted partitions and root of trust (in the bootloader, TPM or secure element).”

Video 3:wolfBoot for STM32, Part 3: Out of the Box Experience https://youtu.be/VrgooHCoUNk

• “How to configure, build, run, and debug wolfBoot on NUCLEO-G071RB board.”

Video 4: How to expand the wolfBoot HAL support for a new target.

Stay tuned for more information on when the next part of this video series goes live.

Additional Resources

• https://www.st.com/en/embedded-software/wolfboot.html
• https://www.wolfssl.com/products/wolfboot/

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

For technical support, please contact support@wolfssl.com or view our FAQ page.

In the meanwhile, 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.

wolfLCU 0.0.8 is available! wolfCLU is the wolfSSL (Command Line Utility) and is meant to be used for simple key generation, certificate operations, and more. It is being developed to also be an alternative for the commonly used OpenSSL command line utility. There were vast feature enhancements over the last release. Support for several new commands were added in.

• rand
• pkcs12
• s_client
• verify
• rsa
• crl
• ca
• dsaparam
• sha256, sha384, sha512
• dhparam

This release also included some fixes. A running list of changes can be found in the bundled ChangeLog.md. Visit our alternatives download page or https://github.com/wolfssl/wolfclu for downloading the bundle. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Great news, wolfSSL is thinking about adding a Rust wrapper this year! The wolfSSL embedded TLS library is a lightweight, portable, C-language-based SSL/TLS library known for its low footprint, speed, and feature set. Users have been able to take advantage of our library not only in C but also in their Java, C#, Python, and JavaScript projects using the various wrappers we provide. And in 2022, we’re interested in adding Rust to that list.

Similar to C, Rust is a low-level programming language with direct access to hardware and memory, which will make our wolfSSL Rust Binding/Wrapper a great SSL/TLS solution for embedded and IoT development for Rust projects.

Are you interested in a Rust wrapper?

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 ecosystem consists of several software modules and components, each with specific goals and purposes. We make sure all our software products are engineered using the quality standards required by our process.

Each step in the software lifetime is regulated by strict rules and testing criteria (including stringent fuzz based testing) that ensure the detection of defects and regressions in the code very early.

Software engineering process overview

From a software engineering standpoint, the life cycle of the design and development of wolfSSL software components is structured in three steps:

• Identification and analysis of software requirements and specifications
• API-oriented software design
• Software module development

Each step is then verified through a specific set of quality control procedures, including:

• Unit tests and periodic coverage analysis
• API consistency tests
• Integration tests on multiple architectures/compilers and use cases/combinations of compile time configuration options
• Interoperability tests against other implementations
• Formal algorithm and module verifications
• Fuzz testing

In order to improve the safety of the code, and in order to detect potential defects or misbehaviors, additional quality controls are regularly applied to the software modules, in particular tools like static analyzers, dynamic memory diagnostic tools, fuzzers and more, being added all the time.

Distributing the source code under a GPL license and exposing the entire development process publicly on the GitHub platform guarantees that hundreds of users, contributors and people interested in the project are constantly aware about every change in the code, and the conversations generated during code reviews. Corporate security organizations, cybersecurity partners and academic researchers give very valuable contributions by constantly studying new vulnerabilities and carefully exploring the potential attack surfaces that may be harder to identify while writing the code. wolfSSL Inc. takes vulnerability management very seriously and has a precise and detailed checklists to run in case of emergency fix and rapid release.

Due to the constantly changing nature of the specifications, the software design process must be flexible enough to accommodate updates in the algorithm implementation, the usage recommendations and the guidelines to implement secure protocols and mechanisms.

NIST distributes specifications and guidelines through “Special Publications” (SP). Through its collaboration of industry organizations, government agencies and academic institutions the National Cybersecurity Center of Excellence (NCCoE) as part of NIST. Similarly to IETF publications, the approach of NIST consists in releasing frequent updates and amendments to earlier publications, in order to keep the guidelines updated. The process of updating the guidelines within NIST is regulated by the “NIST Cryptographic standards and guidelines development process” (NIST.IR.7977). Cryptographic functions in wolfCrypt follow the latest specifications from NIST regarding algorithms and their implementation process. As explained later, NIST publications and software tools play an important role in the algorithms and modules verification phase.

WolfMQTT is implemented upon the specifications provided by OASIS, initially covering  MQTT version 3.1.1 approved in December 2015. WolfMQTT has since then evolved to support the specifications in OASIS MQTT Version 5.0, approved as the latest MQTT standard in March 2019.

Software requirements and specifications

The guidelines for the implementation of cryptography, secure communication protocols and secure firmware updates mechanisms are described by open standards. These standards are maintained and documented by several organizations. WolfSSL software projects import specification documents from three major organizations, namely:

• IETF, the Internet Engineering Task Force, a large open international community of engineers, in charge of publishing and updating the documentation for the Internet protocols stack, which nowadays also includes secure communication protocols and algorithms used in ciphersuites
• NIST, the United States National Institute of Standards and Technology, providing guidelines for processes, modules and algorithms, recognized globally as best-practices in cryptography 
• OASIS, the Organization for the Advancement of Structured Information Standards, a global nonprofit consortium that works on the development of open standards for the IoT and data exchange

IETF releases new specifications in the form of “Request for Comments” (RFC). These are individually numbered publications which are published after a peer review process, which often requires multiple draft phases. Once a RFC is assigned its unique number, it is never modified again. In order to update a standard track that has been published in a RFC, it is possible to issue a new RFC that may contain amendments, corrections or replacing of existing RFCs that were previously published. Newer RFCs can supersede older ones by making them obsolete or deprecated. RFCs cover the specifications for a large part of wolfSSL communication modules, such as the TLS protocol standard (RFC8446), DTLS (RFC6347), TLS extensions (RFC6066) and several others. The wolfCrypt library follows the recommendations for the implementation of the cryptographic primitives based on the algorithms supported, such as RSA  public-key cryptography (RFC8017), or the ChaCha20/Poly1305 for AEAD (RFC8439) and many others. WolfSSH has been designed and developed upon the specifications of the RFC4250-RFC4254 series, documenting SSH-2 as proposed internet standard. WolfBoot has been initially designed and developed according to the guidelines of the draft-ietf-suit-architecture, which later on became RFC9019.

Software design

Most of the software components developed by wolfSSL are in the form of a structured library, with an API oriented design. Once functions are part of the API they will never change their signature, their purpose or the meaning of their return values. This ensures compatibility across different versions of the library. If a feature is added to an existing functionality, a new API function is created, which accepts different arguments, or extends specific interfaces. The API function calls are formally documented in the module user manual.

One of the most important aspects to keep in mind during the design phase is the correct meaning, propagation and verification of the error codes across the different layers of the API. Each error code has unique and well-defined meanings that are explained in the manual. This facilitates the identification of run-time errors in the application using the library.

Due to the dynamic, changing nature of the specifications around cryptography and secure protocols, the design process must adapt accordingly. New specifications are analyzed and integrated in the existing module architecture, ensuring that this does not break existing features by keeping the existing API function signatures immutable in time.  

Software development and traceability

All software at wolfSSL is developed and maintained following the continuous integration practice, via a centralized git mainline repository. All source code is public and accessible at any time during the development, under a GPL license. 

The life-cycle of software components in the wolfSSL ecosystem is different from the typical open-source development process, and it is designed to comply with modified condition decision coverage (MC/DC) process. WolfSSL owns and maintains the entire code base, which means that there are strict rules in place regarding changes and updates of the mainline. Modifications to the repositories are only allowed by wolfSSL engineers, who also have to comply with a strict peer-review policy before any change is merged into the master branch.

To contribute to wolfSSL repositories, a developer must submit a “pull request” through GitHub. The request is then reviewed by one or more wolfSSL engineers (depending on the size, the impact and the nature of the patch). This often results in requests for alignment with the purposes in the design documents, changes in the code, re-adaptations and improvements before the code is accepted for merging. Only approved contributors are allowed to submit their code to review. Contributors outside the wolfSSL engineering team must be approved beforehand before the code is considered for inclusion.

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

Hardware Security Module (HSM)

A hardware security module (HSM) is a physical computing device that protects digital key management and key exchange, and performs encryption operations for digital signatures, authentication and other cryptographic functions. It can be thought of as a “trusted” network computer for performing cryptographic operations. A HSM is secure because it:

• Is built on top of well-tested, lab certified hardware.
• Has a security-focused OS.
• Has limited access via a network interface controlled by internal rules.
• Actively hides and protects cryptographic material.

HSMs may have tamper evidence features such as visible signs of tampering, tamper resistance where tampering makes the HSM inoperable, or tamper responsiveness such as deleting keys upon tamper detection. Many HSM systems have secure backup systems, which allows keys to be backed up and stored on a computer disk or externally using a secure portable device. HSMs are usually certified to internationally recognized standards, such as FIPS 140, to provide independent assurance of sound design and implementation.

The best way of protecting trust anchors and other cryptographic material is using a hardware component that is designed for this purpose. Hardware security modules (HSM, TPM, etc.) usually offer both key storage and cryptographic operation acceleration in the same module. wolfSSL supports the NXP CAAM hardware, which offers the same functions as HSM, but built into i.MX silicon. For more information, visit our blog about NXP CAAM.

wolfCrypt, our crypto engine that powers wolfBoot, supports all possible schemes from a wide range of manufacturer-specific API to access this functionality, such as Microchip ATECC608, ARM CryptoCell, NXP CAU/mmCAU/LTC, STMicroelectronic PKA, and many others.

wolfSSL also supports PKCS#11, a HSM standard that defines an API for using cryptographic tokens. Using wolfSSL on your application or your device will now allow you to utilize PKCS#11 for access to hardware security modules, smart cards, and other cryptographic tokens.

Trusted Platform Module (TPM)

Trusted Platform Module (TPM) is an international standard for a secure cryptoprocessor – a special microcontroller designed to secure hardware through integrated cryptographic keys. This microcontroller interfaces with a standard hardware/software platform to be secured to serve the interests of the system designer alone. TPM can also refer to a chip conforming to the standard. The standard was designed by the Trusted Computing Group, and TPM 2.0 is the most recent edition of the standard. 

TPM is used to:

• Securely create, store, and limit the use of cryptographic keys.
• Authenticate platform devices and encrypt data using the TPM’s unique RSA bind key.
• Ensure platform integrity by storing security and system integrity measurements.
• Create a nearly unforgeable hash key summary of the hardware and software configuration, which allows a third party to verify that the software has not been changed, called remote attestation.
• Generate random numbers from hardware.

TPM technology is now available for embedded systems thanks to wolfTPM, a library providing APIs to access TPM 2.0 compatible secure element, and the only TPM 2.0 library designed for bare metal and embedded systems. It also has native Windows and Linux support, alongside a TPM simulator for rapid development and testing. Popular TPM devices supported by wolfTPM include the ST33 and the Infineon 9670. Due to wolfTPM’s portability, it is generally very easy to compile on new platforms. For more information, visit the wolfTPM product page!

Secure Enclave

Secure enclaves are becoming a popular way to separate and protect sensitive code and data from other processes running on a system. Two popular secure enclaves are SGX and TrustZone, both of which can be used in securing trusted execution environments.

A trusted execution environment (TEE) is a secure area of a main processor which guarantees confidentiality and integrity of code and data loaded inside. A TEE as an isolated execution environment provides security features such as isolated execution, integrity of applications executing with the TEE, along with confidentiality of their assets.

Intel Software Guard Extensions (SGX) are a set of security-related instruction codes that are built into some modern Intel CPUs. SGX allows user-level and operating system code to define enclaves – private regions of memory whose contents are protected and unable to be either read or saved by any outside process. SGX involves encryption by the CPU of a portion of memory and protects data via application isolation technology. In cryptography, SGX can be used to conceal proprietary algorithms and encryption keys. 

SGXs can be thought of as a black-box where no other application running on the same device can see inside regardless of privilege. From a security standpoint, this means that even if a malicious actor were to gain complete control of a system including root privileges, that actor would not be able to access data inside of this “black-box”. An Intel enclave is a form of user-level TEE which can provide both storage and execution – users can store sensitive information, as well as move sensitive portions of a program or an entire application inside.

The wolfCrypt FIPS validated cryptographic module has been validated while running inside an Intel SGX enclave and examples have been set up for both Linux and Windows environments. For more information, visit our blog post on wolfSSL and Intel SGX. 

Arm TrustZone technology offers an efficient, system-wide approach to security with hardware-enforced isolation built into the CPU. It provides the perfect starting point for establishing a device root of trust based on Platform Security Architecture (PSA) guidelines. TrustZone is used on billions of application processors to protect high-value code and data for diverse use cases including authentication, payment, content protection and enterprise. On application processors, TrustZone is frequently used to provide a security boundary for a GlobalPlatform Trusted Execution Environment.

wolfBoot provides support for secure boot on systems with a TEE. wolfBoot provides embedded developers with a code base that complies with the specification for the separation between secure and non-secure world, on those CPUs and microcontrollers that support it. On ARMv8 Cortex-A CPU and Cortex-M microcontrollers it is now possible to create a hardware-enforced separation between the two worlds, using the ARM TrustZone technology. For more information, read our blog post on wolfBoot support for ARM TrustZone. 

Secure Element/Hardware Root of Trust

Hardware root of trust prevents simulation of hardware with user-controlled software, using a set of private keys used for cryptographic functions that are embedded directly into the chip during manufacturing. These keys cannot be changed, even after device resets, and have public counterparts kept in a manufacturer database. The public key is used to verify a digital signature of trusted vendor-controlled firmware (such as secure enclaves in SGX), which is then used in remote attestation.

Hardware root of trust also enables a secure boot process, using hardware that makes it immune from malware attacks. It can be used on its own or implemented as a security module within a processor or a system on chip (SoC).

Secure element refers to secure solutions like STSAFE, ATECC608, and hardware roots of trust without the standard TPM interface. Secure elements are unique in terms of interface.

A secure element is a tamper-resistant hardware platform, capable of securely hosting applications and storing confidential and cryptographic data. It provides a highly-secure environment that protects user credentials. Secure element features include:

• Detection of hacking and modification attempts
• Creation of a Root of Trust (RoT) platform for encryption systems
• Secure memory for storing private encryption keys and other sensitive information
• Secure random number generation
• Generation of encryption keys

The wolfTPM library provides APIs to access TPM 2.0 compatible secure elements. 

Conclusion

HSM, TPM, Secure Enclave, and Secure Element/Hardware Root of Trust all have the same function, which is to securely store keys, and securely execute cryptographic operations. The difference is that they’re all uniquely named. wolfSSL provides products that support all different schemes to best fit your cryptographic 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.

Love it? Star us on GitHub!

The latest release of wolfMQTT, v1.12.0, is now available! This release has several bug fixes and optimizations including:

• Allow MqttClient_WaitType to return MQTT_CODE_CONTINUE with MT (PR #283)
• Fix decoding user property and add example (PR #282)
• Fix issue with MqttClient_Publish_WriteOnly not waiting properly for ACK
  (PR #281)
• Fix MQTTv5 disconnect with props (PR #279)
• Add new publish write only API for multi-threading (PR #277)
• Fix for multithreaded cancel (PR #276)
• MQTT-SN Add disconnect_cb when disconnect recv from broker; Fix PUB ACK
  return status handling (PR #274)
• Enable TLS1.3 in examples (PR #273)
• Adding windows github actions build test (PR #272)

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

https://github.com/wolfSSL/wolfMQTT/blob/master/ChangeLog.md

While you’re there, show us some love and give the wolfMQTT project a Star!

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

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

wolfSSL is holding an upcoming webinar on February 24th, 2022!  Join us for a comprehensive presentation on how to leverage wolfSSL for all of your automotive security needs. Our expert engineers will go through a variety of different use cases, stories, and examples, each with specific engineering details. Bring your questions for the Q&A session to follow!

Topic: Looking Under the Hood – Everything you need to know about automotive security that you’re too afraid to ask: wolfSSL Automotive Stories and Examples!

Watch the webinar here: Looking Under The Hood-wolfSSL Automotive Security

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

One of the reasons for wolfSSL ubiquity is its easiness to support a wide range of platforms, interfaces and hardware accelerations. Now wolfSSL makes another step in this direction supporting an additional cryptographic interface, the Platform Security Architecture (PSA) crypto API. This means that everything wolfSSL supports (DTLS 1.2, TLS 1.3, etc.) can now leverage the API exposed by a PSA capable system. To start experimenting take a look at https://github.com/wolfSSL/wolfssl/tree/master/wolfcrypt/src/port/psa.

For a more hands-on approach feel free to check our examples, where you can find how to establish a TLS 1.3 connection on Trusted Firmware-M (https://github.com/wolfSSL/wolfssl-examples/tree/master/psa), the reference implementation for the PSA ecosystem. The example uses an STM32L5 NUCLEO-L552Ze-Q 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.