RECENT BLOG NEWS

One of the earliest posts on our blog is this one: https://www.wolfssl.com/wolfssl-supports-the-rim-playbook/

In 2010 it was announced that wolfSSL supported (Research In Motion) RIM’s BlackBerry Playbook and mentions QNX support ever since the first source release of wolfSSL.  That has been close to 20 years of support.

In this post we’d like to mention that it is not just the wolfSSL library that supports QNX; all of our products do!

• wolfSSL and wolfCrypt with FIPS, DO-178 DAL A or without are all fully supported
• Running QNX on a board with a TPM on it? Then wolfTPM which supports the TPM 2.0 protocol is something you must use.
• Need a light-weight SSH implementation on your QNX project? Then wolfSSH is your solution.
• Want to guarantee the integrity of your QNX firmware image or do over the air updates? Then the wolfBoot bootloader is perfect for you.
• Looking for an (Intrusion Detection and Prevention System) IDPS to secure your QNX-based deployment? Then wolfSentry is what you’re looking for.
• Have a need for lightweight data transfer? Try curl or even tiny-curl for those low-resource platforms that QNX is known to run on.

Please reach out to us to learn more about how we can help you secure your QNX deployments! If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

With the myriad of options available for a bootloader today many integrators try and fail to find the most secure and flexible bootloader with the smallest footprint. To help put an end to this search we will be going over wolfBoot’s many advantages compared to its competitors to make clear why wolfBoot is the best fit for your application.

Supported Signature Verification Algorithms

Signature verification in secure boot is the process of verifying and authenticating a boot image using a signature and public key provided by a signing authority. Out of the box Das U-Boot supports RSA image signature verification using SHA-1 or SHA-256 digests. U-Boot can be extended to include any algorithm you wish but that requires the additional effort of including or writing an external crypto library that will inflate code size and increase the time it takes to get a working product.

WolfBoot was built using wolfCrypt, our small embeddable crypto library that powers all of our products, and leverages it to support a wide range of signature verification options including ED25519, ECC and RSA. It does not support the outdated SHA-1 but instead supports the modern SHA-256, SHA-384 and SHA3 hashing algorithms and because its free software can also be extended as you wish.

Encrypted Boot Partition

Both wolfBoot and U-Boot support encrypted images but wolfBoot supports both AES and CHACHA encryption while U-Boot only supports AES.

Beauty and the Bloat

U-Boot has many unnecessary features for a secure bootloader, including a command line interface and a full TCP/IP networking stack. These features increase the amount of code, which increases the number of potential bugs, the size of the image and creates a larger attack surface to compromise your system.

WolfBoot was built by security experts and thus was designed to boot into the application image as fast and securely as possible. By constraining wolfBoot to the essentials we are able to keep code size down leading to less bugs in the first place and less attack vectors open to compromise your system. Keeping code size down leaves more room for such features in the application image where they belong.

Portability

Porting U-Boot to a new system is a complicated process as U-Boot takes responsibility for bringing up the system’s peripherals ahead of the OS being loaded. WolfBoot takes a hands off approach and leaves those tasks to the application image, making it system and OS agnostic. Getting wolfBoot running on a new target only requires adding a new Hardware Abstraction Layer (HAL) file for setting the clock up and reading and writing flash. HALs are straightforward to write with the right documentation and usually come in under 600 lines of code.

Interruptible Update Process

While both U-Boot and wolfBoot support image updates, only wolfBoot has an interruptible update process that allows it to complete an update even in the event of a power failure during the update. In this event of an unfortunately timed power failure this makes the difference between a working board and a paperweight.

Delta Updates

In addition to being interrupt safe, wolfBoot also has the additional feature of delta updates, which chunks and strips an updated image down to only the parts that differ from the last image. WolfBoot will then apply this new image to the old one as a patch, which leads to significantly smaller update images that save space in environments where flash memory is scarce.

FIPS Support

FIPS (Federal Information Processing Standards) is a cryptography standard that firms who deal with the United States government are often required to comply with in order to sell to them. WolfCrypt is FIPS compliant (when built with the correct options) and therefore wolfBoot is FIPS compliant without any additional work required, saving a lot of time on compliance. U-Boot on the other hand uses a standalone cryptography library that would need to be manually replaced with a fips compliant library, which is a costly and time consuming process.

