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.
Because of the exceptional portability of our wolfCrypt library, plus our fantastic team of engineers, we’re able to frequently add new ports. We’ll be showcasing a few of the latest open source project ports over the next ten weeks, so tune in!
First, we just integrated wolfSSL with the NTP (Network Time Protocol) project. This port allows for the use of NTP with our FIPS-validated crypto library, wolfCrypt. NTP is designed to synchronize the clocks of computers over packet-switched, variable-latency data networks. For more information on NTP, you can also visit the project’s website at ntp.org.
We’ve enabled NTP to be able to call into wolfSSL through the OpenSSL compatibility layer. You can access the GitHub page here: https://github.com/wolfSSL/osp/tree/master/ntp/4.2.8p15
The wolfSSL library has for a long time supported encryption and decryption using ECC with an implementation of ECIES (Elliptic Curve Integrated Encryption Scheme). Recently the ECIES code was updated to support the SEC.1 and ISO/IEC 18033 variants.
ECIES is the elliptic curve equivalent of the RSA encryption algorithm and is useful as a key encapsulation mechanism (KEM). KEMs are used to established shared keys between two parties that have never communicated before. By securing, say, a symmetric key with the EC public key, only the owner of the EC private key can derive it.
Unlike RSA encryption, ECIES can also be used for sending a message securely to the owner of the private key (i.e. data encapsulation mechanism (DEM)). The integration of a symmetric cipher in the ECIES algorithm allows it to encrypt any amount of data.
In the wolfSSL library, the default algorithm is now as described in SEC.1. If you require the original wolfSSL algorithm then configure with
-–enable-ecies=old or define
WOLFSSL_ECIES_OLD. Alternatively, if the ISO/IEC 18033 algorithm is required then configure with
-–enable-ecies=iso18033 or define
Contact us at firstname.lastname@example.org to learn more!
The wolfSSL library includes a useful tool for sniffing TLS traffic. This can be used to capture and decrypt live or recorded PCAP traces when at least one of the keys is known. Typically a static RSA ciphersuite would be used, however with TLS v1.3 only Perfect Forward Secrecy (PFS) ciphers are allowed. For TLS v1.3 all cipher suites use a new ephemeral key for each new session.
In order to solve this we added a “static ephemeral” feature, which allows setting a known key that is used for deriving a shared secret. The key can be rolled periodically and synchronized with the sniffer tool to decrypt traffic. This feature is disabled by default and is only recommended for internal or test environments.
As a proof of concept we added this support to Apache httpd to demonstrate real-time decryption of web traffic. We are also working on a key manager to assist with key rolling and synchronization.
A use case that might be interesting is a company internal web server that requires auditing.
Contact us at email@example.com to learn more!
The wolfSSL embedded SSL/TLS library supports many popular hardware secure elements from several suppliers using different technologies.
Some of these hardware elements are specifically designed to enable end-to-end security in IoT devices, by providing a hardware ‘Root of Trust’, and by providing asynchronous cryptography functionality and key vaults.
GSMA is an alliance representing mobile operators, manufacturers and companies focusing on the mobile communication industry. The alliance has published the guidelines to implement a Root-of-trust mechanism, IoT SIM Applet For Secure End-to-End Communication, also known as IoT-SAFE. This technology promotes the use of SIM cards as Root-of-Trust to secure applications and services running on embedded systems connected through the mobile network. IoT-SAFE opens new possibilities for key provisioning through a component that is, in fact, already designed to support end-to-end security within different layers of the protocol.
wolfSSL, in collaboration with partners in the mobile industry, has recently developed an IoT-SAFE module for the wolfSSL embedded TLS library.
The code is portable and it’s designed to be used on an embedded board, equipped with an LTE modem and an IoT-SAFE capable SIM card, but can be easily adapted to run on any environment that has access to a communication channel with an IoT-SAFE capable SIM card.
The module includes several features, such as the possibility to use IoT-SAFE as true random number generator, access asymmetric key operations on the SIM, as well as generate, store and retrieve keys in the secure vault. The most important feature though, is the possibility to equip wolfSSL sessions with IoT-SAFE support, so that all the operations during the TLS handshake for that session are executed through IoT-SAFE commands.
To demonstrate a full TLS endpoint using IoT-SAFE API to complete the handshake and establish a TLS session, we have prepared an example that uses a SIM card pre-provisioned with our test ECC certificate and keys. Both TLS 1.3 and 1.2 are supported.
Securing Device-to-Cloud communication with a robust end-to-end strategy is of course the main priority of this module. However, we are looking forward to seeing wolfSSL IoT-SAFE support used in different applications and use cases.
Are you planning to integrate GSMA IoT-Safe in your TLS or cryptography design? Let us know about your architecture and use cases, write us an email to firstname.lastname@example.org.
wolfSSL is an exhibiting sponsor at this year’s International Cryptographic Module Conference (ICMC) in Maryland. We’re all about doing cryptography right, and as the best-tested crypto on the market, we can’t wait to talk through securing your projects at ICMC.
Find us September 1-3 in Washington DC at the Hyatt Regency Bethesda or online to join this hybridized event! We’re talking about:
- Benchmarking wolfCrypt for your target
- FIPS 140-3 validated crypto
- The advantages of TLS 1.3
- wolfCrypt as an engine for OpenSSL
- TPM/HSM support
- OCSP support
- TLS 1.3 sniffing
- wolfRand, wolfSSL’s FIPS module with a hardware entropy source
- DO-178C DAL A
- Post-quantum algorithms in wolfSSH
- RISC-V support in wolfBoot
- Commercial-style developer support backed 24×7 by a team of real Engineers
- Why open source matters for best-tested security
Come meet us at ICMC and bring all your cryptography questions! In the meantime, download and star wolfSSL on GitHub. If you’d like to book a meeting online or in-person, email facts@wolfSSL.com. We can’t wait to see you!
ExpressVPN’s Lightway protocol is out of beta and leverages wolfSSL for secure crypto. As such, the “modern VPN” inherits speed, performance, best-tested security and is able to maintain it’s lightweight mobility.
“In terms of the encryption, [ExpressVPN’s Chief Architect, Pete] Membrey explained that Lightway uses wolfSSL. ‘To be clear, we didn’t roll any of our own crypto. It’s something we – as a principle – keep well away from. It’s extremely easy to get that wrong so we outsourced it, effectively, to a library that’s open source and has been audited.’
wolfSSL is used on millions of devices already and is the library that powers Pokémon GO. It’s designed for embedded devices, so it’s fast on Apple M1 chip, on routers, iPhones and more.”
A block cipher is an encryption method that applies a deterministic algorithm along with a symmetric key to encrypt a block of text, rather than encrypting one bit at a time as in stream ciphers. For example, a common block cipher, AES (Advanced Encryption Standard), encrypts 128 bit blocks with a key of predetermined length: 128, 192, or 256 bits. Block ciphers are pseudorandom permutation (PRP) families that operate on the fixed size block of bits. PRPs are functions that cannot be differentiated from completely random permutations and thus, are considered reliable, until proven unreliable.
Block cipher modes of operation have been developed to eliminate the chance of encrypting identical blocks of text the same way, the ciphertext formed from the previous encrypted block is applied to the next block. A block of bits called an initialization vector (IV) is also used by modes of operation to ensure ciphertexts remain distinct even when the same plaintext message is encrypted a number of times.
Some of the various modes of operation for block ciphers include CBC (cipher block chaining), CFB (cipher feedback), CTR (counter), and GCM (Galois/Counter Mode), among others. AES, described above, is an example of a CBC mode where an IV is crossed with the initial plaintext block and the encryption algorithm is completed with a given key, and the ciphertext is then outputted. This resultant cipher text is then used in place of the IV in subsequent plaintext blocks.
For information on the block ciphers that are implemented in wolfSSL or to learn more about the wolfSSL lightweight, embedded SSL library, visit wolfssl.com or contact us at email@example.com.
 Pseudorandom permutation. (2014, November 23). In Wikipedia, The Free Encyclopedia.Retrieved 22:06, December 18, 2014, from http://en.wikipedia.org/w/index.php?title=Pseudorandom_permutation&oldid=635108728.
 Margaret Rouse. (2014). Block Cipher [Online]. Available URL: http://searchsecurity.techtarget.com/definition/block-cipher.
 Block cipher mode of operation. (2014, December 12). In Wikipedia, The Free Encyclopedia. Retrieved 22:17, December 18, 2014, from http://en.wikipedia.org/w/index.php?title=Block_cipher_mode_of_operation&oldid=637837298
 Wikimedia. (2014). Available URL: http://upload.wikimedia.org/wikipedia/commons/d/d3/Cbc_encryption.png.
