First DO-178 SOI Audits

As a Cybersecurity company we have to make sure all of our products are state of the art. In accordance, wolfSSL is conducting Stages of Involvement (SOI) audit 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. 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.

For more information regarding wolfSSL, wolfCrypt, DO-178, or any additional questions, please contact

Upcoming Webinar: Getting Started with wolfSSL

wolfSSL is going back to basics! Join us for our upcoming webinar on July 8th, 2020 with wolfSSL Engineering Manager, Chris Conlon. We will review best practices for compile options, build process, examples and testing to ensure your wolfSSL implementation achieves the best possible results for your project. Bring your questions and findings for the Q&A session to follow!

When: July 8th, 2020 10:00 AM Pacific Time (US and Canada)
Duration: 1 hour
Topic: Getting Started with wolfSSL

If you are new to wolfSSL, here are some of our key differentiators:

  • wolfSSL is up to 20x smaller than OpenSSL
  • First commercial implementation of TLS 1.3
  • Best tested, most secure, fastest crypto on the market with incomparable certifications and highly customizable modularity
  • Access to 24×7 support from a real team of Engineers
  • Support for the newest standards (SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3, DTLS 1.0, and DTLS 1.2, + DTLS 1.3 forthcoming)
  • Multi-platform, royalty free, with an OpenSSL compatibility API to ease porting into existing applications which have previously used the OpenSSL package

For additional support, please contact or check out our user manual.

If you are interested, please register in advance for this webinar:

After registering, you will receive a confirmation email containing information about joining the webinar.

Hope to see you there!

Please contact us at with any questions about the webinar.

In the meanwhile, check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL.

Upcoming Webinar: Testing cURL for Security

wolfSSL is excited to announce that we will be hosting a webinar on June 30th, 2020 with wolfSSL engineer and cURL founder Daniel Stenberg on testing, fuzzing, and CI! There will be a Q&A session that follows so stay tuned.

cURL is used in virtually every connected device for secure data transfer and Stenberg believes it may be one of the world’s most widely used open source projects. On his own blog he states some of the biggest cURL installations from Internet servers at number ten, to Netflix devices, overall listing smartphones as number one. wolfSSL currently offers commercial support on cURL which can be built with wolfCrypt FIPS and is FIPS ready. For more information on using cURL with your project, please contact

When: June 30, 2020 10:00 AM Pacific Time (US and Canada)
Duration: 30-40 minutes
Topic: Testing cURL for Security

If you are interested, please register in advance for this webinar:

After registering, you will receive a confirmation email containing information about joining the webinar.

Looking forward to seeing you there!

Please contact us at with any questions about the webinar, the wolfSSL embedded SSL/TLS library, cURL, or tinycURL!

wolfSSL libest Port

Are you interested in having the best tested cryptography ported to libest? wolfSSL has many ports to various devices and projects. We are constantly working on and expanding our collection of ports and will soon be working on porting wolfSSL/wolfCrypt into libest.

The libest project is a library that implements RFC 7030 (Enrollment over Secure Transport). EST is used to provision certificates from a CA or RA. EST is a replacement for SCEP, providing several security enhancements and support for ECC certificates. Libest is written in C and currently is set up to use OpenSSL 1.0.1.  This port will allow libest to use wolfSSL in place of OpenSSL.

If you are interested in using wolfSSL with libest, or are looking to use wolfSSL with a different open source project, contact us at

Special Offer for NTLM + cURL Users

We hope everyone is enjoying this June weather. We understand due to current circumstances we have been under lockdown and cannot enjoy the weather as we have in the past. It is however a fantastic time to start a new project, or update and get proper support for your existing ones. That is why we are offering a 20% discount on support for NTLM + cURL users this June.

cURL is a computer software project providing a library for transferring data using various protocols. These protocols include (but are not limited to) FTP, FTPS, HTTP, HTTPS, and more. This version of the cURL library is nearly identical to the original library, except for a major difference: it is available for dual-licensing like many of the other wolfSSL products. Additionally, wolfSSL provides commercial curl support as well as support for wolfCrypt FIPS and FIPS ready.

NTLM authentication is a family of authentication protocols that are encompassed in the Windows Msv1_0.dll. The NTLM authentication protocols include LAN Manager version 1 and 2, and NTLM version 1 and 2. The NTLM authentication protocols authenticate users and computers based on a challenge/response mechanism that proves to a server or domain controller that a user knows the password associated with an account.

Contact us at to take advantage of this offer!

Upcoming Webinar: wolfBoot

Don’t miss this hot topic next week! wolfSSL Engineer Daniele Lacamera presents:

Wednesday, June 24th 2020 at 10AM Pacific time (GMT-8)
Register here:

Trusted firmware updates have become a requirement for IoT projects.

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. You probably already know this. But what don’t you know about the best secure boot loader on the market?

wolfBoot provides reliable support to remote firmware updates on a wide range of devices, supporting the most common architectures. wolfBoot supports all types of RTOS and embedded operating systems. Bring questions and roadmap items to this presentation on all things wolfBoot!

We can’t wait for you to join us!

After registering, you will receive a confirmation email containing information about joining the webinar.

What questions do you have around wolfBoot? Daniele Lacamera has answers. Email us at with any questions.

