wolfSSL WICED Port

wolfSSL recently released version 4.0.0 of the wolfSSL embedded SSL/TLS library with a litany of port additions. One of these new ports is added functionality for Cypress’s WICED Studio SDK! WICED Studio is an SDK targeting IoT devices, offering both Bluetooth and WI-Fi (IEEE 802.11) development platforms. WICED SDK offers code examples and tools for embedded development boards including Adafruit Feather boards which, is a great alternative to Arduino for student boards. The code examples demonstrate the use of wolfCrypt and integrate wolfSSL functionality into the WICED platform. A TLS client and server was added using the wolfSSL library, as well as, an HTTPS client example. wolfSSL supplies a client and server for testing purposes, the HTTPS client example also runs against the wolfSSL example server as well as www.example.com for demonstration purposes.

wolfSSL is a highly configurable option to accompany WICED software allowing manual configuration options affecting functionality and build size. The examples provided serve as a starting point for any embedded project and works with TLS versions 1.0, 1.1, 1.2, and 1.3; they are built on the ThreadX RTOS using NetX Duo for the TCP/IP stack.

wolfSSL v4.0.0.0 can be downloaded from the wolfSSL download page, or from the GitHub repository here: https://github.com/wolfssl/wolfssl.git.

Supported functionality and features:

  • wolfCrypt test suite and benchmark test
  • wolfSSL TLS client and server
  • wolfSSL HTTPS client
  • NetX Duo TCP/IP stack for embedded systems
  • ThreadX RTOS for embedded platforms
  • Server Name Indication (SNI) extension
  • Maximum fragment length extension
  • Truncated HMAC
  • TLS versions 1.0, 1.1, 1.2, and 1.3
  • Certificate verification
  • Certificate chain loading
  • RSA and ECC certificates
  • Multithread capability
  • Session resumption

Cipher suites supported out of the box:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-RSA-CHACHA20-POLY1305
AES128-GCM-SHA256
AES256-SHA256
AES256-GCM-SHA384
AES128-SHA

Cipher suites supported for TLS 1.3 out of the box:

TLS13-AES128-GCM-SHA256
TLS13-AES256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES128-CCM-SHA256

wolfSSL Java JSSE Provider

We’re happy to announce that wolfSSL is currently working on a Java Secure Socket Extensions (JSSE) provider for the native wolfSSL embedded SSL/TLS library!  JSSE is a way for Java applications to utilize the SSL and TLS protocols through a standardized Java API using pluggable “providers” underneath. It was integrated into Java versions following Java 1.4. With this upcoming provider, Java applications will have the ability to use the most recent and secure version of the TLS protocol, TLS 1.3!  And for FIPS 140-2 users, this will allow Java applications to use wolfCrypt FIPS underneath if needed.  Additionally, this will also allow users to take advantage of other features offered by the wolfSSL library such as high-speed and high-strength encryption, high portability, low footprint size, and more!

Are you interested in a JSSE provider for wolfSSL?  For more information about the wolfSSL library, its features, or if you would like to share your interest on this feature addition, please contact facts@wolfssl.com.

Reference
wolfSSL GitHub repository: https://github.com/wolfssl/wolfssl.git
Oracle JSSE reference guide: https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#Introduction

wolfSSL at Japan IT Week Spring 2019

wolfSSL is at Japan IT Week - Spring this year! Japan IT Week Spring occurrs twice this year, once in April and once in May. wolfSSL will be attending the event in April, which will include two exhibitions: IoT/M2M Expo Spring and Embedded Systems Expo. For 2019, Japan IT Week Spring (part 1) will be held in Tokyo, Japan.

Where wolfSSL will be located for Japan IT Week:
Venue: Tokyo Big Sight
Booth #: 6-9, West Hall
When: April 10-12
Directions: https://www.japan-it-spring.jp/en-gb/visit/access.html

