RECENT BLOG NEWS

Did you know that the wolfSSL embedded SSL/TLS library supports the Renesas Trusted Secure IP Driver (TSIP) and has been tested on the Renesas RX65N platform? Using the TSIP driver, wolfSSL can offload supported cryptographic and TLS operations to the underlying Renesas hardware for increased performance.

wolfSSL has been integrated with the following TSIP capabilities:

• TSIP driver open/close
• Random number generation, tested with SP 800-22
• SHA-1 and SHA-256 hash function support
• AES-128-CBC and AES-256-CBC support
• TLS capabilities including:
  • Root CA verification
  • Client and/or Server certificate verification including intermediate certificate verification
  • Support for four TLS cipher suites:
    • TLS_RSA_WITH_AES_128_CBC_SHA
    • TLS_RSA_WITH_AES_128_CBC_SHA256
    • TLS_RSA_WITH_AES_256_CBC_SHA
    • TLS_RSA_WITH_AES_256_CBC_SHA256

The following benchmarks show the performance improvement when using hardware cryptography on the Renesas RX65N through the Renesas TSIP driver.

If you have questions about our TSIP support, or are interested in trying this in your environment, contact us at facts@wolfssl.com!  More information can be found on our Renesas TSIP webpage as well.

Don’t miss this hot topic next week! wolfSSL Engineer David Garske presents:

TPM wolfBoot
Wednesday, May 27th, 2020 at 10 AM Pacific time (GMT-7)
https://us02web.zoom.us/webinar/register/WN_Attz6zbXRsOFuPCIAdV8ZQ

In this webinar, we will talk about securing your hardware’s firmware and how to leverage a TPM 2.0 module for root-of-trust and measured boot. wolfBoot can use the wolfTPM software interface for secure and measured boot.

This combination supports use in a bare-metal environment with no external dependencies. Think reduced code size, minimal attack surfaces, and ease of maintenance.

What questions do you have around secure boot feasibility with TPM? David Garske has answers. Email us at facts@wolfssl.com with any questions.

wolfSSL is developing a library to handle the location of where crypto operations run amongst multiple cores. For large systems that have many sign/verify operations happening at once this library would be able to distribute those sign/verify requests based on a user’s input. In addition to managing where the operation runs it can be used to plug in hardware acceleration for handling requests that come in. An example use case would be having 3 cores for generic lower priority operations and saving 1 core that has hardware acceleration for fast, real time responses, that would run high priority operations.

For more details or questions, contact us at facts@wolfssl.com!

The new Automated Cryptographic Validation Protocol is the successor to the two decade old CAVP system from NIST. The ACVP system is intended to alleviate the manual steps of the older process, creating a more efficient and effective method for cryptographic algorithm testing and validation. The project started in 2016 and is currently executing the final Phase 4 objectives. More information from NIST’s website about the ACVP project can be found here:
https://csrc.nist.gov/Projects/Automated-Cryptographic-Validation-Testing

When completed, ACVP will be required for FIPS 140 compliance. wolfSSL is ready, and has already begun submitting algorithms to the NIST Demo server using the wolfACVP client library. Those results can be viewed here.

wolfSSL wants to make your FIPS 140, TLS, embedded, or IoT project successful!

Download the latest release from https://www.wolfssl.com/download/
or from our GitHub page at https://github.com/wolfSSL/wolfssl
While you’re there, show us some love by starring our project!

Contact us at facts@wolfssl.com for questions or more information.

wolfSSL is a growing company looking to add a top notch embedded systems software engineer to our organization. wolfSSL develops, markets and sells the leading Open Source embedded SSL/TLS protocol implementation, wolfSSL. Our users are primarily building devices or applications that need security. Other products include wolfCrypt embedded cryptography engine, wolfMQTT client library, and wolfSSH.

Job Description:

Currently, we are seeking to add a senior level C software engineer with 5-10 years experience interested in a fun company with tremendous upside. Backgrounds that are useful to our team include networking, security, and hardware optimizations. Assembly experience is a plus. Experience with encryption software is a plus. RTOS experience is a plus.  Experience with hardware-based cryptography is a plus.

