RECENT BLOG NEWS

Storing encrypted firmware updates with wolfBoot

At wolfSSL, we work together with our customers to better understand the real-life scenarios in embedded security.

One of the concerns that we have been addressing the most when it comes to secure boot is the protection of the ‘data at rest’ when the firmware updates are received and stored on unprotected non-volatile memory supports, such as external SPI FLASH devices or other customized forms of storage.

wolfBoot, our fully open source secure bootloader solution for embedded systems, now supports encrypted external partitions, to safely store your firmware updates during the update process. The algorithm used is ChaCha20, implemented via wolfCrypt.

Each update can now be signed-and-encrypted to be distributed on the target, and the application can set a decrypt key at runtime, using wolfBoot API. This support has been recently merged in master branch and it will be included in the next release.

Here is how to enable it:

1. Compile the bootloader with the option `ENCRYPT=1`
2. Create a buffer of 44 random Bytes, and store it into a `secret_key` file. This file now contains the key and vector that will be used for the encryption of the firmware image.
3. Add the extra step `–encrypt secret_key` to the sign tool invocation. This will generate an extra *_signed_and_encrypted.bin image file
4. Transfer the _signed_and_encrypted image to the target. The system application can still use wolfBoot HAL to access external devices, because encryption is only enabled in bootloader mode.
5. Set the secret key and vector in the application via the wolfBoot API call `wolfBoot_set_encryption_key()`. The secret key could be e.g. pre-stored in a secure element, or transmitted during the update through a secure channel.
6. Initiate the update as usual, with `wolfBoot_trigger_update()`, and reboot. wolfBoot will attempt to decrypt and verify the firmware, and initiate the installation if the verification is successful.

The image stored in the UPDATE partition is always encrypted, including the backup copy of the previously running system during the installation. This ensures that reading out the partition would never reveal its content as long as the secret encryption key is kept safe.

The partition encryption support in wolfBoot is an additional protection for data at rest, when the firmware is stored on external devices where it is not possible to activate any effective read-out protection.

For data in motion, as usual, we recommend transferring the updates using TLS 1.3, and always using encrypted communication towards the firmware consumer device.

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

At wolfSSL, we love our open-source community and fully support users working with us on our code, whether it’s finding errors or asking for technical assistance. We are always quick to address our security vulnerabilities–one recent example includes the article published by the Daily Swig on “Embedded security: wolfSSL can be abused to impersonate TLS 1.3 servers and manipulate communications” and our speedy response to the situation. 

As the Daily Swig narrates, Gérald Doussot, principal security consultant at UK-based cybersecurity firm NCC Group, discovered a high-risk bug in the SanityCheckTls13MsgReceived() function of file tls13.c:6925 that may put networks at risk of man-in-the-middle (MitM) attacks. NCC Group promptly alerted wolfSSL to the vulnerability in its eponymous, flagship product on July 27. 

And upon hearing the alert, we immediately addressed this issue. A fix was published on GitHub, then successfully tested by NCC Group, the next day. The patch was incorporated into the next major release, version 4.5.0, which landed on August 19.  The vulnerability (CVE-2020-24613) will affect versions up to 4.5.0 across all wolfSSL platforms that run TLS 1.3.

Additionally, our experts wolfSSL always urge users with TLS 1.3 enabled for client-side connections to update to the latest version, after a researcher demonstrated how attackers could use the open source library to impersonate TLS 1.3 servers, then read or modify data passed between clients. Additional sources state: 

“Users that have applications with client side code and have TLS 1.3 turned on, should update to the latest version of wolfSSL,” vendor in an accompanying GitHub advisory.

“Users that do not have TLS 1.3 turned on, or that are server side only, are NOT affected by this report.”

Version 4.5.0 of wolfSSL will assimilate fixes for five other vulnerabilities that may pose a risk of denial-of-service (DoS) attacks, cache timing attacks, side-channel attacks, the leak of private keys, and clear application_data messages in epoch 0 being processed and returned to the application during the handshake. 