Stop by to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, to meet the wolfSSL Japan 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 Japan IT Week Spring can be found here: https://www.japan-it-spring.jp/ja-jp.html

wolfSSH Nonblocking Support

wolfSSL's wolfSSH library is a small footprint, fast, embedded SSH implementation. With recent additional support and adjustments, support for non-blocking connections has been added to the library! This allows for use of non-blocking connections with other features besides SSH, such as use with SFTP and SCP. This non-blocking support is supported by default and is easy to use. The default API can be called and the wolfSSH library internally handles all saving and restoring of states, returning WS_WANT_READ or WS_WANT_WRITE when calling wolfSSH_get_error() to signal if the API should be called again. The library is designed to be easy to use and quick to integrate into an application.

For more information about wolfSSH or using it in your project, please contact facts@wolfssl.com.

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.

wolfSSL now has lwIP support

The wolfSSL (formerly CyaSSL) embedded SSL library supports lwIP, the light weight internet protocol implementation, out of the box.  The user merely needs to define WOLFSSL_LWIP or uncomment the line /* #define WOLFSSL_LWIP */ in os_settings.h to use wolfSSL with lwIP.

The focus of lwIP is to reduce RAM usage while still providing a full TCP stack.  That focus makes lwIP great for use in embedded systems, the same area where wolfSSL is an ideal match for SSL/TLS needs.  An active community exists with contributor ports for many systems.  Give it a try and let us know if you have any suggestions or questions.

For the latest news and releases of lwIP, you can visit the project homepage, here: http://savannah.nongnu.org/projects/lwip/

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

wolfSSL with MPLAB Harmony v3

Since earlier versions, wolfSSL's embedded SSL/TLS library has been included with MPLAB Harmony. MPLAB Harmony is a flexible, fully integrated embedded software development framework for 32-bit MCUs and MPUs. Recently, MPLAB Harmony version 3 was released, with wolfSSL packaged within! The new release of MPLAB Harmony features aspects from the latest version of wolfSSL, version 3.15.7. wolfSSL is included in such a way that the example applications, demos, and source code of the wolfSSL library can be easily integrated and executed with other MPLAB projects. Additionally, other software libraries and examples are also being included in this new release of MPLAB Harmony, such as CMSIS-FreeRTOS.

For more information on the new release of MPLAB Harmony v3, please visit Microchip's page here: https://www.microchip.com/mplab/mplab-harmony/mplab-harmony-v3.

For more information about wolfSSL, wolfSSL with MPLAB Harmony, or other general inquiries, please contact facts@wolfssl.com.

 

MQTT v5.0 Approved by OASIS

wolfSSL provides many different products for many different implementations of internet protocols, one of which is wolfMQTT. The wolfMQTT library is a client implementation of the MQTT written in C for embedded use, with support for SSL/TLS via the wolfSSL library, and also provides support for MQTT-Sensor Network (MQTT-SN). While wolfMQTT is based on the MQTT 3.1.1 specification, wolfMQTT also provides support for the MQTT v5.0 specification - which was recently approved and standardized by OASIS. This new standard comes with some changes, which are outlined below (from the MQTT v5.0 standard):

  • Enhancements for scalability and large scale systems
  • Improved error reporting
  • Formalize common patterns including capability discovery and request response
  • Extensibility mechanisms including user properties
  • Performance improvements and support for small clients

For more information about wolfMQTT or its MQTT v5.0 support, please contact facts@wolfssl.com.

Reference
wolfMQTT GitHub Repository: https://github.com/wolfssl/wolfmqtt.git
wolfMQTT User Manual: https://www.wolfssl.com/docs/wolfmqtt-manual/
MQTT v5.0 specification: https://docs.oasis-open.org/mqtt/mqtt/v5.0/cos02/mqtt-v5.0-cos02.html#_Toc1477318

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.

Differences between SSL and TLS Protocol Versions (#TLS13)

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.

Posts navigation

1 2