RECENT BLOG NEWS

Yocto and Buildroot are powerful solutions designed to manage the complexities of deploying embedded products. Unlike general-purpose distributions such as Ubuntu or Red Hat Enterprise Linux, these systems allow for highly targeted deployments tailored specifically for embedded devices.

General Functionality of Both:

• Compiling from Source: They both handle compiling the kernel, system libraries, bootloader, and user applications, doing everything that is needed for the target environment.
• Cross-Compilation: They allow builds on a host machine (often of a different architecture) to compile software for the target device’s architecture.
• Package Customization: They provide mechanisms to apply custom configuration files and patches, enabling modifications and optimizations of packages to suit specific needs more effectively

Yocto Specific Features:

• Meta-layers and Recipes: Yocto uses meta-layers and recipes (.bb files), which are maintained by the community and offer detailed configuration options, sourcing, and build specifications.
• Toolchain Building: Specializes in creating custom toolchains, enabling the development of environments specifically tailored for the hardware’s architecture and project requirements.
• Complexity and Flexibility: Yocto’s complexity allows for extensive flexibility, supporting multiple development streams and detailed configuration options, suitable for large-scale industrial applications.
• Community and Documentation: Yocto is supported by a vast network of developers and offers robust documentation for complex, industrial-scale deployments.
• Petalinux: Xilinx’s petalinux is based on a fork of Yocto, meaning that the recipes and layers can easily be reused.
• Security Features: Offers advanced security configurations ideal for high-security needs.

Buildroot Specific Features:

• Makefile-Based Build System: Utilizes .mk Makefiles and kconfig for a straightforward approach to managing the download, configuration, and compilation of packages.
• Simplicity by Design: Less resource-intensive and fewer dependencies make it ideal for smaller systems or projects where simplicity is a priority.
• Firmware Generator: Primarily focuses on generating a root filesystem image, streamlining the process to produce minimal and ready-to-deploy firmware.
• Performance Metrics: Known for quicker configuration and compilation, making it suitable for rapid prototyping and small-scale projects.
• Learning Curve and Ease of Use: Offers a simpler learning experience, making it accessible and straightforward for beginners.
• Long-term Maintenance and Updates: Its simplicity facilitates easier updates, while the straightforward nature allows for manual security updates.

By understanding the strengths and limitations of each system, developers can choose the most appropriate tool to create efficient and stable embedded systems. Whether your project demands the robust flexibility of Yocto or the streamlined simplicity of Buildroot, selecting the right tool is crucial for optimal performance and success.

Interested in building one of wolfSSL’s solutions like wolfCLU, wolfMQTT, wolfTPM, or wolfSSH with Yocto? Check out our Yocto layer meta-wolfssl!

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Watch our webinar, “Linux Kernel Module with FIPS 140-3.” The session will be led by wolfSSL Senior Software Engineer Daniel Pouzzner.

In this webinar, you’ll learn the fundamentals of how the wolfSSL Library functions as a Linux kernel module and explore advanced features, including how developers can utilize it with FIPS 140-3.

Check it out here: Linux Kernel Module with FIPS 140-3

wolfSSL is excited to announce that the Linux kernel module now supports kernel cryptosystem registration for AES-XTS, with a simple configure option, providing FIPS 140-3 AES-XTS with performance meeting or exceeding native in-tree performance.

Watch it now for this exclusive webinar and gain fundamental and advanced knowledge of using wolfSSL with the Linux kernel module. Stay updated on the latest features and advancements!

As always, our webinars will include Q&A sessions throughout. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

We’ve done a lot to enable post quantum cryptography in our products over the last 3 years. The list below outlines everything we have available, in open source, for users right now. If you see something on the list that you have questions about, or think there is some further enablement that we should do, please email us at facts@wolfSSL.com and share your thoughts.

wolfCrypt

We now have our own in house developed implementations of the following post-quantum algorithms:

• Kyber/ML-KEM
• LMS/HSS
• XMSS/XMSS^MT
• Dilithium/ML-DSA (Coming soon!!)

We will be implementing more over the coming months. These implementations live up to the wolfCrypt standards: Minimum code size, maximum performance, and ability to run on bare metal, RTOS, and standard environments.

wolfSSL

For TLS 1.3 and DTLS 1.3, we know from Grover’s algorithm that the symmetric ciphers lose about half their security in the presence of a Cryptographically Relevant Quantum Computer (CRQC). Typically, AES-128 is considered sufficient. As such, if you want to preserve that level of security, simply move to AES-256 which is easy because we already support TLS_AES_256_GCM_SHA384.

