Category: Uncategorized

wolfCrypt implementations of LMS/HSS and XMSS/XMSS^MT signatures: build options and benchmarks (Intel x86)

At wolfSSL we’re excited about stateful hash-based signature schemes and the CNSA 2.0, and we just had a webinar on this subject. If you recall, previously we added initial support for LMS/HSS and XMSS/XMSS^MT, through external integration with the hash-sigs and xmss-reference implementations.

Recently however we have completed our own wolfCrypt implementations of these algorithms, and would like to share benchmarking results and some of the build options available. Generally the wolfCrypt implementations of these signature methods are faster, with more options available to tune build size and performance.

With that said, we’ll review some of the more relevant build options and benchmarking data for LMS/HSS, and XMSS/XMSS^MT. These benchmarks were obtained on a Fedora 38 workstation with an Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz. Only a single core was used. wolfSSL was built with –enable-intelasm to utilize assembly speedups for all tests. Note: LMS/HSS and XMSS/XMSS^MT support a very wide range of parameters. For the sake of conciseness only a targeted range is benchmarked here.

LMS build options and benchmarking

The five main defines that customize the wolfCrypt LMS/HSS build are the following:

  • WOLFSSL_LMS_LARGE_CACHES
  • WOLFSSL_WC_LMS_SMALL
  • WOLFSSL_LMS_MAX_LEVELS=N
  • WOLFSSL_LMS_MAX_HEIGHT=H
  • WOLFSSL_LMS_VERIFY_ONLY

The define WOLFSSL_LMS_LARGE_CACHES will cache more of the authentication path into memory, speeding up signing operations for larger height trees.

The define WOLFSSL_WC_LMS_SMALL reduces code size and memory use overall, with the tradeoff of much slower signing operations. However the performance impact for verification is negligible.

The defines WOLFSSL_LMS_MAX_LEVELS, and WOLFSSL_LMS_MAX_HEIGHT set compile time limits on the size of the LMS/HSS hypertree, and mainly reduce code footprint without impacting performance. These can be used to slim the build size if you are only interested in a specific parameter set range. More specifically, WOLFSSL_LMS_MAX_LEVELS sets the max allowed levels in HSS (the number of trees in the hypertree), while WOLFSSL_LMS_MAX_HEIGHT sets the max allowed height per tree for both LMS and HSS.

The define WOLFSSL_LMS_VERIFY_ONLY restricts the build to a smaller verify-only subset (LMS API and data structures needed for keygen/signing are omitted). This does not impact verify performance, and is intended for embedded targets that need verify-only functionality (e.g. wolfBoot). WOLFSSL_LMS_VERIFY_ONLY can be combined with WOLFSSL_WC_LMS_SMALL, WOLFSSL_LMS_MAX_LEVELS, and WOLFSSL_LMS_MAX_HEIGHT for further footprint reduction.

In Table 1 we show benchmarking results (obtained with ./wolfcrypt/benchmark/benchmark -lms_hss) for these different build options, with the external LMS/HSS implementation provided for comparison.

In general we see the default wolfCrypt LMS/HSS performance (wc_lms) is much faster than the external integration (ext_lms) for all categories of operation (keygen, signing, verifying). The WOLFSSL_LMS_LARGE_CACHES (wc_lms large) option speeds up signing operations for larger height trees, but otherwise does not impact performance. The small variations in verify speed across wc_lms, wc_lms large, and wc_lms small are likely just system noise and do not represent a systematic trend. The WOLFSSL_WC_LMS_SMALL option (wc_lms small) significantly reduces signing speed, but leaves verification speed basically unchanged, making this option attractive for verify-only applications in embedded systems.


Table 1: Comparison of wolfCrypt LMS/HSS (wc_lms), wolfCrypt LMS/HSS with WOLFSSL_LMS_LARGE_CACHES (wc_lms large), wolfCrypt LMS/HSS with WOLFSSL_WC_LMS_SMALL (wc_lms small), and the external integration implementation (ext_lms). All values in units of ops/sec.

