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.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.

wolfSSL 4.0.0 Now Available

Spring is here, and along with it is the newest and shiniest release of the wolfSSL embedded SSL/TLS library!

As with every release, this release includes many feature additions, bug fixes, and improvements to the wolfSSL library. Additionally, this new version of the wolfSSL library includes support for the new FIPS 140-2 Certificate for wolfCrypt v4.0! More information on wolfSSL and FIPS can be found here: https://www.wolfssl.com/license/fips/.

The list below outlines the new feature additions that are included with the release of wolfSSL version 4.0.0:

Additionally, the wolfSSL blog will be posting more elaboration and details on the ports and support that have been added with this release in the furture. Stay tuned for more information!

The following list outlines the various fixes, updates, and general improvements that have been included with wolfSSL 4.0.0:

  • Added new wrapper for snprintf for use with certain Visual Studio builds
  • Added ECC_PUBLICKEY_TYPE to the supported PEM header types
  • Added strict checking of the ECDSA signature DER encoding length
  • Added ECDSA option to limit sig/algos in client_hello to key size with USE_ECDSA_KEYSZ_HASH_ALGO
  • Compatibility fixes for secure renegotiation with Chrome
  • Better size check for TLS record fragment reassembly
  • Improvements to non-blocking and handshake message retry support for DTLS
  • Improvements to OCSP with ECDSA signers
  • OCSP fixes for memory management and initializations
  • Fixes for EVP Cipher decryption padding checks
  • Removal of null terminators on wolfSSL_X509_print substrings
  • wolfSSL_sk_ASN1_OBJCET_pop function renamed to wolfSSL_sk_ASN1_OBJECT_pop
  • Adjustment to include path in compatibility layer for evp.h and objects.h
  • Fixes for decoding BER encoded PKCS7 contents
  • Move the TLS PRF to wolfCrypt.
  • Update to CMS KARI support
  • Fixes and additions to the OpenSSL compatibility layer
  • Xcode project file update
  • Fixes for ATECC508A/ATECC608A
  • Fixes issue with CA path length for self signed root CA's
  • Fixes for Single Precision (SP) ASM when building sources directly
  • Fixes for STM32 AES GCM
  • Fixes for ECC sign with hardware to ensure the input is truncated
  • Fixes for proper detection of PKCS7 buffer overflow case
  • Fixes to handle degenerate PKCS 7 with BER encoding
  • Fixes for TLS v1.3 handling of 6144 and 8192 bit keys
  • Fixes for possible build issues with SafeRTOS
  • Improved Arduino sketch example
  • Improved crypto callback features
  • Improved TLS benchmark tool

There was also a bug in the tls_bench.c example test application (unrelated to the crypto or TLS portions of the library) that was resolved in wolfSSL 4.0.0 - CVE-2019-6439.

To download and view the most recent version of wolfSSL, the wolfSSL GitHub repository can be cloned from here: https://github.com/wolfssl/wolfssl.git, and the most recent stable release can be downloaded from the wolfSSL download page here: https://www.wolfssl.com/download/.

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

TLS 1.3 Performance Analysis – Server Pre-Generation

TLS 1.3 has some significant changes from TLS 1.2 that are targeted at performance. This is the fourth part of six 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. This blog discusses the server generating a key pair before the handshake starts.

As mentioned in the first blog in this series there is a way to mitigate some of the key exchange cost in TLS 1.3. If the server knows which key exchange algorithm will be used, it can preemptively generate a key pair after accepting a TCP/IP connection by calling wolfSSL_UseKeyShare(). In an architecture where both end-points are controlled by the same entity, a choice of security parameters, like the key exchange algorithm, is made upfront and can be relied on.

When directly connecting to a server, typically, a client only starts creating the ClientHello once a TCP/IP connection has been made. The server accepts the connection and waits for the client to generate a key share and send a ClientHello message. In this time, the server can also generate a key pair.

When using DH for key exchange this provides a significant saving as key generation is expensive. For example when using RSA for server authentication and running both client and server on the same computer, the connection is about 20% faster and with session reuse or PSK for server authentication, the connection is about 30% faster. For connections using ECDH with ECDSA for server authentication, the connection is only about 4% faster and with session reuse or PSK for server authentication, the connection is about 7% faster. EC key generation is very fast in optimised implementations and the impact of hiding its cost is therefore less.

