RECENT BLOG NEWS

wolfSSL recently released version 3.15.5 of the wolfSSL embedded SSL/TLS library. This new release includes many new feature additions and updates, including a port to Contiki.

Contiki is an open source operating system for the Internet of Things. It connects tiny low-cost, low-power microcontrollers to the Internet. Contiki is a perfect match for wolfSSL, which was built for use on embedded and resource-constrained devices with portability in mind. In addition to being highly portable, wolfSSL provides support for the latest and greatest version of the TLS protocol, TLS 1.3! Using the wolfSSL port with your device running Contiki will allow your IoT device to connect to the internet in one of the most secure ways possible.

The Contiki port in wolfSSL is activated by using the "WOLFSSL_CONTIKI" macro when compiling wolfSSL. An example of this on embedded devices would be placing WOLFSSL_CONTIKI into a user_setttings.h file, or by including the option CPPFLAGS="-DWOLFSSL_CONTIKI" if compiling wolfSSL by using autotools.

For more information, please contact facts@wolfssl.com.

Resources
The most recent version of wolfSSL can be downloaded from our download page, here: https://www.wolfssl.com/download/
wolfSSL support for TLS 1.3: https://www.wolfssl.com/docs/tls13/
Contiki OS homepage: http://www.contiki-os.org

Have you heard talk about SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3 but never really knew the differences between the different versions? Secure Socket Layer (SSL) and Transport Security Layer (TLS) are both cryptographic protocols which provide secure communication over networks. These different versions are all in widespread use today in applications such as web browsing, e-mail, instant messaging and VoIP, and each is slightly different from the others.

wolfSSL supports all three of these ciphers to best suit your needs and requirements. Below you will find the major differences between the different protocol versions.

SSL 3.0
This protocol was released in 1996, but first began with the creation of SSL 1.0 developed by Netscape. Version 1.0 wasn`t released, and version 2.0 had a number of security flaws, thus leading to the release of SSL 3.0. Some major improvements of SSL 3.0 over SSL 2.0 are:
- Separation of the transport of data from the message layer
- Use of a full 128 bits of keying material even when using the Export cipher
- Ability of the client and server to send chains of certificates, thus allowing organizations to use certificate hierarchy which is more than two certificates deep.
- Implementing a generalized key exchange protocol, allowing Diffie-Hellman and Fortezza key exchanges as well as non-RSA certificates.
- Allowing for record compression and decompression
- Ability to fall back to SSL 2.0 when a 2.0 client is encountered

Netscape`s Original SSL 3.0 Draft: http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt
Comparison of SSLv2 and SSLv3: http://stason.org/TULARC/security/ssl-talk/4-11-What-is-the-difference-between-SSL-2-0-and-3-0.html

TLS 1.0
This protocol was first defined in RFC 2246 in January of 1999. This was an upgrade from SSL 3.0 and the differences were not dramatic, but they are significant enough that SSL 3.0 and TLS 1.0 don`t interoperate. Some of the major differences between SSL 3.0 and TLS 1.0 are:
- Key derivation functions are different
- MACs are different - SSL 3.0 uses a modification of an early HMAC while TLS 1.0 uses HMAC.
- The Finished messages are different
- TLS has more alerts
- TLS requires DSS/DH support

RFC 2246: http://tools.ietf.org/html/rfc2246

TLS 1.1
This protocol was defined in RFC 4346 in April of 2006, and is an update to TLS 1.0. The major changes are:
- The Implicit Initialization Vector (IV) is replaced with an explicit IV to protect against Cipher block chaining (CBC) attacks.
- Handling of padded errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
- IANA registries are defined for protocol parameters
- Premature closes no longer cause a session to be non-resumable.

RFC 4346: http://tools.ietf.org/html/rfc4346#section-1.1

TLS 1.2
This protocol was defined in RFC 5246 in August of 2008. Based on TLS 1.1, TLS 1.2 contains improved flexibility. The major differences include:
- The MD5/SHA-1 combination in the pseudorandom function (PRF) was replaced with cipher-suite-specified PRFs.
- The MD5/SHA-1 combination in the digitally-signed element was replaced with a single hash. Signed elements include a field explicitly specifying the hash algorithm used.
- There was substantial cleanup to the client`s and server`s ability to specify which hash and signature algorithms they will accept.
- Addition of support for authenticated encryption with additional data modes.
- TLS Extensions definition and AES Cipher Suites were merged in.
- Tighter checking of EncryptedPreMasterSecret version numbers.
- Many of the requirements were tightened
- Verify_data length depends on the cipher suite
- Description of Bleichenbacher/Dlima attack defenses cleaned up.

RFC 5246: http://tools.ietf.org/html/rfc5246

TLS 1.3
This protocol is currently being revised, and is in its 28th draft. The major differences from TLS 1.2 include:
- The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.
- A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.
- Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
- All handshake messages after the ServerHello are now encrypted.
- Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.
- The handshake state machine has been restructured to be more consistent and remove superfluous messages.
- ECC is now in the base spec and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.
- Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.
- TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.
- Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.

RFC 8446: https://tools.ietf.org/html/rfc8446

Resources:
If you would like to read more about SSL or TLS, here are several resources that might be helpful:
TLS - Wikipedia (http://en.wikipedia.org/wiki/Transport_Layer_Security)
SSL versus TLS - What`s the Difference? (http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html)
Cisco - SSL: Foundation for Web Security (http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html)

As always, if you have any questions or would like to talk to the wolfSSL team about more information, please contact facts@wolfssl.com.

Recently, wolfSSL released version 3.15.5 of the wolfSSL embedded SSL/TLS library. This new release contains many feature releases and updates, including the addition of an Atollic TrueSTUDIO static library project for wolfSSL.

Atollic TrueSTUDIO is a full-featured IDE used for STM32 development with out-of-the-box support for all STM32 boards and devices, and features advanced debugging and code analysis. The availability of a wolfSSL static library project for TrueSTUDIO will speed up the development and implementation of using wolfSSL with your STM32 device - providing an example of how to integrate wolfSSL into a TrueSTUDIO-based project.

For more information, please contact facts@wolfssl.com.

wolfSSL also provides support for TLS 1.3, the most recent version of the TLS protocol!

Resources
wolfSSL v3.15.5 release notes: https://www.wolfssl.com/wolfssl-3-15-5-now-available/
Atollic homepage: https://atollic.com

wolfSSH has added in enhancements to our SFTP implementation for use on Windows systems. The embedded SSH library can now be used with the default Windows file system. SFTP is a protocol that runs on top of SSH that enables securely accessing, browsing and managing files. The leading edge of wolfSSH code and development can be found on the GitHub repository here https://github.com/wolfSSL/wolfssh, and the latest stable release can be downloaded from the wolfSSL website here https://www.wolfssl.com/download/.

For more information about using wolfSSH contact facts@wolfssl.com.

wolfSSL provides support on four levels, one of which is the 24x7 support level. This support level includes many key features not available on the others, such as an unlimited number of support incidents, around-the-clock support from dedicated members of the wolfSSL support team, and remains in effect for an entire year.

wolfSSL provides three other levels of paid support, which also include some of the same features provided by 24x7 support. More details on the wolfSSL support packages and levels can be viewed here: https://www.wolfssl.com/products/support-packages-options/

wolfSSL also provides support for the latest version of the TLS protocol, TLS 1.3! Read more about wolfSSL's implementation and the protocol itself here: https://www.wolfssl.com/docs/tls13/

For more information, please contact facts@wolfssl.com.

Recently, wolfSSL released version 3.15.5 of the wolfSSL embedded SSL/TLS library. This new release contains many feature additions and updates, including a port to Apache Mynewt.

