Month: September 2016

Intel ® SGX (Software Guard Extensions) allows for additional security and a smaller surface area for attack. One way this is accomplished is by restricting access to portions of memory even from other applications running on the same computer. This additional security is for both code that is being executed and stagnant information with “sealing” data.

Do you have a use case where cryptography with Intel’s ® SGX is needed? wolfSSL has a port to use SGX under development. A demo version of this port was shown at the IDF conference and demonstrated the low latency for additional security gains that Intel’s ® SGX provides.

If you have a need for an embedded SSL/TLS library with Intel ® SGX contact us today facts@wolfssl.com.

One of the changes in the recent wolfSSL 3.9.10 release, to mitigate against the SWEET32 attack, is that the 3DES algorithm is now disabled by default when using the Autoconf (./configure) build system. Non Autoconf users can disable 3DES by defining NO_DES3 when compiling wolfSSL.

For those not familiar with SWEET32, more information can be found on the attack’s website, listed below. In summary, SWEET32 is an attack on block cipher algorithms that use a block size of 64 bits:

https://sweet32.info/

For more information about the wolfSSL embedded SSL/TLS library, please contact facts@wolfssl.com.

wolfSSL release 3.9.10 fixes 3 medium level security vulnerabilities:

CVE-2016-7440 The C software version of AES Encryption and Decryption in wolfSSL 3.9.8 and earlier uses a T-table based implementation where Table lookups do not properly consider cache-bank access times.  This makes it easier for a local user to discover AES keys by running a crafted application on the same machine as a victim and leveraging cache-bank timing differences.

CVE-2016-7439 The C software implementation of RSA in wolfSSL 3.9.8 and earlier uses a different variable during squaring depending on the key state and does not properly consider cache bank monitoring.  This makes it easier for a local user to discover RSA keys by running a crafted application on the same CPU core as a victim and leveraging cache-bank hit differences.

CVE-2016-7438 The C software implementation of ECC in wolfSSL 3.9.8 and earlier uses a different variable during doubling depending on the key state and does not properly consider cache bank monitoring.  This makes it easier for a local user to discover RSA keys by running a crafted application on the same CPU core as a victim and leveraging cache-bank hit differences.

VM users, hyper-threading users, and users where potential attackers have access to the CPU cache will need to update if they utilize AES, RSA private keys, or ECC private keys.

Thanks to Gorka Irazoqui Apecechea and Xiaofei Guo from Intel Corporation for the reports.

If you have a need for an embedded SSL/TLS library or any questions please contact us today at facts@wolfssl.com.

Version 3.9.10 of the wolfSSL embedded SSL/TLS library is now available for download. This release contains bug fixes, new features, and includes fixes for three medium level vulnerabilities.

Vulnerabilities fixed by this release include CVE-2016-7440, CVE-2016-7439, and CVE-2016-7438, as explained in this recent wolfSSL blog post. This includes fixes for
potential AES, RSA, and ECC side channel leaks that a local user monitoring the same CPU core cache could exploit. VM users, hyper-threading users, and users where potential attackers have access to the CPU cache will need to update if they utilize AES, RSA private keys, or ECC private keys. Thanks to Gorka Irazoqui Apecechea and Xiaofei Guo from Intel Corporation for
the report.

Other changes and new features in this release are described below.

Default Configure Option Changes

3DES (–enable-des3) is disabled by default.  3DES has been disabled for security after the Sweet32 attack was announced.

ECC Supported Curves Extension (–enable-supportedcurves) is enabled by default.  The ECC Supported Curves Extension, when enabled, broadcasts the ECC curves supported by the client in the Client Hello message.

TLS Extended Master Secret (–enable-extended-master) is enabled by default.  The 3SHAKE attack demonstrated how an active attacker can synchronize two TLS sessions so that they share the same “master_secret”.  As per RFC 7627, this extension “changes the way the “master_secret” value is computed in a full handshake by including the log of the handshake messages, so that different sessions will, by construction, have different master secrets.”

Added checking CA certificate path length, and new test certs

From RFC 5280, “the basic constraints extension identifies whether the subject of the certificate is a CA and the maximum depth of valid certification paths that include this certificate.”  The path length constraint field (pathLenConstraint) specifies the maximum number of non-self-issued intermediate certificates that may follow a given CA certificate in a certificate chain.

wolfSSL now checks the path length between an intermediate CA certificate and its signer’s path length, always decodes the path length if present, and saves the path length into the signers list.  The path length is capped at 127 certificates.  New test certificates have been added for this scenario, located under the “./certs/test-pathlen” directory.

Fix to DSA pre padding and sanity check on R/S values

This fix adds pre padding of DSA signature with zeros and adds sanity checks for R/S values during DSA sign operations to make sure they are not zero.

Added CTX level RNG for single-threaded builds

In SINGLE_THREADED mode wolfSSL has a new API, wolfSSL_CTX_new_rng(), that creates an RNG object at the WOLFSSL_CTX level that is shared with each created WOLFSSL session object. This is only allowed in SINGLE_THREADED mode because otherwise locking/blocking would be needed. The benefit to this CTX-level RNG is there is only one RNG object to seed and this also saves 200 bytes or so from each WOLFSSL session. It can be called immediately after wolfSSL_CTX_new(), the example client now uses it in SINGLE_THREADED mode.

