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.

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 wolfSSL and the TLS 1.3 protocol can be found here: https://www.wolfssl.com/docs/tls13/.

Additionally, please contact facts@wolfssl.com for any questions.

Multithread Support in wolfMQTT

The most requested feature for the wolfMQTT client library is now available! Multithreading support allows an application to create multiple threads that use the wolfMQTT client library. There is a new example that demonstrates this functionality, located in `examples/multithread/`. This example creates a thread that subscribes to a topic and then waits for incoming messages; it also creates many threads that publish a unique message to the topic. 

As a side note, wolfMQTT uses the wolfSSL embedded SSL/TLS library for SSL/TLS support.  Since wolfSSL supports TLS 1.3, your wolfMQTT-based projects can now use MQTT with TLS 1.3 on supported broker!

You can download the latest release from our website or clone on GitHub. For more information please email us at facts@wolfssl.com.

wolfSSL and the Zombie POODLE and GOLDENDOODLE Attacks

The wolfSSL library is NOT vulnerable to these attacks, thanks to previous fixes we’ve made and our extensive testing. 

Ongoing research regarding CBC padding oracle attacks against TLS will be presented in August 2019 at USENIX Security. These attacks were originally presented by Craig Young at BlackHat Asia in March 2019 (slides). 

Both attacks target the MAC and Padding used for TLS v1.2 with AES CBC cipher suites. TLS padding occurs when a record is not 16-byte aligned and is padded with the length value. The MAC uses HMAC with SHA/SHA256 to calculate an authentication code. For TLS the order of operation is MAC -> PAD -> ENCRYPT.

The attack requires a man-in-the-middle (MITM) position to employ the attack. It takes valid records and alters either MAC or Padding or cause TLS errors. If the TLS server responds differently to each of these errors then it can leak information about the plain text message.

The author Craig Young wrote a “padcheck” tool, which tests the following error cases:

  1. Invalid MAC with Valid Padding (0-length pad)
  2. Missing MAC with Incomplete/Invalid Padding (255-length pad)
  3. Typical POODLE condition (incorrect bytes followed by correct length)
  4. All padding bytes set to 0x80 (integer overflow attempt)
  5. Valid padding with an invalid MAC and a 0-length record

For wolfSSL, we respond consistently with the same alert and close the socket for each of these conditions.

The recommendation from the author is to stop using AES CBC cipher suites and start using TLS v1.3, which is supported by wolfSSL. More information about wolfSSL and TLS 1.3 can be found here: https://www.wolfssl.com/docs/tls13/

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

Building wolfSSL and TLS 1.3 on Windows

We wanted to cover building for TLS 1.3 today for our Windows users! For those interested in testing with TLS 1.3 on Windows system please use the wolfssl64.sln located in the root directory of our download (wolfssl-x.x.x/wolfssl64.sln).

The wolfssl64.sln solution provides builds configurations for:

WIN32 | Debug

WIN32 | DLL Debug

WIN32 | Release

WIN32 | DLL Release 

x64 | Debug

x64 | DLL Debug

x64 | Release

x64 | DLL Release

To customize the configuration for wolfSSL we use the file wolfssl-x.x.x/IDE/WIN/user_settings.h with the wolfssl64.sln. Simply add these settings to that header:

#define WOLFSSL_TLS13

#define HAVE_TLS_EXTENSIONS

#define HAVE_SUPPORTED_CURVES

#define HAVE_ECC

#define HAVE_HKDF

#define HAVE_FFDHE_8192

#define WC_RSA_PSS

Then rebuild and run the example client/server with the -v 4 option to test TLS 1.3! (See screenshot below)

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

Using Pre-Shared Keys (PSK) with wolfSSL

Ever wondered how to use PSK with the embedded wolfSSL library?  PSK is useful in resource constrained devices where public key operations may not be viable.  It`s also helpful in closed networks where a Certificate Authority structure isn`t in place.  To enable PSK with wolfSSL you can simply do:

$ ./configure --enable-psk

Using PSK on the client side requires one additional function call:

wolfSSL_CTX_set_psk_client_callback()

