RECENT BLOG NEWS
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:
Live Webinar: Medical Device Security
Learn a comprehensive overview of the current medical device landscape, the associated security challenges, and how wolfSSL’s solutions can help you navigate these complexities effectively.
Check it out: Medical Device Security: Key Strategies for Cyber Security and Data Protection
In the rapidly evolving medical device sector, ensuring the security and integrity of devices is paramount. Join our expert, Eric Blankenhorn, as he delves into the intricacies of the medical device landscape, exploring common attack vectors, regulatory requirements, and emerging security trends. Discover how wolfSSL’s suite of solutions can safeguard your devices and ensure compliance with industry standards.
Key topics that will be covered include:
- Overview and Trends: Introduction to wolfSSL and the latest security trends in medical devices.
- Regulatory Compliance: Learn about regulatory requirements and how wolfSSL meets them.
- Solutions and Use Cases: Discover wolfSSL’s solutions and real-world use cases in the medical sector.
- Key Technologies: Overview of wolfSSL’s SSL/TLS, wolfCrypt FIPS 140-2/3, and wolfBoot.
- Advanced Features: Explore wolfSentry and wolfSSL robust testing protocols.
Don’t miss out on this opportunity to elevate the security of your medical devices. Watch it now and take a proactive step towards safeguarding your devices against emerging threats.
As always, our webinars include Q&A sessions. If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
Changes to Maximum Alternative Names Macro in wolfSSL
In the 5.7.2 release, a new macro WOLFSSL_MAX_ALT_NAMES was introduced to limit the maximum number of allowed subject alternative names to a default value of 128 to prevent a possible denial of service attack. Unfortunately, after the release, some commonly used certificates were brought to our attention that have more than 128 subject alternative names. If you started using 5.7.2 and hit error -161 on certificate handling this may be your problem. This issue can be immediately mitigated by building with WOLFSSL_MAX_ALT_NAMES at a number larger, say 512 or 1024. The wolfSSL master branch already has an increased default of 1024 which should be sufficient for all real world certificates and will be included in the 5.7.3 release.
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 SHA-1 Retirement
In December 2022, NIST announced that the venerable SHA-1 algorithm, introduced in 1995, is at end-of-life. While wolfSSL does not use or recommend SHA-1 for new designs, we implement and support it in our products. With the NIST announcement, that will soon change for new FIPS 140 submissions, as we too will retire SHA-1.
The wolfCrypt module holds the world’s first SP800-140Br1 FIPS 140-3 validated certificate #4718 includes SHA-1. Thus, customers with an existing requirement for SHA-1 will be able to satisfy that requirement with wolfCrypt FIPS 140-3.
However, and regardless of FIPS status, customers still using SHA-1 in security-critical roles — signatures, authentications, HMAC, KDFs, etc. — should refactor the implicated systems to use a modern hash algorithm such as SHA-2 or SHA-3. wolfSSL stands ready to help our customers select and implement an appropriate migration path.
All FIPS 140 modules submitted on or after December 31 2025 will exclude SHA-1, to avoid early certificate sunset under the timeline announced by NIST.
In preparation for this transition, wolfSSL has already prepared its FIPS 140-3 codebase to build, run, and pass full ACVP testing, with SHA-1 gated out. We are also routinely testing our mainline and FIPS codebases to assure correct function with SHA-1 disabled.
For more information on the announcement from NIST, check here.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.
Download wolfSSL Now
wolfProvider Release 1.0.0
wolfSSL is proud to announce the release of wolfProvider 1.0.0. This release is the first official support for being a Provider for OpenSSL 3.x. Intended for use by customers who want to have a FIPS validated module, but are already invested in using OpenSSL. The provider gives drop-in replacements for the cryptographic algorithms used by OpenSSL. The wolfProvider uses the wolfCrypt engine underneath which is FIPS 140-3 certified.
Refer to the README.md found in the release for usage instructions. We also maintain a ChangeLog.md for a list of changes in each release.
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 secures the world’s first SP800-140Br1 compliant FIPS 140-3 Validation Certificate
In case you missed the news, wolfSSL Inc., a globally renowned leader in cryptography and network security solutions, is thrilled to announce the world’s first SP800 140Br1 compliant FIPS 140-3 Validation Certificate #4718 for wolfSSL’s wolfCrypt module.
EDMONDS, Wash., July 16, 2024 /PRNewswire-PRWeb/ — wolfSSL, INC., has partnered with AEGISOLVE, INC., on this unprecedented automated pilot program. Aegisolve is accredited by the National Voluntary Laboratory Accreditation Program (NVLAP Lab Code: 200802-0) for Cryptographic and Security Testing to assess and validate cryptographic based security systems and telecommunications infrastructure.
“As we move forward, wolfSSL remains focused on enhancing our technologies and expanding our capabilities. We are dedicated to continuous innovation in security. The advancements in our FIPS 140-3 module highlight our commitment to delivering state-of-the-art cryptographic solutions that meet the rigorous demands of today’s cybersecurity landscape.” Stated wolfSSL’s CTO, Todd Ouska. “Our collaboration with AEGISOLVE is just the beginning of a new era in cryptographic security, paving the way for future innovations and industry standards.”
“As a first of its kind, this is a tremendous achievement and a huge step forward for the next generation of FIPS 140-3 Validated Cryptographic Modules.” Reported Travis Spann, Founder and President of AEGISOLVE (NVLAP Lab Code: 200802-0). “AEGISOLVE is proud to have collaborated with the high-caliber wolfSSL team in the NIST SP800-140Br1 Pilot Project to achieve this groundbreaking milestone and we are eager to assist others to achieve the same goal.”
FIPS 140-3 validation testing is a rigorous and extensive process including detailed source code reviews, design reviews, documentation reviews, finite state machine verifications, CVE threat analysis, error injection, port sniffing, configuration management verifications, operational testing and test evidence auditing to the applicable requirements of the FIPS 140-3 Derived Test Requirements and FIPS 140-3 Implementation Guidance.
The National Institute of Standards and Technology (NIST) under the Cryptographic Module Validation Program (CMVP) issues the 140 Publication Series to coordinate the requirements and standards for cryptographic modules for use by departments and agencies of the United States federal government.
Highlights: Under wolfCrypt FIPS 140-2, power on times in standard and embedded targets could be slower due to power on self test requirements of the module. With the wolfCrypt FIPS 140-3 module self-tests are now only required the first time an algorithm is used or when the application decides is an ideal time to run the test during a slower event cycle and ahead of first algorithm use. This means much faster boot times and optimal power and resource consumption with careful planning!**
Differences between wolfCrypt FIPS 140-2 and wolfCrypt FIPS 140-3:
– 3DES removed from the module, 3DES no longer available
+ CAST (conditional algo self tests)
+ KDF-TLS, TLS v1.2 KDF and TLSv1.3 KDF
+ SSH KDF
+ AES-OFB mode
+ RSA 3072, 4096 and PSS
+ New Degraded mode of operation, which means that in the event of a CAST failure other algorithm services will remain available.
* FIPS 140-3: Federal Information Processing Standard Publication 140-3. For more about what FIPS is please checkout these blogs:
- What is FIPS (long version)
- What is FIPS (short version)
- Everything You Need To Know About FIPS 140-3
** For information on transitioning from 140-2 to 140-3 please checkout our blog: What is the difference between FIPS 140-2 and FIPS 140-3?
If you have questions about any of the above, please contact us at fips@wolfssl.com or +1 425 245 8247.
Download wolfSSL Now
Weekly updates
Archives
- July 2025 (3)
- June 2025 (22)
- May 2025 (25)
- April 2025 (24)
- March 2025 (22)
- February 2025 (21)
- January 2025 (23)
- December 2024 (22)
- November 2024 (29)
- October 2024 (18)
- September 2024 (21)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)