CNSA 2.0 Update Part 2: NIAP
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 second in a multipart series of postings about the questions and answers that we feel are most interesting and our reactions to them.
But first, some clarifications on terms and acronyms:
- NIST SP 800-208 National Institute of Standard and Technology Special Publication 800-208 titled: Recommendation for Stateful Hash-Based Signature Schemes
- NIAP: National Information Assurance Partnership: A United States government organization that oversees evaluations of commercial information technology products for use in national security systems
- LMS: Leighton-Micali Signatures; a stateful hash-based signature scheme
- XMSS: eXtended Merkle Signature Scheme; a stateful hash-based signature scheme
- CAVP: The Cryptographic Algorithm Validation Program; provides guidelines for validation testing which is a pre-requisite for CMVP testing
- CMVP: Cryptographic Module Validation Program; security accreditation program for cryptographic modules.
Q: As a commercial vendor, how do I know if my NIST SP 800-208 implementation meets CNSA 2.0?
A: NIAP validates products against its published Protection Profiles, which will start
including quantum-resistant signatures in line with our published transition timelines. For
commercial vendors, we do not anticipate NIAP Protection Profiles will perform
signature generation within the Target of Evaluation (TOE) boundary, only signature
verification. As signature generation is the component of LMS/XMSS that requires state
management, if only signature verification is being performed, only CAVP validation (not
CMVP) will be expected for such products.
Anyone who has been following wolfSSL’s progress with post-quantum algorithms knows we have our own implementations of LMS/HSS and XMSS/XMSS^MT and they are integrated into the wolfBoot product! wolfBoot only uses them to verify the signature of the firmware, therefore one only needs to build these algorithms with verification functionalities. Check out sections 17 and 20 of our wolfSSL INSTALL file.
Requiring only CAVP validation is an excellent bonus for our customers. It means that validation will be a simpler and easier process for our team to help you achieve. You can count on fast turnaround times and little if any paperwork.
Preparing for NIAP and need the best cryptography? Contact us at support@wolfSSL.com or reach out with any questions at facts@wolfSSL.com or +1 425 245 8247.
Catch up on ‘CNSA 2.0 Updated Part 1: Today!‘ and stay tuned for more insights in our upcoming blogs!
Download wolfSSL Now
CNSA 2.0 Update Part 1: Today!
On April 18th, 2024, the NSA released updates and clarifications to their CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) advisory. They did it in the form of an FAQ document (list of Frequently Asked Questions with Answers). The FAQ document was sent to the PQC Forum. This will be a multi-part series of postings about the questions and answers that we feel are most interesting and our reactions to them.
Q: Is there a quantum-resistant public-key algorithm that commercial vendors should adopt today?
A: NSA encourages vendors to use CNSA 2.0 approved hash-based signatures for software- and firmware-signing. NSA does not approve using pre-standardized or non-FIPS-validated CNSA 2.0 algorithms (even in hybrid modes) for NSS missions. However, NSA does recommend limited use of pre-standardized or non-FIPS-validated CNSA 2.0 algorithms and modules in research settings to prepare for the transition. NSA requests vendors begin preparing to implement CNSA 2.0 algorithms so they are primed to provide products soon after NIST completes standardization.
The NSA has spoken and they expect the industries from which they purchase to provide products that support the CNSA 2.0 Algorithm Suite upon standardization. That means DO NOT start when standardization is complete; start now.
Note that for software/firmware signing it says you should already have it added and tested in your system! By next year, it should be the default and preferred. This means if you are not using LMS or XMSS in your boot loader then you are out of compliance with the CNSA 2.0 guidance. Checkout wolfBoot where we have already added support for the stateful hash-based signature schemes.
The NSA is also saying you need to be prepared with these algorithms already integrated into your products. Here at wolfSSL we have been saying the same message for years. You need to prepare for and understand the impacts that the larger keys, cipher text and signatures are going to have on your systems. Will these larger cryptographic artifacts require more memory resources? Will they slow down your transmissions? Will the answer to those questions cascade into new requirements and trade-offs? Now is the time to find the answers to those questions. Contact us at support@wolfSSL.com for benchmarking details.
If you haven’t already, go ahead and get started today. See Appendix G of our wolfSSL manual. Have further questions about getting started with CNSA 2.0 using wolfSSL, contact us at support@wolfSSL.com.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
Live Webinar: How to Determine FIPS Compliance for Government Buyers
In today’s security-conscious world, ensuring that your technology solutions meet stringent compliance standards is more crucial than ever, especially for government buyers. One key compliance standard is FIPS (Federal Information Processing Standards). Join us for an informative webinar where Kaleb Himes, Senior Software Engineer at wolfSSL, will guide you through the essential aspects of determining FIPS compliance.
Watch Today: How to Determine FIPS Compliance for Government Buyers
This webinar will cover:
- Why is FIPS important?
- Why is having a specific OE on the cert important?
- How to lookup a cert and determine if that cert fits your program requirements
- How to detect fake FIPS claims & Red Flags to lookout for
And more
This webinar is designed for government buyers who need to ensure that their systems meet the rigorous standards of FIPS. Kaleb will provide valuable insights and practical tips to help you navigate the complexities of FIPS compliance, avoid potential pitfalls, and make informed decisions.
Don’t miss this opportunity to enhance your understanding of FIPS compliance and safeguard your systems. Check it out for this exclusive webinar!
As always, our webinar includes Q&A 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
wolfBoot Supports the Infineon AURIX TriCore TC3xx
We’re thrilled to announce that wolfBoot now supports Infineon’s AURIX TriCore TC3xx family of microcontrollers, bringing enhanced security and flexibility to your automotive and industrial applications.
Why AURIX TC3xx?
Infineon’s AURIX TriCore TC3xx microcontrollers are renowned for their high performance, safety, and security features, making them ideal for automotive and industrial applications. Adding wolfBoot to your TriCore application means you get a small and performant secure bootloader designed to protect your firmware right from the start.
Why wolfBoot on AURIX TC3xx?
- Security: Ensure only authenticated firmware runs on your TriCore device, safeguarding against malicious code and aftermarket tuning modifications. Encrypted application images prevent attackers from reverse engineering your code and data, and rollback protection ensures bugs in your firmware can’t be exploited once fixed. Secure key storage means your cryptographic material remains inaccessible from the outside world, providing your application with a strong root of trust.
- Reliability: Combine the TC3xx’s functional safety with wolfBoot’s robust image update procedure, providing your application with resilience to power failures and support for delta/incremental updates.
- Flexibility: wolfBoot is OS agnostic, and can interoperate with any RTOS, Linux or bare-metal application, including AUTOSAR stacks. wolfBoot’s tight integration with wolfCrypt, the world’s best-tested cryptography library, provides built-in support for all major cryptographic algorithms, including post-quantum algorithms and Chinese government-mandated SM ciphers. This means your application benefits from exceptional crypto agility, easily adapting to new cryptographic standards and staying secure against evolving threats.
Getting Started
To get started with wolfBoot on the AURIX TC3xx, clone the wolfBoot repository and follow the AURIX build instructions. The example project contains everything you need to load and update images on the AURIX LiteKit-V2 development board, but the steps should be adaptable to any device in the TC3xx family.
wolfBoot TriCore HSM Integration
wolfHSM is a software framework that provides a portable and open-source abstraction to hardware cryptography, non-volatile memory, and isolated secure processing that maximizes security and performance for ECUs. It consists of a client-server library architecture, where the wolfHSM server runs on the secure HSM core, and client applications communicate with the server through the wolfHSM client library. wolfHSM dramatically simplifies client applications by allowing direct use of wolfCrypt APIs, with the library automatically offloading all sensitive cryptographic operations to the HSM core as remote procedure calls with no additional logic required by the client app. The AURIX TC3xx family of devices is fully supported by wolfHSM, and includes HSM hardware crypto acceleration.
With the wolfHSM server running on the AURIX HSM core, wolfBoot can use the wolfHSM client to offload all cryptography and key storage to within the HSM secure environment, providing application images with an HSM-backed root of trust. wolfHSM can also leverage wolfBoot on the HSM core, authenticating both the wolfHSM server application and the TriCore application images before releasing wolfBoot on the application cores.
Using wolfBoot on the Infineon AURIX TC3xx is a big step towards securing your automotive or industrial application with minimal effort, especially when combined with wolfHSM.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
wolfSSL Embraces RISC-V; FIPS 140-3 Certifications Now Available
wolfSSL was a proud sponsor and exhibitor at the RISC-V Summit EU earlier this year. Thank you to all the attendees that stopped by; We enjoyed the interesting discussions regarding wolfSSL in your projects.
Some of the most common questions we heard:
Q: Is wolfSSL supported on RISC-V devices?
A: Yes! Absolutely. The wolfSSL libraries run on nearly every device, including RISC-V. For instance, recently we published a blog on the HiFive Unleashed RISC-V Benchmarks.
Q: Does wolfSSL have support for RISC-V Acceleration Extensions?
A: Yes! For example, see the GitHub wolfSSL PR #7569 that implemented the AES ECB / CBC / CTR / GCM / CCM for RISC-V 64-bit in assembly language where we saw a 50x improvement in performance.
Q: Does wolfSSL have support for IP Hardware Acceleration such as OpenTitan?
A: We are currently evaluating Open Titan and various other IP solutions. We added RISC-V hardware acceleration to the Espressif ESP32-C3 and ESP32-C6 devices earlier this year.
Q: Can RISC-V devices be FIPS 140-3 Certified?
A: Yes! Recently we announced that wolfSSL is the First in the World to offer FIPS 140–3 Automated Submission with our NIST Certificate #4718.
See our prior blogs on:
- What is the difference between FIPS 140-2 and FIPS 140-3?
- FIPS vs FedRAMP Compliance and Requirements
The What is FIPS (short version) blog also applies to RISC-V with regards to how your RISC-V Operating Environment (“OE”) can be certified:
- You send us your hardware and toolchain.
- We run the initial tests which ensure the cryptography module behaves according to specification given your specific hardware and operating system.
- The CMVP certified lab runs and verifies the tests and their documentation.
- The test results are submitted to CMVP for review.
- Your specific operating environment is added to our certificate.
- You are FIPS 140 compliant in 60-90 days.
For more details, see our blog What is FIPS (long version).
Are you interested in RISC-V or FIPS Certification? We want to hear about your project!
If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
FIPS 140-3 and KDF’s (Key Derivation Functions)
As our readers know, wolfSSL is currently the leader in embedded FIPS certificates. The wolfCrypt module holds the world’s first SP800-140Br1 FIPS 140-3 Validated Certificate #4718.
One of the things that is critical to our users is Key Derivation Functions.
Key derivation functions are consumed by TLS 1.2, TLS 1.3, and SSH. We will support KDF’s for all three in our new FIPS 140-3 certificate.
If you have questions on FIPS 140-3, please contact us at fips@wolfSSL.com or see our FIPS FAQ. For any other inquiries, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
Why wolfSSH is Immune to the regreSSHion
Recently, Qualys found an exploit in OpenSSH’s sshd server application that they named regreSSHion. This exploit lets attackers run arbitrary code by exploiting a race condition in a signal handler.
wolfSSH is not a port or fork of OpenSSH. It is written from scratch by wolfSSL Inc. While wolfSSHd is using the same alarm signal to time out users, our signal handler only sets a flag. OpenSSH’s handler, on the other hand, called unsafe functions.
How wolfSSH Avoids This Vulnerability
wolfSSH’s signal handling is designed to be safer due to:
- Minimalist Signal Handling: Our handler only sets a flag, reducing race condition risks.
- Async-Signal Safe Operations: We ensure all operations within the signal handler are safe.
- Independent Implementation: wolfSSH is a complete rewrite, avoiding inherited vulnerabilities.
Conclusion
The regreSSHion exploit in OpenSSH underscores the need for safe signal handling. wolfSSH’s simple and secure approach to signal handling avoids the vulnerabilities found in OpenSSH, making it a safer choice for SSH server applications.
If you have any questions or want to talk about wolfSSH, please feel free to send us an email at facts@wolfssl.com or sales@wolfssl.com, or call us at +1 425 245 8247.
Download wolfSSL Now
Why Would You Want wolfSSL’s FIPS 140-3 Certificate
As our readers know, wolfSSL is currently the leader in embedded FIPS certificates. The wolfCrypt module holds the world’s first SP800-140Br1 FIPS 140-3 Validated Certificate #4718, valid through July 10th, 2029.
There are a few significant changes coming with FIPS 140-3. Over the years with many specification updates, a few things got a little inconsistent, so these inconsistencies have been brought back in line. wolfSSL is prepared to deliver the first and best implementation of FIPS 140-3, so get ready.
As FIPS 140-3 is the replacement for FIPS 140-2 it is always a good idea to switch over to it as soon as possible. You will also want wolfSSL’s FIPS 140-3 Certificate for many additional reasons that include:
- Merging the FIPS + ISO Standard
- CAST Testing Streamlined – just testing the algos they are actually using.
- Addition of TLS KDF in FIPS Boundary
- Addition of SSH KDF in FIPS Boundary
- Addition of RSA 4096
- Addition of ECDSA + SHA-3
- Removal of insecure algorithms: example Triple DES
Check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Eclipse Mosquitto Broker with wolfSSL
The wolfSSL team has expanded our Open Source Projects repository with a port for Mosquitto, an open source MQTT broker. Mosquitto users can benefit from wolfSSL’s lightweight SSL/TLS library.
Why should you use wolfSSL with Mosquitto?
- Portability across platforms and OS/RTOS environments
- Low/optimized memory use (runtime and footprint)
- Best-tested SSL/TLS/crypto implementation available, reducing vulnerabilities
- Current protocol support, up to TLS 1.3
- Progressive algorithm support (ChaCha20, Poly1305, Curve/Ed25519, etc)
- Commercial support available direct from wolfSSL engineers
- Commercial licenses available (in addition to standard GPLv2)
To use the Mosquitto port, follow the instructions in the patch file.
Set up wolfSSL
git clone https://github.com/wolfSSL/wolfssl.git
cd wolfssl
./autogen.sh
./configure --enable-mosquitto
make
make install
Set up Eclipse Mosquitto
git clone https://github.com/eclipse/mosquitto.git
cd mosquitto
git checkout v2.0.18
patch -p1 <
make WITH_TLS=wolfssl
make WITH_TLS=wolfssl test
Let us know what you think! We plan to add support for CMake builds. If you are interested or have questions about any of the above, please contact us at facts@wolfssl.com or +1 425 245 8247.
Download wolfSSL Now
ACVP and FIPS 140-3
As many in the FIPS world are aware NIST retired CAVP (Cryptographic Algorithm Validation Protocol) testing on June 30th of 2020, permanently replacing CAVP with ACVP (Automated Cryptographic Validation Protocol), also referred to as ACVTS (Automated Cryptographic Validation Test System).
In order to prepare for this transition NIST offered a “demo server” that Vendors like wolfSSL and FIPS Labs could utilize in standup of the new protocol. Once the transition was completed NIST also setup “production servers” which only FIPS Labs with a trusted certificate issued by NIST can connect to; Production Vectors passing are now the gateway to Algorithm Certification (IE certs like the ones wolfSSL just received!).
Algorithm Certification is a prerequisite to CMVP FIPS 140-3 validations. This design keeps in place the need for a FIPS lab to achieve algorithm certification but it now allows for Vendors such as wolfSSL to pre-test in advance of requesting production vectors for certification! wolfCrypt holds the world’s first SP800-140Br1 FIPS 140-3 Validated Certificate #4718.
wolfSSL also supports the new ACVP, which is the successor to the two decade old CAVP system from NIST. ACVP is intended to alleviate the manual steps of the older CAVP process, creating a more efficient and effective method for cryptographic algorithm testing and validation.
More on ACVP’s
ACVP stands for (Automated Cryptographic Validation Protocol) and it is the upcoming protocol that will be used for FIPS validation. This is going to be a prerequisite certificate for the CMVP(Cryptographic Module Validation Program) and CAVP(Cryptographic Algorithm Validation Program) certificates.
ACVP makes testing cryptographic algorithms and modules more efficient than the current method and more automated. There are three main parts to ACVP – a server, a proxy, and a client.
- The server side handles requests for test vectors and requests for validation among other requests. This side is operated by a FIPS lab or by NIST themselves.
- A proxy with ACVP can be used to communicate to offline systems and handle transferring information from the system being tested to the server. Often an ACVP client is used instead.
- The last part being a client, which is most relevant to users who are wanting to get their cryptography FIPS validated. An ACVP client is directly hooked up to the module to be tested and then communicates with the ACVP server to send requests for test vectors, responses of the results from running those tests, and requests for algorithm validation. There are multiple pieces required to build a ACVP client in order to complete a validation process, some of the large portions of the effort go into
- JSON parsing / creation for communication with a ACVP server
- HTTPS GET / POST / PUT / DELETE messages used for securely transporting information
- 2 factor authentication with TOTP (Time-Based One-Time Password Algorithm)
- Plugging in the test harness that runs crypto operations
Ultimately an ACVP client communicates with the server to validate cryptographic operations. This includes creating, or referencing meta data such as; vendor, OE, and module information. A simplified message flow for getting an algorithm validated is as follows: