Month: March 2022

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.

Hardware Security Module (HSM)

A hardware security module (HSM) is a physical computing device that protects digital key management and key exchange, and performs encryption operations for digital signatures, authentication and other cryptographic functions. It can be thought of as a “trusted” network computer for performing cryptographic operations. A HSM is secure because it:

• Is built on top of well-tested, lab certified hardware.
• Has a security-focused OS.
• Has limited access via a network interface controlled by internal rules.
• Actively hides and protects cryptographic material.

HSMs may have tamper evidence features such as visible signs of tampering, tamper resistance where tampering makes the HSM inoperable, or tamper responsiveness such as deleting keys upon tamper detection. Many HSM systems have secure backup systems, which allows keys to be backed up and stored on a computer disk or externally using a secure portable device. HSMs are usually certified to internationally recognized standards, such as FIPS 140, to provide independent assurance of sound design and implementation.

The best way of protecting trust anchors and other cryptographic material is using a hardware component that is designed for this purpose. Hardware security modules (HSM, TPM, etc.) usually offer both key storage and cryptographic operation acceleration in the same module. wolfSSL supports the NXP CAAM hardware, which offers the same functions as HSM, but built into i.MX silicon. For more information, visit our blog about NXP CAAM.

wolfCrypt, our crypto engine that powers wolfBoot, supports all possible schemes from a wide range of manufacturer-specific API to access this functionality, such as Microchip ATECC608, ARM CryptoCell, NXP CAU/mmCAU/LTC, STMicroelectronic PKA, and many others.

wolfSSL also supports PKCS#11, a HSM standard that defines an API for using cryptographic tokens. Using wolfSSL on your application or your device will now allow you to utilize PKCS#11 for access to hardware security modules, smart cards, and other cryptographic tokens.

Trusted Platform Module (TPM)

Trusted Platform Module (TPM) is an international standard for a secure cryptoprocessor – a special microcontroller designed to secure hardware through integrated cryptographic keys. This microcontroller interfaces with a standard hardware/software platform to be secured to serve the interests of the system designer alone. TPM can also refer to a chip conforming to the standard. The standard was designed by the Trusted Computing Group, and TPM 2.0 is the most recent edition of the standard. 

TPM is used to:

• Securely create, store, and limit the use of cryptographic keys.
• Authenticate platform devices and encrypt data using the TPM’s unique RSA bind key.
• Ensure platform integrity by storing security and system integrity measurements.
• Create a nearly unforgeable hash key summary of the hardware and software configuration, which allows a third party to verify that the software has not been changed, called remote attestation.
• Generate random numbers from hardware.

TPM technology is now available for embedded systems thanks to wolfTPM, a library providing APIs to access TPM 2.0 compatible secure element, and the only TPM 2.0 library designed for bare metal and embedded systems. It also has native Windows and Linux support, alongside a TPM simulator for rapid development and testing. Popular TPM devices supported by wolfTPM include the ST33 and the Infineon 9670. Due to wolfTPM’s portability, it is generally very easy to compile on new platforms. For more information, visit the wolfTPM product page!

Secure Enclave

Secure enclaves are becoming a popular way to separate and protect sensitive code and data from other processes running on a system. Two popular secure enclaves are SGX and TrustZone, both of which can be used in securing trusted execution environments.

A trusted execution environment (TEE) is a secure area of a main processor which guarantees confidentiality and integrity of code and data loaded inside. A TEE as an isolated execution environment provides security features such as isolated execution, integrity of applications executing with the TEE, along with confidentiality of their assets.

Intel Software Guard Extensions (SGX) are a set of security-related instruction codes that are built into some modern Intel CPUs. SGX allows user-level and operating system code to define enclaves – private regions of memory whose contents are protected and unable to be either read or saved by any outside process. SGX involves encryption by the CPU of a portion of memory and protects data via application isolation technology. In cryptography, SGX can be used to conceal proprietary algorithms and encryption keys. 

SGXs can be thought of as a black-box where no other application running on the same device can see inside regardless of privilege. From a security standpoint, this means that even if a malicious actor were to gain complete control of a system including root privileges, that actor would not be able to access data inside of this “black-box”. An Intel enclave is a form of user-level TEE which can provide both storage and execution – users can store sensitive information, as well as move sensitive portions of a program or an entire application inside.

The wolfCrypt FIPS validated cryptographic module has been validated while running inside an Intel SGX enclave and examples have been set up for both Linux and Windows environments. For more information, visit our blog post on wolfSSL and Intel SGX. 

Arm TrustZone technology offers an efficient, system-wide approach to security with hardware-enforced isolation built into the CPU. It provides the perfect starting point for establishing a device root of trust based on Platform Security Architecture (PSA) guidelines. TrustZone is used on billions of application processors to protect high-value code and data for diverse use cases including authentication, payment, content protection and enterprise. On application processors, TrustZone is frequently used to provide a security boundary for a GlobalPlatform Trusted Execution Environment.

wolfBoot provides support for secure boot on systems with a TEE. wolfBoot provides embedded developers with a code base that complies with the specification for the separation between secure and non-secure world, on those CPUs and microcontrollers that support it. On ARMv8 Cortex-A CPU and Cortex-M microcontrollers it is now possible to create a hardware-enforced separation between the two worlds, using the ARM TrustZone technology. For more information, read our blog post on wolfBoot support for ARM TrustZone. 

Secure Element/Hardware Root of Trust

Hardware root of trust prevents simulation of hardware with user-controlled software, using a set of private keys used for cryptographic functions that are embedded directly into the chip during manufacturing. These keys cannot be changed, even after device resets, and have public counterparts kept in a manufacturer database. The public key is used to verify a digital signature of trusted vendor-controlled firmware (such as secure enclaves in SGX), which is then used in remote attestation.

Hardware root of trust also enables a secure boot process, using hardware that makes it immune from malware attacks. It can be used on its own or implemented as a security module within a processor or a system on chip (SoC).

Secure element refers to secure solutions like STSAFE, ATECC608, and hardware roots of trust without the standard TPM interface. Secure elements are unique in terms of interface.

A secure element is a tamper-resistant hardware platform, capable of securely hosting applications and storing confidential and cryptographic data. It provides a highly-secure environment that protects user credentials. Secure element features include:

• Detection of hacking and modification attempts
• Creation of a Root of Trust (RoT) platform for encryption systems
• Secure memory for storing private encryption keys and other sensitive information
• Secure random number generation
• Generation of encryption keys

The wolfTPM library provides APIs to access TPM 2.0 compatible secure elements. 

Conclusion

HSM, TPM, Secure Enclave, and Secure Element/Hardware Root of Trust all have the same function, which is to securely store keys, and securely execute cryptographic operations. The difference is that they’re all uniquely named. wolfSSL provides products that support all different schemes to best fit your cryptographic needs!

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

Love it? Star us on GitHub!