Authentication and key exchange are a different story. These are asymmetric algorithms and we know from Shor’s algorithm that our modern methods are completely broken in the presence of a CRQC. As such, we support Kyber/ML-KEM in both hybrid and normal modes:

• Kyber Level 1
• Kyber Level 3
• Kyber Level 5
• ECDHE P-256 hybridized with Kyber Level 1
• ECDHE P-384 hybridized with Kyber Level 3
• ECDHE P-521 hybridized with Kyber Level 5

For authentication, we support Dilithium/ML-DSA as well as Falcon. We have chosen to use the method of hybridization that is specified in the most recent edition of the X.509 specification where an alternative public key and signature are specified as X.509 extensions; we call these dual-algorithm certificates. At the TLS 1.3 layer, which key(s) and signature(s) are used in the CertificateVerify handshake message is negotiated via TLS extensions.

We support authentication in both hybrid and normal modes:

• Dilithium Level 2
• Dilithium Level 3
• Dilithium Level 5
• Falcon Level 1
• Falcon Level 5
• ECDSA P-256 and Dilithium Level 2
• ECDSA P-384 and Dilithium Level 3
• ECDSA P-521 and Dilithium Level 5
• ECDSA P-256 and Falcon Level 1
• ECDSA P-521 and Falcon Level 5
• RSA-3072 and Dilithium Level 2
• RSA-3072 and Falcon Level 1

wolfMQTT

Note that our wolfMQTT product uses the TLS 1.3 implementation from wolfSSL so you can get these post-quantum features automatically.

wolfSSH

For wolfSSH, we support the hybrid key exchange known as ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org which allows us to interop with the OQS fork of OpenSSH and the AWS Transfer Family SSH implementation.

wolfBoot

For wolfBoot, we have support for the stateful hash based signature schemes LMS/HSS and XMSS/XMSS^MT.

Open Source Integrations

In terms of open source project integrations, we have post-quantum integrations with these three web servers:

• Apache
• Nginx
• Lighttpd

And for the web client side, we have also made cURL quantum-safe! See this video for instructions on how to build.

If you’ve got an application where making changes is difficult due to legacy software, we’ve got our post-quantum integration with stunnel to make your migration a breeze.

The Future

Our own implementation of Dilthium/ML-DSA is coming soon.
We have plans to add Curve25519 hybridized with Kyber in TLS 1.3, DTLS 1.3 and SSH. Want to get these plans accelerated? Send us a message letting us know your protocol preference!

If you have questions about our post-quantum efforts or any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Pseudorandom Number Generators (PRNGs) and True Random Number Generators (TRNGs) are both used to generate “random” sequences of numbers that can be used as input in a wide variety of applications. The key distinction between the two lies in how they generate randomness.

PRNGs employ deterministic algorithms and an initial seed value to generate sequences of numbers. These algorithms aim to mimic the statistical properties of true randomness, but their output is ultimately deterministic and predictable if you know the seed. This means that given the same seed, a PRNG will produce the same sequence of numbers consistently. PRNGs find common usage in applications where practical randomness suffices but they can also be used to ‘stretch’ TRNG output. Meaning, because TRNG output is expensive to obtain, we can use PRNGs to derive cryptographically secure RNG data from the seed that came from the TRNG. PRNGs offer the advantage of speed and simplicity in implementation, as they rely solely on computational algorithms without the need for specialized hardware.

In contrast, TRNGs exploit inherently unpredictable physical phenomena such as radioactive decay, thermal noise, or ring oscillators to use as a source of randomness. TRNGs often require specialized hardware components to capture and process physical randomness reliably. Unlike PRNGs, which generate numbers based on deterministic algorithms, TRNGs produce numbers that are genuinely random and unpredictable. These qualities make TRNGs suitable for applications where high-quality randomness is critical, including cryptography.

wolfSSL’s software based TRNG wolfEntropy, is currently undergoing SP800-90B ESV validation and operates out-of-the-box with our crypto engine, wolfCrypt. If wolfEntropy isn’t a perfect fit, most higher end microcontrollers have TRNG sources which wolfCrypt can use as a direct random source or as a seed for its internal PRNG. Intel RDRAND, a silicon-based TRNG, is supported by wolfCrypt, along with the following hardware systems TRNGs:

