RECENT BLOG NEWS
Or sign up to receive weekly email notifications containing the latest news from wolfSSL.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.
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!
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.
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.
Have any questions? Email us at firstname.lastname@example.org for general inquiry and email@example.com for technical support. 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.
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.
Realizing your “Root of Trust” Security into your IoT devices for Tomorrow!
Guess what? wolfSSL and Renesas are thrilled to announce their partnership for a very special webinar: Realizing your “Root of Trust” Security into your IoT devices for Tomorrow! If you missed our first session, join us for our second session being held tomorrow!
September 3rd, 10am Central European Time
Please join this unique and latest webinar co-hosted by Renesas and wolfSSL. This session will illustrate how Renesas’s new RX products and Trusted Secure IP (TSIP) can help you implement robust security and how that align with wolfSSL, TLS 1.3 supported embedded SSL/TLS library. In this session, we also show the most recent benchmarking data of wolfSSL comparing our software cryptography implementation versus the TSIP hardware acceleration performance.
- Introducing Renesas RX MCU with dedicated security hardware ‘Trusted Secure IP’ features – By Renesas
- Experiencing the outstanding security performance of RX MCU with wolfSSL’s SSL/TLS security – By wolfSSL
September 3rd, 10am Central European Time
After registering, you will receive a confirmation email containing information about joining the webinar.
We look forward to seeing you there!
Who We Are
wolfSSL focuses on providing lightweight and embedded security solutions with an emphasis on speed, size, portability, features, and standards compliance, such as FIPS 140-2 and 140-3, RTCA DO-178C level A certification, and support for MISRA-C capabilities. wolfSSL supports industry standards up to the current TLS 1.3 and DTLS 1.2, 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. Our products are open source, giving customers the freedom to look under the hood.
About Our Partner
“Renesas Electronics Corporation delivers trusted embedded design innovation with complete semiconductor solutions that enable billions of connected, intelligent devices to enhance the way people work and live. A global leader in microcontrollers, analog, power, and SoC products, Renesas provides comprehensive solutions for a broad range of automotive, industrial, infrastructure, and IoT applications that help shape a limitless future.”
To learn more: https://www.renesas.com/us/en/
Renesas Related Blog Posts:
- Read on wolfSSL’s latest support for Renesas RX72N Envision Kit: https://www.wolfssl.com/renesas-rx72n-envision-kit-supported/
- Learn more about how wolfSSL embedded SSL/TLS library supports the Renesas Trusted Secure IP Driver (TSIP): https://www.wolfssl.com/renesas-tsip-driver-support/
- Check out the embedded-C wolfSSL TLS and wolfCrypt cryptography libraries on the Renesas RA Family of 32-bit MCUs with Arm Cortex-M Core: https://www.wolfssl.com/wolfssl-delivers-best-tested-feature-rich-security-renesas-ra-family-mcus/
To learn more about wolfSSL:
- Check out the wolfSSL embedded SSL/TLS library
- Star us on Github
- Learn more about the latest TLS 1.3 is available in wolfSSL.
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
Contact us at firstname.lastname@example.org with any questions about using new features available in the wolfSSH embedded SSH library! 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:
- Planning Review
- Design review
- Validation and Verification review
- 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, please contact email@example.com.
- 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.
Check out our release notes for more details, and feel free to contact us at firstname.lastname@example.org with any questions.
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 email@example.com with any questions:
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
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 firstname.lastname@example.org with any questions:
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
Anyone using DTLS with wolfSSL versions prior to release 4.5.0.
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.
Update to wolfSSL version 4.5.0.
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.
More available upon public disclosure of research. The patch fixing this issue can be viewed at this link:
Please contact email@example.com if you have any questions.
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
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.
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.
Contact us at firstname.lastname@example.org with any SSL/TLS, crypto, or secure boot questions!
- September 2020 (13)
- August 2020 (13)
- July 2020 (13)
- June 2020 (18)
- May 2020 (17)
- April 2020 (17)
- March 2020 (7)
- February 2020 (24)
- January 2020 (18)
- December 2019 (9)
- November 2019 (16)
- October 2019 (14)
- September 2019 (24)
- August 2019 (21)
- July 2019 (8)
- June 2019 (13)
- May 2019 (35)
- April 2019 (32)
- March 2019 (20)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (11)
- October 2018 (18)
- September 2018 (18)
- August 2018 (8)
- July 2018 (15)
- June 2018 (29)
- May 2018 (15)
- April 2018 (11)
- March 2018 (19)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (7)
- September 2017 (8)
- August 2017 (6)
- July 2017 (11)
- June 2017 (8)
- May 2017 (10)
- April 2017 (5)
- March 2017 (7)
- February 2017 (1)
- January 2017 (8)
- December 2016 (3)
- November 2016 (2)
- October 2016 (18)
- September 2016 (8)
- August 2016 (5)
- July 2016 (4)
- June 2016 (11)
- May 2016 (4)
- April 2016 (5)
- March 2016 (4)
- February 2016 (12)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (6)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (13)
- January 2015 (6)
- December 2014 (7)
- November 2014 (3)
- October 2014 (2)
- September 2014 (11)
- August 2014 (6)
- July 2014 (9)
- June 2014 (11)
- May 2014 (11)
- April 2014 (9)
- March 2014 (3)
- February 2014 (3)
- January 2014 (5)
- December 2013 (9)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (8)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (9)
- December 2012 (13)
- November 2012 (5)
- October 2012 (7)
- September 2012 (4)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (6)
- April 2012 (7)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (6)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (8)
- May 2011 (12)
- April 2011 (4)
- March 2011 (12)
- February 2011 (9)
- January 2011 (13)
- December 2010 (17)
- November 2010 (12)
- October 2010 (14)
- September 2010 (11)
- August 2010 (20)
- July 2010 (14)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)