RECENT BLOG NEWS

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.

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.

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.

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.

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

Microsoft and Canonical`s new tools Windows Subsystem for Linux and Bash on Ubuntu on Windows brings a familiar bash environment based on the Ubuntu user-space to Windows 10.  This allows developers to use tools available on Linux and other Unix-like systems from within Windows.

Before developers can utilize Windows Subsystem for Linux, the feature has to be installed.   

1. Open Settings
2. Click Update & Security
3. Click For Developers
4. Click Developer Mode  
5. Now open Control Panel
6. Click Programs and Features
7. Click Turn Windows features on or off.
8. Find and check Windows Subsystem for Linux (Beta)
9. Click OK and follow prompts to finish installation.

Now that WSL is installed it is time to install the Ubuntu image.  This is accomplished by launching the Windows Command Prompt and typing “bash.exe”.  Follow the prompts to finish the installation.

You now have a fully installed Linux image on Windows!  You can launch bash by either running a Windows command prompt and entering the command “bash” or you can find the shortcut “Bash on Ubuntu on Windows” in your start menu.

To setup your environment to build wolfSSL you`ll need the following:

– make
– autoconf
– gcc

These can be installed with “$ sudo apt-get install make autoconf gcc” in bash.  Finally, the steps to build and install wolfSSL for Linux are:

1. $ ./autogen.sh
2. $ ./configure
3. $ make
4. $ make install

This was tested and verified with GCC version 4.8.4 and Linux kernel 3.4.0. make in our test environment was able to build wolfSSL in 28.415s.

Additional references:
wolfSSL Embedded SSL/TLS Library
https://blogs.windows.com/buildingapps/2016/07/22/fun-with-the-windows-subsystem-for-linux/
https://msdn.microsoft.com/en-us/commandline/wsl/about
https://msdn.microsoft.com/en-us/commandline/wsl/install_guide

wolfSSL is a growing company looking to add a top notch embedded systems software engineer to our organization. We develop, market and sell the leading Open Source embedded SSL/TLS protocol implementation, wolfSSL. Our users are primarily building devices or applications that need security. Other products include wolfCrypt embedded cryptography engine, wolfMQTT client library, and wolfSSH.

Operating environments of particular interest to us include Embedded Linux and RTOS varieties (VxWorks, QNX, ThreadX, uC/OS, MQX, FreeRTOS, etc). Experience with mobile environments like Android and iOS is a plus.

Currently, we are seeking to add a senior level C engineer interested in a fun company with tremendous upside. Backgrounds that are useful to our team include networking, security, and hardware optimizations. Assembly experience is a plus. Experience with encryption software is a plus. RTOS experience is a plus.

Location is flexible. For the right candidate, we’re open to this individual working from virtually any location.

How To Apply

To apply or discuss, please send your resume and cover letter to facts@wolfssl.com.

wolfSSL is interested in hiring an experienced web developer to redesign and maintain the wolfSSL website. This will be a full time position as an employee of wolfSSL. Responsibilities will include website redesign, development, and maintenance as well as writing and improving product documentation. The website will have both static and dynamic content, including a blog and product download pages.

The ideal candidate will have experience with modern web tools and frameworks, experience with web server setup and maintenance, good technical writing skills, and have a passion for cryptography and security fields.

Responsibilities:

+ Redesign of the wolfSSL website, based on a modern web framework
+ Integration of a dynamic blogging platform
+ Creation and maintenance of software documentation
+ Maintenance, expansion, and optimization of the wolfSSL website and forums

Requirements:

+ Knowledge of HTML, CSS, PHP, and modern web languages
+ Familiarity and experience with web and blog frameworks
+ Knowledge of web design best practices
+ Knowledge of back end database systems, such as MySQL
+ Knowledge of SEO and search engine compatibility
+ Team player, able to work well either individually or in a group
+ Interest in cryptography and security software
+ Proficient technical writing skills

How to Apply:

If interested in applying, please send your resume to facts@wolfssl.com.  wolfSSL product and company details can be found online at www.wolfssl.com.

Microchip recently released an end-to-end security solution for IoT devices that connects to the Amazon Web Services (AWS). The kit, AT88CKECC, allows users to easily and securely connect to AWS out of the box. It includes the ECC508 device which provides secure key generation and storage.

Full details and product links can be found in the Microchip press release, or on the Microchip website.

wolfSSL has partnered with Microchip / Atmel to add support for the ATECC508A module in wolfSSL’s embedded SSL/TLS library. Please visit our ATECC508A webpage for complete details and a link to our downloadable package.

wolfSSL is happy to help answer any questions you may have about using wolfSSL with Microchip or Atmel platforms. Please reach out to us at facts@wolfssl.com to get in touch.