DO-178 Certification

In addition to FIPS, wolfCrypt, and by extension wolfBoot, is DO-178 Certifiable. DO-178 is a strict aviation standard that the FAA (Federal Aviation Administration) and EASA (European Union Aviation Safety Agency) require for software components that run inside aircraft approved to fly in their airspace. WolfSSL itself is DO-178 DAL A certified on numerous operating environments and our expert DO-178 engineers are available for consulting to help get your operating environment certified. U-Boot’s standalone cryptography library would need to be brought through the certification process from scratch or an external library would need to be swapped out for a certifiable one.

If you need need a secure and flexible bootloader, with the smallest footprint, wolfSSL can help. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Recent research from Universidade do Minho in Portugal was presented at the Black Hat Asia conference in Singapore. The work of Dr. Sandro Pinto and Cristiano Rodrigues brought to the surface a groundbreaking technique that exploits the shared pipeline on the newest Cortex-M CPUs to place a time based, side-channel attack from an application running in non-secure domain to security code running in secure mode. The researchers named this attack “BUSted”. This is sudden and difficult news hitting the new generations of ARMv8 microcontrollers. The attack was demonstrated live using a Cortex-M33 microcontroller as target.

Due to the nature of the attack, targeting specific microarchitectural design issues, this disclosure has already been compared to “Spectre” and “Meltdown”, well known attacks that have affected more sophisticated architectures in the recent past. All the embedded projects that were counting on hardware-assisted privilege separation through TrustZone-M should now take into account the possibility of leaking information from the trusted components running in the secure world.

According to the researchers, software based countermeasures and mitigations are possible to counter the effects of this microarchitectural design fault. The most important aspect to take into account when dealing with time-based attacks is to avoid as much as possible secret-dependent code in the implementation of security operations. In other words, the time required for a security procedure to run must not depend on the success of the operation or on any secret involved in the operation.

wolfCrypt cryptography functions are already secret-independent. Our implementation ensures that all the critical operations that involve secrets are run in constant-time, unless specifically disabled. When using wolfSSL software, you should expect these types of countermeasures to be activated by default. This specific attack however may be even more subtle, because it can target custom code built around hardened code, e.g. if wolfCrypt cryptography is accessed through a custom wrapper in non-secure-callable code. In this case even the smallest time difference between two branches of a single ‘if’ instruction may be sufficient to make assumptions on the results of the underlying secure operation or on any of the keys. As the authors of the research suggest, there might be additional specific mitigations needed.

Our secure bootloader, wolfBoot, is capable of configuring and managing the separation between the two execution domains on Cortex-M23, M33 and M35 targets. In future releases wolfBoot will also feature a secure domain monitor that handles cross-domain calls from the application, protecting cryptography code and keys from direct access from the non-secure world.

wolfBoot’s main responsibility is of course to secure the boot process by ensuring that no unauthorized application code can execute in the non-secure domain. Our recommendation is to always enforce public-key based authentication of all the software running on the system, to cut the origin of these attacks as much as possible, by preventing rogue code to be run on the system. By using wolfcrypt, all the necessary mitigations against side-channel attacks are already integrated and activated by default.

You can download wolfBoot today from our download page or from our github repository

Has your design been affected by “BUSted”? Is your embedded system currently relying on TEE to enforce privilege separation between software modules? Share your story with us and let us know. Ask us anything about time-based attacks, hardened code and side-channel prevention! If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Around the end of last year, Amazon announced MQTT v5.0 support for its AWS IoT Core MQTT Broker. Support for this protocol was added to the AWS wolfMQTT client example with a recent effort here at wolfSSL.

The wolfMQTT library is a client implementation of MQTT written in C for embedded use, with support for SSL/TLS via the wolfSSL library. wolfMQTT supports both the MQTT 3.1.1 specification as well as the MQTT v5.0 specification. And with the recent updates, the AWS client can now be used to test out AWS IoT Core’s new protocol support and its functionality. Note that we updated our AWS host instance to use an ATS endpoint, as they are the only ones that support MQTT v5.0 as of now.

For more information about wolfMQTT or its MQTT v5.0 support, If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Reference
wolfMQTT GitHub Repository
wolfMQTT User Manual
AWS MQTT v5.0 Upgrade
AWS IoT Core ATS
MQTT v5.0 specification
HiveMQ: “MQTT 5: Upgrade now. Here’s why.”

