If our little meme didn’t already convince you otherwise, raccoon attacks are not a big deal when it comes to wolfSSL, read more on our internal review of raccoon attacks here: https://www.wolfssl.com/wolfssl-raccoon-attack/!
To learn more about us, checkout the wolfSSL embedded SSL/TLS library, star us on GitHub, and find out more about using TLS 1.3 on wolfSSL!
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Did you know that wolfSSL includes a port to the Tenasys INTime RTOS? You can read more in our original press release from Tenasys here: Secured INtime system traffic! Tenasys is using wolfSSL to secure their networked real-time systems and wolfSSL is happy to be integrated into the INTime networking stack which allows us to provide world renowned security to INTime SDK consumers.
wolfSSL also provides a FIPS 140-2 (and soon to be FIPS 140-3!) validated version of wolfCrypt! We also provide a “FIPS Ready” version of wolfSSL which is not associated with a FIPS validation, but includes FIPS-specific code. For users who may need a FIPS validated cryptography library in the future, FIPS Ready can be a good choice to make the transition as easy as possible.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
A big thank you to @eli.hughes who has shared results for their own project in hopes of further helping fellow users when building on an embedded Cortex M platform.
“I had a working project build with Segger Embedded Studio for a Nordic NRF52840 (64MHz Cortex M). We switched our build tooling to use cmake/ninja along with the newlib-nano libraries packaged with ARM GCC tools. One thing I noticed is that our TLS handshake in our application went from 3 seconds to about 16 seconds.
Using the built in wolf test functions, I was able to track down the issue.
While Segger Embedded Studio uses GCC, they have their own builds of the C standard libraries.The wolfcrypt ECC routines are very sensitive to how the C libraries are built.
Results
I could eventually get “better” performance than the SES custom library but had to use NewLib and not NewLib-nano. This results in a larger binary but the performance is much better.
wolf Test Time
Segger Embedded Studio w/ custom std libs: 208 seconds
ARM GCC Embedded w/ Newlib-Nano: 608 seconds
ARM GCC Embedded w/ Newlib: 202 seconds
ARM GCC Embedded w/ Newlib &WOLFSSL_SP_ARM_CORTEX_M_ASM : 175 seconds
In addition to using Newlib, I found the macro WOLFSSL_SP_ARM_CORTEX_M_ASM helped quite a bit. (Appears it has hand tuned ASM routines for SP math).
Apparently, newlib is built with speed optimizations and newlib-nano is built with size optimizations. I was surprised at the stark difference. I have other math heavy routines and the difference in execution speed is only 5% between -03 and -Os. It seems that the ECC SP routines have some sensitivity to the C library.
Hope this is helpful to anyone building for a Cortex M MCU.”
To read the original forum post: https://www.wolfssl.com/forums/post5456.html#p5456
Thank you @eli.hughes for sharing these findings. We hope others on the Cortex M will see this. The SP WOLFSSL_SP_ARM_CORTEX_M_ASM option is quite impressive for RSA/DH/ECC math speedups because it uses hand written assembly. At wolfSSL, we love to hear your findings and projects, so please feel free to reach out and keep us posted!
Additional Resources
Check out Eli’s article series for NXP on LPC55S69 and stay tuned for an upcoming set on cellular IoT and cloud connectivity.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
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.
This post has been cross posted from Daniel Stenberg’s blog – originally posted here.
We have started the work on extending wolfSSL to provide the necessary API calls to power QUIC and HTTP/3 implementations!
Small, fast and FIPS
The TLS library known as wolfSSL is already very often a top choice when users are looking for a small and yet very fast TLS stack that supports all the latest protocol features; including TLS 1.3 support – open source with commercial support available.
As manufacturers of IoT devices and other systems with memory, CPU and footprint constraints are looking forward to following the Internet development and switching over to upcoming QUIC and HTTP/3 protocols, wolfSSL is here to help users take that step.
A QUIC reminder
In case you have forgot, here’s a schematic view of HTTPS stacks, old vs new. On the right side you can see HTTP/3, QUIC and the little TLS 1.3 box there within QUIC.
ngtcp2
There are no plans to write a full QUIC stack. There are already plenty of those. We’re talking about adjustments and extensions of the existing TLS library API set to make sure wolfSSL can be used as the TLS component in a QUIC stack.
One of the leading QUIC stacks and so far the only one I know of that does this, ngtcp2 is written to be TLS library agnostic and allows different TLS libraries to be plugged in as different backends. I believe it makes perfect sense to make such a plugin for wolfSSL to be a sensible step as soon as there’s code to try out.
A neat effect of that, would be that once wolfSSL works as a backend to ngtcp2, it should be possible to do full-fledged HTTP/3 transfers using curl powered by ngtcp2+wolfSSL. Contact us with other ideas for QUIC stacks you would like us to test wolfSSL with!
FIPS 140-2
We expect wolfSSL to be the first FIPS-based implementation to add support for QUIC. I hear this is valuable to a number of users.
When
This work begins now and this is just a blog post of our intentions. We and I will of course love to get your feedback on this and whatever else that is related. We’re also interested to get in touch with people and companies who want to be early testers of our implementation. You know where to find us!
I can promise you that the more interest we can sense to exist for this effort, the sooner we will see the first code to test out.
It seems likely that we’re not going to support any older TLS drafts for QUIC than draft-29.
wolfSSL offers commercial support packages and consulting for cURL and tiny-curl!
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Three years ago, wolfSSL partnered with Infineon, making it easier to ensure security on Infineon-based projects. Today wolfSSL continues to foster our relationship with Infineon, including support for the latest AURIX boards.
AURIX (Automotive Real Time Integrated Next Generation Architecture) is a 32- bit Infineon microcontroller family targeting the automotive industry in terms of performance and safety. AURIX’s multicore architecture is based on up to three independent 32-bit TriCore CPUs.
Infineon designs, develops, manufactures and markets a broad range of semiconductors and system solutions. The focus of its activities is on automotive electronics, industrial electronics, mobile devices and chip card-based security. Combining entrepreneurial success with responsible action, Infineon addresses some of the most critical challenges of society: Efficient use of energy, environmentally friendly mobility and security in a connected world.
The wolfSSL embedded SSL/TLS library is a perfect fit for securing lightweight, resource-constrained devices. wolfSSL has a footprint size of 20-100kB, offers protocol support up to TLS 1.3 and DTLS 1.2, progressive algorithm support, hardware crypto support, and more.
Read more about our partnership with Infineon:
https://www.wolfssl.com/wolftpm-tested-nightly-infineon-optiga-tmp20-slb-9670/
https://www.wolfssl.com/wolfssl-announces-partnership-with-infineon/
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
In the meanwhile, check out the wolfSSLembedded SSL/TLS library, star us on GitHub, and learn more about the latestTLS 1.3 is available in wolfSSL.
wolfSSL and SYSGO are excited to announce our partner webinar: Security & Certifications for Critical Embedded Industries!
wolfSSL and SYSGO have teamed up to integrate wolfSSL’s SSL/TLS crypto library into PikeOS real-time operating system (RTOS), which includes a type 1 hypervisor. With this integration, wolfSSL brings a FIPS crypto library to PikeOS’ certified Separation Kernel in a pre-integrated bundle that ensures robust, proven Security for your project’s architecture.
Join this webinar for a demo in which you can also see two instances of wolfMQTT: One subscriber as the input side, and a publisher as the output side, each utilizing a TLS connection. Learn about the benefits of utilizing the latest TLS 1.3 protocol, for which wolfSSL was the first commercial implementation.
Watch the webinar here: Security & Certifications for Critical Embedded Industries
About SYSGO
SYSGO, the European leader in real-time operating systems (RTOS) and hypervisors for certifiable embedded systems, and wolfSSL, the leading provider of TLS and cryptography, have announced that they joined forces to integrate wolfSSL security technology into SYSGO’s PikeOS real-time operating system (RTOS) that includes a separation kernel based type 1 hypervisor. As part of the cooperation, SYSGO will provide pre-integrated wolfSSL technologies into the development environment of PikeOS and its embedded Linux ELinOS product.
Find out more about our partner announcement here: https://www.sysgo.com/news-events/news-articles/article/sysgo-integrates-wolfssl-security-technologies-into-its-pikeos-real-time-operating-system
Are you new to wolfSSL?
wolfSSL focuses on providing lightweight and embedded security solutions with an emphasis on speed, size, portability, features, and standards compliance, such as FIPS 140-2 and 140-3, RTCA DO-178C level A certification, and support for MISRA-C capabilities. wolfSSL supports industry standards up to the current TLS 1.3 and DTLS 1.2, is up to 20 times smaller than OpenSSL, offers a simple API, an OpenSSL compatibility layer, is backed by the robust wolfCrypt cryptography library, and much more. Our products are open source, giving customers the freedom to look under the hood.
See you there!
Additional Resources
In the meanwhile, 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.
Contact Us
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Check out this fantastic tutorial by Daniele Lacamera about wolfBoot and its TPM capabilities, hosted by our friends at TPM.dev! To watch the recording and slides from the presentation, check out the link below:
https://developers.tpm.dev/posts/wolfboot-with-tpm
About wolfBoot
wolfBoot is a portable, OS-agnostic, secure bootloader solution, relying on wolfCrypt for firmware authentication, providing firmware update mechanisms.
To learn more: https://www.wolfssl.com/products/wolfboot/
To watch more videos and tutorials on wolfSSL products, check out our Youtube Channel: https://www.youtube.com/wolfssl
Watch the Tutorial and Download the Slides: https://developers.tpm.dev/posts/wolfboot-with-tpm
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
FIPS 140-2 requires the use of validated cryptography in the security systems implemented by federal agencies to protect sensitive information. The wolfCrypt Module is a comprehensive suite of FIPS Approved algorithms. All key sizes and modes have been implemented to allow flexibility and efficiency.
The National Institute of Standards and Technology (NIST) is sending FIPS cert #2425 into sunset June 2021. For customers who will be impacted, the wolfCrypt Cryptographic Module maintains its #3389 certificate and can be used in conjunction with the wolfSSL embedded SSL/TLS library for full TLS 1.3 client and server support. Upgrade your FIPS cert with wolfSSL to stay afloat and benefit from:
Contact us to upgrade to FIPS cert #3389 at fips@wolfssl.com.
Additional Resources
Learn more about wolfSSL support for FIPS cert #3389: https://www.wolfssl.com/wolfcrypt-fips-certificate-3389-3/
For a list of supported Operating Environments for wolfCrypt FIPS, check our FIPS page: https://www.wolfssl.com/license/fips/
Our FIPS Story
wolfSSL is currently the leader in embedded FIPS certificates. We have a long history in FIPS starting with wolfCrypt FIPS 140-2 Level 1 Certificate #2425 as well as wolfCrypt v4 FIPS 140-2 Level 1 Certificate #3389. wolfSSL partners with FIPS experts KeyPair to bring you FIPS consulting services, and high assurance along each step of your FIPS certification process. Additionally, wolfSSL will be the first implementation of FIPS 140-3. Stay tuned for an upcoming webinar on this topic.
wolfSSL also provides support for a wolfCrypt FIPS Ready version of the library! wolfCrypt FIPS Ready is our FIPS enabled cryptography layer code included in the wolfSSL source tree that you can enable and build. You do not get a FIPS certificate, you are not FIPS approved, but you will be FIPS Ready. FIPS Ready means that you have included the FIPS code into your build and that you are operating according to the FIPS enforced best practices of default entry point, and power on self test.
wolfCrypt FIPS Ready can be downloaded from the wolfSSL download page located here: https://www.wolfssl.com/download/. More information on getting set up with wolfCrypt FIPS Ready can be found in our FIPS Ready User guide here: https://www.wolfssl.com/docs/fips-ready-user-guide/
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
We are hosting a special webinar on the Network Security Required for Avionics Systems for our Japan audience on September 29th!
Watch the webinar here : Security in Avionics
About
The avionics industry is currently moving to encourage avionics manufacturers to offer more interactive connectivity than ever before. The growing threat of cybersecurity attacks in communication systems is no exception in the avionics industry, and systems must be protected from these attacks.
To develop a secure system, you first need to define the required security level requirements. Often, these requirements fall to the relevant system level through a system-wide security assessment. As part of this process, you need a security plan that considers the entire product life cycle. Without a reliable safety foundation in the development life cycle, it is difficult to prove and maintain the safety of a product.
In this webinar, how will the architectural foundation of Deos, a Time & Space Partitioned RTOS that was certified as DO-178 Level A in 1998, and the cryptography and Deos provided by wolfSSL be integrated? Learn how to achieve the secure features that today’s avionics manufacturers need.
What an RTOS vendor needs to provide for safety and security:
This webinar will be held in English.
Watch the webinar now. After registering, we will send you a confirmation email regarding your participation in the webinar.
We look forward to your participation.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
Please see here for other webinar schedules and the release of the on-demand version .
wolfSSL did an internal review of the Raccoon Attack, in addition to reaching out to the research team behind the report, to determine if wolfSSL users are affected by this attack.
The report pertains to the use of static DH cipher suites and the re-use of a DH key with DHE cipher suites. The wolfSSL internal review concluded that:
A) wolfSSL does not support static DH. Conclusion – Not affected
B) wolfSSL ALWAYS generates a fresh key for every connection using DHE cipher suites with TLS 1.2 and lower protocol versions. (Special note: TLS 1.3 is not affected). Conclusion – Not affected
wolfSSL also received feedback from the research team that DHE-PSK cipher suites suffer from an inherent specification flaw that can leak the “length” of the Pre Shared Key under certain circumstances. This is due to the way the Premaster Secret (PMS) is generated for DHE_PSK cipher suites. The PMS is generated from:
Length | PMS | Length | PSK
The above is hashed and the runtime is affected by the length of the PSK being used. Attackers can measure this runtime remotely by sending ClientKeyExchange messages and measuring the response times to determine the length of the PSK. This is covered in more detail in section 4.2 of the Raccoon Attack paper (link included above and in the Ref below). Long, regular sized PSK’s are typically used but if this is of concern in your application wolfSSL recommends that ECDHE_PSK cipher suites be used in preference to DHE_PSK cipher suites.
Certain weak projects that claim to be secure will not respond to this attack. You should not use those products or projects because they will expose you.
If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.
