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.

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.

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 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!

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

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 at ICMC 2019

wolfSSL is at ICMC this year! The International Cryptographic Module Conference (ICMC) attracts hundreds of cryptographic professionals from across the Pacific to address the unique challenges faced by the people who develop, produce, test, specify, and use cryptographic modules, with an emphasis on FIPS 140-2, ISO/IEC 19790 and Common Criteria standards. For 2019, ICMC will be held in Vancouver, BC.

Where ICMC will be held for 2019:
Venue: JW Mariott Parq Vancouver
wolfSSL Booth #: 103
When: May 15-16
Directions: https://icmconference.org/?page_id=7194

Additionally, wolfSSL founder and CTO Todd Ouska will be on the panel for the track session "Panel on TLS: The Problems in Moving to 1.3". Stop by the Cambie space to learn more about the problems in upgrading to the newest version of TLS (Friday, May 17th, at 10:30am)

Stop by our booth to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, to meet the wolfSSL team, or to get some free stickers and swag!

For more information about wolfSSL, its products, or future events, please contact facts@wolfssl.com.

More information about ICMC can be found here: https://icmconference.org.

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.

wolfSSL at NXP Tech Days – Seattle

wolfSSL is at NXP Tech Days's Seattle event this year! NXP Technology Days is a deep-dive, technical training program for engineers designing solutions with embedded technology. This one-day event offers hands-on workshops and technical lectures over multiple markets enabling attendees to customize a schedule that is most relevant to their training needs.

Where NXP Tech Days will be for Seattle:
Venue: Meydenbauer Center, Bellevue, WA 98004
When: May 7th, 2019
Directions: https://www.meydenbauer.com/parking-directions/

Stop by to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, to meet the wolfSSL team, or to get some free stickers and swag!

For more information about wolfSSL, its products, or future events, please contact facts@wolfssl.com.

More information about NXP Tech Days and the Seattle Agenda can be found here: https://www.nxp.com/support/training-events/nxp-technology-days:NXP-TECH-DAYS.

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)

wolfSSL Renesas Support

The wolfSSL embedded SSL/TLS library supports running on several Renesas platforms and has support for both the Renesas CS+ and e2 studio development environments. To make it easy to get started with wolfSSL, wolfSSL offers several example CS+ and e2 studio projects which can be run on a Starter Kit or Alpha Project board. The example programs include SSL/TLS server/client example projects running on top of uITRON and TINET (their network layer API). Additionally, there is also a wolfCrypt test (benchmark application) example project included as well that allows the user to see the performance of wolfCrypt's implementations on the desired platform.

Renesas CS+ (formerly CubeSuite+) is an integrated development environment that provides simplicity, security and ease of use in developing software through iterative cycles of editing, building, and debugging. Renesas e2 studio is a development environment based on the popular Eclipse CDT (C/C++ Development Tooling), which includes build (editor, compiler and linker control), as well as debug interfaces. More information about Renesas and wolfSSL can be found here: https://www.wolfssl.com/docs/wolfssl-renesas-support/.

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

Posts navigation

1 2 3 93 94 95 96 97 98 99 185 186 187

Weekly updates

Archives