RECENT BLOG NEWS

So, what’s new at wolfSSL? Take a look below to check out the most recent news, or sign up to receive weekly email notifications containing the latest news from wolfSSL. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support questions.

wolfSSH SSHv2 Server Library

wolfSSL provides many products, services, and support for almost all things TLS and embedded. One of these products provided by wolfSSL is wolfSSH - an SSHv2 server library!

wolfSSH is wolfSSL's own open-source and dual-licensed implementation of the SSHv2 protocol. It's a server library written in ANSI C and targeted for embedded/RTOS/resource-constrained environments. It's fast, has a small code size, and an extensive feature set.  This feature set includes items such as SCP support, SFTP support, PEM and DER certificate support, and also hardware cryptography for supported devices! This comes from wolfSSH's leverage of the wolfCrypt crypto engine for its cryptographic operations.

wolfSSH can be downloaded from the wolfSSL download page (located here: https://www.wolfssl.com/download/), or from a git-clone of the wolfSSH GitHub repository (located here: https://github.com/wolfssl/wolfssh.git).

Additionally, wolfSSL provides support and maintenance for all of its products, wolfSSH included. More information on wolfSSH support and maintenance can be found on the wolfSSL support page, located here: https://www.wolfssl.com/products/support-and-maintenance/.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSL Asymmetric Cryptography Support

One of the software libraries that is provided by wolfSSL includes the wolfCrypt crypto engine. wolfCrypt includes support for single-precision math, ECC, extensive list of supported ciphers, key/certificate generation, and also Asymmetric cryptography! Asymmetric cryptography differs from regular (synchronous) cryptography that instead of using a singular shared key, they will use a key-value pair. Popular algorithms where this is found include RSA, DH, and ECC - which are algorithms supported and implemented by wolfSSL!

wolfSSL's implementation of these Asymmetric algorithms can also be tuned based on the user's needs as well. For example, if a user requires the same security offered by these algorithms in combination with high performance fast encryption, wolfSSL has the options (or corresponding macro definitions) --enable-fastmath and --enable-fast-rsa available for use. Additionally, if a user needs to improve protection against attacks targeting implementations of these algorithms, wolfSSL has options to improve the security of its implementations of these Asymmetric algorithms. The options for these improvements are --enable-maxstrength and --enable-harden. These options can also be enabled by adding their corresponding defines within the settings file that is in use by the system, and are listed below:

  • --enable-fastmath corresponds with USE_FAST_MATH
  • --enable-fast-rsa has many different defines that would be used for many different devices, as hardware encryption and architecture comes in to play. It also requires the user have fast RSA libraries in place. Please contact support@wolfssl.com for assistance with enabling this.
  • --enable-maxstrength corresponds with WOLFSSL_MAX_STRENGTH
  • --enable-harden corresponds with TFM_TIMING_RESISTANT, ECC_TIMING_RESISTANT, and WC_RSA_BLINDING if using rng.

If you have any questions or run into any issues, contact us at, facts@wolfssl.com or call us at +1 425 245 8247.

wolfSSL DTLS Session Export

The wolfSSL embedded SSL/TLS library supports features not only pertaining to TLS, but DTLS as well! A prime example of a DTLS feature supported by wolfSSL is DTLS session exporting. This allows for serializing and sending a DTLS session immediately after the handshake has been completed. The ability to export the session after a handshake is established has many practical use cases in IoT and embedded environments.

In establishing and maintaining a DTLS connection the handshake portion is the most resource intensive. With this additional feature it is possible to offload the handshake onto a more powerful system, serialize and export it after the handshake is completed, and then have throughput handled by a more resource constrained device.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSL also supports TLS 1.3! More information can be found here: https://www.wolfssl.com/docs/tls13/

wolfSSL Adds Support for the Deos Safety Critical RTOS

Are you a user of Deos?  If so, you will be happy to know that wolfSSL recently added support for Deos RTOS and added TLS client/server examples to the wolfSSL embedded SSL/TLS library for Deos!

Deos is an embedded RTOS used for safety-critical avionics applications on commercial and military aircraft. Certified to DO-178C DAL A, the time and space partitioned RTOS features deterministic real-time response and employs patented “slack scheduling” to deliver higher CPU utilization. DO-178C DAL A refers to a specification that is required for software to be used in aerospace software systems. 

The Deos port in wolfSSL is activated by using the "WOLFSSL_DEOS" macro. For instructions on how to build and run the examples on your projects, please see the “<wolfssl-root>/IDE/ECLIPSE/DEOS/README” file.  This support is currently located in our GitHub master branch, and will roll into the next stable release of wolfSSL as well.

wolfSSL provides support for the latest and greatest version of the TLS protocol, TLS 1.3! Using the wolfSSL port with your device running Deos will allow your device to connect to the internet in one of the most secure ways 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.

Resources
The most recent version of wolfSSL can be downloaded from our download page, here: https://www.wolfssl.com/download/
wolfSSL GitHub repository: https://github.com/wolfssl/wolfssl.git
wolfSSL support for TLS 1.3: https://www.wolfssl.com/docs/tls13/
Deos RTOS homepage: https://www.ddci.com/category/deos/

wolfBoot – wolfSSL’s Secure Bootloader

wolfBoot is wolfSSL's own implementation of 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/

Additionally, wolfSSL will be at ICMC in a couple of weeks! Be sure to stop by booth #103 and say hello!

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSH Version 1.4.0 Now Available

Version 1.4.0 of the wolfSSH SSHv2 server library has been released! Many new and exciting features were added to wolfSSH with this release. Some of the new additions include: support for port forwarding, client side pseudo terminal support, enhancements for non blocking use, AES-CTR cipher support, and support for SFTP on windows.

This release also includes fixes and enhancements to existing features. Some of the fixes include resolving GCC-7 warnings and fixes for example use cases when wolfSSL ECC caching is turned on.

A full list of notable addition and fixes is as follows:

  • SFTP support for time attributes
  • TCP port forwarding feature added (--enable-fwd)
  • Example TCP port forwarding added to /examples/portfwd/portfwd
  • Fixes to SCP, including default direction set
  • Fix to match ID during KEX init
  • Add check for window adjustment packets when sending large transfers
  • Fixes and maintenance to Nucleus port for file closing
  • Add enable all option (--enable-all)
  • Fix for --disable-inline build
  • Fixes for GCC-7 warnings when falling through switch statements
  • Additional sanity checks added from fuzz testing
  • Refactor and fixes for use with non blocking
  • Add extended data read for piping stderr
  • Add client side pseudo terminal connection with ./examples/client/client -t
  • Add some basic Windows terminal conversions with wolfSSH_ConvertConsole
  • Add wolfSSH_stream_peek function to peek at incoming SSH data
  • Change name of internal function from SendBuffered to wolfSSH_SendPacket to avoid clash with wolfSSL
  • Add support for SFTP on Windows
  • Use int types for arguments in examples to fix Raspberry Pi build
  • Fix for fail case with leading 0’s on MPINT
  • Default window size (DEFAULT_WINDOW_SZ) lowered from ~ 1 MB to ~ 16 KB
  • Disable examples option added to configure (--disable-examples)
  • Callback function and example use added for checking public key sent
  • AES CTR cipher support added
  • Fix for freeing ECC caches with examples
  • Renamed example SFTP to be examples/sftpclient/wolfsftp

The most up-to-date versions of wolfSSH and other wolfSSL products can be found on the wolfSSL download page here: https://www.wolfssl.com/download/.

For more information about wolfSSH or the changes incorporated into the 1.4.0 release, please contact facts@wolfssl.com.

wolfSSL FIPS-Ready

With the release of wolfSSL 4.0.0, the wolfSSL team has also released a new product: the wolfSSL FIPS Ready library. This product features new, state of the art concepts and technology. In a single sentence, wolfSSL FIPS Ready is a testable and free to download open source embedded SSL/TLS library with support for FIPS validation, with FIPS enabled cryptography layer code included in the wolfSSL source tree. To further elaborate on what FIPS Ready really means, you do not get a FIPS certificate and you are not FIPS approved. 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 (POST).

FIPS validation is a government certification for cryptographic modules that states that the module in question has undergone thorough and rigorous testing to be certified. FIPS validation specifies that a software/encryption module is able to be used within or alongside government systems. The most recent FIPS specification is 140-2, with various levels of security offered (1-5). Currently, wolfCrypt has FIPS 140-2 validation with certificates #2425 and #3389. When trying to get software modules FIPS validated, this is often a costly and time-consuming effort and as such causes the FIPS validated modules to have high price tags.

Since the majority of wolfSSL products use the wolfCrypt encryption engine, this also means that if wolfSSH, wolfMQTT (with TLS support), wolfBoot, and other wolfSSL products in place can be tested FIPS validated code with their software before committing.

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

For more information about wolfSSL and its FIPS Ready initiative, please contact facts@wolfssl.com.

Building WebSocket++ with wolfSSL Support

wolfSSL can now be used to replace OpenSSL in WebSocket++!

WebSocket++ is a header only C++ library that implements RFC6455 The WebSocket Protocol. It allows integrating WebSocket client and server functionality into C++ programs and uses interchangeable network transport modules including one based on raw char buffers, one based on C++ iostreams, and one based on Asio (either via Boost or standalone). End users can write additional transport policies to support other networking or event libraries as needed.

Since wolfSSL is compatible with Asio and Boost.Asio (see Asio blog post), it can be used to replace OpenSSL for cryptographic and TLS purposes when building WebSocket++ with Asio or Boost.Asio.

To build WebSocket++, enter the following commands from the root directory of your WebSocket++ download.

$ cmake .
$ make
$ sudo make install

Now install the wolfSSL compatible versions of Asio or Boost.Asio and build it with wolfSSL (see blog post).

You should now be able to compile and execute programs with WebSocket++ and wolfSSL. Just make sure to link all of the necessary libraries (asio and wolfSSL) and their include paths when compiling.

To run the WebSocket++ unit tests with wolfSSL you will need the wolfSSL modified version of WebSocket++. Please contact facts@wolfssl.com if you want us to send you the source code.

To run the Ctest tests, execute the following commands from the root directory of the wolfSSL modified WebSocket++ download.

$ cmake -DBUILD_TESTS=ON -DBUILD_EXAMPLES=ON -DWOLFSSL=/path/to/wolfSSL/install .
$ ctest .

If you want to run more thorough tests with wolfSSL and WebSocket++ you will need to download and install scons. You should then be able to execute the scons tests with the following commands.

$ export BOOST_ROOT=$WORKSPACE/boost_1_67_0
$ export WOLFSSL_PATH=/path/to/wolfSSL/install
$ scons
$ scons test

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

wolfCrypt FIPS Certificate #3389

The National Institute of Standards and Technology (NIST) has completed the validation of the wolfCrypt module version 4 for an updated Federal Information and Processing Standards (FIPS) 140-2 certificate in addition to its previous FIPS 140-2 certificate. This new certificate includes updated and more secure algorithms added to the wolfCrypt module's boundary, some of which are listed further below.

FIPS 140-2 is a government standard that specifies a software module is compatible and allowed to be used in government systems. This includes such areas as drone software, government databases, and other high-security/high-power uses.

The new FIPS 140-2 validation has certificate #3389. The Operating Environments (OEs) tested are Ubuntu Linux (16.04) and Windows 10 on Intel Core i5 processors. Full details about the OEs can be found on the CSRC certificate page. Additionally, the certificate also includes the following algorithms: 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.

For more information about wolfSSL, wolfCrypt, or our FIPS 140-2 validations, please view our resources below.

Other information can be obtained, or questions can also be answered by contacting facts@wolfssl.com.

wolfSSL will also be attending ICMC this year! More information about ICMC can be found here: https://icmconference.org

TLS 1.3 Performance Analysis – Throughput

Some interesting results were found when comparing the throughput of TLS 1.2 and TLS 1.3 using an assembly optimized wolfSSL – some good, some bad. This is the last of the blogs discussing the performance differences observed between TLS 1.2 and TLS 1.3 in wolfSSL and how to make the most of them in your applications. There are differences in the way the data is encrypted in TLS 1.2 and 1.3. For some algorithms this makes a noticeable difference.

TLS 1.2 encrypts the plaintext of the message and generates an authentication code on the encrypted data plus additional_data which includes: a 64-bit sequence number, 1 byte content type, 2 byte version and 2 byte length. This is a total of 13 extra bytes in additional_data.

TLS 1.3 encrypts the plaintext of the message plus one byte for the real record type and generates an authentication code on the encrypted data plus the record header of 5 bytes.

For AES-GCM cipher suites the throughput was observed to be slightly increased with the Intel x86 64-bit optimized assembly code. This is due to the number of bytes passed in as additional authentication data (AAD). The AAD bytes are processed separately before encryption and decryption and it turned out processing 5 bytes was faster than 13. The extra byte on the end of the encrypted data did not have a significant impact.

For Chacha20-Poly1305 the different size of data passed in as AAD has no significant impact as the data is placed into a 16 byte block and padded before being processed. But, the extra byte at the end of the plaintext did impact the Chacha20 and Poly1305 performance. For Poly1305, the extra byte resulted in an extra 16 byte block being processed. In total this had about a 3-5% impact on throughput with the Intel x86 64-bit optimized assembly code.

TLS 1.3 has better throughput when using AES-GCM and is another reason to change. For maximum throughput consider sending one less than the maximum plaintext size, by default 16384 bytes, in an application data message. This will have a positive impact for both AES-GCM and Chacha20-Poly1305 cipher suites.

Part 1 (TLS 1.3 Performance – Resumption)
Part 2 (TLS 1.3 Performance – Full Handshake)
Part 3 (TLS 1.3 Performance – Pre-Shared Key (PSK))
Part 4 (TLS 1.3 Performance – Server Pre-Generation)
Part 5 (TLS 1.3 Performance – Client-Server Authentication)

Posts navigation

1 2 3 111 112 113 114 115 116 117 194 195 196

Weekly updates

Archives