Servers currently reuse the ephemeral key pair across multiple connections. It is common to regenerate the key pair once an hour up to once a day. This mechanism can be used instead of server pre-generation but at the cost of perfect forward security for the server.

If your architecture allows for it, the server should be implemented to generate the key pair after accepting a connection. For DH, it is well worth it. But even for ECDH the small performance improvement will result in more connections per second.

The next blog will discuss the performance issues with handshakes performing client-server authentication.

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

wolfSSL at Satellite 2019

wolfSSL is at Satelilite this year! The Satellite experience includes networking opportunities, SGx, Tech Demos, a Startup Space, and an international resource center curated from the 15k+ attendees from over 100 countries who come together for this global show. Connectivity and aerospace professionals will lead discussions on the future of satellite connectivity and the changing market landscape, hundreds of industry peers will be exhibiting cutting-edge technologies to buyers in enterprise, finance, military and government, telecommunications and transportation sectors. For 2019, Satellite will be located in Washington, DC.

Where Satellite will be :
Venue: Walter E. Washington Convention Center
Booth #: 838
When: May 6-8, 2019
Directions: https://2019.satshow.com/travelling-to-satellite/

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 Satellite can be found here: https://2019.satshow.com.

TLS 1.3 Performance Analysis – Pre-Shared Key (PSK)

TLS 1.3 has a different handshake flow when using pre-shared keys and this impacts performance. This is the third part of six 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. This blog discusses how and why PSK handshakes are only similar in speed generally but faster when using DH style key exchange.

For TLS 1.2, handshakes using PSK are defined in a separate document (RFC 4279). In order to fit in with the existing flow, a full handshake is performed. In TLS 1.3, PSK handshakes are the same as resumption handshakes. Therefore there is one less round-trip required for TLS 1.3.

This change in flow has a significant impact on the performance of TLS 1.3. The amount of hashing and encryption/decryption has increased but losing a round-trip means that using PSK without a DH style key exchange is only slightly slower. On higher latency networks, the difference is trivial and the savings great.

In TLS 1.3 using DH or ECDH with PSK results in the following handshake operations.

So, the secret is calculated on the server after the ServerHello is sent. This means that the processing of the ServerHello and secret calculation on the client is happening at the same time relative to the server calculating the secret. The parallel secret generation resulted in, with client and server running on the same computer, TLS 1.3 being about 25% faster than TLS 1.2 when using DH. Using ECDH with P-256, TLS 1.3 is about 15% faster.

It is clear that using pre-shared keys in a secure way, with DH style key exchange, is faster with TLS 1.3 in wolfSSL. The next blog will discuss use cases that result in the removal of a key generation from the list of expensive cryptographic operations in TLS 1.3.

Part 1 (TLS 1.3 Performance – Resumption)
Part 2 (TLS 1.3 Performance – Full Handshake)

For more information regarding wolfSSL performance or usage of PSK, please contact facts@wolfssl.com.