Intel RDSEED enhancements

Improvements to Intel RDSEED include:
+ Increase RDSEED retries to 32, still an order of magnitude faster than /dev/urandom
+ Increase RDSEED retrieval to 64bits, halving the number of calls
+ Allow fallback to /dev/urandom on retry failure
+ Allow fallback override (that is hard failure) with FORCE_FAILURE_RDSEED which does not fallback to /dev/urandom

ARMv8 hardware acceleration support for AES-CBC/CTR/GCM, SHA-256

Users running wolfSSL on ARMv8 now have access to increased performance through hardware acceleration integration.  More details can be found in this blog post, or by emailing us directly.

Arduino support updates

Interested in securing your Arduino-based project?  Arduino build instructions and build script have been updated to make building wolfSSL for Arduino environments more intuitive.  Arduino build instructions can be found in “./IDE/ARDUINO/README.md” located in the wolfSSL download package.

Added the Extended Master Secret TLS extension

Support for the TLS Extended Master Secret extension has been added to wolfSSL, both at the SSL/TLS and sniffer levels.  This extension is enabled by default and can be disabled through the provided API functions (reference the wolfSSL Manual for API and usage).

OCSP fix with issuer key hash, lookup refactor

This includes two fixes.  The first for the wolfSSL CertManager OCSP lookup where the issuer key hash wasn’t being set correctly and could lead to unknown responses from the lookup.  The second fix addresses the default OCSP lookup callback which previously could get blocked waiting for the server to close the socket.

Added support for Frosted OS

wolfSSL now has support for the Frosted (Free POSIX OS for tiny embedded devices) operating system.  More information about FROSTED can be found in their GitHub repository.

Added support for DTLS over SCTP

wolfSSL has added support for DTLS over SCTP (Stream Control Transmission Protocol).  If you are not familiar with SCTP, from Wikipedia, “SCTP provides some of the same service features of both [TCP and UDP]: it is message-oriented like UDP and ensures reliable, in-sequence transport of messages with congestion control like TCP; it differs from these in providing multi-homing and redundant paths to increase resilience and reliability.”

wolfSSL has a new configure option to enable DTLS-SCTP support called “–enable-sctp”, and now includes example tools and test applications under the “./examples/sctp” directory.  These include an SCTP Client, Server, and DTLS-SCTP Client and Server.

Added support for static memory with wolfCrypt

wolfCrypt now has the ability to use only static memory with the wc_LoadStaticMemory() function.  The wolfCrypt test and benchmark applications can use this functionality when WOLFSSL_STATIC_MEMORY is defined.

Fix to ECC Custom Curve support

This includes a fix for wc_ecc_set_custom_curve() not setting the index as ECC_CUSTOM_IDX and also includes cleanup of the ECC test cases.

Support for asynchronous wolfCrypt RSA and TLS client

Added asynchronous wolfCrypt RSA, TLS client and Cavium Nitrox V support including asynchronous wolfSSL client support for “DoServerKeyExchange”, “SendClientKeyExchange”, “SendCertificateVerify” and “DoCertificateVerify”. This includes fixes for asynchronous DTLS, a refactor of the event and asynchronous handling for use in wolfCrypt, and a refactor of the async device support so it is hardware agnostic.

Added Cavium Nitrox V support (Nitrox tested using SDK v0.2 CNN55XX-SDK with new configure “–with-cavium-v=/dir” option) and Nitrox specific functions have been moved to a new port file called “port/cavium/cavium_nitrox.c”.

RSA has been refactored to handle async with states including RSA optimization for using dpraw for private key decode. wolfCrypt test and benchmark support for async RSA has been added. Asynchronous mode can now be enabled using “./configure –enable-asynccrypt”. If no async hardware is defined then the internal async simulator (WOLFSSL_ASYNC_CRYPT_TEST) is used. Note: Using async mode requires async.c/h files from wolfSSL. If interested in using asynchronous mode please send email to facts@wolfssl.com.

Added distribution build configure option

For easier creation of OS and Distribution packages, a new ./configure option has been added called “–enable-distro”.  Package maintainers should now use this option instead of hand picking options themselves for wolfSSL packages.  This will guarantee that ./configure options are enabled/disabled as the wolfSSL engineers recommend.

Update the test certificates

The wolfSSL test certificates have been updated so that they now all have the same expiration date.  Additional DER formatted test certificates, including ECC ones, have been added.

Please contact wolfSSL at facts@wolfssl.com with any questions about new features or fixes made in this release of wolfSSL.

Hi! We are currently embarking on a mission to support TPM 2.0 with the wolfSSL embedded SSL library. If you are interested in being an alpha tester, please let us know at facts@wolfssl.com.

Are you looking to use cryptography on an ARMv8 board? wolfSSL is in the process of optimizing AES and SHA256 operations using ARMv8 hardware acceleration. This gives the embedded TLS/SSL library a large performance boost when enabled and using AES-SHA256 cipher suites. The current development state can be found on our GitHub repository and enabled with “./configure —enable-armasm”.

For more information contact us at facts@wolfssl.com