RECENT BLOG NEWS

A little while ago we announced support for post-quantum KEM groups and then hybrid groups. We are now proud to announce support for the PQC NIST round 3 finalist signature scheme FALCON. With this announcement, customers can now experiment with fully quantum-safe TLS 1.3 handshakes.

From a high level perspective, for every TLS 1.3 connection, authentication and confidentiality are the two main goals that protect each connection. Authentication is maintained via signature schemes such as ECDSA. Confidentiality is maintained by key establishment algorithms such as ECDHE and then using the established key with symmetric encryption algorithms such AES to encrypt a communication stream. We can thus decompose the security of the TLS 1.3 protocol into 3 types of cryptographic algorithms:

– authentication algorithms
– key establishment algorithms
– symmetric cipher algorithms

When a cryptographically relevant quantum computer is finally developed, Shor’s algorithm completely breaks the security of modern authentication and key establishment algorithms while Grover’s algorithm reduces the security of modern symmetric cipher algorithms by half. So, we must replace our modern authentication and key establishment algorithms with quantum-safe ones and double the strength of our symmetric cipher algorithms to maintain the security of our communications.

Now that wolfSSL has integrated FALCON, we can use it for authentication. We can use any one of our new KEMs and just in case, we can hybridize it with NIST-approved ECDSA groups. And finally, since the strength of AES-128 is generally accepted to be sufficient, we can double our strength by using AES-256 by using the AES_256_GCM_SHA384 TLS 1.3 ciphersuite. To get a connection that has such a handshake, you would run the following commands:

$ examples/server/server -v 4 -l TLS_AES_256_GCM_SHA384 \ 
 -A certs/falcon_level5_root_cert.pem \ 
 -c certs/falcon_level5_server_cert.pem \ 
 -k certs/falcon_level5_server_key.pem \ 
 --oqs P521_KYBER_LEVEL5 
 
 $ examples/client/client -v 4 -l TLS_AES_256_GCM_SHA384 \ 
 -A certs/falcon_level5_root_cert.pem \ 
 -c certs/falcon_level5_cleint_cert.pem \ 
 -k certs/falcon_level5_client_key.pem \ 
 --oqs P521_KYBER_LEVEL5 

You can then use a modified wireshark that recognizes our algorithms to monitor the connection and see what is really going over the wire:

The merge request for the wireshark modifications can be found here:
https://gitlab.com/wireshark/wireshark/-/merge_requests/4924/

The pull request for instructions for making a docker image with the wireshark modifications can be found here:

https://github.com/open-quantum-safe/oqs-demos/pull/104

The integration of FALCON has made it onto our wolfSSL master branch, and will be part of the next release of wolfSSL.

One last word on the threat model and why it is important to consider post-quantum authentication sooner rather than later. Due to your application parameters or use case, it might not be cost effective or even possible to update software components. In these cases, you must carefully evaluate the lifetime of your product. If you project that we will see a cryptographically relevant quantum computer within the lifetime of your product, but it can’t be updated, then perhaps you need to start thinking about a strategy for moving to post-quantum algorithms today.

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

