RECENT BLOG NEWS
Or sign up to receive weekly email notifications containing the latest news from wolfSSL.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.
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.
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!
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.
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! Contact us at email@example.com to learn more.
Happy Monday to our wolfSSL community! This week we will be participating in two very exciting events! Come visit us virtually to learn more about wolfSSL as well as the greater community in cryptography and embedded systems.
September 21st – 24th is the virtual International Cryptographic Module Conference (ICMC20)!
ICMC is the leading event for global expertise in commercial cryptography. At ICMC20 Virtual over 400 industry leaders from 27 countries collaborate to address the challenges faced by those who develop, produce, test, specify, and use cryptographic modules. In this upcoming event, there will be a strong emphasis on standards such as FIPS 140-3, ISO/IEC 19790, eEIDAS, and Common Criteria.
To learn more:
September 23rd – 24th is the MtoM & Connected Objects – Embedded Systems Conference! This conference will be a virtual event surrounding embedded systems and software, display, visualization, design and testing of systems. It enables attendees to discover new technological trends, standards and regulations of IoT, MtoM and embedded systems markets and supports them in developing or deploying new projects.
Our partner AC6 will be hosting at our stand A12. Stop by to learn about this exciting new partnership and how your customers can benefit from wolfSSL training in SSL/TLS and the importance of security in embedded systems.
To learn more: https://www.salon-iot-mtom.com/
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:
For more information regarding wolfSSL or any additional questions, please contact firstname.lastname@example.org.
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.
Webinar Date and Time
The webinar will be offered twice: On September 22nd at 4PM CEST for our customers in the AMER and EMEA region as well as on September 23rd at 9AM CEST for those in the APAC region.
- Register for the September 22nd, 2020 at 04:00 PM (CEST) slot: https://us02web.zoom.us/webinar/register/WN_VoeRxMsfTUij2cG9LV063g
- Register for the September 23rd, 2020 at 09:00 AM (CEST) slot: https://us02web.zoom.us/webinar/register/WN_xAJRriyuT-G40V9NWPHADw
After registering, you will receive a confirmation email containing information about joining the webinar.
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!
Please contact us at email@example.com with any questions about the webinar and for technical support, please contact firstname.lastname@example.org or view our FAQ page. As always, there will be a Q&A session following the live presentation.
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:
wolfBoot is a portable, OS-agnostic, secure bootloader solution, relying on wolfCrypt for firmware authentication, providing firmware update mechanisms.
- Multi-slot partitioning of the flash device
- Integrity verification of the firmware image(s) using SHA2 or SHA3
- Authenticity verification of the firmware image(s) using wolfCrypt’s digital signature algorithms (ECDSA SECP256R1, Ed25519, RSA 2048/4096)
- Highly reliable, transport-agnostic firmware update mechanism
- Anti-rollback protection (via version numbering)
- Hardware-assisted dual-bank swapping
- Support for secure keystores, OTP memory, TPM 2.0
- Support for encrypted firmware images
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
And as always, contact us at facts@wolfssl for general questions and email@example.com for technical help!
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:
- Algorithm support for TLS 1.3!
- New algorithms such as AES (CBC, GCM, CTR, ECB), CVL, Hash DRBG, DSA, DHE, ECDSA (key generation, sign, verify), HMAC, RSA (key generation, sign, verify), SHA-3, SHA-2, SHA-1, and Triple-DES
- Hardware encryption support for NXP’s Cryptographic Assistance and Assurance Module (CAAM), NXP Memory-Mapped Cryptographic Acceleration Unit (mmCAU), Intel’s AES-NI, and more
- Support for secure elements and TPM’s
- Interoperability with wolfBoot, wolfSSH, and wolfTPM
- Integration support for third party libraries such as strongswan, nginx, python and more
Contact us to upgrade to FIPS cert #3389 at firstname.lastname@example.org.
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/
We are hosting a special webinar on the Network Security Required for Avionics Systems for our Japan audience on September 29th!
Registration Link: https://us02web.zoom.us/webinar/register/5715959850834/
Date and Time: Tuesday, September 29, 2020 10:00 AM Japan Time
Speaker: wolfSSL Inc. Software Engineer, Tesfa Mael
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:
- · Deos as a foundation for a secure platform
- · Secure Boot
- · Secure Update
- · Secure Transport
- · Cryptography (a building block for all of the above)
This webinar will be held in English.
For those who wish to participate, please click here. 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, please contact us at email@example.com .
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.
For any questions or concerns feel free to contact wolfSSL support at firstname.lastname@example.org.
This post has been cross posted from Daniel Stenberg’s blog – originally posted here.
Today I’m happy to bring you the news that tiny-curl 7.72.0 was just released. Now it also builds and runs fine on the Micrium OS.
Timed with this release, I changed the tiny-curl version number to use the same as the curl release on which this is based on, and I’ve created a new dedicated section on the curl web site for tiny-curl:
Head over there to download.
With tiny-curl you get an HTTPS-focused small library, that typically fits in 100Kb storage, needing less than 20Kb of dynamic memory to run (excluding TLS and regular libc needs).
You want to go with libcurl even in these tiny devices because your other options are all much much worse. Lots of devices in this category (I call it “devices that are too small to run Linux“) basically go with some default example HTTP code from the OS vendor or similar and sure, that can often be built into a much smaller foot-print than libcurl can but you also get something that is very fragile and error prone. With libcurl, and tiny-curl, instead you get:
- the same API on all systems – porting your app over now or later becomes a smooth ride
- a secure and safe library that’s been battle-proven, tested and checked a lot
- the best documented HTTP library in existence
- commercial support is readily available
tiny and upward
tiny-curl comes already customized as small as possible, but you always have the option to enable additional powers and by going up slightly in size you can also add more features from the regular libcurl plethora of powerful offerings.
wolfSSL offers commercial support packages and consulting for cURL and tiny-curl! Contact us at email@example.com to learn more.
Storing encrypted firmware updates with wolfBoot
At wolfSSL, we work together with our customers to better understand the real-life scenarios in embedded security.
One of the concerns that we have been addressing the most when it comes to secure boot is the protection of the ‘data at rest’ when the firmware updates are received and stored on unprotected non-volatile memory supports, such as external SPI FLASH devices or other customized forms of storage.
wolfBoot, our fully open source secure bootloader solution for embedded systems, now supports encrypted external partitions, to safely store your firmware updates during the update process. The algorithm used is ChaCha20, implemented via wolfCrypt.
Each update can now be signed-and-encrypted to be distributed on the target, and the application can set a decrypt key at runtime, using wolfBoot API. This support has been recently merged in master branch and it will be included in the next release.
Here is how to enable it:
- Compile the bootloader with the option `ENCRYPT=1`
- Create a buffer of 44 random Bytes, and store it into a `secret_key` file. This file now contains the key and vector that will be used for the encryption of the firmware image.
- Add the extra step `–encrypt secret_key` to the sign tool invocation. This will generate an extra *_signed_and_encrypted.bin image file
- Transfer the _signed_and_encrypted image to the target. The system application can still use wolfBoot HAL to access external devices, because encryption is only enabled in bootloader mode.
- Set the secret key and vector in the application via the wolfBoot API call `wolfBoot_set_encryption_key()`. The secret key could be e.g. pre-stored in a secure element, or transmitted during the update through a secure channel.
- Initiate the update as usual, with `wolfBoot_trigger_update()`, and reboot. wolfBoot will attempt to decrypt and verify the firmware, and initiate the installation if the verification is successful.
The image stored in the UPDATE partition is always encrypted, including the backup copy of the previously running system during the installation. This ensures that reading out the partition would never reveal its content as long as the secret encryption key is kept safe.
The partition encryption support in wolfBoot is an additional protection for data at rest, when the firmware is stored on external devices where it is not possible to activate any effective read-out protection.
For data in motion, as usual, we recommend transferring the updates using TLS 1.3, and always using encrypted communication towards the firmware consumer device.
Contact us at firstname.lastname@example.org and ask how we can help design and integrate tailored custom secure boot solutions specific to your embedded systems.
- November 2020 (14)
- October 2020 (7)
- September 2020 (22)
- August 2020 (11)
- July 2020 (8)
- June 2020 (14)
- May 2020 (15)
- April 2020 (14)
- March 2020 (4)
- February 2020 (24)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (24)
- August 2019 (21)
- July 2019 (8)
- June 2019 (13)
- May 2019 (35)
- April 2019 (31)
- March 2019 (20)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (10)
- October 2018 (18)
- September 2018 (18)
- August 2018 (8)
- July 2018 (15)
- June 2018 (29)
- May 2018 (15)
- April 2018 (11)
- March 2018 (19)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (7)
- September 2017 (8)
- August 2017 (6)
- July 2017 (11)
- June 2017 (8)
- May 2017 (10)
- April 2017 (5)
- March 2017 (7)
- February 2017 (1)
- January 2017 (8)
- December 2016 (3)
- November 2016 (2)
- October 2016 (18)
- September 2016 (8)
- August 2016 (5)
- July 2016 (4)
- June 2016 (10)
- May 2016 (4)
- April 2016 (5)
- March 2016 (4)
- February 2016 (12)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (6)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (13)
- January 2015 (6)
- December 2014 (7)
- November 2014 (3)
- October 2014 (2)
- September 2014 (11)
- August 2014 (6)
- July 2014 (9)
- June 2014 (11)
- May 2014 (11)
- April 2014 (9)
- March 2014 (3)
- February 2014 (3)
- January 2014 (5)
- December 2013 (9)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (8)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (9)
- December 2012 (13)
- November 2012 (5)
- October 2012 (7)
- September 2012 (4)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (5)
- April 2012 (7)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (6)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (8)
- May 2011 (12)
- April 2011 (4)
- March 2011 (12)
- February 2011 (8)
- January 2011 (13)
- December 2010 (17)
- November 2010 (12)
- October 2010 (14)
- September 2010 (11)
- August 2010 (20)
- July 2010 (14)
- 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)