wc_lms wc_lms large wc_lms small ext_lms
L2_H10_W2 keygen 6.482 6.494 12.828 1.330
L2_H10_W2 sign 4437.469 5521.796 6.526 786.083
L2_H10_W2 verify 13954.450 14087.794 13874.450 4789.383
L2_H10_W4 keygen 3.567 3.592 6.954 0.764
L2_H10_W4 sign 2452.361 3052.326 3.562 443.225
L2_H10_W4 verify 6482.891 6707.271 6962.215 2281.440
L3_H5_W4 keygen 70.926 73.673 227.376 17.467
L3_H5_W4 sign 4660.370 4669.019 74.653 820.640
L3_H5_W4 verify 4632.118 4670.963 4790.742 1756.355
L3_H5_W8 keygen 9.395 9.413 29.041 2.265
L3_H5_W8 sign 609.408 605.199 9.542 106.059
L3_H5_W8 verify 561.759 554.635 573.341 214.093
L3_H10_W4 keygen 2.384 2.368 7.128 0.569
L3_H10_W4 sign 2459.698 3067.848 2.376 444.601
L3_H10_W4 verify 4895.203 4345.130 4793.853 1618.676
L4_H5_W8 keygen 7.045 7.017 29.258 1.770
L4_H5_W8 sign 608.915 607.318 7.168 106.881
L4_H5_W8 verify 446.384 443.804 438.542 145.672

Graph 1: Signing speeds for wolfCrypt LMS/HSS (wc_lms), wolfCrypt LMS/HSS with WOLFSSL_LMS_LARGE_CACHES (wc_lms large), and the external integration implementation (ext_lms). All values in units of ops/sec.

XMSS build options and benchmarking

Three important defines that customize the wc_xmss build are:

  • WOLFSSL_WC_XMSS_SMALL
  • WOLFSSL_XMSS_MAX_HEIGHT=N
  • WOLFSSL_XMSS_VERIFY_ONLY

The define WOLFSSL_WC_XMSS_SMALL reduces code size and memory use overall, with the tradeoff of much slower signing operations, and 20-30% slower verification.

The define WOLFSSL_XMSS_MAX_HEIGHT=N sets compile time limits on the max height of the hypertree, and mainly reduces code size without impacting performance.

The define WOLFSSL_XMSS_VERIFY_ONLY restricts the build to a smaller verify-only subset, and can be combined with WOLFSSL_WC_XMSS_SMALL, and WOLFSSL_XMSS_MAX_HEIGHT for further size reduction. It does not impact verify performance.

In Table 2 we show benchmarking results for XMSS/XMSS^MT for these options (obtained with ./wolfcrypt/benchmark/benchmark -xmss_xmssmt_sha256), with the external XMSS/XMSS^MT implementation for comparison. The default wolfCrypt XMSS/XMSS^MT (wc_xmss) is in general better than the external integration (ext_xmss), for all operations. There is a smaller difference between wc_xmss and ext_xmss as compared to wc_lms and ext_lms though, because ext_xmss can benefit from assembly speedups whereas ext_lms cannot. Similar to LMS, the WOLFSSL_WC_XMSS_SMALL option (wc_xmss small) significantly reduces signing performance, but verify speeds remain fast, making this a good option for embedded verify-only targets.

Table 2: Comparison of wolfCrypt XMSS/XMSS^MT (wc_xmss), wolfCrypt XMSS/XMSS^MT with WOLFSSL_WC_XMSS_SMALL (wc_xmss small), and the external integration implementation (ext_xmss). All values in units of ops/sec.

wc_xmss wc_xmss small ext_xmss
XMSS-SHA2_10_256 keygen 1.587 1.079 0.943
XMSS-SHA2_10_256 sign 363.693 1.106 226.782
XMSS-SHA2_10_256 verify 3050.276 2044.995 1892.234
XMSSMT-SHA2_20/2_256 keygen 0.808 1.100 0.472
XMSSMT-SHA2_20/2_256 sign 298.138 0.551 191.214
XMSSMT-SHA2_20/2_256 verify 1307.295 982.836 852.348
XMSSMT-SHA2_20/4_256 keygen 9.880 35.274 7.309
XMSSMT-SHA2_20/4_256 sign 390.942 8.681 290.516
XMSSMT-SHA2_20/4_256 verify 729.433 517.298 443.444
XMSSMT-SHA2_40/4_256 keygen 0.406 1.107 0.237
XMSSMT-SHA2_40/4_256 sign 294.738 0.276 161.656
XMSSMT-SHA2_40/4_256 verify 750.591 487.257 424.986
XMSSMT-SHA2_40/8_256 keygen 5.604 35.318 3.755
XMSSMT-SHA2_40/8_256 sign 469.764 4.374 293.184
XMSSMT-SHA2_40/8_256 verify 361.289 262.160 225.254
XMSSMT-SHA2_60/6_256 keygen 0.266 1.099 0.159
XMSSMT-SHA2_60/6_256 sign 280.160 0.185 144.637
XMSSMT-SHA2_60/6_256 verify 521.610 352.718 295.882
XMSSMT-SHA2_60/12_256 keygen 4.143 35.280 2.505
XMSSMT-SHA2_60/12_256 sign 514.658 2.910 292.371
XMSSMT-SHA2_60/12_256 verify 247.682 170.459 152.471