A stream cipher encrypts plaintext messages by applying an encryption algorithm with a pseudorandom cipher digit stream (keystream). Each bit of the message is encrypted one by one with the corresponding keystream digit. Stream ciphers are typically used in cases where speed and simplicity are both requirements. If a 128 bit block cipher (such as AES [Advanced Encryption Standard]) were to be used in place of a stream cipher where it was encrypting messages of 32 bit blocks, 96 bits of padding would remain. This is an inefficient approach and is one reason why a stream cipher would be preferred over a block cipher, since stream ciphers operate on the smallest possible unit.
Some common stream ciphers include Salsa20, ChaCha (a seemingly better variant of Salsa20), Rabbit, and HC-256, among others. Block ciphers can be used in stream mode to act as a stream cipher. If a block cipher is run in CFB (cipher feedback), OFB (output feedback), or CTR (counter) mode, it does not require additional measures to handle messages that aren’t equivalent to the length of multiples of the block size, and eliminates the padding effect.
For information on the stream ciphers that can be implemented with wolfSSL or to learn more about the wolfSSL embedded SSL/TLS library, please view our wolfSSL product page or contact us at firstname.lastname@example.org.
 Stream cipher. (2014, November 19). In Wikipedia, The Free Encyclopedia. Retrieved 16:19, December 19, 2014, from http://en.wikipedia.org/w/index.php?title=Stream_cipher&oldid=634494612.
 Margaret Rouse. Stream Cipher. (2005). Available URL: http://searchsecurity.techtarget.com/definition/stream-cipher.
 Block cipher mode of operation. (2014, December 12). In Wikipedia, The Free Encyclopedia. Retrieved 17:13, December 19, 2014, from http://en.wikipedia.org/w/index.php?title=Block_cipher_mode_of_operation&oldid=637837298.
