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 FIPS 140-3 latest standards, anticipates receipt of a FIPS 140-3 certificate any day now and our support staff will gladly assist any team with proper implementation of the FIPS module on their target OE which is highly crucial to a successful FedRAMP effort.
Beyond getting proper OE’s for FEDRAMP initiatives, wolfSSL can support customers that are either:
Using an alternative OS within AWS, Azure, or Oracle cloud, or,
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!
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:
wolfssljni: a wolfSSL JSSE Provider (wolfJSSE), and a JNI wrapper around wolfSSL.
wolfcrypt-jni: a wolfCrypt JCE Provider (wolfJCE), and a JNI wrapper around wolfCrypt.
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.
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
In a well-designed modular system there is a dedicated component that performs cryptographic operations. It can be a discrete physical chip, a software library or a mix. Whenever a system component needs a cryptographic operation like hashing, signature verification, encryption, key creation, etc. it delegates the operation to the “cryptographic provider”.
But how to interact with the cryptographic provider?
Ideally, with a (good) standardized application programming interface (API). Having a common interface for cryptographic providers has several advantages: the provider becomes interchangeable, the software is more maintainable and easier to audit, and as a consequence, it’s safer. Unfortunately, designing a good API is an overwhelming task: the abstraction has to be clean and easy to use and read, but at the same time flexible and secure.
Public Key Cryptographic Standard 11 (PKCS#11) and Platform Security Architecture (PSA) Crypto API specifications try to accomplish this daunting task: defining a common API for cryptographic providers.
What about Trusted Platform Module (TPM) 2.0?
The TPM2.0 is aimed at a specific category of cryptographic devices, quoting from the TPM 2.0 specification: “…a device that enables trust in computing platforms in general”. A TPM is a device that, besides normal cryptographic functions, provides the necessary foundation to enable device identification and overall system integrity reporting. Very early stages of software typically use it in a platform to establish a Root of Trust and allow secure boot and remote attestation features. So while PSA and PKCS#11 both define only an API to access cryptographic providers, TPM2.0 has a much larger scope, as it defines the system architecture to achieve the “trust” of the platform alongside the interface with the TPM device. Moreover, the interface to the TPM is described in terms of commands and responses that a compliant TPM device will understand, unlike PKCS#11 and PSA where the interface is described using C function prototypes and data structure.
But even if PKCS#11 and PSA are both C-based, they show several differences in how they model the cryptographic operations and the terminology used. As an example, PKCS#11 uses a hierarchical sophisticated object model to represent keys, algorithms (called mechanisms), devices (called tokens), etc, while PSA Crypto aims for a more flat and simpler model, where algorithms and keys are just a typedef of an integer type.
wolfSSL support for TPM2.0, PKCS#11 and PSA
Regarding TPM 2.0, wolfTPM library abstracts away the details of the communication with the device and exposes a 1:1 mapping of the TPM commands defined in the specification, plus wrappers that hide away the complexity of using the commands directly.
For PKCS#11 and PSA Crypto API wolfSSL can both expose its functionality using the defined interface and consume cryptographic functions from a provider of the interface.
This not only means that wolfSSL can use cryptographic providers that expose one of the three interfaces, not only that wolfSSL can be used by any software that uses one of the three interfaces, but that wolfSSL can also act as a sort of polyglot translator between software components!
You can refer to here as an example of this, where an application can use wolfPKCS11 to talk with a TPM, thanks to wolfCrypt using wolfTPM to talk with the latter. I report here a diagram of the article as a reference:
So no matter what interfaces you need, wolfSSL has you covered! Do you need more info about a specific use-case? Do you have any suggestions? or if you have questions about any of the above, feel free to drop a line at facts@wolfSSL.com or call us at +1 425 245 8247.
wolfTPM v3.2.0 is here, and among the new features is support for pre-provisioned device identity keys and certificates for the ST33, following the specification of the Trusted Computing Group’s TPM 2.0 Keys for Device Identity and Attestation. This feature allows you to read pre-provisioned certificates and keys that are tied to the device’s identity, which can then be used for TLS mutual authentication, for example. We’ve updated our tls_client example to show an example of this, and you can read more about it in our PR here if you’re curious about the details.
Anthony will delve into the differences between wolfEngine and wolfProvider and guide you on which product is suitable for your use cases. Both wolfEngine and wolfProvider offer the best solutions for achieving FIPS compatibility in a timely manner for OpenSSL users.
You can expect to learn about:
Optimal alternatives: OpenSSL compat layer
Understanding the OpenSSL 1.0.2, 1.1.1, and 3.x.y branch releases
Determining suitable branches for engines and providers
Utilizing wolfEngine and wolfProvider with the openssl app
Integrating wolfEngine and wolfProvider with the OpenSSL API
Available algorithms and cryptographic primitives
Insights on FIPS compatibility
Don’t miss this opportunity to deepen your understanding of how wolfEngine and wolfProvider can efficiently meet the OpenSSL requirements. Anthony will showcase how wolfEngine and wolfProvider act as connectors between OpenSSL and wolfCrypt FIPS, saving you time and effort. Don’t miss this opportunity to deepen your understanding of how wolfEngine and wolfProvider can efficiently meet the OpenSSL requirements. Anthony will showcase how wolfEngine and wolfProvider act as connectors between OpenSSL and wolfCrypt FIPS, saving you time and effort. Watch it now!
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 call us at +1 425 245 8247.
It may not be as glamorous as the new ESP32 RISC-V chipsets with all the various hardware acceleration capabilities, but the ESP8266 is a well established device which has a large codebase available with an even larger user community.
Due to high customer demand, we’ve enhanced the wolfSSL libraries for the ESP8266. The recent changes have improved both the ESP-IDF CMake and traditional Makefile builds. This new capability allows for specification of the wolfSSL component source code as an alternative to using the setup script to copy everything locally.
For make, set the WOLFSSL_ROOT value in components/wolfssl/component.mk
For cmake, there are more options:
Set the WOLFSSL_ROOT value in components/wolfssl/CMakeLists.txt
Set the WOLFSSL_ROOT environment variable.
Have the components/wolfssl/CMakeLists.txt as a subdirectory in wolfSSL.
When a project is in a subdirectory of wolfSSL, the cmake file will search parent directories, up to the root, looking for wolfSSL.
The ability to specify the wolfSSL component source code ensures consistent versioning across projects and facilitates easy updates via GitHub.
You may have seen our recent announcement regarding wolfCrypt hardware acceleration for the ESP32 series. There’s no such capability on the ESP8266. However, there’s still a noticeable difference between debug and release optimizations, as shown at the end of this blog.
Once the Espressif ESP8266 RTOS SDK is installed, it is easy to get the wolfSSL examples working (see the README for more details):
# Set your path to RTOS SDK,
# shown here for default from WSL with VisualGDB
WRK_IDF_PATH=/mnt/c/SysGCC/esp8266/rtos-sdk/v3.4
# or
WRK_IDF_PATH=~/esp/ESP8266_RTOS_SDK
# Setup the environment
. $WRK_IDF_PATH/export.sh
# Optional: install as needed / prompted
# /mnt/c/SysGCC/esp8266/rtos-sdk/v3.4/install.sh
# Fetch wolfssl from GitHub if needed:
cd /workspace
git clone https://github.com/wolfSSL/wolfssl.git
# change directory to wolfssl client example.
cd wolfssl/IDE/Espressif/ESP-IDF/examples/wolfssl_client
# Adjust settings as desired
# Set IP address and wifi SSID name & password
idf.py menuconfig
# Build, flash and monitor
idf.py build flash -p /dev/ttyS70 -b 115200
idf.py monitor -p /dev/ttyS70 -b 74880
Are you interested in using the ESP8266 or ESP32 in your next project? Let us know! We love to hear about how wolfSSL is being used, and can optionally help promote your project on social media, with your approval.
On April 18th, 2024, the NSA released updates and clarifications to their CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) advisory in the form of an FAQ. This is the fifth and final in a series of postings about the questions and answers that we feel are most interesting and our reactions to them.
Q: Can I mitigate the quantum threat by using a pre-shared key?
A: Many commercial protocols allow a pre-shared key option that may mitigate the quantum threat, and some allow the combination of pre-shared and asymmetric keys in the same negotiation. However, this issue can be complex. Customers who wish to explore this option should contact NSA or follow guidance the CSfC program provides.
This is great news for our customers as this means they can enable our PSK (pre-shared key) support in wolfSSL and start their post-quantum journey today! If you’re using Sneakernet (avoiding network transmission) then you’re golden! The knowledge of the pre-shared key takes care of both authentication and key establishment so there is no need for public key cryptography and therefore thwarts Shor’s algorithm.
That said, the NSA is correct, this issue is complicated. Here are just a few points to think about:
How is the key shared? If it was sent over a data connection that was negotiated with non-quantum-safe algorithms, then this is not considered mitigating the quantum threat.
How is the key generated? If it was done using an entropy source and/or PRNG (Pseudo-Random Number Generator) that is not approved then you are going to run into problems.
Do you require PFS (Perfect Forward Secrecy)? Then you might have to think about how you’re going to achieve that very carefully.
How are you storing and protecting the pre-shared keys? If your efforts to protect it are insufficient then you leave yourself vulnerable to other attack vectors.
Let our experts help you sort out these details. Get started on your journey into a world with quantum computers by downloading wolfSSL now.
Security is paramount in the automotive industry to protect the integrity, confidentiality, and authenticity of data. Automotive HSMs (Hardware Security Modules) play a crucial role. It enhances the security of cryptographic keys and cryptographic processing.
During this webinar, Bill will explore a wide range of topics from the functionality and design of wolfHSM to its application in AUTOSAR/SHE/PKCS11, and provide a demonstration on the Infineon Aurix Tricore TC375.
You can expect to learn:
The Essentials of Hardware Security Modules
Functional design insights of wolfHSM
Application of wolfHSM in AUTOSAR, SHE, and PKCS11
Hardware porting and support strategies for wolfHSM
A demonstration using the Infineon Aurix Tricore TC375
And much more…
Watch now to learn how wolfHSM can boost your security, offering a portable and open-source abstraction to hardware cryptography, non-volatile memory, and isolated secure processing.
As always, our webinars will include Q&A sessions throughout. If you have questions on any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
On April 18th, 2024, the NSA released updates and clarifications to their CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) advisory in the form of an FAQ. This is the fourth in a multipart series of postings about the questions and answers that we feel are most interesting and our reactions to them.
Q: When should deployment of CNSA 2.0 algorithms in mission systems begin?
A: When validated products become available they should be deployed in mission systems. Meanwhile, NSA encourages responsible testing in vendor and government research environments now to understand the effects of deployment of the new algorithms on particular systems given the increased sizes used in these algorithms.
Translation: time to “get cracking” and build post-quantum cryptographic implementations you plan to use. You need to understand that while performance for Kyber/ML-KEM won’t be an issue, (see our benchmarks) artifact sizes are increasing!
If you are used to the tiny artifacts in ECDHE then this should be a real eye opener. We’re talking kilobytes going over the wire and taking up memory.
How will this affect you? First of all, if your transmission medium is slow then more bytes going over the wire during the protocol handshake will naturally increase the time to your first application data being sent. Secondly, if your current application is already memory constrained, you might need to re-evaluate how you use your memory or even increase the amount of memory available to your application.
Considering these things takes time and planning, now is the time to start. Download now!
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.