Differences between TLS 1.2 and TLS 1.3 (#TLS13)

wolfSSL's embedded SSL/TLS library has included support for TLS 1.3 since early releases of the TLS 1.3 draft. Since then, wolfSSL has remained up-to-date with the TLS 1.3 specification. In this post, the major upgrades of TLS 1.3 from TLS 1.2 are outlined below:

TLS 1.3

This protocol is defined in RFC 8446. TLS 1.3 contains improved security and speed. The major differences 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.

More information about the TLS 1.3 protocol can be found here: https://www.wolfssl.com/docs/tls13/. Additionally, please contact facts@wolfssl.com for any questions.

OpenSSL Compatibility Layer Expansion

Recently, wolfSSL released version 4.0.0 of the wolfSSL embedded SSL/TLS library. This new version includes many new port/feature additions, maintenance updates, and a couple bug fixes. Among those new feature additions includes multiple new API added to wolfSSL's OpenSSL compatibility layer! The compatibility layer is a series of commonly used and essential API that users can utilize to transition from OpenSSL to wolfSSL. The function names are redefined as their wolfSSL counterparts, which have similar signatures and output to their OpenSSL counterparts.

The list of new compatibility API included with the most recent release include the following:

  • BN_Init
  • EVP_Digest
  • EVP_MD_CTX_block_size
  • EVP_MD_CTX_size
  • EVP_PKEY_assign_EC_KEY
  • EVP_PKEY_assign_RSA

The list of OpenSSL compatibility API that were added in the release prior can be found here: https://www.wolfssl.com/openssl-compatibility-layer-expansion-2/

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

wolfSSL is available for download at the wolfSSL download page here (https://www.wolfssl.com/download/), or through a git-clone of the wolfSSL repository here (https://github.com/wolfssl/wolfssl.git).

For more information about wolfSSL or porting from OpenSSL, please contact facts@wolfssl.com.

wolfSSL at LinuxFest Northwest

wolfSSL is at LinuxFest Northwest (LFNW) this year! Bellingham Linux Users Group and the Information Technology department at BTC co-produce this annual Open Source event in Washington state. Attend presentations and exhibits on free and open source topics as well as Linux distributions and applications, InfoSec and privacy. For 2019, LFNW will be located in Bellingham, WA.

Where LFNW will be :
Venue: Bellingham Technical College
When: April 26-28, 2019
Directions: https://linuxfestnorthwest.org/conferences/2019#venue

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 LFNW can be found here: https://linuxfestnorthwest.org/conferences/2019.

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.

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/

wolfSSH Port for µC/OS-III

At wolfSSL, we currently have a wolfSSH port to µC/OS-III in the works! µC/OS-III is a highly portable and scalable real-time kernel. Designed for ease of use on a huge number of CPU architectures, these kernels are a key component of the µC/OS real-time operating system. The features of this kernel allow it to pair nicely with the wolfSSH SSHv2 library, resulting in the maximization of the best possible encryption, speed, and strength while simultaneously allowing for minimal resource usage.

Other features that are readily available and currently supported by wolfSSH include SCP, SFTP, client authentication via RSA keys or passwords, and more!

More information about the wolfSSH library: https://www.wolfssl.com/products/wolfssh/

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

wolfSSL at IoT Tech Expo Global

wolfSSL is at wolfSSL at IoT Tech Expo Global this year! IoT Tech Expo Global is the world’s largest IoT conference series, covering the latest innovations within the IoT and how they impact industries such as Manufacturing, Transport, Supply Chain, Insurance, Logistics, Government, Energy and Automotive. This year’s key topics include smart building and facilities management, building the connected supply chain, smart city and transport management, smart grid data management and analytics, delivering smart connected new products, and much more. For 2019, IoT Tech Expo Global will be held in London, England.

Location details:
Venue: Olympia Grand, London, UK
When: April 25-26, 2019
Directions: https://www.iottechexpo.com/global/travel-accommodation/

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 IoT Tech Expo Global can be found here: https://www.iottechexpo.com/global/

wolfSSL’s Effective Timing Resistance

In cryptography and encryption, timing can be an unconsidered element of the security for various operations. However, if an encryption library is built without considering timing or the possible attacks that a malicious agent could execute with timing attacks, then that encryption library could be vulnerable to multiple different attacks that have occurred or can occur. An actual timing attack requires the agent to precisely time the logical operations performed by a CPU or other device, and by measuring these times is able to construct the sensitive data that was used to perform these operations. These kinds of attacks are even practical against well known, generally secure algorithms including RSA, DSA, and other signature algorithms.

When it comes to the wolfCrypt crypto engine, there are features in place by default to protect against timing attacks. Although these features are enabled by default, to ensure that wolfSSL's timing resistance is enabled, users can either enable it through wolfSSL's configure script or manually define the relevant preprocessor defines. The option "--enable-harden" can be passed to configure to enable both timing resistance and RSA blinding. Macros that can be manually defined are listed below:

ECC_TIMING_RESISTANT /* define to enable timing resistance in ECC */
TFM_TIMING_RESISTANT /* define to enable timing resistance in underlying
                        fastmath math library */

More information on timing attacks can be found here: https://en.wikipedia.org/wiki/Timing_attack

For more information about the wolfSSL embedded SSL/TLS library or other security features offered, please contact facts@wolfssl.com.  wolfSSL also supports TLS 1.3!

Posts navigation

1 2 3 4 … 89 90 91

Weekly updates

Archives

Latest Tweets