Operating environments of particular interest to us include Linux, Windows, Embedded Linux and RTOS varieties (VxWorks, QNX, ThreadX, uC/OS, MQX, FreeRTOS, etc). Experience with mobile environments such as Android and iOS is also a plus, but not required.

Location is flexible. For the right candidate, we’re open to this individual working from virtually any location.

How To Apply

To apply or discuss, please send your resume and cover letter to facts@wolfssl.com.

This post was written by Guido Vranken and originally published on his blog (May 13, 2020).

Larry Stefonic of wolfSSL contacted me after he’d noticed my project for fuzzing cryptographic libraries called Cryptofuzz. We agreed that I would write a Cryptofuzz module for wolfSSL.

I activated the wolfSSL module for Cryptofuzz on Google’s OSS-Fuzz, where it has been running 24/7 since. So far, Cryptofuzz has found a total of 8 bugs in wolfCrypt.

Larry and Todd Ouska then asked me if I was interested in writing fuzzers for the broader wolfSSL library. I was commissioned for 80 hours of work.

I started by implementing harnesses for the TLS server and client. Both support 5 different flavors of TLS: TLS 1, 1.1, 1.2, 1.3 and DTLS.

wolfSSL allows you to install your own IO handlers. Once these are in place, each time wolfSSL wants to either read or write some data over the network, these custom handlers are invoked, instead calling recv() and send() directly.

For fuzzing, this is ideal, because fuzzers are best suited to operate on data buffers rather than network sockets. Working with actual sockets in fuzzers is possible, but this tends to be slower and more complex than piping data in and out of the target directly using buffers.

Hence, by using wolfSSL’s IO callbacks, all actual network activity is sidestepped, and the fuzzers can interact directly with the wolfSSL code.

Emulating the network

In the write callback, I embedded some code that specifically checks the outbound data for uninitialized memory. By writing this data to /dev/null, it can be evaluated by valgrind and MemorySanitizer.

Furthermore, I ensured that my IO overloads mimic the behavior of a real network.

On a real network, a connection can be closed unexpectedly, either due to a transmission failure, a man-in-the-middle intervention or as a deliberate hangup by the peer.

It is interesting to explore the library’s behavior in the face of connection issues, as this can activate alternative code paths that normally are not traversed, so this strategy harbors the potential to find bugs that are missed otherwise.

For example, what if wolfSSL wants to read 50 bytes from a socket, but the remote peer sends only 20?

These are situations that are feasible if an attacker were to deliberately impose transfer throttling in their communication with an endpoint running wolfSSL.

Addition and subtraction have shown to pose a challenge in programming, especially when they pertain to array sizes; many buffer overflows and infinite loops in software (not wolfSSL in particular) can be traced back to off-by-one calculations and integer overflows.

Networking software like wolfSSL needs to keep a tally of completed and pending transmissions and in light of this it is a worthwhile experiment to observe what will happen when faced with uncommon socket behavior.

Finding instances of resource exhaustion

Buffer overflows are not the only kind of bug software can suffer from.

For example, it would be unfortunate if an attacker could bring down a TLS server by sending a small, crafted packet.

Fuzzing can be helpful in finding denial of service bugs. Normally, fuzzers use code coverage as a feedback signal. By instead using the branch count or the peak memory usage as a signal, the fuzzer will tend to find slow inputs (many branches taken means a long execution time) or inputs that consume a lot of memory, respectively.

Several years ago I implemented some modifications to libFuzzer which allow me to easily implement fuzzers that find denial-of-service bugs. For my engagement with wolfSSL, I applied these techniques to each fuzzer that I wrote. I ended up providing three binaries per fuzzer:

• a generic one that seeks to find memory bugs, using code coverage as a signal
• one that tries to find slow inputs by using the branch count as a signal
• one that finds inputs resulting in excessive heap allocation

Emulating allocation failures

Using wolfSSL_SetAllocators(), wolfSSL allows you to replace its default allocation functions. This opens up interesting possibilities for finding certain bugs.

