CMSIS-RTOS2 v2.1.3 running on a Silicon Labs EFM32G (Giant Gecko) chipset with wolfCrypt v4.6.1
Testing and standup for the EFM32 Giant Gecko was done collaboratively between wolfSSL Inc. and one of wolfSSLs’ customers. wolfCrypt had not previously been ported to or run on an EFM32 device so this was an exciting opportunity to both test on an EFM32 for the first time and to take wolfCrypt, running on the EFM32, through FIPS certification!
If you have any questions about getting wolfCrypt or wolfSSL up and running on your EFM32 target, not only is it possible, it is possible with FIPS 140-2 (and soon FIPS 140-3) certification as well!
Other OE’s added since the original ACVP client post are:
Linux 4.14 running on ARMv8 Cortex A53 with and without PAA (module version 4.5.4)
Windows CE 6.0 running on ARM Cortex-A8 (module version 4.6.2)
Linux 4.19 running on ARMv8 Cortex A53 with and without PAA (module version 4.5.4)
At the time of this posting wolfSSL has:
10 OE additions (1SUB) in coordination phase with the CMVP to be added to cert 3389
4 OE additions (1SUB) that have completed all testing and are ready to be submitted to the CMVP
5 OE additions (1SUB) actively in the testing process
1 OE addition (1SUB) in the queue to start
While the CMVP is no longer accepting 3SUB and 5SUB submissions for FIPS 140-2 (Cutoff date was 22 Sep 2021) wolfSSL Inc. continues to work on 1SUB OE additions. wolfSSL Inc. will continue to work on 1SUB OE additions to cert 3389 until 7 months before the expiration date of cert 3389.
wolfSSL Inc. was one of the first to submit for FIPS 140-3 and we expect to be one of the first to receive a 140-3 certificate. If you are looking for a commercial FIPS 140-3 solution, then look no further!
Recently, a lot of post-quantum activity has been happening here at WolfSSL.
First, we’ve simplified and unified our naming conventions for the variants of the post-quantum algorithms. We now refer to each variant by the algorithm submitter’s claimed NIST level. For example, what used to be referred to as LIGHTSABER is now known as SABER_LEVEL1 in our command-line applications and APIs.
We are now working towards making cURL resistant to “harvest now; decrypt later” attacks from a future quantum-enabled adversary. This protection is important if you value confidentiality over the long term. Do you know how long your data need to stay confidential?
This effort involves enabling the the use of the new post-quantum groups for TLS 1.3 in cURL when built with wolfSSL. For more details, please have a look at the following pull request: https://github.com/curl/curl/pull/7728. Once the GitHub pull request is merged, it will go into the next release of cURL.
Adding security to a connection comes at a cost. It takes a little time to perform the crypto operations and some memory gets used during the operations. Not all TLS implementations are equal … how much memory and how much time is lost depends on what TLS library is being used.
Recently OpenSSL came out with their 3.0.0 version and we did a quick collection of runtime memory used. Both to re-collect and make sure wolfSSL has not gotten any unexpected bloat and to check out what OpenSSL has done with their long awaited update. What we found surprised us. To run a simple, single TLS 1.2 connection OpenSSL 3.0.0 took up over 800 KiB of memory where wolfSSL 4.8.1 took up 37.4 KiB. This was collected using the very basic example TLS server from wolfssl-examples/tls/server-tls.c where the functions in it were changed to the OpenSSL versions (i.e. wolfSSL_new -> SSL_new), and changed to run a single connection instead of a loop. First linked to OpenSSL 3.0.0 then to wolfSSL 4.8.1. The memory used during the single connection was collected using Valgrind’s massif tool and then converted into a graph with massif-visualizer.
The memory usage difference between the two libraries is dramatic. A lot of the memory usage with OpenSSL 3.0.0 appears to be surrounding the startup/shutdown code but even when trimming that necessary portion of the runtime memory usage off, it takes over 100 KiB per connection versus wolfSSL’s 13.9 KiB per connection. This makes OpenSSL 3.0.0 difficult if not impossible to be used in some IoT devices and also requires more resources when scaled to large server use cases. Leading to more hardware required and more memory to handle the same number of connections (more $$$). You may ask though, what about performance? wolfSSL has a SP version that has optimizations for the public key algorithms commonly used in TLS connections. To configure with the “small” version of these optimizations the build “./configure –enable-opensslextra –enable-sp-math-all=small –enable-sp=small” could be used. Recollecting memory usage with the same server-tls.c app linked to the sp small version of wolfSSL used 26.3 KiB. Even less memory than before because along with optimizations for speed some optimizations for memory are also turned on.
Recently, we announced our wolfSSL libOQS integration and we said we were planning to hybridize our KEMs with NIST-standardized ECDSA. The hybridization is completed. This is a brief summary of why this matters and what we did.
It might come as a shock, but the sad truth is that we do not actually know that these algorithms will resist attacks from quantum computers. But wait, it gets worse. We don’t even know that these algorithms are safe against a conventional computer!! For all we know, someone could break lattice-based cryptography tomorrow. Please don’t panic. Why? Because this is how cryptography has always worked.
We started using ECC because it looked promising and as more and more people studied it and tried to break it and failed, the more we trusted it. We never actually knew that ECC was safe, but no matter how hard we tried, we simply could not break it and so we trusted it. But now we know we will have quantum computers so we have to move to something else.
So what do we do? One solution is to not put our full faith into these new algorithms. For now, in the early days, we can hedge our bets by hybridizing post-quantum algorithms with cryptographic algorithms that we actually trust. ECC with NIST standardized curves seem like good candidates and we have to keep using them anyways since FIPS compliance is a priority.
> Additionally, NIST plans to incorporate a cleaner, and therefore preferable, hybrid key establishment construction in a future revision of SP 800-56C:
> In any of the key derivation methods specified in SP 800 – 56C, the revision would permit a concatenation of Z and T, e.g., Z||T, to serve as the shared secret instead of Z. This would require the insertion of T into the coding for the scheme and the FIPS 140 validation code may need to be modified.
This means that as you are testing and experimenting in preparation for your migration to post-quantum cryptography you can do it in a more realistic situation; an environment that uses FIPS-certified software.
– The client’s key share is the classical public key concatenated with the post-quantum public key.
– The server’s key share is the classical public key concatenated with the post-quantum ciphertext.
– The shared secret is the classical shared secret concatenated with the post-quantum shared secret.
The future on the cryptography landscape is scary and exciting. We at wolfSSL Inc want to help you navigate these dangers with cutting edge technologies so that calm is what you’ll be feeling with wolfSSL in your corner..
This post has been cross posted from Daniel Stenberg’s blog – originally posted here.
Within 24 hours of the previous release, 7.79.0, we got a bug-report filed that identified a pretty serious regression in the HTTP/2 code that we deemed required a fairly quick fix instead of waiting a full release cycle for it.
So here’s 7.79.1 with several bug-fixes that we managed to queue up and merge in the seven days since the previous release. Enjoy
Release presentation
Numbers
the 203rd release
0 changes
7 days (total: 8,587) 10 bug-fixes (total: 7,280) 17 commits (total: 27,668)
0 new public libcurl function (total: 85)
0 new curl_easy_setopt() option (total: 290) 0 new curl command line option (total: 242) 11 contributors, 5 new (total: 2,489) 3 authors, 0 new (total: 948) 0 security fixes (total: 111) 0 USD paid in Bug Bounties (total: 16,900 USD)
Bug-fixes
This was a very short release cycle but there were two rather annoying bugs fixed and we also managed to get a few other corrections merged since they arrived perfectly timed…
HTTP/2: don’t change connection data
For one of the HTTP/2 fixes I was happy to land for 7.79.0 I overdid it a little and change a few lines too many. This caused my previous “fix” to also break common use cases and I had to follow up with this additional fix.
The reason this bug managed to sneak in, is that we don’t have test cases exercising this code path that depends on multiple concurrent HTTP/2 streams over a single connection.
fix the broken >3 digit HTTP response code detection
Probably the second worst bug and regression added in the previous release. When I made the HTTP/1 response code parser stricter and made it allow no more than three digits I messed up my sscanf() fu and forgot that %d also skips leading space. This made curl treat responses that had a fine response code that were followed by a leading digit in the “reason phrase” field get detected as badly formatted and rejected! Now we have test cases verifying this.
curl_multi_fdset: make FD_SET() not operate on sockets out of range
This function would wrongly skip the check for a too large file descriptor if libcurl was built to use poll(), which in this case was a totally unrelated and wrong check. Unfortunately, we don’t (yet) have test cases to catch FD_SETSIZE issues.
provide lib/.checksrc in the tarball
When you build curl with --enable-debug or otherwise run ‘make checksrc’, the code style is changed and due to this missing control file, it would erroneously report an error. The error happened because within a source file a specific checksrc-warning is disabled, but since lib/.checksrc was missing the warning was never enabled in the first place and this discrepancy was not allowed. We didn’t catch this before release because we don’t test-build release tarballs with debug enabled in the CI…
CURLSTS_FAIL from hsts read callback should fail transfer
libcurl didn’t properly handle this return code from the HSTS read callback. Instead of failing the transfer it would just continue! Now we have test cases verifying this.
handle unlimited HSTS expiry
When using HSTS and passing in an entry to libcurl that you specify should never expire, libcurl would pass that the maximum time_t value as an argument to the gmtime() function. The problem is then just that on 64 bit systems, the largest possible time_t value is so big that when converted into a struct tm, the number of years would still overflow the year struct field! This causes the function to return a NULL and libcurl would misbehave. Now we have test cases verifying this.
use sys_errlist instead of strerror on Windows
Another little fix to avoid strerror() on Windows as well where it also is documented as not thread-safe.
make the ssh tests work with openssh-8.7p1
The test suite fired up openssh for testing purposes in a way that no longer is accepted by this OpenSSH version.
Next
We will not change the schedule for next release due to this patch version. It means that the next feature window will instead be one week shorter than usual and that the next release remains set to get released on November 10, 2021.
Support
wolfSSL offers Curl support is available, and part of that support revenue goes into finding and fixing these kinds of vulnerabilities.
Customers under curl support can get advice on whether or not the advisories apply to them.
24×7 support on curl is available, and can include pre-notification of upcoming vulnerability announcements.
This post has been cross posted from Daniel Stenberg’s blog – originally posted here.
The curl factory has once again cranked out a new curl release.
Release presentation
Numbers
the 202nd release
3 changes
56 days (total: 8,580)
128 bug-fixes (total: 7,270)
186 commits (total: 27,651)
0 new public libcurl function (total: 85)
0 new curl_easy_setopt() option (total: 290)
0 new curl command line option (total: 242)
62 contributors, 25 new (total: 2,484)
41 authors, 16 new (total: 948)
3 security fixes (total: 111)
3,500 USD paid in Bug Bounties (total: 16,900 USD)
Security
This time we once again announce security advisories in association with the release.
CVE-2021-22945 is a double-free flaw in the MQTT code. Patch your old curl or upgrade to this version if you use it to send MQTT. The reporter of this flaw was awarded 1,000 USD from the curl bug-bounty program.
CVE-2021-22946 is a bug in response handling for several protocols (IMAP, POP3 and FTP) that bypasses the enforced TLS check so that even transfers that are explicitly told to require TLS can accidentally silently be performed in clear text! Rewarded 1,000 USD.
CVE-2021-22947 allows a mitm attacker to inject data into the protocol stream for FTP, IMAP, POP3 or SMTP in a way before the TLS upgrade so that curl accepts that data and uses it after after having upgraded to TLS. The untrusted data slips in and gets treated as trusted! Rewarded 1,500 USD.
These two latter ones came as an indirect result/inspiration from the NO STARTTLS research.
Changes
This release comes with three changes to take note of…
Users of the bearssl TLS backend will appreciate that it too now supports the CURLOPT_CAINFO_BLOB option so that the CA certificate easily can be provided in-memory by applications.
The cookie engine in curl now considers http://localhost to be secure and thus cookies that are marked “secure” will be sent over it – even when not using HTTPS. This is done because curl now since a while back makes sure that localhost is always truly local.
Users of the Secure Transport TLS backend can now use CURLINFO_CERTINFO to extract information about the server’s certificate chain.
Bug-fixes
Some of the most interesting bug-fixes we did this round.
use ares_getaddrinfo()
When you build curl to use the c-ares name resolver backend, curl will now use this function to get improved handling for IPv4+ IPv6. This also ups our requirement on c-ares to 1.16.0.
hyper works better
1xx responses, Transfer-Encoding and more have been fixed. The number of tests that are disabled for hyper builds are even fewer than before, but there’s still plenty of work to do before it can be considered not experimental.
cmake builds: avoid poll() on macOS
We have deliberately not used poll() in macOS builds for a long time when building with configure, and now we realized that cmake builds inadvertently had poll() use enabled, which caused curl to misbehave when for example connecting to a host while that connection got closed by the peer. poll() is now disabled on macOS even when cmake is used.
configure: also check lib64 for the OpenSSL pkg-config file
OpenSSL did a very late change just before they shipped version 3.0.0: they modified the default installation path for the library for 64 bit systems from $prefix/lib to $prefix/lib64, and subsequently we had to update our configure script detection logic accordingly. This helps configure to find OpenSSL v3 installs.
curl.1: provide examples for each option
The documentation now must provide at least one example command line for each command line option curl provides. This is verified in the build and will cause build errors if a file doesn’t comply! Feel free to suggest new, more or better examples when you start to see them in the man page.
HTTP 1.1: disallow >3-digit response codes
The HTTP protocol is defined to only allow three-digit numbers and now curl enforces that check stricter. This was in part made to align behavior when curl is built to use hyper.
HTTP 1.1: ignore content-length if any transfer-encoding is used
Non-chunked transfer-encoded content that also sends Content-Length headers is rare but was incorrectly handled by curl. Found when aligning behavior with hyper builds.
http_proxy: only wait for writable socket while sending request
Due to a mistake in the handling of what socket activity to wait for, curl could accidentally be made to busy-loop from the CONNECT request was sent to the proxy until the first data arrived.
Support mbedTLS 3.0.0
When mbedTLS released a new version with support for TLS 1.3 etc, they also modified the API a bit.
Ban strerror
We’ve had our own internal strerror replacement function for a long time (primarily due to it not being thread-safe), but a recent code review revealed that a lot of uses of this function had still crept in. Starting now, our code check tool (checksrc) will error if strerror is used in libcurl code.
The mailing lists move from cool.haxx.se to lists.haxx.se
Our old decommissioned server hosted 29 mailing lists. We moved most of them and killed off a few. All our mailing lists are now hosted on lists.haxx.se, including all the curl related ones of course! The old server name will simply redirect to the new one if you go there with a browser.
Support
wolfSSL offers Curl support is available, and part of that support revenue goes into finding and fixing these kinds of vulnerabilities.
Customers under curl support can get advice on whether or not the advisories apply to them.
24×7 support on curl is available, and can include pre-notification of upcoming vulnerability announcements.
wolfSSL is a lightweight embedded SSL/TLS library and we pride ourselves for being the best-tested crypto and SSL/TLS stack available on the market. From API unit testing to fuzz testing to continuous integration, we do it all to ensure we’re secure for our customers. Now we’re adding an additional static analysis tool to the arsenal, GrammaTech’s CodeSonar, for even more security assurance.
Static analysis also known as static application security testing (SAST) is the process of using a tool to scan for bugs and defects in source code without actually running a program. CodeSonar’s analysis of our codebase helped reveal even more ways to ensure that all of our bases are covered and security is maximized. By displaying the defects through thorough descriptions and visualizations, CodeSonar allowed us to come up with quick and efficient fixes. Setting up the program was straight-forward and it took about 2 hours to scan through the wolfSSL code base. The figure below offers a brief summary of the warnings generated by the analysis.
We reviewed all the warnings and marked them appropriately. CodeSonar also now allows us to list the new warnings that are introduced by code changes and allows us to maintain our security posture easily.
These were the defects detected throughout the hundreds of thousands of lines of code in the wolfSSL code base. Most of the Buffer Overruns generated have safeguards around them to make certain that they don’t happen during execution. A majority of the Uninitialized Variable warnings are generated because of the way wolfSSL initializes keys and other structs (initialized by constructor methods instead of direct initialization). And, the Null pointer Dereferences are to guarantee that nothing in the code makes it past where it needs to be.
CodeSonar did help us uncover possible leaks that we were able to fix within a day. With CodeSonar, our development team can take swift and methodical action whenever a problem is uncovered. We know that’s what customers like to hear! So if you’d like peace of mind knowing that your product incorporates a cutting-edge lightweight and secure TLS/Cryptography library, download wolfSSL.
Need more? Subscribe to our YouTube page for access to webinars.
As you may know, wolfSSL has integrated our FIPS-certified crypto module (wolfCrypt) with OpenSSL as an OpenSSL engine, a product we call wolfEngine. You may also know that OpenSSL 3.0 has done away with the engines paradigm in favor of a new concept, called providers. wolfSSL has begun work on an OpenSSL 3.0 provider, allowing you to use latest version of OpenSSL backed by our FIPS-certified wolfCrypt library. Like wolfEngine, the wolfSSL provider for OpenSSL is an excellent pathway for users looking to get FIPS compliance fast while still using OpenSSL.
wolfSSL is excited to announce support for using Silicon Labs Hardware acceleration. The EFR32 family of devices support multiple wireless interfaces with hardware cryptographic operations. wolfSSL can now offload cryptographic operations for dramatically increased performance on the Silicon Labs EFR32 family!
Our new support includes hardware acceleration of the following algorithms:
RNG
AES-CBC
AES-GCM
AES-CCM
SHA-1
SHA-2
ECDHE
ECDSA
The new functionality can be enabled by defining WOLFSSL_SILABS_SE_ACCEL. In user_settings.h More details are available in the README.md in wolfcrypt/src/port/silabs of the wolfSSL tree.
Benchmarks
Benchmark was performed on an EFR32 Gecko 2 (Series 1) using the xGM210P022.
wolfSSL now supports NXP’s SE050 hardware security chip. This is an external I2C crypto co-processor chip that supports RSA key sizes up to 4096-bit, ECC curves up to 521 bit and ED25519 / Curve25519. You can see the full implementation details in GitHub pull request 4322.
We have also expanded our Kinetis LTC support to accelerate RSA key generation. This made it into our v4.8.1 release of wolfSSL.
NXP Semiconductor is a key member of wolfSSL’s partner network. wolfSSL ships with support for offloading cryptographic operations onto several NXP devices, such as the Coldfire, Kinetis, LPC, S32 and i.MX microprocessors. Additionally we support hardware cryptographic acceleration using NXP’s CAU, MMCAU, LTC, CAAM and SE050 hardware. If your target is missing, tell us!
wolfSSL develops a full suite of products supporting NXP designs. Learn about wolfBoot secure boot and TLS 1.3 firmware update with FreeRTOS and wolfSSL on NXP Freedom Board K64 here. After the release of wolfSSL version 4.2.0, we provide improved support for crypto hardware performance, now on NXP mmCAU. Download the latest wolfSSL version 4.8.1 here!