WolfSSL will attend Xponential at booth 3014 May 9th to May 11th in Denver, CO. At Xponential 2023, the focus is on new developments in unmanned vehicle systems.

WolfSSL offers highly optimized TLS and cryptography libraries that secure IoT devices and embedded systems against cyber attacks. At both tradeshows, the wolfSSL team will meet with attendees and discuss how their products can support their projects. They have the expertise and experience to help you achieve your security goals and enhance system performance.

By scheduling a meeting with the wolfSSL team attendees can gain valuable insights into the latest trends and technologies in cybersecurity. Don’t miss out on this opportunity to meet with wolfSSL and explore the latest advancements in unmanned vehicle 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.

wolfSSL is extremely proud to announce that an additional 18 OEs (Operating Environments) have been added to cert #3389 with only a 62-day turnaround from the CMVP between submission and approval: Feb 23 2023 – April 26 2023.

INFO:

Cert Location: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3389
SunSet Date: 3/3/2024

Operating Environments validated (raw count): 73
Operating Environments validated (non-PAA specific): 50

The 18 OEs that were added to cert #3389 are as follows:

1. Linux 3.10 (CentOS 7) Intel® Atom™ CPU D525 @ 1.80GHz with PAA Beckman Coulter PROService RAP BOX 4.3.2
2. Linux 3.10 (CentOS 7) Intel® Atom™ CPU D525 @ 1.80GHz without PAA Beckman Coulter PROService RAP BOX 4.3.2
3. Yocto (dunfell) 3.1 AMD GX-412TC SoC with PAA LinkGuard 4.3.2
4. Yocto (dunfell) 3.1 AMD GX-412TC SoC without PAA LinkGuard 4.3.2
5. Linux 5.4 Intel® Xeon® Gold 5218 CPU @ 2.30GHz LiveAction LiveNX Appliance 4.3.2
6. Windows 10 Pro Intel® Core™ i7-1255U @ 1.70 Ghz Dell Precision 3570 4.3.2
7. Debian GNU/Linux 8 (jessie) Intel® Atom™ C2558 @ 2.40GHz ufiSpace Cloud and Data Center Switch S7810-54QS 4.3.2a
8. FreeBSD 10.3 on VMWare ESXi 7.0 Intel® Xeon® Silver 4210 @ 2.20GHz Supermicro X11DPH-i 4.3.2a
9. Linux 5.15 on VMWare ESXi 7.0 Intel® Xeon® Silver 4210 @ 2.20GHz Supermicro X11DPH-i 4.3.2a
10. Debian GNU/Linux 8 (jessie) Broadcom BCM5634 Corning 1LAN-SDDP24POE 4.3.2a
11. Linux IPHO00550F22 4.1 Broadcom BCM6858 Corning 1LAN-SDAN-7691 4.3.2a
12. Linux IPHO00559B23 3.4 Broadcom BCM6838 Corning 1LAN-SDAN-7290 4.3.2a
13. macOS Monterey 12.5 Intel® Core™ i7-8569U @ 2.80Ghz with PAA Macbook Pro 4.3.2a
14. Windows 11 Enterprise Intel® Core™ i7-10610U @ 1.80Ghz with PAA Dell Latitude 7410 4.3.2a
15. macOS Monterey 12.5 Apple M1 Max with PAA Macbook Pro 4.5.4a
16. VxWorks 7 SR0630 Intel® Core™ i7-5850EQ @ 2.70GHz F-16 WASP 4.3.2a
17. macOS Monterey 12.5 Apple M1 with PAA Macbook Air 4.5.4b
18. macOS Monterey 12.5 Apple M1 without PAA Macbook Air 4.5.4b

This brings the total count of OEs tested and validated by wolfSSL Inc (vendor) in collaboration with UL Verification Services Inc (NVLAP accredited FIPS lab) under cert #3389 to a whopping total of 77! 4 OEs that had originally been tested and validated prior to SP800-56A Rev3 requirements were dropped from cert #3389 during the retesting effort leaving a total of 73 tested and validated Operating Environments under FIPS certificate #3389.