One thing I did in my custom allocator was to return an invalid pointer for a malloc() or realloc() call requesting 0 bytes. This way, if wolfSSL would try to dereference this pointer, a segmentation fault will occur.

This special code is needed because even AddressSanitizer will not detect access to a 0-byte allocated region, but it is important to test for, as such behavior can lead to real crashes on systems like OpenBSD, which intentionally return an invalid pointer from malloc(0), just like my code does.

Another possibility of implementing your own memory allocator is that it can be designed to fail sometimes.

On most desktop systems, malloc() always succeeds, but that may not be the case universally, especially not on resource-constrained systems which cannot resort to page swapping for acquiring additional memory.

Allocation failures activate code paths which are normally not accounted for by unit tests. I implemented this behavior for all fuzzers I wrote for wolfSSL.

In the TLS-specific code, 5 bugs were found.

Fuzzing auxiliary code

TLS is large and complex, and it can take fuzzers a while to traverse all its code paths, so in the interest of efficiency, I wrote several additional fuzzers specifically aimed at subsets of the library, like X509 certificate parsing (historically a wellspring of bugs across implementations), OCSP request and response handling (for which a subset of HTTP is implemented) and utility functions like base64 and base16 coders.

This approach found 9 additional bugs.

Testing the bignum library

wolfSSL comes with a bignum library that it uses for asymmetric cryptography. Because it is imperative that computations with bignums are sound, I took a project of mine called bignum-fuzzer (which has also found security bugs in other bignum libraries, like OpenSSL’s CVE-2019-1551) and appropriated it for use with wolfSSL. It is not only able to find memory bugs, but also incorrect calculation results.

I set out to test the following sub-libraries in wolfSSL:

• Normal math
• Single-precision math (–enable-sp)
• Fastmath (–enable-fastmath)

5 instances of incorrect calculations were found. The other bugs involved invalid memory access and hangs.

wolfSSH

In addition to wolfSSL and wolfCrypt, I also spent some time looking at wolfSSH, which is the company’s SSH library offering.

In this component I uncovered 7 memory bugs, 1 memory leak and 1 crash bug.

The Hexagon SDK is used for building code to run on DSP processors. Use of the Hexagon toolchain to offload ECC verify operations has been added to wolfSSL. This can free up the main CPU for other operations or lead to future optimizations with HVX on some algorithms that use vector operations. The Makefile for building with the Hexagon toolchain and a README with more information can be found in the directory wolfssl-4.4.0/IDE/HEXAGON.

For questions about the wolfSSL embedded SSL/TLS library contact facts@wolfssl.com.

Join us for our upcoming Roadmap call presented by wolfSSL CTO Todd Ouska!

Register here:
https://us02web.zoom.us/webinar/register/WN_p1tjcBxeQgGEilLT30Gprg
Thursday, May 14th, 2020 at 9 AM Pacific time (GMT -8)

wolfSSL CTO and Founder Todd Ouska presents on the 2020 Roadmap. Who drives our roadmap? Customers! Be sure to join us to learn what wolfSSL users are looking for in cybersecurity. We’re talking about:

• • DO-178 support from wolfBoot, wolfMQTT, and wolfDTLS – curl with MQTT
  • Common Criteria
  • FIPS 140-3
  • DTLS 1.3 support

As always, we want to hear from you! There will be a dedicated Q&A after the webinar where you can tell us about your priorities, concerns, and questions around embedded security.

Hope to see you there!

At wolfSSL, we have been developing secure boot solutions with customers for many years, and more recently we have released wolfBoot, a secure bootloader designed for embedded systems.

wolfBoot provides reliable support to remote firmware updates on a wide range of devices, supporting the most common architectures (ARM Cortex-M, ARM Cortex-A, RISC-V RV32).

wolfBoot supports all types of RTOS and embedded operating systems, so it can be used to boot FreeRTOS, Contiki, RIOT-OS, ChibiOS, ThreadX, VxWorks, QNX, TRON/ITRON/uITRON, Micrium’s uC/OS, FreeRTOS, SafeRTOS, Freescale MQX, Nucleus, TinyOS, TI-RTOS, uTasker, embOS, INtime, MbedOS, Linux, and many more…