On the issue, our co-founder, Larry Stefonic stated, 

“It was not a tricky fix and we had the fix ready in about 36 hours after the report. [Additionally] Gerald was efficient and easy to work with in his bug submission. He wrote good examples that were easy to reproduce. We are appreciative of that. 

Despite having two sets of our internal eyeballs on each line of code, and sometimes three, we need people like Gerald who have the mindset and intellect to find these things.” 

So with all the bugs fixed and our newest updates released, we encourage people to continue to look at our code and break it. We look forward to hearing more feedback from our users! 

Read more: https://portswigger.net/daily-swig/embedded-security-wolfssl-can-be-abused-to-impersonate-tls-1-3-servers-and-manipulate-communications

New to wolfSSL? 

We are the best-tested crypto on the market and currently secure over 2 billion connections with more than 1,000 OEM customers and dozens of resellers.  Here at wolfSSL, we provide lightweight and embedded security solutions with an emphasis on speed, size, portability, features, and standards compliance. wolfSSL supports high security designs in the automotive (MISRA-C capabilities), avionics (complete RTCA DO-178C level A certification), and other industries.

For government consumers, wolfSSL has a strong history in FIPS 140-2, with upcoming FIPS 140-3 validation and Common Criteria support. wolfSSL supports industry standards up to the current TLS 1.3 and DTLS 1.3, is up to 20 times smaller than OpenSSL, offers a simple API, an OpenSSL compatibility layer, is backed by the robust wolfCrypt cryptography library, and much more.

Contact Us 

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

Learn more about wolfSSL’s embedded SSL/TLS library, star us on Github, and check out the latest version of TLS 1.3 available with wolfSSL.

Press Release

August 25th, 2020

wolfSSL and iWave have partnered together to enable embedded TLS in the iWave portfolio of embedded solutions. iWave is a global embedded solution provider that offers a wide array of rugged and high-performance System on Modules (SoMs) and Single Board Computers (SBCs) build on NXP i.MX6, i.MX8 series of Processors and INTEL FPGA series. This partnership allows iWave to strengthen their product offerings by utilizing the wolfSSL embedded SSL/TLS library and hardware crypto support onto the System on Modules and embedded solutions. 

“IoT devices are often deployed in remote environments and deal with sensitive user information, which makes them highly vulnerable to attacks. iWave Systems is taking measures to address the security challenges in IoT devices with turnkey security mechanisms that ensure complete reliability and value to end applications. To enable advanced and secure applications in customer products, collaboration with trusted partners like wolfSSL is integral to our go-to-market strategy.” – Abdullah Khan, Director-Engineering, iWave Systems Technologies.

wolfSSL stack in iWave devices are well-equipped to engage in connected solutions and supported by a strong engineering team to help customers through product development and deployment cycles. This partnership allows iWave’s extensive software service involving stack integration, configuration optimization, and application development to improve efficiency and time to market of IoT solutions. 

iWave consumers will also have access to all of wolfSSL’s key differentiators such as FIPS and DO-178 support for critical applications, the first commercial implementation of TLS 1.3, feasibility of integration with the entire wolfSSL product suite including secure boot, OpenSSL compatibility APIs, and 24×7 support for the best-tested crypto on the market.

Stay tuned for an upcoming partner webinar!

Read More

https://www.iwavesystems.com/partners-with-wolfssl-enable-embedded-tls 

https://www.iwavesystems.com/engineering-services/software-design-services/security.html

About iWave

iWave Systems Technologies Pvt. Ltd., established in the year 1999, focuses on product engineering services involving embedded hardware design and development, software development and FPGA services. iWave is a global leader in design and manufacturing of System on Modules based on NXP, Xilinx and INTEL chipsets.

About wolfSSL

