RECENT BLOG NEWS

The wolfSSL ecosystem consists of several software modules and components, each with specific goals and purposes. We make sure all our software products are engineered using the quality standards required by our process.

Each step in the software lifetime is regulated by strict rules and testing criteria (including stringent fuzz based testing) that ensure the detection of defects and regressions in the code very early.

Software engineering process overview

From a software engineering standpoint, the life cycle of the design and development of wolfSSL software components is structured in three steps:

• Identification and analysis of software requirements and specifications
• API-oriented software design
• Software module development

Each step is then verified through a specific set of quality control procedures, including:

• Unit tests and periodic coverage analysis
• API consistency tests
• Integration tests on multiple architectures/compilers and use cases/combinations of compile time configuration options
• Interoperability tests against other implementations
• Formal algorithm and module verifications
• Fuzz testing

In order to improve the safety of the code, and in order to detect potential defects or misbehaviors, additional quality controls are regularly applied to the software modules, in particular tools like static analyzers, dynamic memory diagnostic tools, fuzzers and more, being added all the time.

Distributing the source code under a GPL license and exposing the entire development process publicly on the GitHub platform guarantees that hundreds of users, contributors and people interested in the project are constantly aware about every change in the code, and the conversations generated during code reviews. Corporate security organizations, cybersecurity partners and academic researchers give very valuable contributions by constantly studying new vulnerabilities and carefully exploring the potential attack surfaces that may be harder to identify while writing the code. wolfSSL Inc. takes vulnerability management very seriously and has a precise and detailed checklists to run in case of emergency fix and rapid release.

Due to the constantly changing nature of the specifications, the software design process must be flexible enough to accommodate updates in the algorithm implementation, the usage recommendations and the guidelines to implement secure protocols and mechanisms.

NIST distributes specifications and guidelines through “Special Publications” (SP). Through its collaboration of industry organizations, government agencies and academic institutions the National Cybersecurity Center of Excellence (NCCoE) as part of NIST. Similarly to IETF publications, the approach of NIST consists in releasing frequent updates and amendments to earlier publications, in order to keep the guidelines updated. The process of updating the guidelines within NIST is regulated by the “NIST Cryptographic standards and guidelines development process” (NIST.IR.7977). Cryptographic functions in wolfCrypt follow the latest specifications from NIST regarding algorithms and their implementation process. As explained later, NIST publications and software tools play an important role in the algorithms and modules verification phase.

WolfMQTT is implemented upon the specifications provided by OASIS, initially covering  MQTT version 3.1.1 approved in December 2015. WolfMQTT has since then evolved to support the specifications in OASIS MQTT Version 5.0, approved as the latest MQTT standard in March 2019.

Software requirements and specifications

The guidelines for the implementation of cryptography, secure communication protocols and secure firmware updates mechanisms are described by open standards. These standards are maintained and documented by several organizations. WolfSSL software projects import specification documents from three major organizations, namely:

• IETF, the Internet Engineering Task Force, a large open international community of engineers, in charge of publishing and updating the documentation for the Internet protocols stack, which nowadays also includes secure communication protocols and algorithms used in ciphersuites
• NIST, the United States National Institute of Standards and Technology, providing guidelines for processes, modules and algorithms, recognized globally as best-practices in cryptography 
• OASIS, the Organization for the Advancement of Structured Information Standards, a global nonprofit consortium that works on the development of open standards for the IoT and data exchange

IETF releases new specifications in the form of “Request for Comments” (RFC). These are individually numbered publications which are published after a peer review process, which often requires multiple draft phases. Once a RFC is assigned its unique number, it is never modified again. In order to update a standard track that has been published in a RFC, it is possible to issue a new RFC that may contain amendments, corrections or replacing of existing RFCs that were previously published. Newer RFCs can supersede older ones by making them obsolete or deprecated. RFCs cover the specifications for a large part of wolfSSL communication modules, such as the TLS protocol standard (RFC8446), DTLS (RFC6347), TLS extensions (RFC6066) and several others. The wolfCrypt library follows the recommendations for the implementation of the cryptographic primitives based on the algorithms supported, such as RSA  public-key cryptography (RFC8017), or the ChaCha20/Poly1305 for AEAD (RFC8439) and many others. WolfSSH has been designed and developed upon the specifications of the RFC4250-RFC4254 series, documenting SSH-2 as proposed internet standard. WolfBoot has been initially designed and developed according to the guidelines of the draft-ietf-suit-architecture, which later on became RFC9019.

Software design

Most of the software components developed by wolfSSL are in the form of a structured library, with an API oriented design. Once functions are part of the API they will never change their signature, their purpose or the meaning of their return values. This ensures compatibility across different versions of the library. If a feature is added to an existing functionality, a new API function is created, which accepts different arguments, or extends specific interfaces. The API function calls are formally documented in the module user manual.

One of the most important aspects to keep in mind during the design phase is the correct meaning, propagation and verification of the error codes across the different layers of the API. Each error code has unique and well-defined meanings that are explained in the manual. This facilitates the identification of run-time errors in the application using the library.