Graph 2: Verify speeds for wolfCrypt XMSS/XMSS^MT (wc_xmss), wolfCrypt XMSS/XMSS^MT with WOLFSSL_WC_XMSS_SMALL (wc_xmss small), and the external integration implementation (ext_xmss). All values in units of ops/sec.

Conclusions

In general our wolfCrypt implementations for LMS/HSS and XMSS/XMSS^MT are significantly faster than the external reference implementations, with speedups of 20-30% to even 3x-4x possible depending on the combination of operation, algorithm, and parameters.

The small footprint build shows fast verification speeds for all parameters, making it an attractive choice for embedded verify-only applications (e.g. wolfBoot).

Overall our LMS/HSS implementation is faster than XMSS/XMSS^MT (at least on x86), which is consistent with what is known about these two methods. However which of the two is more appropriate for your use case will ultimately depend on other factors as well, such as signature size, target environment, and parameters used.

If you’re interested in learning more about our post-quantum work, or want to learn more about stateful hash-based signature schemes, contact us at wolfSSL by emailing facts@wolfSSL.com or calling us at +1 425 245 8247 to reach out to your regional wolfSSL business director.

Download wolfSSL Now

Live Webinar: Linux Kernel Module with FIPS 140-3

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

Everything wolfSSL is Preparing for Post-Quantum as of Spring 2024

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:

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

Difference between Pseudorandom Number Generators and True Random Number Generators

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:

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

wolfBoot vs u-boot: Comparing Secure Boot Solutions for Embedded Systems

While working on wolfBoot, many people ask us, how is it different from u-boot, and how does it compare to it if I am designing a secure boot strategy for my embedded systems based on microprocessors.

While taking the same role in embedded systems, wolfBoot and u-boot are two very different projects.

As bootloaders, they are responsible for initializing the hardware, loading the operating system kernel into memory and then executing it. Bootloaders are typically stored in a non-volatile memory like ROM or flash memory and are the first piece of software to run when a device is powered on or reset.

However, their design, code structure, modularity and core responsibilities are far from each other. Let’s find out by looking at the history of the two projects.

The rise of embedded Linux

U-Boot, short for “Das U-Boot,” is an open source bootloader commonly used in embedded systems, particularly in devices like mobile phones and network equipment. Its origins date back to 1999, when the bootloader was originally developed for the PowerPC-based systems. It has since been ported to many other architectures, including ARM and x86.

U-Boot is highly configurable and customizable, allowing developers to adapt it to various hardware configurations and requirements. It provides a command-line interface (CLI) for interacting with the bootloader during the boot process, allowing users to modify boot parameters, load additional software at runtime and even connect to a network to download new images. In addition to its primary role as a bootloader, U-Boot often includes additional features such as support for multiple filesystems, network booting, firmware updates, and diagnostic tools, making it a versatile and powerful tool in embedded system development. Its open-source nature also fosters a strong community of developers contributing to its ongoing development and improvement.

U-Boot is definitely feature rich, flexible and has lived up to its name for so many years, as the most popular generic-purpose bootloader for embedded systems within the range of microprocessors it supports. Throughout the past decades, U-Boot played a significant role in making embedded Linux systems more accessible and widespread. Its versatility and compatibility with diverse hardware architectures contributed to the popularity and success of embedded Linux in various applications, from consumer electronics to industrial automation.

The advent of IoT and its security challenges

With the advent of the Internet of Things (IoT) and the proliferation of connected devices, security concerns in embedded systems became more pronounced. High-profile attacks like the “Mirai” botnet, which exploited vulnerabilities in IoT devices, underscored the importance of securing firmware and boot processes. In response to the growing demand for secure boot solutions, the Internet Engineering Task Force (IETF) started to work on standardizing guidelines for secure boot mechanisms in embedded devices, publishing a draft document which was later on published as RFC9019 in 2021.

wolfBoot has been inspired in the first place by the many successful attempts of wolfSSL customers integrating wolfCrypt public-key verification mechanisms in custom bootloader solutions. This process however would consume a lot of time and resources, which could have been otherwise applied to more central features in their products, if only a solution would have been available to secure the boot mechanism. wolfBoot was then initially developed in 2018, using the draft document from IETF to define its core guidelines.

RFC9019 emphasizes the importance of establishing a secure root of trust and ensuring the integrity of the boot process from the hardware level onwards. It advocates for the use of cryptographic techniques, including public key ciphers such as RSA and ECC, for authentication and verification of firmware images and bootloader components. By using public key cryptography, embedded systems can verify the authenticity and integrity of firmware images before execution, mitigating the risk of unauthorized code execution and firmware tampering.