Apache Mynewt is a Real-Time Operating System (RTOS) that is used to build, deploy, and securely manage billions of devices. It is designed for IoT devices that have limited memory and storage and need to run for a long time with minimal power consumption. wolfSSL's port for Mynewt uses Mynewt's raw socket interface "mnsocket" to send and receive data through an SSL/TLS connection.

The wolfSSL port for Apache Mynewt is the ideal solution for security in your embedded IoT device. Apache Mynewt is an RTOS created with resource constrained devices in mind, and wolfSSL is an embedded SSL/TLS library created with speed, strength, portability, and low footprint size in mind. The combination of wolfSSL and Apache Mynewt results in a powerful security solution.

For more information, please contact facts@wolfssl.com.

wolfSSL also provides support for TLS 1.3, the most recent version of the TLS protocol!

Resources
wolfSSL v3.15.5 release notes: https://www.wolfssl.com/wolfssl-3-15-5-now-available/
Apache Mynewt homepage: https://mynewt.apache.org

wolfSSL is a lightweight TLS/SSL library that is targeted for embedded devices and systems. It has support for the TLS 1.3 protocol, which is a secure protocol for transporting data between devices and across the Internet. In addition, wolfSSL uses the wolfCrypt encryption library to handle its data encryption.

Because there is a FIPS 140-2 validated version of wolfCrypt, this means that wolfSSL not only has support for the most current version of TLS, but it also has the encryption backbone to support your FIPS 140-2 needs if required.

Some key benefits of combining TLS 1.3 with FIPS validated software include:

1. Software becomes marketable to federal agencies - without FIPS, a federal agency is not able to use cryptographic-based software
2. Single round trip
3. 0-RTT (a mode that enable zero round trip time)
4. After Server Hello, all handshake messages are encrypted.

And much more! For more information regarding the benefits of using TLS 1.3 or using the FIPS validated version of wolfCrypt, check out wolfSSL's TLS 1.3 Protocol Support and our wolfCrypt FIPS page.

FIPS 140-2 is a government validation that certifies that an encryption module has successfully passed rigorous testing and meets high encryption standards as specified by NIST. For more information or details on FIPS 140-2, it may be helpful to view this Wikipedia article: https://en.wikipedia.org/wiki/FIPS_140-2

For more details about wolfSSL, TLS 1.3, or if you have any other general inquiries please contact facts@wolfssl.com

To find out more about FIPS, check out the NIST FIPS publications or contact fips@wolfssl.com

wolfSSL will be exhibiting at the 2018 TRON Symposium (TRONSHOW). wolfSSL will be exhibiting from 10:00am to 5:00pm, on December 12th-14th.

The TRON Symposium 2018 will be located at the Tokyo Midtown Hall, with wolfSSL exhibiting at booth B2.
Tokyo Midtown Hall: Akasaka 9-7-1, Minato-ku, Tokyo (directions)

Stop by to hear about the wolfSSL embedded SSL/TLS library which provides support for the latest versions of TLS, wolfTPM, wolfMQTT, wolfSSH, or any of the other wolfSSL products which provide the link between TLS and hardware security. We look forward to seeing you there!

For questions, feel free to contact facts@wolfssl.com.

wolfSSL is pleased to announce the first ever release of wolfBoot!

wolfBoot v1.0 release page: https://github.com/wolfSSL/wolfBoot/releases/tag/v1.0

wolfBoot is a secure bootloader that leverages wolfSSL's underlying wolfCrypt module to provide signature authentication for the running firmware.

The role of a secure bootloader is to effectively prevent the loading of malicious or unauthorized firmware on the target. Additionally, wolfBoot provides a fail-safe update mechanism, that can be interrupted at any time, and resumed at next boot.

wolfBoot is designed to be a portable, OS-agnostic, secure bootloader solution for all 32-bit microcontrollers, relying on wolfCrypt for firmware authentication.