wolfSSL provides lightweight and embedded security solutions with an emphasis on speed, size, portability, features, and standards compliance. wolfSSL supports high security designs in the automotive (MISRA-C capabilities), avionics (complete RTCA DO-178C level A certification), and other industries. For government consumers, wolfSSL has a strong history in FIPS 140-2, with upcoming Common Criteria support. wolfSSL supports industry standards up to the current TLS 1.3 and DTLS 1.3, is up to 20 times smaller than OpenSSL, offers a simple API, an OpenSSL compatibility layer, is backed by the robust wolfCrypt cryptography library, and much more.

Contact Us 

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

To all our wolfSSL readers, we have exciting news! wolfSSL is now integrated with our partner Netburner, in their standard offering of their NNDK tools. This new incorporation is available on their NNDK 3.3 tools, and will be migrating support to the NNDK 2.9.x tools in the near future! 

To read more on this integration, check out Netburner’s latest blog post  Introducing wolfSSL: Serious Updates to Our Security Suite

Netburner offers high quality, affordable network enabling technologies. They were established out of the need to provide a superior solution to the otherwise costly and time consuming development, tools and software licenses to produce a product. As a proud partner of NetBurner, together wolfSSL hopes to ensure security in the booming industries of IoT and embedded systems.

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 Inc is proud to announce the release of wolfSSH v1.4.5, the embedded SSH library for devices, IoT, and the cloud. Included in the release are:

• Added SSH-AGENT support to the echoserver and client
• Added support for building for EWARM
• Echoserver can now spawn a shell and set up a pty with it
• Added example to the SCP callback for file transfers without a filesystem
• Fix for building with wolfSSL v4.5.0 with respect to `wc_ecc_set_rng()`; configure will detect the function’s presence and work around it absence; see note in internal.c regarding the flag `HAVE_WC_ECC_SET_RNG` if not using configure
• Improved interoperability with winSCP
• Improved interoperability with Dropbear
• Example client can now authenticate with public keys

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247. Download the new release today from the wolfSSL download page or direct from GitHub.

As a cybersecurity company we have to make sure all of our products are state of the art. To make sure we have the best DO-178 cryptography, wolfSSL is conducting Stages of Involvement (SOI) audits on our wolfCrypt product. 

Last year wolfSSL added support for complete RTCA DO-178C level A certification. wolfSSL offers DO-178 wolfCrypt as a commercial off-the-shelf (COTS) solution for connected avionics applications. The primary goal of this was to provide the proper cryptographic underpinnings for secure boot and secure firmware update in commercial and military avionics. Avionics developers now have a flexible, compact, economical, high-performance COTS solution for quickly delivering FIPS 140-2 validated crypto algorithms can be used in DO-178 mode for combined FIPS 140-2/DO-178 consumption.

Any aviation system development requires Stages of Involvement (SOI) audits to review the overall software project and ensure that it complies with the objectives of DO-178 cryptography. Originally, DO-178-based development did not require SOI’s, however a problem arose because of divergence between different development organizations and what the certification authorities wanted. As a result, SOI’s have become an informal de facto standard applied to most projects. 

To assess compliance, there are four Stages of Involvement. The four stages are:

1. Planning Review
2. Design review
3. Validation and Verification review
4. Final Review

We have fully completed SOI #1 through #4, and have the best DO-178 cryptography on the market.

For more information regarding wolfSSL, wolfCrypt, DO-178, or any additional questions, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfBoot version 1.6 has been released and can be downloaded from our website. New features that are available starting from this release include:

• Support for encryption of external partitions
• Support for MPU on ARM Cortex-M platforms
• Support for using an RSA signature that includes ASN.1 encoded header
• Support for bootloader updates from external flash: SPI functions can now run from RAM
• Support for RSA verify via TPM
• Added option to use software SHA in combination with TPM

wolfBoot can now store the update image encrypted on external flash devices. The key tools distributed with wolfBoot can produce encrypted update images, using a pre-shared Chacha20 encryption key.