Here is our list of the top ten interesting facts about secure boot.

10. Trusted firmware updates have become a requirement for IoT projects

IoT devices are not immune to cyber attacks, and many real-life cases have proven that misconfigured systems may even be an easier challenge for an attacker, and sometimes even compromise the entire distributed system from a single vulnerability in one software component.

Vulnerabilities happen. No matter whether the software is completely written from scratch or depends on third party components, defects in the implementation may surface at the worst time possible for the project timeline, and critical systems cannot afford to keep vulnerable versions running. At wolfSSL we know that security software development never sleeps. As soon as new vulnerabilities are discovered, the entire team immediately switch their focus on delivering a fix, launch all the tests and release a new version of the software.

IT services may already benefit of continuous deployment mechanisms to ensure that new versions of the software components are available to run just after they have been updated and delivered. This is a good way to reduce risks related to running outdated software in production.

Why should similar mechanisms not be widely available on embedded systems? Well, the question is complicated, due to a few aspects. The diversity of microcontrollers available on the market poses quite a few challenges for embedded systems developers to provide a unified mechanism that fits all the scenarios, use cases, platform specific hardware and sometimes unique communication interfaces and protocols. Moreover, embedded software is generally installed from a monolithic
binary file, containing a 1:1 match to the physical content of the non-volatile memory onboard. Updating a single component may be tricky unless there has been some specific partitioning mechanism in place.

The effort for defining the guidelines for a secure and safe firmware update mechanism have been lead by the SUIT group within IETF, which has studied the problem and has produced a standard draft: draft-ietf-suit-architecture-08. The document “[…] lists the requirements and describes an architecture for a firmware update mechanisms suitable for IoT devices.”

9. Updates are verified using public-key signature authentication

The key feature offered by a secure bootloader following the SUIT definition is the use of state-of-the-art cryptography to guarantee the authenticity of the current firmware and the updates that are coming from a remote source. By using public-key based authentication it is possible to verify that all the software on board before running it.

The mechanism is quite simple: the owner of the device creates a key pair. The private key is secret, it is never revealed or stored on the device itself. The private key is used by a script or a program to sign the manifest header, which is transmitted alongside with the binary image of the new software. The manifest header contains all the meta-data associated to the firmware image.

The bootloader can access a copy of the public key, as it is stored on the non-volatile memory on board, or on a specific hardware secure vault. The public key is not a secret, and even if revealed, it does not pose any risk for the secure boot process.

When the bootloader receives the update package, it uses the public key to initiate the verification. Only software that contains valid metadata, including a verifiable signature, will be allowed to run on the target.

8. Operating with small bootloaders

The secure bootloader is, in many cases, the only immutable part of an embedded system. SUIT specifications assume that in general the bootloader itself will not be uploaded because this may pose a risk in reliability. For this reason, one of the requirements for the implementation of a secure bootloader is to keep the bootloader small, and dedicate other components in the system to the task of transferring the firmware images and initiating the update.

This also means that code safety is critical in bootloader context, to guarantee the required level of reliability and minimize the attack surface. SUIT in particular mandates the use of small parsers in the code, since parsers are described as a “known source of bugs”.

One step further in this direction is to completely avoid dynamic memory allocations in the bootloader code. Measuring the memory usage at compile time and allocating static buffers for all the data structures significantly reduce the chance of memory management bugs such as overlapping of sections or heap-stack collisions when inappropriate memory mappings are configured.

A secure bootloader implementation cannot ignore resources and safety related requirements, or the risk is to create bigger issues than what it is expected to fix!

7. Rollback attacks

In the perspective of continuous vulnerability management, new updates are released and made available often. Unless the firmware images are transferred using a secure channel, such as TLS, there is always a risk that an old update is intercepted by an attacker, or anyone who is sniffing the traffic towards the firmware consuming device. This is particularly true in those broadcast-friendly environments, e.g. if the firmware images are distributed through a local mesh network that does not support secure socket communication.

An attacker may know about a vulnerability in a previous version, and attempt to downgrade the firmware on the target device to that specific version, by repeating the transmission of the firmware image previously recorded by wiretapping on the network.