• Espressif ESP32-WROOM-32
• Infineon Aurix TC3xx
• Intel SGX
• Microchip ATECC608
• Microchip PIC32MZ
• Nordic nRF5x
• NXP i.MX6 CAAM
• NXP i.MX7 CAAM
• NXP i.MX RT1060
• NXP Kinetis and KSDK
• Renesas TSIP
• Silicon Labs SE
• Telit M2MB
• Whitewood Quantum RNG
• Windows CryptGenRandom
• STM32C0xx
• STM32L0xx
• STM32G0xx
• STM32F0xx
• STM32L1xx
• STM32F2xx
• STM32F3xx
• STM32L4xx
• STM32G4xx
• STM32F4xx




• STM32WBxx
• STM32WLxx
• STM32F5xx
• STM32U5xx
• STM32L5xx




• STM32F7xx
• STM32H7xx
• STM32H5xx

You can find the full list of all hardware acceleration/cryptography platforms currently supported by wolfSSL here: Hardware Cryptography Support

If you have questions or comments about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Ensuring the security of cryptographic modules is paramount world-wide, particularly in governments and regulated industries. The Cryptographic Algorithm Validation Program (CAVP) and the Cryptographic Module Validation Program (CMVP) serve as cornerstones in this endeavor.

The CAVP particularly focuses on validating individual cryptographic algorithms against the Federal Information Processing Standard or FIPS for short. The CAVP issues algorithm certificates.

The CMVP particularly focuses on ensuring that cryptographic modules are adhering to specific criteria above and beyond the algorithms correctness. The CMVP issues FIPS certificates.

CAVP:
Once a module has proven the correctness of its algorithm implementations by passing a series of “test vectors” the CAVP publishes certificates that attest to the correctness of these algorithms on the NIST website. Key elements of a CAVP certificate include the module implementation name and version, the chip microarchitecture and version, the operating system and version on which testing was performed. These three elements (module, chip and OS) comprise what is known as the operational environment or OE. Algorithm capabilities are all viewable on the CAVP certificate. Once the CAVP has issued algorithm certs for a module that module can then go on to be tested and reviewed for adherence under other programs such as the Cryptographic Module Validation program (CMVP), Common Criteria (CC), National Information Assurance Partnership (NIAP), Federal Risk and Authorization Management Program (FedRAMP) or Joint Interoperability Test Command (JITC) to name a few. CAVP certificates are essential and the prerequisite to beginning the certification process under these other programs.

CMVP:
The CMVP (via an accredited NVLAP lab submission and recommendation) approves the entire cryptographic module against the FIPS 140-2/3 standards that apply for the module’s algorithm set. NVLAP accredited labs (also called CSTLs short for “Cryptographic and Security Testing Laboratories”) ensure that cryptographic modules meet comprehensive security standards above and beyond algorithm correctness and submit recommendations to the CMVP that they award the module with a FIPS certificate. By awarding a module with a FIPS certificate the CMVP affirms that a cryptographic module provides a secure environment for processing, storing, and transmitting sensitive information on the OEs for which testing was performed and that appear on the CMVP issued FIPS certificate.

Take note that if an OE is not listed on the FIPS certificate, the CMVP will not affirm the module on that OE or back a claim that the module is FIPS compliant when run on that OE. Vendor affirmation and user affirmation serve as alternatives to CMVP affirmation when a certificate’s vendor is incapable of adapting the module to a new environment or when the costs of such adaptation are prohibitive. However, these non-CMVP backed affirmations lack the weight and guarantee associated with a CMVP affirmation. Vendor affirmation or user affirmation of FIPS compliance are often viewed as insufficient for federal procurement standards and fail to meet the procurement requirements of many agencies.
In conclusion, CMVP certifications are broader in scope than CAVP certifications and applicable to various procurement policies, particularly in the US and Canadian federal agencies. Together, the CAVP and the CMVP play critical roles in upholding cryptographic security standards, ensuring the integrity and confidentiality of sensitive data throughout the world.

For any questions/comments/concerns about FIPS or other related certifications please contact the wolfSSL team by emailing fips@wolfSSL.com or support@wolfSSL.com anytime.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

We’re thrilled to announce that Daniel Stenberg, the founder and lead developer of cURL and libcurl, will be hosting an exciting webinar. Join us for “Advanced curl.” This webinar is a must-attend for anyone eager to enhance their curl skills and explore its full potential.

Check it out here: Advanced curl: Learn From the Founder, Daniel Stenberg

cURL, widely known for its versatility, empowers users to securely transfer data across a variety of protocols, including FTP, FTPS, HTTP, HTTPS, and more.