Memory protection ensures extra safety in the bootloader when running on Cortex-M targets, thanks to the support for MPU on this platform, when available.

The support for wolfTPM has been improved. It is now possible to use either ECC or RSA signature verification through a TPM device, if the module supports it. A new hybrid mechanism has been implemented to implement SHA calculation in software, using wolfCrypt, even when the TPM option is selected. This improves the boot time when using TPM devices that do not overperform the software implementation when calculating SHA digests.

Integration with third party key provisioning systems has been improved as well, now supporting RSA signatures that include ASN.1 encoded headers.

The safety of the manifest header parser has improved thanks to professional assessment of the robustness of wolfBoot against attacks targeting memory boundaries and address overflows.

Support for a new hardware platform has been added: Cypress PSoc6 MCU family, including the possibility to enable the hardware CRYPTO accelerator available on these targets.

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 summer release of wolfTPM, v1.9.0, is now available! This release has lots of new features, several bug fixes, and optimizations including:

• Fix when building wolfSSL with old names `NO_OLD_WC_NAMES`. (PR #113)
• Fix for TPM2 commands with more than one auth session. (PR #95)
• Bugfixes for TPM2_Packet_AppendSymmetric and TPM2_Packet_ParseSymmetric. (PR #111)
• TPM attestation fixes. (PR #103)
• If creating an NV and it already exists, set auth and handle anyways. (PR #99)
• Cleanups, removed unused code from the PCR examples. (PR #112)
• Improvements to the signed timestamp example. (PR #108)
• New example of a TPM2.0 Quote using wolfTPM. (PR #107)
• NPCT75x Nuvoton support and dynamic module detection support. (PR #102)
• RSA sign/verify support and expanded RSA key loading API’s. (PR #101)
• Attestation key wrappers. (PR #100)
• Added missing xor overload to TPMU_SYM_KEY_BITS. (PR #97)
• Signed timestamp example (AIK and Attestation). (PR #96)
• Added more testing. (PR #93)
• Added TPM benchmarking results for Nuvoton NPCT650 TPM2.0 module. (PR #92)

Check out the ChangeLog from the download for a full list of features and fixes, or contact us at facts@wolfssl.com with any questions:
https://github.com/wolfSSL/wolfTPM/blob/master/ChangeLog.md

While you’re there, show us some love and give the wolfTPM 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/wolfTPM

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 summer release of wolfMQTT, v1.7.0, is now available! This release has several bug fixes and optimizations including:

• Fix for publish with short topic name and example. (PR #169)
• Add MqttProps_ShutDown(). Fix MqttProp leaks(PR #167)
• Multithread fixes. (PR #166)
• Fix buffer overrun in strcpy(). Fix logic around getaddrinfo(). (PR #165)
• Fix MqttClient_WaitType for nonblock mode. (PR #164)
• Change anon union for ARMv6 error. (PR #163)
• Fix for publish large payload. (PR #162)
• Fixing LWT prop and allow null LWT. (PR #161)
• Fix for receive timeout in mqttsimple example. (PR #158)

Check out the ChangeLog from the download for a full list of features and fixes, or contact us at facts@wolfssl.com with any questions:
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

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

Affected Users:

Anyone using DTLS with wolfSSL versions prior to release 4.5.0.

Summary:

An issue was discovered in the DTLS handshake implementation in wolfSSL before 4.5.0. Clear DTLS application_data messages in epoch 0 do not produce an out-of-order error. Instead, these messages are returned to the application.

Recommendation:

Update to wolfSSL version 4.5.0.

Research:

The research for this vulnerability is not yet publicly available, a public disclosure containing more details is currently scheduled for November 15th, 2020. CVE-2020-24585 has been reserved for when the public disclosure is made available.

Additional Details:

More available upon public disclosure of research. The patch fixing this issue can be viewed at this link:

https://github.com/wolfSSL/wolfssl/commit/3be7f3e

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