A secure boot mechanism must retain the information about the firmware version alongside with all the other information in the manifest header. The version number, like the rest of the meta data, is enclosed in the envelope together with the firmware image during the signing process, which means that the version cannot be altered by an attacker without compromising the validity of the signature for the update package. The bootloader will not allow to install packages with a version number that is older than the one that is currently running on the system.

Rollback attacks are very easy to perform and preventing them is a key task for the secure bootloader.

6. Power failures and high reliability

According to Murphy’s law “anything that can go wrong will go wrong”. In the case of remote updates installation, the worst point to lose the power or having any kind of hardware glitch that results in a system reset is when the content of the non-volatile memory is altered during the installation of firmware updates. If a power cut occurs in the middle of a FLASH sector copy operation, the state of the destination sector is unpredictable upon the next boot.

A mechanism that can prevent this situation, like the one implemented in wolfBoot, consists in keeping always two copies of the same sector, and using a mechanism based on flags to confirm that each step has been completed. Upon reboot, the operation can be resumed from the last successful operation, so there is no risk of leaving the system in an unrecoverable state.

5. Secure boot and secure update transfers

Downloading the new version is a task for the embedded application, or a thread running on top of a real-time operating system. As indicated by SUIT, including the responsibility of transferring the firmware image in the bootloader code
would result in a bigger, more complex secure bootloader with external dependencies on protocol stack implementations and platform-specific device drivers. Embedded systems may in fact access the network picking from a variety of different connectivity technologies available. Not all of these technologies share the same protocol families or transport mechanisms. Some low power communication protocol such as LPWAN may even have stricter requirements on bandwidth or network availability.

wolfSSL is the embedded SSL/TLS library targeted for embedded systems. Being transport-layer agnostic that can provide secure socket communication on top of all kinds of data transfer technologies and operating system or bare metal applications.

Using the latest standard (TLS 1.3) to secure your connections means that devices can communicate to each other and to the back-end on end-to-end secured channels, using the best cryptography available as standard to date.

Some of the benefits of securing all the data in motion using TLS include of course encryption of all the data transferred between two endpoints, and optionally server-side identification for clients that access data, services or remote firmware updates.

On systems where the entire stack is deployed, including TLS socket communication, transferring the firmware images can be done over the same channel so that the update package can travel the network to the firmware consumer securely.

As TLS may not be an option for a subset of device with a very limited amount of resources available, at least encryption should be considered on such devices. wolfCrypt is a crypto engine targeted for embedded, RTOS and resource constraint environments, which is the core component of wolfSSL, but can as well used as standalone library to access the implementation of the most popular algorithms and cyphers.

4. Key management and trust anchors

In a distributed system architecture designed for remote firmware updates, key management is a critical task. The back-end system is in charge of keeping the private key (or keys) safe, and generating signed packages to distribute to firmware consumers when a new version is available.

wolfBoot is distributed with a toolbox of key management scripts and utilities that can be easily integrated on server side to facilitate these tasks. In the simplest case, the signature that is included in update packages is obtained using a private key which is accessible by the owner of the device. In some cases, a more elaborated key provisioning system is in place. When a separate software or hardware component is performing the signature step, the package creation process can be split to redirect and delegate the DSA step to another component.

The public key that is stored inside the embedded system is considered a ‘trust anchor’, because the trust in the validity of the remote firmware updates depends on the integrity of the public key used for digital authentication.

Trust anchor management is in general outside the generic scope of a bootloader itself because it depends on the hardware platform. However, it is of primary importance to include adequate protections against the risk of compromising the public key stored on the device and used by the bootloader to validate the authenticity of the firmware. A trust anchor store should be protected against write access using the available countermeasures available in hardware.

3. Secure elements and trust anchor stores

The best way of protecting trust anchors and other cryptographic material is using a hardware component that is designed for this purpose. Hardware security module (HSM, CAAM, etc.) usually offer both key storage and cryptographic operation acceleration in the same module. 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 ATECC608A, ARM CryptoCell, NXP CAU/mmCAU/LTC, STMicroelectronic PKA, and many others.