Throughout the session, participants will delve into the intricacies of curl’s advanced features and capabilities, designed to elevate their expertise to the next level. This webinar promises to equip attendees with the skills needed to tackle any curl challenge that comes their way.

Watch it today! Don’t let this exclusive opportunity pass you by! Be sure to share this video with colleagues and peers who are eager to elevate their curl skills alongside you.

As always, our webinars will include Q&A sessions throughout. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

NSA’s Type 1 encryption has long been the gold standard for protecting classified data. However Type 1 Encryptors can be impractical due to their stringent design requirements and long road to market.

The CSfC program offers a more flexible alternative by integrating commercial-off-the-shelf solutions into a multi-layered solution providing redundancy, reducing likelihood of failure on all fronts and offering advantages like lower costs and faster deployment by taking advantage of 2 or more turn-key solutions. CSfC requires the same adherence to NSA’s Protection Profiles with a multi-layer implementation approach. As CSfC matures, its benefits are expected to grow, making it an increasingly appealing option for organizations looking to prioritize efficiency and time-to-market with trusted and safe cybersecurity solutions.

wolfSSL Inc has been considering a CSfC submission that would make the FIPS 140-2 certified (and soon FIPS 140-3 certified) wolfCrypt one of the optional encryption layers in an NSA compliant solution. To date there has been some interest on this front but not enough to spur the wolfSSL team into action. Cost and time are both factors we have to consider. If seeing wolfCrypt as an option on the CSfC list is something that would be desirable or beneficial to the reader, please send the wolfSSL team an email at facts@wolfSSL.com or support@wolfSSL.com. Feedback adds another data point for our team’s consideration and may tip the scales enough to convert this long-time-consideration into a reality!

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

The wolfSSL team has noticed an uptick in questions about FedRAMP requirements. Today, we want to cover the differences between FIPS and FedRAMP.

FIPS:

The Federal Information Processing Standards (FIPS) stipulate security requirements for cryptographic modules, which wolfSSL Inc. meets with our wolfCrypt FIPS module. NIST and the CMVP then encourage all federal programs using cryptography to follow these standards. Federal Procurement Officers (at the urging of NIST and the CMVP) then require FIPS compliance for solutions that consume cryptography and are used within the scope of their federal program(s).

FEDRAMP:

The Federal Risk and Authorization Management Program (FedRAMP) focuses on the security assessment, authorization, and continuous monitoring of cloud products and services. A prerequisite for FedRAMP is the proper implementation of a FIPS-validated cryptographic module by the cloud service provider.

Both programs aim to enhance data security but differ in scope. While FIPS focuses on cryptographic module validation and cryptography, FedRAMP ensures the overall security of cloud services, one part of which is proper implementation of FIPS validated cryptography for all cryptography running in the cloud. Beyond checking for proper FIPS implementations, FedRAMP also ensures the cloud service provider is fully compliant with NIST SP 800-53 IE: Security Controls, a NIST Risk Management Framework (RMF), service is monitored continuously, data protection methods are robust, incidents can be detected, responded to and recovered from, and more. For a complete list please refer to SP 800-53 at this [LINK].

To support wolfSSL customers, wolfSSL Inc. offers a service to fully validate any Operational Environment (OE) (IoT, embedded, FPGA, Digital Signal Processor (DSP), laptop, desktop, server blade, or cloud system). wolfSSL Inc (the vendor) will fully test and validate the OE of choice using a third-party NVLAP accredited FIPS lab (or CSTL) and get the OE listed as a CMVP-validated OE on the wolfCrypt FIPS Certificate. This is a CMVP-backed OE addition which is guaranteed to be acceptable by any federal program with a FIPS requirement, as opposed to vendor affirmation or user affirmation which often fall short of the mark. Additionally, once the primary certificate is updated with the OE of choice, a rebranded cert with the customer’s logo and letterhead can be offered including that new OE.

wolfSSL’s wolfCrypt FIPS module supports the latest FIPS 140-3 standards and holds the world’s first SP800-140Br1 FIPS 140-3 validated certificate (#4718). Our expert support team is available to assist with the proper implementation of the module on your target OE, a critical step for achieving a successful FedRAMP effort.

Beyond getting proper OE’s for FEDRAMP initiatives, wolfSSL can support customers that are either:

1. Using an alternative OS within AWS, Azure, or Oracle cloud, or,
2. If you are standing up your own cloud, support you with meeting the FedRAMP FIPS requirements for the operating system of your choice.

For more information on how wolfSSL can help with your FIPS or FedRAMP compliance needs, shoot us an email at fips@wolfSSL.com today!

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now