Due to the dynamic, changing nature of the specifications around cryptography and secure protocols, the design process must adapt accordingly. New specifications are analyzed and integrated in the existing module architecture, ensuring that this does not break existing features by keeping the existing API function signatures immutable in time.  

Software development and traceability

All software at wolfSSL is developed and maintained following the continuous integration practice, via a centralized git mainline repository. All source code is public and accessible at any time during the development, under a GPL license. 

The life-cycle of software components in the wolfSSL ecosystem is different from the typical open-source development process, and it is designed to comply with modified condition decision coverage (MC/DC) process. WolfSSL owns and maintains the entire code base, which means that there are strict rules in place regarding changes and updates of the mainline. Modifications to the repositories are only allowed by wolfSSL engineers, who also have to comply with a strict peer-review policy before any change is merged into the master branch.

To contribute to wolfSSL repositories, a developer must submit a “pull request” through GitHub. The request is then reviewed by one or more wolfSSL engineers (depending on the size, the impact and the nature of the patch). This often results in requests for alignment with the purposes in the design documents, changes in the code, re-adaptations and improvements before the code is accepted for merging. Only approved contributors are allowed to submit their code to review. Contributors outside the wolfSSL engineering team must be approved beforehand before the code is considered for inclusion.

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

Thanks to the portability of our wolfCrypt library, plus our team of expert engineers, wolfSSL is frequently adding new ports. Keep an eye out as we continue showcasing a few of the latest open source project ports over the next few weeks!

We have recently integrated wolfSSL with the socat tool for Linux. This port allows for the use of socat with our FIPS-validated crypto library, wolfCrypt. Socat is a command line based utility that allows for bidirectional data transfers between two independent channels. For more information on socat, please visit the project’s website at www.dest-unreach.org/socat. 

As of wolfSSL version 4.8.0, we have enabled socat to be able to call into wolfSSL through the OpenSSL compatibility layer. You can access the GitHub page here: https://github.com/wolfSSL/osp/tree/master/socat

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!

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 wolfSSL library is now safe against the “Harvest Now, Decrypt Later” post-quantum threat model with the addition of our new TLS 1.3 post-quantum groups. But where does that leave wolfSSH? It is still only using RSA and elliptic curve key exchange algorithms which are vulnerable to the threat model mentioned above.

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 Linux kernel module support has grown by leaps and bounds, with new support for public key (PK) cryptographic acceleration, FIPS 140-3, accelerated crypto in IRQ handlers, portability improvements, and overall feature completeness.

The module provides the entire libwolfssl API natively to other kernel modules, allowing fully kernel-resident TLS/DTLS endpoints with in-kernel handshaking.  Configuration and building is turnkey via the --enable-linuxkm option, and can optionally be configured for cryptographic self-test at load time (POST), including full FIPS 140-3 core hash integrity verification and self-test.

As with library builds, the kernel module can be configured in detail to meet application requirements, while staying within target capabilities and limitations.  In particular, developers can opt to link in only the wolfCrypt suite of low level cryptographic algorithms, or can include the full TLS protocol stack with TLS 1.3 support.

For PK operations, the kernel module leverages our new function-complete SP bignum implementation, featuring state of the art performance and side channel attack immunity.  AVX2 and AES-NI accelerations are available on x86, and are usable from both normal kernel threads and from interrupt handler contexts. When configured for AES-NI acceleration, the module delivers AES256-GCM encrypt/decrypt at better than 1 byte per cycle.

Kernel module builds of libwolfssl are supported in wolfSSL release 4.6 and newer, and are available in our mainline github repository, supporting the 3.x, 4.x, and 5.x Linux version lines on x86-64, with limited support for ARM and MIPS. Full FIPS 140-3 support on x86-64 will be available in the forthcoming wolfSSL Version 5.0 release.

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!

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

It came to our attention that OpenSSL just published two new vulnerabilities.

• CVE-2021-3711 – “SM2 decryption buffer overflow” (nakedsecurity)
• CVE-202103712 – “Read buffer overruns processing ASN.1 strings.” (nakedsecurity)

These were specific OpenSSL issues and do not affect wolfSSL. For a list of CVEs that apply to wolfSSL please watch the security page on our website here: https://www.wolfssl.com/docs/security-vulnerabilities/

We wanted to take this opportunity to remind our customers and users that wolfSSL is in no way related to OpenSSL. wolfSSL was written from the ground up and is a unique SSL/TLS implementation.

That being said, wolfSSL does support an OpenSSL compatibility layer allowing OpenSSL users to drop in wolfSSL but continue to use the most commonly found OpenSSL API’s after re-compiling their applications to link against wolfSSL.

One individual also pointed out the time delta between report and fix on the above CVEs and wolfSSL would like to remind our customers and users of how proud we are of our less than 48 hour delta between report and fix. For more on our response time and process regarding vulnerabilities check out https://www.wolfssl.com/everything-wanted-know-wolfssl-support-handles-vulnerability-reports-afraid-ask/

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