More recently, an effort of agreeing on the protocols used to the access to security cryptoprocessors, ISO/IEC standardized the TPM (Trusted Platform Module) format, which is in use nowadays in nearly all personal computers and notebooks. The same technology is now available for embedded systems thanks to wolfTPM, a library providing APIs to access TPM 2.0 compatible secure element. Popular TPM devices supported by wolfTPM include the ST33 and the Infineon 9670.

wolfBoot can as well be optionally compiled together with wolfTPM to make use of secure key storage and cryptography acceleration provided by these devices.

2. Updating the bootloader

The SUIT proposed standard recommends that the small bootloader is immutable, due to the intrinsic complexity for the bootloader to implement a reliable way to update itself. However in some cases it is useful to have the possibility to update the bootloader code itself.

Consider for example a situation where the public key is built-in the bootloader code, key provisioning relies on a single private key and this key gets compromised on the back-end.

Another case is a long life product, where the algorithms or the key length in use by the bootloader code today may become obsolete, or compromised, by many years of research. In a few years it may become a requirement to update the bootloader code to match new requirements.

For these reasons we think that giving the possibility to update the bootloader code is important. wolfBoot can be optionally compiled to support this option. A special update package that is marked as wolfboot self-update will cause the bootloader to overwrite its own code after a successful validation of the package itself.

The bootloader update process is not completely fail-safe due to intrinsic hardware constraints, but it is sufficiently reliable to be used for those emergency cases described above.

1. Estimating the development effort

When approaching secure boot and remote updates, it is often too easy to underestimate the impact of this single task on the development cycle of the entire project. A large amount of effort is spent on guaranteeing the reliability of the system in all the possible cases that could occur when the device is deployed.

The bootloader is perhaps the most critical part of the system. Everything else in your application can break, as long as there is still a way to update it from a remote location. Implementing a secure bootloader from scratch for a specific project is a tough task which in some cases may require as much development and testing as all the rest of the software components in the system.

At wolfSSL we have several years of experience in supporting our customers to build secure boot and remote updates solutions, and we have designed wolfBoot to provide a solid platform that can be used as the fundamental building block that can fit any secure boot architectural requirements.

We are available to talk with you about your design and we are happy to provide design and development services to complete the integration with any custom embedded system.

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.

Contact us at facts@wolfssl.com with any SSL/TLS, crypto, or secure boot questions!

wolfSSL has offered long-time support for PikeOS and ELinOS from SYSGO, and we are thrilled to announce wolfSSL’s integration into PikeOS Real Time Operating System for safety and security critical embedded systems. wolfSSL brings a FIPS crypto library to PikeOS’ EAL 3+ certified Separation Kernel in a pre-integrated bundle that ensures robust, proven security for your project’s architecture.

wolfSSL’s ongoing partnership with SYSGO serves our shared goal of certifiable security at the highest standards. Together we support critical embedded applications in avionics, automotive and railway industries, to name a few, and we’re pleased to bring our DO-178 support, MISRA-C capabilities, and established background in FIPS 140-2 to our collaboration with SYSGO.

Stay tuned to our Events page for upcoming Partner webinar information.

About SYSGO
SYSGO is the leading European manufacturer of embedded operating systems, supporting safety and security-critical applications in the aerospace, automotive, railway and IIoT industries for more than 25 years. The company develops and maintains PikeOS, the world’s first SIL 4 certified real-time operating system with multi-core support. The hypervisor (Type 1), which runs directly on the hardware, is certified according to the strictest safety standards such as IEC 61508, EN 50128 and ISO 26262. In terms of security, PikeOS is currently the only separation kernel certified to Common Criteria (EAL3+). In addition, PikeOS offers a fully certified programming interface and thus enables application development according to the “Safe & Secure by Design” principle. For less critical systems, SYSGO also offers ELinOS, an industrial grade Linux distribution with real-time extensions for embedded systems.

Follow SYSGO
Twitter
LinkedIn
RTOS Group on LinkedIn
SYSGO Blog

Find SYSGO in our Partner Network. Tell us about your embedded projects! facts@wolfSSL.com.