RECENT BLOG NEWS

So, what’s new at wolfSSL? Take a look below to check out the most recent news, or sign up to receive weekly email notifications containing the latest news from wolfSSL. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support questions.

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

wolfSSL Inc. announces wolfHSM for Automotive HSMs (Hardware Security Modules)

A framework that makes it easy to integrate Automotive HSMs. Quantum-resistant cryptography now available for Automotive HSMs

EDMONDS, Wash., June 5, 2024 /PRNewswire-PRWeb/ — wolfSSL INC. (Headquarters: Edmonds, Washington, USA), a vendor specialized in cryptography and network security, announces its new product wolfHSM. Automotive HSMs (Hardware Security Modules) dramatically improve the security of cryptographic keys and cryptographic processing by isolating signature verification and cryptographic execution, which are the core of security, into physically independent processors. Automotive HSM’s are mandatory or strongly recommended for ECU’s that require robust security. With this in mind, wolfSSL has ported our popular, well-tested, and industry-leading cryptographic library to run in popular Automotive HSMs like Aurix Tricore TC3XX.

“Automotive Tier 1’s and OEM’s are tired of inflexible, slow-moving, and costly HSM software vendors. We’re the new alternative for better price, performance, speed of execution, and cryptographic know-how in this market segment.” said Todd Ouska, CTO of wolfSSL Inc.

wolfHSM provides a portable and open-source abstraction to hardware cryptography, non-volatile memory, and isolated secure processing that maximizes security and performance for ECUs. By integrating the wolfCrypt software crypto engine on hardware HSM’s like Infineon Aurix Tricore TC3XX, Chinese-mandated government algorithms like SM2, SM3, and SM4 are available. Additionally, Post Quantum Cryptography algos like Kyber, LMS, XMSS, and others are easily made available to automotive users to meet customer requirements. At the same time, when hardware cryptographic processing is available on the HSM, we leverage it to enhance performance.

One of the prime consumers for wolfHSM is wolfBoot, which is a mature and portable secure bootloader solution designed for bare-metal bootloaders and equipped with failsafe NVM controls. It offers comprehensive firmware authentication and update mechanisms, leveraging a minimalistic design and a tiny HAL API, which makes it fully independent from any operating system or bare-metal application. wolfBoot manages the flash interface and pre-boot environment, accurately measures and authenticates applications, and utilizes low-level hardware cryptography as needed. wolfBoot can use the wolfHSM client to support HSM-assisted application core secure boot, Additionally, wolfBoot can run on the HSM core to ensure the HSM server is intact, offering a secondary layer protection. This setup ensures a secure boot sequence, aligning well with the booting processes of HSM cores that rely on NVM support.

All of the other wolfSSL products that consume cryptography can now also consume HSMs via wolfHSM, including our flagship TLS 1.3 implementation, wolfSSH, and curl.

Extensibility of cryptographic algorithms:
When it comes to security, it is necessary to keep in mind that the technology on the attacker side is constantly evolving, so the technology on the defense must also evolve. With wolfHSM, you are not limited to fixed functions provided by hardware, but can enhance and expand cryptographic algorithms and functions using software while maintaining high security at the hardware level.
For example, as post quantum cryptography becomes necessary in more requirements, wolfHSM allows you to seamlessly add it within the HSM without changing the hardware.

Migration from conventional technology:
wolfHSM provides an interface (API) that unifies traditional software-based cryptographic processing and HSM processing, allowing smooth implementation of HSM without major changes to existing system structure.

Consistency with security functions:
In addition to being used as a standalone HSM, wolfHSM offers integration with security protocols such as wolfSSL, wolfSSH, and wolfBoot for secure firmware updates.

Integration with Autosar:
wolfHSM exposes the wolfCrypt API, which comes complete with an Autosar shim layer for compatibility.

The currently supported HSMs are as follows:

  • Infineon Aurix TC3xx
  • ST SPC58NN
  • Infineon Aurix TC4x (Coming soon)
  • Infineon Traveo T2G (Coming soon)
  • Renesas RH850 (Coming soon)
  • Renesas RL78 (Coming soon)

wolfSSL Inc., will be exhibiting at the AutoTech Detroit, which will be held at The Suburban Collection Showplace in Novi, MI June 5-6, 2024. In addition to wolfHSM, we will explain the latest network security including post-quantum cryptography and FIPS 140-3. For those who wish to use the TLS 1.3 library wolfSSL, we will also guide you through the preparations to start using it at the venue.

Date: Wednesday, June 5th, 2024 – Thursday, June 6th
Venue: Suburban Collection Showplace
wolfSSL booth number: 730

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

Download wolfSSL Now

Posts navigation

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

Weekly updates

Archives