A quick followup to the post “wolfSSLs’ Proprietary ACVP client”.

wolfSSL Inc. is proud to announce a recent addition to the wolfCrypt FIPS cert 3389!

• CMSIS-RTOS2 v2.1.3 running on a Silicon Labs EFM32G (Giant Gecko) chipset with wolfCrypt v4.6.1

Testing and standup for the EFM32 Giant Gecko was done collaboratively between wolfSSL Inc. and one of wolfSSLs’ customers. wolfCrypt had not previously been ported to or run on an EFM32 device so this was an exciting opportunity to both test on an EFM32 for the first time and to take wolfCrypt, running on the EFM32, through FIPS certification!
If you have any questions about getting wolfCrypt or wolfSSL up and running on your EFM32 target, not only is it possible, it is possible with FIPS 140-2 (and soon FIPS 140-3) certification as well!

Other OE’s added since the original ACVP client post are:

• Linux 4.14 running on ARMv8 Cortex A53 with and without PAA (module version 4.5.4)
• Windows CE 6.0 running on ARM Cortex-A8 (module version 4.6.2)
• Linux 4.19 running on ARMv8 Cortex A53 with and without PAA (module version 4.5.4)

At the time of this posting wolfSSL has:

• 10 OE additions (1SUB) in coordination phase with the CMVP to be added to cert 3389
• 4 OE additions (1SUB) that have completed all testing and are ready to be submitted to the CMVP
• 5 OE additions (1SUB) actively in the testing process
• 1 OE addition (1SUB) in the queue to start

While the CMVP is no longer accepting 3SUB and 5SUB submissions for FIPS 140-2 (Cutoff date was 22 Sep 2021) wolfSSL Inc. continues to work on 1SUB OE additions. wolfSSL Inc. will continue to work on 1SUB OE additions to cert 3389 until 7 months before the expiration date of cert 3389.

wolfSSL Inc. was one of the first to submit for FIPS 140-3 and we expect to be one of the first to receive a 140-3 certificate. If you are looking for a commercial FIPS 140-3 solution, then look no further!

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

Recently, a lot of post-quantum activity has been happening here at WolfSSL.

First, we’ve simplified and unified our naming conventions for the variants of the post-quantum algorithms. We now refer to each variant by the algorithm submitter’s claimed NIST level. For example, what used to be referred to as  LIGHTSABER is now known as SABER_LEVEL1 in our command-line applications and APIs.

We are now working towards making cURL resistant to  “harvest now; decrypt later” attacks from a future quantum-enabled adversary.  This protection is important if you value confidentiality over the long term.  Do you know how long your data need to stay confidential?

This effort involves enabling the the use of the new post-quantum groups for TLS 1.3 in cURL when built with wolfSSL.  For more details, please have a look at the following pull request: https://github.com/curl/curl/pull/7728.  Once the GitHub pull request is merged, it will go into the next release of cURL.

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

Adding security to a connection comes at a cost. It takes a little time to perform the crypto operations and some memory gets used during the operations. Not all TLS implementations are equal … how much memory and how much time is lost depends on what TLS library is being used.

Recently OpenSSL came out with their 3.0.0 version and we did a quick collection of runtime memory used. Both to re-collect and make sure wolfSSL has not gotten any unexpected bloat and to check out what OpenSSL has done with their long awaited update. What we found surprised us. To run a simple, single TLS 1.2 connection OpenSSL 3.0.0 took up over 800 KiB of memory where wolfSSL 4.8.1 took up 37.4 KiB. This was collected using the very basic example TLS server from wolfssl-examples/tls/server-tls.c where the functions in it were changed to the OpenSSL versions (i.e. wolfSSL_new -> SSL_new), and changed to run a single connection instead of a loop. First linked to OpenSSL 3.0.0 then to wolfSSL 4.8.1. The memory used during the single connection was collected using Valgrind’s massif tool and then converted into a graph with massif-visualizer.

The memory usage difference between the two libraries is dramatic. A lot of the memory usage with OpenSSL 3.0.0 appears to be surrounding the startup/shutdown code but even when trimming that necessary portion of the runtime memory usage off, it takes over 100 KiB per connection versus wolfSSL’s 13.9 KiB per connection. This makes OpenSSL 3.0.0 difficult if not impossible to be used in some IoT devices and also requires more resources when scaled to large server use cases. Leading to more hardware required and more memory to handle the same number of connections (more $$$).

You may ask though, what about performance? wolfSSL has a SP version that has optimizations for the public key algorithms commonly used in TLS connections. To configure with the “small” version of these optimizations the build “./configure –enable-opensslextra –enable-sp-math-all=small –enable-sp=small” could be used. Recollecting memory usage with the same server-tls.c app linked to the sp small version of wolfSSL used 26.3 KiB. Even less memory than before because along with optimizations for speed some optimizations for memory are also turned on.

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