There`s an example client callback in cyassl/test.h called my_psk_client_cb().  The example sets the client identity which is helpful for the server if there are multiple clients with unique keys and is limited to 128 bytes.  It could also examine the server identity hint in case the client is talking to multiple servers with unique keys.  Then the pre-shared key is returned to the caller, here that is simply 0x1a2b3c4d, but it could be any key up to 64 bytes in length (512 bits).

On the server side two additional calls are required:

wolfSSL_CTX_set_psk_server_callback()
wolfSSL_CTX_use_psk_identity_hint()

The server stores it`s identity hint to help the client with the 2nd call, in our server example that`s “cyassl server”.  An example server psk callback can also be found in my_psk_server_cb() in cyassl/test.h.  It verifies the client identity and then returns the key to the caller, which is again 0x1a2b3c4d, but could be any key up to 64 bytes in length.  If you have any questions about using PSK with TLS please let us know.

wolfSSL at Sensors Expo 2019

wolfSSL at Sensors Expo and Conference

Come visit wolfSSL at the 2019 Sensors Expo & Conference! Sensors Expo & Conference is the premier event for sensors, connectivity and systems, attracting the largest gathering of engineers and professionals of sensing-related technologies. This year the Sensors Expo & Conference will be held in San Jose, CA.

Where Sensors Expo & Conference will be held for 2019:
Venue: McEnery Convention Center, San Jose, CA
Booth #: 1525
When: June 25-27
Directionshttps://www.sensorsexpo.com/show-overview/

Stop by to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, or to meet the wolfSSL team! Feel free to say hello!

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

More information about Sensors Expo & Conference can be found here: https://www.sensorsexpo.com/

wolfCrypt Support for Cryptographic Callbacks

wolfCrypt adds support for cryptographic callbacks that can be registered for replacing stock software calls with your own custom implementations. The goal is to make adding hardware cryptographic support easier.

Currently supported crypto callbacks:

  • RNG and RNG Seed
  • ECC (key gen, sign/verify and shared secret)
  • RSA (key gen, sign/verify, encrypt/decrypt)
  • AES CBC and GCM
  • SHA1 and SHA256
  • HMAC

This feature is enabled using “–enable-cryptocb” or “#define WOLF_CRYPTO_CB”.

To register a cryptographic callback function use the “wc_CryptoCb_RegisterDevice” API. This takes a unique device ID (devId), callback function and optional user context.

typedef int (*CryptoDevCallbackFunc)(int devId, wc_CryptoInfo* info, void* ctx);
WOLFSSL_API int wc_CryptoCb_RegisterDevice(
    int devId,
    CryptoDevCallbackFunc cb,
    void* ctx);

To enable use of the crypto callbacks you must supply the “devId” arguments on initialization.

For TLS use:  

  • wolfSSL_CTX_SetDevId(ctx, devId);
  • wolfSSL_SetDevId(ssl, devId);

For wolfCrypt API’s use the init functions that accept “devId” such as:

  • wc_InitRsaKey_ex
  • wc_ecc_init_ex
  • wc_AesInit
  • wc_InitSha256_ex
  • wc_InitSha_ex
  • wc_HmacInit

Examples:

For questions please email us at facts@wolfssl.com.

wolfBoot adds RISC-V Support

We have added support for RISC-V hardware in our wolfBoot library. The reference example uses the SiFive HiFive1 FE310 board to demonstrate a secure bootloader and firmware upgrade.

The HiFive1 is a 32-bit E31 RISC-V core capable of running at 320MHz. It includes 4MB of external flash and 16KB of internal RAM.

The wolfBoot library provides:

  • Boot validation of the firmware image using hash and signature
  • Reliable firmware update (power fail safe).
  • Rollback support if application does not report “success”
  • Version checking to prevent downgrade attack
  • Support for external flash on updates

This adds support for:

  • RV32 Hardware Access Layer (HAL) support for:
    • PLL Clock configuration
    • Flash eSPI
    • UART
    • RTC
  • Firmware update example using the serial interface

Full setup and installation instructions can be found in “docs/Targets.md”.

These new features can be found on GitHub here:
https://github.com/wolfSSL/wolfBoot/pull/14

For questions please email us at 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.

wolfSSL Adds Support for the Arm® TrustZone® CryptoCell-310

Are you a user of MCU with CryptoCell hardware?  If so, you will be happy to know that wolfSSL recently added support for CryptoCell with wolfCrypt and benchmark examples to the wolfSSL embedded SSL/TLS library!

The wolfSSL port supports the following features:

  • SHA-256
  • AES CBC
  • Elliptic Curve Digital Signature Algorithm (ECDSA) – sign and verify
  • Elliptic Curve Diffie Hellman (ECDH) – shared secret
  • ECC key generation support
  • RSA sign and verify
  • RSA key generation support
  • RSA encrypt and decrypt

These features are tested on nRF52840 hardware platform with Nordic nRF5_SDK_15.2.0.

You can use the WOLFSSL_CRYPTOCELL macro to activate the CryptoCell support in wolfSSL. For instructions on how to build and run the examples on your projects, please see the “<wolfssl-root>/IDE/CRYPTOCELL/README” file.  This support is currently located in our GitHub master branch, and will roll into the next stable release of wolfSSL.

wolfSSL provides support for the latest and greatest version of the TLS protocol, TLS 1.3! Using the wolfSSL port 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/

Posts navigation

1 2 3 4 95 96 97

Weekly updates

Archives

Latest Tweets