Due to its minimalist design and the tiny Hardware Abstraction Layer (HAL) API, wolfBoot is completely independent of any OS or bare-metal application, and can be easily ported and integrated into existing embedded software solutions.

wolfBoot provides the basis for secure firmware update (OTA) management at boot time, cutting down the development effort needed to implement and validate the required mechanisms to handle the updates. It reduces the development effort to just receiving the image using a secure channel within the application/OS. We recommend using wolfSSL to encrypt the firmware transfer over TLS, to avoid eavesdropping. Once the image is transferred and stored into the update partition, wolfBoot takes care of the update procedure at the next boot.

Remote updates that would lead to a faulty firmware are automatically reverted by wolfBoot after the first 'test' boot, by restoring the original firmware image whenever the update has failed to boot properly. This mechanism protects the target device from accidental updates on the field.

wolfBoot can be downloaded from the wolfSSL download page here: https://www.wolfssl.com/download/

More about boot loaders can be found here: https://en.wikipedia.org/wiki/Booting#BOOT-LOADER
More about wolfSSL: https://www.wolfssl.com/products/wolfssl/
More about wolfCrypt: https://www.wolfssl.com/products/wolfCrypt/

Contact facts@wolfssl.com for any questions or for more information

Recently, wolfSSL released version 3.15.5. This new release contains many new feature additions and updates, including the addition of several new ports. One of these ports is for replacing OpenSSL with wolfSSL in the Asio and Boost.Asio C++ libraries!

Asio is a cross-platform C++ library for network and low-level I/O programming that provides developers with a consistent asynchronous model using a modern C++ approach. It is used in a multitude of different projects and is included as part of the core C++ Boost libraries as Boost.Asio.

As of right now, our changes to the Asio repository are still in the process of being merged upstream. However, If you are interested in using Asio with wolfSSL in your project don’t hesitate to contact us at facts@wolfssl.com and we will send you the required source code. Then, follow the instruction in the rest of this blog post to learn how to build Asio with wolfSSL.

After cloning or downloading the latest version of wolfSSL from GitHub, execute the following commands from the wolfSSL root directory.

$ ./autogen.sh
$ ./configure --enable-asio
$ make
$ sudo make install

After cloning or downloading the latest version of Asio from GitHub, execute the following commands from the Asio root directory. Asio can be downloaded from GitHub here: https://github.com/chriskohlhoff/asio

$ ./autogen.sh
$ ./configure --with-wolfssl=/path/to/wolfSSL/installation        #(i.e. /usr/local)
$ make
$ sudo make install

To run Asio’s unit tests and ensure everything has been built correctly with wolfSSL, you can run the following command:

$ make check

The wolfSSL compatible Asio version relies on the preprocessor statement “ASIO_USE_WOLFSSL” to function correctly. You may need to define this when compiling your application or you can insert “#include <wolfssl/options.h>” before any SSL related Asio header files are declared.

For more information on building and installing Asio, view the Asio documentation.

Until wolfSSL support for Asio has been merged into the stable releases of Boost, you will have to manually replace Boost.Asio in the current Boost release with the wolfSSL compatible version. To do this, follow the instructions below.

In the root directory of the wolfSSL compatible Asio download, execute the following command to convert the standalone Asio version into the Boost.Asio version.

$ ./boostify.pl

You will now need to copy the asio directory located in asio/boostified/libs/asio/include/boost and replace the asio directory in your Boost download. The asio directory in Boost can be found in boost_1_67_0/boost

You can now build and install Boost to your system by running the following command from the Boost root directory.

$ ./bootstrap.sh
$ ./b2
$ sudo ./b2 install

The preprocessor statement that Boost.Asio relies on is “BOOST_ASIO_USE_WOLFSSL”.

That's it! You should now be able to run your own applications that use Asio or Boost.Asio with wolfSSL!

For more information or help with getting Asio and wolfSSL into your project, please contact us at facts@wolfssl.com.