• Improve FALL_THROUGH macro logic for XC32. (PR #227)
• Fix potential NULL printf in MqttSocket_Connect with verbose debug enabled. (PR #229)
• Fix non-block chunked transfer. (PR #230)
• Fix QoS responses (PR #231, 240)
• Fix MQTTv5 property handling (PR #232, 233, 234, 236, 238, 241)
• Fix fuzzing test issues (PR #242)

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

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

The main difference is DTLS uses UDP and TLS uses TCP. DTLS stands for Datagram Transport Layer Security and is a communications protocol designed to protect data privacy and prevent eavesdropping/tampering. It is based on TLS protocol and used across web browsing, mail, and instant messaging.

Using the DTLS library of wolfSSL, sensor data is protected all the way from the client to the gateway, and then from the gateway on to the broker using standard TLS.

You can download our latest wolfSSL release here: https://www.wolfssl.com/download/

Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfssl

While you’re there, show us some love and give the wolfSSL project a Star!

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 embedded SSL/TLS library has maintained support for the Cisco CJOSE library since version 4.4.0. CJOSE implements Javascript Object Signing and Encryption (JOSE) in C/C++. JOSE is a framework that allows parties to exchange transfer claims in a secure way. The CJOSE library has been ported to work with wolfSSL, the best tested crypto library on the market.

To build wolfSSL for CJOSE:

• ./configure --enable-opensslall --enable-aeskeywrap CPPFLAGS='-DHAVE_EX_DATA -DWOLFSSL_KEY_GEN'
• make
• make install

To build CJOSE for wolfSSL:

• Download the appropriate patch from https://github.com/wolfSSL/osp/tree/master/cjose. Choose a patch that corresponds or is closest to your version of cjose.
• patch -p1 < <path/to/downloaded/patch>
• autoreconf
• ./configure --with-wolfssl=/usr/local
• make

To verify that this build passes the tests, run:

• make check

wolfSSL currently supports CJOSE version 0.6.1, the most recent release. For details on CJOSE, visit https://github.com/cisco/cjose.
This feature has been added in commit 0cfde0794b9c5ab1c01171745b800140ee4f8662.

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

Because of the exceptional portability of our wolfCrypt library, plus our fantastic team of engineers, we’re able to frequently add new ports. We’ll continue showcasing a few of the latest open-source project ports over the next few weeks!

wolfSSL has been integrated with the OpenLDAP project, which is one of the most popular open-source implementations of LDAP. LDAP (Lightweight Directory Access Protocol) is an industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. OpenLDAP is command-line driven software that allows IT admins to build and manage an LDAP directory. For more information on LDAP and OpenLDAP, visit Introduction to OpenLDAP Directory Services. 

This port allows for the use of OpenLDAP with our FIPS-validated crypto library, wolfCrypt. We’ve enabled OpenLDAP 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/openldap

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.

wolfSSL is implementing MIKEY-SAKKE!

MIKEY-SAKKE is a standard created by the UK government’s National Cyber Security Center (NCSC) designed to enable secure, cross-platform multimedia communications. It is highly scalable, requiring no prior setup between users or distribution of user certificates. It is designed to be centrally-managed, giving a domain manager full control of the security of the system. Even so, it maintains high availability, as calling does not require interaction with centralized architecture.

wolfSSL is a lightweight TLS/SSL library that is targeted for embedded devices and systems. It has support for the TLS 1.3 protocol, which is a secure protocol for transporting data between devices and across the Internet. In addition, wolfSSL uses the wolfCrypt encryption library to handle its data encryption.

Secure communications are needed across all governments, so governments create policies encouraging the development of security solutions. MIKEY-SAKKE is the answer to the security requirements from the UK government to specify secure, open, and patent-free cryptographic methods. This empowers private industry to provide the government with interoperable secure communication solutions. As a result, many private and commercial organizations perceive a sizable advantage to being MIKEY-SAKKE compliant.

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 there is a desire for wolfSSL to include other cybersecurity standards, please let us know!

Where do you see crypto heading in the next 10 years? What’s currently on wolfSSL’s roadmap?

Post-Quantum Computing (PQC) cryptographic algorithms are the biggest thing on our radar (See our updates on post-quantum wolfSSH and post-quantum cURL!). We have started with adding the Key Exchange algorithms from liboqs into our TLS implementation, as well as working on an optimized implementation of NTRU. wolfSSL now supports the round 3 finalist KEM algorithms of the NIST PQC competition which are appropriate for TLS 1.3. This means that everyone can experiment with the new up and coming algorithms that will be standardized.

Signatures are more of a problem in the context of TLS, since the CA infrastructure needs to be updated to issue certificates using the PQC algorithms before they can be used.

At the moment, it seems as though all the post-quantum algorithms have disadvantages that make it difficult to drop one in without impact. Some are too slow, while others require too much data to be sent over the wire. Embedded is even harder!

DTLS 1.3 is also on our roadmap further down the line – the specification is done but not published as an RFC yet.

Advice for people who are looking to build security apps or develop secure networking processes?

• Use TLS 1.3.  All major browsers, and 47.8% of the most popular web sites, support TLS 1.3.
• Use well known algorithms like AES-GCM, SHA-2, (EC)DH, RSA and ECDSA.
• Use secure, well supported protocols like TLS 1.2 and TLS 1.3, and DTLS 1.2.
• Be prepared to change to new PQC secure algorithms. Quantum computers aren’t possible yet, but when they are, attackers can go back and decrypt old messages.
• Be prepared to sign with two signatures, first with an existing algorithm like RSA or ECDSA, and secondly with a new PQC secure algorithm. The first signature can be verified quickly right now, and the second later, if and when quantum computers come online.
• Keep your private keys safe – in hardware where possible.

For more, check out our interview with ExpressVPN!

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 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.

Quality assurance

The first verification for the functionality of the code is performed locally, on the development PC of the contributor. Git commit and push hooks ensure that the code can be submitted only if it passes a first set of functionality and unit tests. Once the pull request is published, a full round of non-regression and integration tests are automatically started and the status of the pull request is updated with the test results. In order for the pull request to be accepted for inclusion, it must pass the peer review and the non-regression and integration tests. The tests are automatically retriggered during the review process every time that the code for the pull request is modified.

Quality control automation

At wolfSSL we have deployed an hybrid (on-site + cloud based) infrastructure, using Jenkins to coordinate the workload between the nodes to apply quality control on a regular basis. This includes the execution of software tests every time a contribution is evaluated for inclusion in the mainline, as well as other types of quality control applied on a regular basis (e.g. nightly, weekly).

The reason behind the hybrid approach is due to the portability trait of the wolfSSL software ecosystem. The software must run on several different hardware architectures, and interoperate with specific hardware components, such as hardware crypto modules and TPMs. Using physical machines on some of the jenkins nodes provides mechanisms to configure and control specific hardware targets, including microcontroller boards that can be configured and programmed automatically.

Some tests require a long time to run. Continuous integration tools are very useful to split the application of the quality control jobs over a longer time, to ensure that every test is performed on a regular basis.

Formal algorithms and modules verification

In order to validate the correctness and the adherence to the standards implemented, wolfSSL software components are tested using tools and procedures recommended by NIST. This includes a full set of functional tests using a set of well-known input values (test vectors) and expected results. The correctness of many cryptographic algorithms can also be verified by inspecting the intermediate results of the calculations. 

NIST also issues a series of publications (FIPS 140) coordinating the requirements and standards for cryptographic modules for use by departments and agencies of the federal Government. Through the effort of specialized accredited third-party laboratories across the U.S. and Canada, two validation programs are made available to certify the compliance with the FIPS 140 regulations. wolfCrypt has achieved the FIPS 140-2 certification, and has already applied for the recently approved FIPS 140-3 certificate. FIPS certification requires that the cryptographic module is successfully submitted through the validation of the two programs:

• Cryptographic Algorithm Validation Program (CAVP) provides validation testing of approved cryptographic algorithms implemented.
• Cryptographic Module Validation Program (CMVP) certifies the module for use by the Government and regulated industries for securing sensitive data and information. 

The same types of tests used in CAVP/CMVP are repeated on the mainline automatically, to ensure that modifications in the code do not impact on the integrity of the algorithms and the modules as specified by FIPS 140.

Interoperability tests

One very effective way of verifying that the behavior of the protocols remains the same throughout the continuous integration, is by running interoperability tests with different implementations of the same standards. WolfSSL quality control infrastructure provides a number of scheduled tests that use a different implementation as the remote endpoint of the communication, and to compare results of cryptography operations starting from common vectors.

Unit tests

Unit tests are mandatory for all core modules, and run on the developer’s machine upon new commits.

The coverage of the unit tests is measured on a weekly basis, to ensure that there are no coverage regressions when adding new functionality to the code. WolfSSL developers receive a full code coverage report in their mailboxes every week thanks to the automation provided by the Jenkins infrastructure for continuous integration.

API consistency verification

One specific set of tests verifies that changes in the implementation do not alter the usage of the API from the application development perspective. These tests are never updated, with the only exception of adding new functions to the API. The API must remain consistent across versions, as it is the contract between the application and the library. Verifying all these aspects is the goal of the subset of tests that are running nightly to verify the adherence to the requirements.

Integration tests

Due to wolfSSL portability, it is necessary to expand the test domain by including custom configurations, which require to compile the software for different architectures and combination of compile-time configuration options and test applications. Both real and virtual machines are used as targets for running the test suite. Automating the tests on different architectures (x86, ARM, PowerPC, RISC-V, MIPS, …) ensures that architecture-specific regressions or bugs can be detected and identified early during the process, and the expected behavior remains consistent in all cases. Thanks to the hybrid model of our continuous integration infrastructure, several targets are connected to Jenkins nodes that are in charge of running the software tests through a wide range of specific hardware and software configurations and use cases.

Safety assessment: looking under the hood

The continuous integration infrastructure also automates the execution of several analysis tools. 

Static analysis tools look for any inconsistency in the code exploring all the different combinations of compile-time options, and following different code paths. These tools can detect a wide range of programming mistakes, potential errors, and undefined behaviors in the language that may not be covered by the compiler, by applying rigorous checks at the source code level. The tools used by wolfSSL and automated in the CI include cppcheck, clang static analyzer (scan-build), Facebook infer and others.

Memory analysis is performed on a regular basis to look for bugs related to memory handling. WolfSSL uses valgrind memcheck tool, clang sanitizer and other dynamic analysis to run the code. These tools detect memory errors such as accessing uninitialized or previously freed memory, using undefined or uninitialized values, memory leaks and more.

Fuzzers are a very important resource to improve the robustness of the code towards unexpected situations. The goal of these tools is to attempt to cause malfunctions in the code by injecting a large number of random inputs in quick succession. Fuzzing is often a very effective way to detect bugs and vulnerabilities in the code that could go unnoticed for a long time. At wolfSSL we constantly run fuzzers to feed the API functions and the transport back-end, periodically rotating all the possible seed values for the PRNG regulating the output values mutation.  With mutation-fuzzing, a bug that is triggered with a given seed value can be reproduced by relaunching the same test with the same seed value manually, allowing for easy reproducibility and analysis through instruments and debuggers. Since these kind of tools must be aware of the application domain, the protocol structures and the characteristics of the data, wolfSSL uses two main fuzzers that have been written for the purpose. WolfFuzz operates over memory buffers and fuzzes the internal cryptography operations. This mechanism allows very fast fuzzing and the entire range of 4 trillion PRNG seeds is tested in three months. A second tool, wolfSSL Network Fuzzer, runs over TCP/IP. For this reason it is much slower but more flexible to test the code that enables security for data in motion.

Vulnerability management

At wolfSSL we take vulnerabilities very seriously, and we are committed to release a new version of the software within 36h from the disclosure. This ensures that, in case of responsible disclosure, the vulnerability is fixed way before its details or any proof of concept to reproduce are made public.

A vulnerability claim triggers emergency procedures, consisting in a Standard Operating Procedure (S.O.P.)  that has to be completed to speed up the resolution of the issue and the release of a new version. The vulnerability claim is verified within the first 120 minutes. In this phase, a document is created to be distributed internally to the engineering team, to document the issue and all available instruments along with instructions on how to reproduce it so that the error can be confirmed and the proposed fix can also be assessed to determine if the issue has been addressed completely. The fix may take between a few minutes up to 24h, depending on the complexity of the issue. When the fix is ready it is submitted either in the form of a internal patch or a public pull request when it has been determined that the fix will not leak critical information to would-be attackers that monitor the wolfSSL git repository. The path or public PR is then reviewed by multiple engineers, since code changes are still validated through both manual code reviews and the test procedures. After a few iterations in the review process loop, the automated integration server verifies the fix by running all the necessary pre-release tests. At the end of the verifications, if all the test passed, a new release is issued,  and all users and customers are notified through all available communication channels.

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.