Additionally, RFC9019 recommends the use of small, robust parsers for processing and verifying configuration files, cryptographic keys, and digital signatures. Small parsers help reduce the attack surface and minimize the risk of vulnerabilities such as buffer overflows or parsing errors. By following these recommendations, embedded systems can enhance their security posture and resilience against sophisticated attacks targeting the boot process and firmware integrity.

A new era of safety-critical, connected systems

In recent years, there has been a proliferation of safety-critical systems that are either connected to the internet or accessible via private networks. This trend extends to various domains, including aerospace, automotive, healthcare and industrial automation. Examples include space systems, autonomous vehicles, medical devices, and industrial control systems. As safety-critical systems become increasingly interconnected, the need for robust security mechanisms, including secure boot, becomes a requirement. These systems are not only subject to safety requirements but also face cybersecurity threats from malicious actors seeking to exploit vulnerabilities and compromise their operation.

The convergence of safety and security considerations poses unique challenges for developers and operators of safety-critical systems. In addition to meeting stringent safety standards and certifications (e.g., DO-178C for avionics, ISO 26262 for automotive), they must also ensure compliance with security standards and best practices to protect against cyber threats and ensure system integrity. Additionally, international regulations are getting stricter every year to enforce traceability of code that is related to security in such scenarios.

wolfSSL offers a range of products that are meeting the needs for certified security that can run in compliance with safety regulations for any specific market. This is where wolfBoot excels among all competitors. A safe bet for cutting the costs towards secure boot in safety-critical embedded systems. wolfCrypt and wolfBoot have been DO-178 certified to DAL A level.

Quantum computers: new challenges to traditional cryptography

While U-Boot offers RSA-based cryptographic options, wolfBoot sets itself apart by leveraging the FIPS 140-2 certified WolfCrypt, a robust and trusted cryptography engine that adheres to the highest security standards. WolfCrypt not only provides support for a wide range of cryptographic algorithms but also offers compatibility with hardware security modules (HSMs), including Trusted Platform Modules (TPMs).

Out of the box, wolfBoot supports a comprehensive set of public key cryptography ciphers, including ECC up to ECC521, RSA up to RSA4096, ED25519, ED448, LMS, and XMSS. This diverse range of cryptographic algorithms ensures flexibility and future-proofing, allowing developers to choose the most suitable algorithms for their specific security requirements.

In the context of long-life systems where the bootloader is immutable, many projects have just started using post-quantum cryptography (PQC). As quantum computing technology advances, traditional cryptographic algorithms like RSA and ECC may become vulnerable to attacks, posing a significant risk to the security of systems relying on them. By incorporating PQC algorithms such as LMS and XMSS, wolfBoot ensures that even with the evolution of quantum computing, the secure boot process remains resilient and future-proof. This proactive approach to security is crucial for safeguarding the integrity and longevity of systems operating in environments where firmware updates are infrequent or impractical. By embracing PQC, wolfBoot offers peace of mind and assurance that the secure boot process will remain robust and secure throughout the lifecycle of the system, providing long-term protection against evolving threats and vulnerabilities.

Secure boot: what really matters

We have analyzed how the two projects have started and evolved with two different goals in the mind of their developers. But what aspects really matter in today’s secure boot solutions? The answer is not easy. U-Boot has so many supported features that could be compared to an operating system, and as we have seen the importance of flexibility in the evolution of embedded Linux systems in the past. wolfBoot is small in size, safety oriented and focuses primarily on the secure boot capabilities. When designing a secure boot strategy, a few key indicators should be taken into consideration:

  • Bootloader’s main purpose: U-Boot aims to be a portable and flexible generic bootloader, while wolfBoot is designed primarily as the main building block for secure boot mechanisms, providing specific countermeasures against attackers having different levels of access to the target system. By default, no user interaction is provided on purpose, to reduce the attack surface as much as possible.
  • Quality of cryptographic engine: wolfBoot is built on top of wolfCrypt, the best tested open source cryptography engine in existence. This means that the algorithms provided to secure the boot process are reliable, certified, transparent and supported by a team of professional developers.
  • Code size: more code certainly means more features, but also more vulnerabilities, higher cost of maintenance, which can easily become unaffordable when safety regulations are added to the picture. wolfBoot guarantees the lowest possible costs related to safety certifications
  • Safety by design: wolfBoot’s compile-time predictability guarantees consistent behavior across different builds and environments. This reliability is invaluable in ensuring the system behaves as expected under all conditions.
  • Post-Quantum cryptography: Quantum computers leverage principles of quantum mechanics to parallelize computations at a scale far exceeding those of classical computers. This computational power poses a significant threat to traditional cryptographic algorithms, which rely on the difficulty of certain mathematical problems for their security. Post-Quantum Cryptography (PQC) seeks to develop cryptographic algorithms that remain secure even in the presence of quantum adversaries. PQC algorithms are designed to withstand attacks from both classical and quantum computers, ensuring long-term security in the post-quantum era. wolfBoot provides support for LMS and XMSS.