For a full list of all 73 tested and validated Operating Environments please checkout FIPS cert #3389 using the link to the certificate at the top of this blog post. If you have any questions about adding an OE please contact wolfSSL at fips@wolfssl.com anytime.

NEWS and the future of FIPS at wolfSSL and cert 3389:

As we approach the SunSet date of cert #3389, which is coming in March of 2024, wolfSSL would like to take this opportunity to address a few topics that regularly come up regarding impact of current and future projects.

• Once a certificate is moved to the historical list a banner is placed at the top of that cert that states: “Historical – The referenced cryptographic module should not be included by Federal Agencies in new procurements. Agencies may make a risk determination on whether to continue using this module based on their own assessment of where and how it is used.“
  • This means the certificate is unlikely to be acceptable for NEW contracts/projects, and can sometimes also impact ongoing software/firmware updates on previously closed contracts/projects. It is up to the purchase authority to weigh the RISK of using older FIPS certificates prior to making an acquisition for a project involving a FIPS requirement.
  • It is not unheard of that already fielded products may continue to ship software/firmware updates under a historical certificate.
    • To that end wolfSSL will continue to maintain, test and support cert #3389 FIPS modules long after cert #3389 is moved to the historical list on behalf of any customers still dependent upon it.
  • Those customers looking to close on NEW contracts/projects with a FIPS requirement will be happy to hear that wolfSSL Inc was one of the first 20 vendors in the world to be in process for FIPS 140-3 and estimates are that the wolfCrypt module is currently #16 in the CMVP queue for receiving a FIPS 140-3 certificate.
    • To-date only 3 vendors (Apple, AMD and VMware) have received 140-3 certificates none of which are commercial FIPS module offerings. wolfSSL anticipates being one of the first (if not THE first) commercial FIPS offering in the world for FIPS 140-3!
• Cert #3389 can not be extended beyond March of 2024 unless the CMVP decides to change their extension policies regarding FIPS 140-2 given that FIPS 140-3 modules are taking SO long to be approved.
  • wolfSSL Inc feels the likelihood of such an extension policy change is small however the probability does exist and is worth mentioning
• wolfSSL is seeing great demand from the industry for 140-3 as soon as it is available. wolfSSL Inc anticipates adding 25 (or more) OEs in the first year after receiving 140-3 certification for the wolfCrypt module. This means there may be a delay if one hesitates too long, please start planning FIPS projects today and get wolfSSL hardware ASAP to have an OE validated under the wolfSSL Inc 140-3 certificate once it is issued!

Are you interested in FIPS? 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 cryptography world is abuzz with the new proposed NIST standard, Ascon. Earlier this year, NIST selected the Ascon family “for lightweight cryptography applications as it meets the needs of most use cases where lightweight cryptography is required”. More details can be found at the NIST News Update. We at wolfSSL have been testing an initial prototype to have this suite ready for production release as soon as the standard is finalized.

Like all serious, commercial-grade cryptography software, the Ascon implementation is completely open source. Each of the candidate authors has signed a release. 

The Ascon suite contains these 12 algorithms:

• crypto_aead/ascon128v12: Ascon-128
• crypto_aead/ascon128av12: Ascon-128a
• crypto_aead/ascon80pqv12: Ascon-80pq
• crypto_hash/asconhashv12: Ascon-Hash
• crypto_hash/asconhashav12: Ascon-Hasha
• crypto_hash/asconxofv12: Ascon-Xof
• crypto_hash/asconxofav12: Ascon-Xofa
• crypto_auth/asconmacv12: Ascon-Mac
• crypto_auth/asconprfv12: Ascon-Prf
• crypto_auth/asconprfsv12: Ascon-PrfShort

For the full details of the implementation, see: https://ascon.iaik.tugraz.at/files/asconv12-nist.pdf

Part of the requirements of the new lightweight crypto was to be easily implemented in hardware. Of particular interest to hardware implementers is the RTL VHDL source code.

Embedded developers in particular will be very interested in these new algorithms designed specifically to be used on small devices with limited memory and computational resources. Are you an embedded developer? Are you interested in ASCON for your project? If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Have you heard the news from the OpenSSL blog?  If you are using the 1.1.1 branch of releases of OpenSSL, come September 11, 2023, there will be no more updates. You can get the details here: 

https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/   

That said, you can breathe a sigh of relief because wolfSSL is here to help.  We have three ways to help.

