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.
Please join us for our upcoming webinar with Sr. Engineer and Security Expert Daniele Lacamera!
Connected embedded systems that support remote updates of different artifacts must take into account the security risks involved. A secure boot mechanism is the best way to prevent the execution of unauthorized code. Our universal, open-source, secure bootloader, wolfBoot, takes care of authenticating and installing new valid firmware images. Due to its transport-agnostic update management, it can be combined with any secure transfer implementation to provide secure and reliable firmware updates.
In this short webinar, we explore some of the possibilities of real-life secure firmware update solutions, designed using the latest standards and best cryptography algorithms.
When: Mar 17, 2021 09:00 AM Pacific Time (US and Canada)
Topic: Webinar: Secure and reliable Firmware updates with wolfBoot
Register in advance for this webinar:
After registering, you will receive a confirmation email containing information about joining the webinar.
Bring any questions you may have, and we look forward to seeing you there!
wolfSSL supports Xilinx SoCs and FPGAs. The wolfSSL embedded SSL/TLS library can be used with FPGAs which use the MicroBlaze CPU and/or Zynq and Zynq UltraScale+ SoCs. Improved performance speeds with using the hardware crpyto can be seen. Increasing AES-GCM, RSA, and SHA3 operations performance. In addition to the performance gained a user also gets the additional security the hardware provides while executing the algorithms.
For more information contact
Did you know that you can build Qt 5.12 and 5.13 against the wolfSSL embedded SSL/TLS library instead of the default OpenSSL backend? Using wolfSSL as a TLS provider in Qt can have many advantages, depending on application and industry. Some of these may include:
- Progressive TLS protocol support (up to TLS 1.3)
- Smaller footprint size (wolfSSL is up to 20 times smaller than OpenSSL)
- Extensive testing (wolfSSL is the best-tested SSL/TLS implementation available today)
- Certifications (FIPS 140-2 / 140-3, DO-178C)
- Portability (wolfSSL supports over 30 operating systems)
- Hardware cryptography support
- Commercial support
- Consulting services and training available
To compile wolfSSL for Qt, wolfSSL includes a configure option named
--enable-qt. To compile Qt with the wolfSSL, first obtain the Qt patch file from wolfSSL (contact us at email@example.com), then follow the steps below:
1. Follow the Building Qt Guide to download needed Qt dependencies and initialize the Qt repository.
2. Change directories into the qt5 directory and checkout a branch between 5.12-5.13.
$ cd qt5 $ git checkout [branch_name]
3. Apply the wolfSSL Qt patch file to qt5.
$ cd qt5/qtbase $ patch -p1 < /path/to/wolfssl_qt_src.patch
4. Link to wolfSSL directly by setting the WOLFSSL_LIBS variable.
$ export WOLFSSL_LIBS="-L/path/to/wolf-install/lib -lwolfssl"
5. Configure Qt using the “-wolfssl-linked” option, and add wolfSSL header directories to the include path.
$ ./configure -wolfssl-linked -I/path/to/wolf-install/include/wolfssl -I/path/to/wolf-install/include
6. Build Qt.
7. Test the build.
$ make test
8. Or, run tests individually:
$ qtbase/tests/auto/network/ssl/qsslcertificate/tst_qsslcertificate $ qtbase/tests/auto/network/ssl/qasn1element/tst_qasn1element $ qtbase/tests/auto/network/ssl/qpassworddigestor/tst_qpassworddigestor $ qtbase/tests/auto/network/ssl/qsslcipher/tst_qsslcipher $ qtbase/tests/auto/network/ssl/qssldiffiehellmanparameters/tst_qssldiffiehellmanparameters $ qtbase/tests/auto/network/ssl/qsslellipticcurve/tst_qsslellipticcurve $ qtbase/tests/auto/network/ssl/qsslerror/tst_qsslerror $ qtbase/tests/auto/network/ssl/qsslkey/tst_qsslkey $ qtbase/tests/auto/network/ssl/qsslsocket/tst_qsslsocket $ qtbase/tests/auto/network/ssl/qsslsocket_onDemandCertificates_member/tst_qsslsocket_onDemandCertificates_member $ qtbase/tests/auto/network/ssl/qsslsocket_onDemandCertificates_static/tst_qsslsocket_onDemandCertificates_static
wolfSSL’s port into Qt has not been merged upstream yet, and is currently distributed in patch form. To request access to the wolfSSL Qt patch file, please email us at firstname.lastname@example.org!
The DO-178C wolfCrypt product which is a cryptographic foundation for secure boot and secure firmware update has been integrated and tested with various operating systems including multi-core ARINC 653 compliant Wind River VxWorks 653 and DDC-I’s DO-178C Level A Deos real-time operating system.
You can start using wolfCrypt as an application with ARINC 653 for space and time partitioning in safety-critical avionics real-time operating systems (RTOS).
Let us know if you need help with security for your ARINC 653 requirements. We can make a world of difference for you!
For more information about wolfSSL, or help getting started with using it in your project, contact us at email@example.com.
wolfSSL provides a robust and secure DTLS 1.2 implementation. During the handshake process, wolfSSL will re-send its previous flight of messages in the following circumstances:
- a network timeout has occurred waiting on data to arrive for processing
- the last message of the peer’s current flight has been received out of order
- a duplicate of the first message of the peer’s current flight has been received
These steps aim to provide a fast and reliable connection process. Unfortunately, the latter two cases may cause wolfSSL to use up more bandwidth than would be necessary for the handshake. If network bandwidth is at a premium for you and you are less worried about latency, then wolfSSL 4.7.0 has introduced a new macro:
Compile wolfSSL with this macro, either by adding it to your configure command (for example
./configure --enable-dtls CPPFLAGS=-DWOLFSSL_DTLS_RESEND_ONLY_TIMEOUT) or by defining it in your
user_setting.h header file. This macro instructs wolfSSL to only re-send its last flight of messages on a network timeout. In practice, wolfSSL will wait longer before re-sending handshake messages so that re-ordered messages get a chance to be processed and duplicate messages don’t trigger re-sends.
If you are interested in using the new features available in wolfSSL 4.7.0, please contact us at firstname.lastname@example.org.
wolfSSL has a major new product in development — wolfSentry, the universal, dynamic, embedded IDPS (intrusion detection and prevention system). At a high level, wolfSentry is a dynamically configurable logic hub, arbitrarily associating user-defined events with user-defined actions, contextualized by connection attributes, tracking the evolution of the client-server relationship. At a low level, wolfSentry is an embedded firewall engine (both static and fully dynamic), with O(log n) lookup of known hosts/netblocks.
wolfSentry will be fully integrated into the wolfSSL library, wolfMQTT, and wolfSSH, with optional in-tree call-ins and callbacks that give application developers turnkey IDPS across all network-facing wolfSSL products, with a viable zero-configuration option. These integrations will be available via simple
--enable-wolfidps configure options in wolfSSL sibling products.
The wolfSentry engine will be dynamically configurable programmatically through an API, or from a textual input file supplied to the engine. Callback and client-server implementations will also be supplied that deliver advanced capabilities including remote logging through MQTT or syslog, and remote configuration and status queries, all cryptographically secured.
Notably, wolfSentry is designed from the ground up to function well in resource-constrained, bare-metal, and realtime environments, with algorithms to stay within designated maximum memory footprints and maintain deterministic throughput. Opportunities include RTOS IDPS, and IDPS for ARM silicon and other common embedded CPUs and MCUs. wolfSentry with dynamic firewalling can add as little as 64k to the code footprint, and 32k to the volatile state footprint, and can fully leverage the existing logic and state of applications and sibling libraries.
The first beta release of wolfSentry is planned for April 2021, with turnkey product integrations to follow.
With the release of wolfSSL 4.7.0, we now support Keying Material Exporters for TLS as defined in RFC 5705! This new functionality allows applications to establish common secrets using the underlying (D)TLS connection. A popular project that makes use of exported keying material is OpenVPN (which wolfSSL supports!). It uses the user provided label, in the
--keying-material-exporter option, to generate secure shared secrets for use by plugins from the (D)TLS connection.
To export keying material in wolfSSL, use the new API:
int wolfSSL_export_keying_material(WOLFSSL *ssl, unsigned char *out, size_t outLen, const char *label, size_t labelLen, const unsigned char *context, size_t contextLen, int use_context);
This API outputs outLen data to out. The label and context match those defined in the RFC:
label – “a disambiguating label string”
context – “a per-association context value provided by the [wolfSSL user]”
If you are interested in using the new features available in wolfSSL 4.7.0, please contact us at email@example.com.
At wolfSSL we have found more and more customers choosing to use TLS 1.3. That’s great! More businesses are taking advantage of the improved security in the new protocol. These customers are finding that they need to use session tickets for resumption for the first time in their applications. In the latest release of wolfSSL, 4.7.0, we’ve made this easier than ever.
Session tickets require the implementation of a callback that encrypts and decrypts them on the server. There is a great example of how in
wolfssl/test.h. Take a look at
myTicketEncCb(). Previously the callback encrypted with ChaCha20-Poly1305 but now we include using AES-GCM instead. Choose the one that suites your application!
Default Encryption Callback
At wolfSSL we decided that a default callback was a valuable addition. wolfSSL 4.7.0 now includes a default session ticket encryption callback. Understanding how it works will inform you as to whether to use the default or write your own.
The callback is encrypting and decrypting the session ticket. You can choose which encryption algorithm to use by defining one of the following:
WOLFSSL_TICKET_ENC_CHACHA20_POLY1305– use ChaCha20-Poly1305
WOLFSSL_TICKET_ENC_AES128_GCM– use AES-GCM with 128-bit key
WOLFSSL_TICKET_ENC_AES256_GCM– use AES-GCM with 256-bit key
Otherwise, the default will be ChaCha20-Poly1305. If that algorithm is not compiled in then it will use AES-GCM with a 128-bit key.
There are two keys that are generated in the callback: primary and secondary. The primary key is generated, with a private random number generator, at first use and which point it is given a lifetime. By default, this is one hour. It can be customized at the second resolution by defining
WOLFSSL_TICKET_KEY_LIFETIME. The lifetime must be larger than the lifetime of a session ticket which is 5 minutes by default. This too can be changed at the second resolution by defining
SESSION_TICKET_HINT_DEFAULT. The longer the key lifetime the longer the exposure time if a key is compromised.
There are two lifetimes for a key: encryption and decryption. A key used to encrypt a ticket must be kept for the life of the ticket. Therefore the encryption lifetime is shorter than the total key lifetime, or decryption lifetime, by the ticket lifetime. See the diagram below:
If the primary key is expired for encryption but not for decryption, i.e is in the shaded area above, then a secondary key is generated on the next encrypt request. See below.
The secondary key is used until it expires for encryption and only then will a new primary key be generated. Note that in the scenario where session tickets are not commonly used, the primary key may expire for decryption before a new call for encryption. In this case, a new primary key will be generated. In a threaded environment, the generation of the global keys are protected by a mutex to ensure no overwriting.
Exporting and importing keys is also possible using:
wolfSSL_CTX_set_tlsext_ticket_keys(). These APIs are useful for sharing keys across processes or server machines and expiration times are included in the blob.
The default session ticket encryption callback will cover most use cases. If you want to use another encryption algorithm, have very limited memory, or need an advanced sharing strategy between servers then define
WOLFSSL_NO_DEF_TICKET_ENC_CB and set your own callback.
TLS 1.3 and TLS 1.2 Session Ticket Use
Finally, customers that haven’t been using session tickets for TLS 1.2 connections and now are for TLS 1.3, wanted to prevent session tickets being used with TLS 1.2. A reasonable request that we now support with the functions:
Calling these functions sets a flag against the context or object that results in the handshake ignoring session tickets on the client and server when the protocol version negotiated is TLS 1.2 or lower.
Session tickets are a integral part of TLS 1.3 for resumption. If you have questions about this feature, or have any commentary or feedback please reach out to our team at firstname.lastname@example.org or email@example.com!
Did you know that wolfSSL is transport agnostic, and can run on bare metal? Did you know that we have DO-178 artifacts for our software? Are you aware of MITM attacks or spoofing attacks that could compromise your network?
Let us know if you need help with security for your ARINC 664 transmissions. We can make a world of difference for you!
- April 2021 (2)
- March 2021 (27)
- February 2021 (29)
- January 2021 (22)
- December 2020 (21)
- 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)