Users can test the latest development master of wolfSSL with the latest version of strongSwan using the following setup:
wolfSSL Build and Installation Steps
$ git clone https://github.com/wolfSSL/wolfssl.git $ cd wolfssl $ ./autogen.sh $ ./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA" $ make $ make check $ sudo make install
strongSwan Build and Installation Steps
# if the following packages are not already installed: $ sudo apt-get install flex bison byacc libsoup2.4-dev gperf $ git clone https://github.com/strongswan/strongswan.git $ cd strongswan $ ./autogen.sh # if packages are missing autogen.sh must be re-run $ ./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem $ make $ make check $ sudo make install
wolfSSL has had interest in enabling FIPS 140-2/140-3 support with strongSwan so our engineers verified everything is working with the wolfCrypt FIPS 140-2 validated Module!
The steps wolfSSL used for testing are as follows:
Testing was done using the wolfSSL commercial FIPS release v4.7.0 which internally uses the wolfCrypt v4.0.0 FIPS 140-2 validated Crypto Module. It was located in the
/home/user-name/Downloads directory on the target test system, Linux 4.15 Ubuntu 18.04 LTS running on Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz.
- wolfSSL was configured and installed with these settings:
./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA -DFP_MAX_BITS=8192" --enable-ed25519 --enable-curve25519 --enable-fips=v2 --enable-intelasm --prefix=$(pwd)/../fips-install-dir make make install
- A custom install location was used which equated to
/home/user-name/Downloads/fips-install-dirand the configuration for strongSwan accounted for this.
- strongSwan was cloned to
git clone https://github.com/strongswan/strongswan.git”
- StongSwan was configured and installed with these settings:
./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem --prefix=$(pwd)/../strongswan-install-dir wolfssl_CFLAGS="-I$(pwd)/../fips-install-dir/include" wolfssl_LIBS="-L$(pwd)/../fips-install-dir/lib -lwolfssl" make make install make check
- In the make check stage of the test, it was observed that 1 test was failing.
Passed 34 of 35 'libstrongswan' suites FAIL: libstrongswan_tests ================== 1 of 1 test failed ==================
- Reviewing the logs it was apparent one of the RSA tests was failing.
- Upon further debugging it turned out the failure was a test in strongSwan that was attempting to create an RSA key size of 1536-bits.
Running case 'generate': DEBUG: key_sizes[_i] set to 1024 + PASS DEBUG: key_sizes[_i] set to 1536 - FAIL DEBUG: key_sizes[_i] set to 2048 + PASS DEBUG: key_sizes[_i] set to 3072 + PASS DEBUG: key_sizes[_i] set to 4096 + PASS
wolfSSL has a function
RsaSizeCheck() which in FIPS mode will specifically reject any non FIPS RSA key sizes so this failure was not only expected, but it is a good thing for those wanting to use strongSwan in FIPS mode and ensure only FIPS-validated RSA key sizes will be supported!
wolfSSL is pleased that with the latest release of wolfSSL v4.7.0 and the wolfCrypt FIPS 140-2 module validated on FIPS certificate 3389, strongSwan support is working splendidly and wolfSSL engineers will be making efforts to ensure continued support into the future!
If you have any questions about wolfSSL, wolfCrypt FIPS, or strongSwan and wolfSSL together please contact our support staff anytime at email@example.com or via our Zendesk portal by registering and opening a support incident at wolfssl.zendesk.com.
Microsoft’s IoT Developer Advocate, Dave Glover, has put together an Azure Sphere Cloud example that uses the wolfMQTT client library and wolfSSL’s Embedded TLS library to demonstrate a secure IoT device connection using the Altair 8800 emulation project.
Find the project here and read more about Dave’s effort to get the Altair emulation connected to the Internet of Things!
Everyone deserves to have their IoT data secure, and wolfSSL provides the best libraries to accomplish that. Secure-IoT-Love from the wolfSSL team!
Don’t forget to add a star while you’re there!
- October 2021 (11)
- September 2021 (15)
- August 2021 (13)
- July 2021 (21)
- June 2021 (19)
- May 2021 (12)
- April 2021 (12)
- 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)