Compatibility Layer

During the configure step of building wolfSSL, simply use –enable-opensslall and that will turn on our compatibility layer.  Your application build will then have to point to wolfSSL’s include path and binary library file. You should not need to change your source code.  That said, if you find you are getting build errors about missing APIs, please send a message to support@wolfssl.com. We would love to help you keep your code base as clean and simple as possible.

wolfEngine

There are some cases where the compatibility layer might not be appropriate. For example, you might be directly modifying members of OpenSSL’s structures since not all of them are hidden. For such cases, we have wolfEngine. You can continue using OpenSSL, but under the hood the wolfCrypt implementations of the cryptographic algorithms will be used. This might be especially useful if you are looking for an accelerated path to FIPS certification.

wolfProvider

Perhaps you have already gone through the work of migrating to the OpenSSL 3.0.x branches. Noticing any performance issues? Having trouble finding help or getting support? The wolfSSL team is known for having the fastest cryptographic implementations and providing excellent support. Why not try out wolfProvider to see if it can help your project?  Like wolfEngine, if you are looking for an accelerated path to FIPS certification, this might be your solution.No matter your circumstances, we are here to help you through this trying time as OpenSSL ends support for the 1.1.1 series of releases. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

If you’re interested in learning more about SSL/TLS or the wolfSSL lightweight SSL library, then you’re in luck. wolfSSL is offering a free 2-day (4 hours each day) training course on wolfSSL.

The next instance of this training course will take place April 19th & 20th from 12:00 PM to 5:00 PM (UTC) both days. This instance was scheduled to accommodate European timezones, soon we will announce an instance that will accommodate Asia time zones.

The course includes Q&A sessions throughout the webinar. To get full access to the course, participants must register for both days. If you’re interested in learning more about SSL/TLS or the wolfSSL library, this training course is an excellent opportunity to deepen your knowledge and skills in this area.

Watch the webinar here: wolfSSL Training Part 1 , wolfSSL Training Part 2

The course objectives are to provide attendees with a basic understanding of how SSL/TLS work, learn the package and design of wolfSSL, effectively build wolfSSL for target platforms, learn effective wolfSSL debugging strategies, add wolfSSL to different client and server applications, learn best practices for adding wolfSSL to embedded, desktop/enterprise, or cloud applications or devices, and develop using wolfSSL’s underlying cryptography library.

If you are working towards CISSP (Certified Information Systems Security Professional) certificate this training webinar could qualify for Group A Credits as a domain related activity. 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 implements support for both client side and server side DTLS. The server side requires extra attention when it comes to Denial-of-Service (DoS) attacks. One way to mitigate DoS on DTLS servers is to operate statelessly until a cookie exchange is completed with the peer. The cookie exchange is implemented in all versions of DTLS. DTLS 1.2 uses a special HelloVerifyRequest message while DTLS 1.3 uses the TLS 1.3 HelloRetryRequest with a cookie extension. The general principle of the cookie exchange is shown in the following figures.

      Client                                   Server
      ------                                   ------
      ClientHello           ------>

                            <----- HelloVerifyRequest
                                   (contains cookie)
      ClientHello           ------>
      (with cookie)

      [Rest of handshake]

Figure 1: DTLS 1.2 cookie exchange (https://www.rfc-editor.org/rfc/rfc6347#section-4.2.1)

      Client                                   Server
      ------                                   ------
      ClientHello           ------>

                            <----- HelloRetryRequest
                                   + cookie
      ClientHello ------>
       + cookie

      [Rest of handshake]

Figure 2: DTLS 1.3 cookie exchange (https://www.rfc-editor.org/rfc/rfc9147.html#section-5.1)

The trick is to parse the initial ClientHello without maintaining state. In wolfSSL release 5.6.0, we implemented parsing the initial ClientHello without maintaining state at all (https://github.com/wolfSSL/wolfssl/pull/5910). Previously, wolfSSL would reset the object when requesting a cookie exchange but this can be unreliable on errors or when new features are implemented. Now we have a dedicated routine to parse the ClientHello statelessly.

wolfSSL also has a callback available when a peer has been verified. To set this callback, use the int wolfDTLS_SetChGoodCb(WOLFSSL* ssl, ClientHelloGoodCb cb, void* user_ctx) API.

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