Hybrid boot chain

Are you still a big fan of u-boot unique features and flexibility? So are we! If you still want to use any of the features u-boot offers but you want to secure your boot mechanisms, then multi-stage, hybrid solutions may be for you. A hybrid approach can be adopted where the bootloaders coexist in separate stages. In this scenario, wolfBoot can serve as the initial secure bootloader responsible for securely loading and verifying the subsequent stages, including U-Boot images.

wolfBoot can be deployed as the early-stage bootloader responsible for initializing the hardware, performing the initial boot sequence, and verifying the integrity and authenticity of subsequent bootloader stages. It securely loads and verifies the authenticity of the next bootloader stages, in this case including the U-Boot image, using cryptographic signatures and trusted keys stored securely within the system. Once the U-Boot image is verified, wolfBoot hands over control to U-Boot, allowing it to execute with the assurance that it has been securely loaded and verified by wolfBoot.

While U-Boot provides advanced features and flexibility, its complexity can introduce potential vulnerabilities. If vulnerabilities or security issues are discovered in the running U-Boot image, wolfBoot can securely update the U-Boot image with a patched version or a newer release. This ensures that the system remains protected against emerging threats and vulnerabilities without compromising its advanced features.

Conclusions

The comparison between wolfBoot and U-Boot reveals distinct strengths tailored to different needs. U-Boot boasts extensive device support and a well-established feature rich codebase, making it ideal for systems requiring flexibility and connectivity from the very initial stages. On the other hand, wolfBoot shines in security, with lightweight design and certified cryptography ensuring system integrity and low costs of maintenance, making it a perfect fit for all secure-boot requirements across all embedded systems.

In those scenarios where ensuring the integrity of the boot process and validating the authenticity of firmware are crucial, wolfBoot’s lightweight design and certified cryptography are definitely a solid choice: wolfBoot defines the path to securing the boot process for safety-critical embedded systems of the future.

Have questions about your boot strategy? Contact us at facts@wolfSSL.com or +1 425 245 8247!

Download wolfSSL Now

What is the difference between CAVP and CMVP?

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

Join Our Live Webinar: Advanced curl: Learn From the Founder, Daniel Stenberg

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

What’s the Difference Between Type 1 and CSfC?

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

FIPS vs FedRAMP Compliance and Requirements

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

What is the difference between JNI, JCE and JSSE?

What are the JNI, the JCE, and the JSSE, and how does wolfSSL fit into this? To answer the first question:

  • The Java Native Interface (JNI) is a programming interface that allows Java to natively call code written in other languages (C, C++, etc). For example, the JNI allows a Java application to natively call API from a library written in C (like wolfSSL).
  • The Java Cryptography Extension (JCE) is a framework that extends Java’s cryptographic functionality, allowing you to choose stronger or more performant implementations for cryptographic operations such as encryption and hashing.
  • The Java Secure Socket Extension (JSSE) is a framework that implements SSL/TLS protocols, with factories for creating SSL client/server sockets, an SSLEngine for streaming TLS data, etc.

Both JCE and JSSE follow a provider architecture, allowing users to choose amongst different registered providers by e.g. name, or highest priority.

To answer the second question, wolfSSL supports two related java packages:

When wolfJSSE is used, it will provide the implementation for familiar JSSE classes such as SSLSocket, SSLEngine, X509KeyManager, etc. Furthermore, it supports up to TLS 1.3. If you want to try it out, we have plenty of examples on github for both the wolfSSL JNI wrapper, and the wolfJSSE Provider.

The wolfJCE provider supports algorithms such as SHA-1, SHA-2, PBKDF2, ciphers such as AES-CBC and AES-GCM, and more. Also, when wolfJCE is registered as the highest priority provider, it will be used for the HashDRBG algorithm in Java’s SecureRandom implementation.

Additionally, a cool feature of JCE providers is they can be signed by a code-signing certificate from Oracle, and thus authenticated by the Oracle JDK. To this end wolfSSL provides pre-signed JAR files so that wolfJCE can be authenticated.

If you want to learn more about our Java related products or if you have questions about any of the above, contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Posts navigation

1 2 3 … 12 13 14 15 16 17 18 … 189 190 191