wolfSSL DTLS 1.2 Secure Renegotiation

wolfSSL has added support for secure renegotiation in DTLS 1.2 as defined in RFC 5746. Secure renegotiation is an extension to (D)TLS 1.2 which fixes the vulnerability found in the original specification. Previously, a third party could use renegotiation to inject malicious data preceding valid data from the client. This could be accomplished by establishing a (D)TLS connection with the target server and sending data over this connection. The third party can then intercept a handshake initiation attempt from the client and send this over its already established connection to trigger a renegotiation. The client’s connection is then established over the third party’s connection. From the perspective of the server the client sent data and then initiated a renegotiation. This is dangerous as the application layer could interpret this as a single valid stream of data causing the malicious traffic to be used in the context of the client’s valid traffic.

RFC 5746 (D)TLS Renegotiation Indication Extension creates a cryptographic binding between the renegotiation and the underlying (D)TLS to disallow a man in the middle attack on the secure connection. In a secure renegotiation, the client and server dismiss an invalid renegotiation attempt.

(D)TLS secure renegotiation may be used for example to establish new cryptographic parameters to increase security. It may also be used to request a certificate from the other party to require authentication before completing some action in the application layer.

To use secure renegotiation in wolfSSL use the “–enable-secure-renegotiation” configure option. For more build options refer to the second chapter of the wolfSSL User Manual.

The wolfSSL DTLS 1.2 secure renegotiation implementation is also compatible with our asynchronous module! Use hardware acceleration and don’t wait on pending cryptographic operations! If you have any questions, contact us at

Treck Vulnerabilities

Recently the Treck ( TCP stack has had some notable vulnerabilities reported. Though this TCP stack is not a part of the wolfSSL software, it is an embedded TCP stack, and we would like to help with notifying the embedded community that if you are using the Treck TCP stack then it should be updated. Attacks from these reports can range anywhere from a denial of service to leaking information. Further reading about the report can be found at the CERT coordinating center site here:

For questions about integrating wolfSSL into your product for SSL/TLS and cryptography, contact us at  wolfSSL supports TLS 1.3, FIPS 140, DO-178, and more!

New Edwards Curve Algorithms: X448 and Ed448

wolfSSL 4.4.0 introduces new high security elliptic curve algorithms: X448 and Ed448. These algorithms are specified for TLS – RFC 8446 and RFC 8442 – and in NIST drafts FIPS 186-5 and SP 800-186.

These high security algorithms are not only fast but also small – 10KB for the optimised X448 C code on Intel x64! And it’s faster than OpenSSL:

AlgorithmOperationwolfSSL COpenSSL 1.1.1c
ECDH X448Key Gen6409
ECDH X448Key Agree64492635
ECDSA ED448Sign145914339
ECDSA ED448Verify52902388

wolfSSL is nearly two and half times faster than OpenSSL when performing key agreement, three and a third times faster for signing and over two times faster when verifying!

Curve448 is great choice for applications where code size matters; especially compared to P-384:

AlgorithmOperationwolfSSL C Curve448wolfSSL C P-384OpenSSL 1.1.1c P-384
ECDH X448Key Gen64098505
ECDH X448Key Agree644931211455
ECDSA ED448Sign1459143391391
ECDSA ED448Verify529023881842

Curve448 can be used in TLS 1.2 and 1.3 for key exchange and certificates.

Do you need higher security or is code size important? Then you must consider using X448 and Ed448 for your public key operations from wolfSSL!

If you have any questions about the wolfSSL embedded SSL/TLS library or X448/Ed448, contact us today at

wolfSSL ARM mbed-os Port

With every release of the wolfSSL embedded SSL/TLS library, there are multiple feature additions, port additions, and updates. One of the ports that was added to the wolfSSL library recently was a port to ARM mbed-os! You can checkout the changes for mbed-os port in PR #12997 the ARMmbed/mbed-os github repository ( . While you’re there we would greatly appreciate it if you could “react” to the PR.

Arm Mbed OS is a free, open-source embedded operating system designed specifically for the “things” in the Internet of Things. Mbed OS provides the Mbed C/C++ software platform and tools for creating microcontroller firmware that runs on IoT devices. It consists of the core libraries that provide the microcontroller peripheral drivers, networking, RTOS and runtime environment, build tools and test and debug scripts. These connections can be secured by compatible SSL/TLS libraries such as wolfSSL, which supports mbed-rtos.

A very important note to make here is that we are the source of TLS 1.3 and FIPS Ready and a whole world of hardware encryption support for MBED OS! (not mbedTLS)

The list of reasons to use wolfSSL vs mbedTLS is very long, but here are a few:

  • Reduced code size
  • Commercial grade production TLS / Crypto library
  • FIPS 140-2 certification
  • Supported by original engineers (
  • Designed for embedded use
  • Performance is better and can be increased further (see ENABLE_WOLF_SPEEDUPS).
  • Fastest vulnerability response time in the industry.
  • TLS v1.3 (can be enabled in mbed-os/blob/wolf/features/wolf/user_settings.h using WOLFSSL_TLS13)
  • Progressive algorithms (SHA3, Curve/ED448, Curve/ED25519, etc…)

If you have any questions about using wolfSSL with MBED OS, or using wolfSSL on your platform, contact us at

Posts navigation

1 2