Month: September 2015

Many technology vendors implement OpenSSH with OpenSSL in their embedded system or appliance prior to starting a FIPS 140-2 validation. During the FIPS testing process, the vendor discovers that the FIPS Laboratory must verify the OpenSSH implementation:

1. Uses FIPS Approved cryptographic algorithms (with CAVP certificates)
2. Includes self-tests for the FIPS Approved algorithms
3. Prevents use of non-approved algorithms
4. Enters an error state upon self-test failure

This strategy of implementing OpenSSH with OpenSSL creates additional challenges for the vendor in an already complex and time-consuming FIPS testing process.

wolfSSL Inc.’s wolfCrypt FIPS Module for OpenSSH provides a fast path to a FIPS 140-2 validation by meeting all of the FIPS requirements. Only FIPS Approved algorithms are available to OpenSSH. The self-tests are optimized. And the wolfSSL team will perform the CAVP algorithm testing (including SSH KDF and FIPS 186-4 KeyGen) for you on your target platform.

Streamline and simplify your OpenSSH implementation by using the wolfCrypt FIPS Module for OpenSSH. Please contact fips@wolfSSL.com to receive expert guidance on your FIPS 140-2 project.

Version 3.6.8 of the wolfSSL embedded SSL/TLS library has been released and is now available for download. Release 3.6.8 of wolfSSL fixes two high severity vulnerabilities. It also includes bug fixes and new features including:

– Two High level security fixes, all users SHOULD update.

a) If using wolfSSL for DTLS on the server side of a publicly accessible machine you MUST update.
b) If using wolfSSL for TLS on the server side with private RSA keys allowing ephemeral key exchange without low memory optimizations you MUST update and regenerate the private RSA keys.

Please see our recent vulnerability blog post for more details

– No filesystem build fixes for various configurations
– Certificate generation now supports several extensions including KeyUsage, SKID, AKID, and Certificate Policies
– CRLs can be loaded from buffers as well as files now
– SHA-512 Certificate Signing generation
– Fixes for sniffer reassembly processing

For more information about using and compiling wolfSSL, please visit the wolfSSL Documentation page or wolfSSL Manual. If you have questions about the wolfSSL embedded SSL/TLS library, or about using it in your project, please Contact Us.

Download wolfSSL 3.6.8: https://www.wolfssl.com/

Attack on RSA CRT:

A recent paper written by Florian Weimer of the Red Hat Product Security group shows a fault attack on RSA. Many cryptographic libraries that perform RSA operations use an optimization called CRT (Chinese Remainder Theorem). The attack is based off of creating a fault during the CRT process, for example; by causing the system to overheat, using a race condition, or simply a faulty CPU. With the introduction of this attack the function wc_RsaSSL_VerifyInline is now used to verify no fault has happened, this verify function is now automatically used on all TLS connections that were previously affected.

Only a small subset of wolfSSL embedded SSL/TLS builds were affected by the attack on RSA CRT. Those using wolfSSL for TLS connections on the server side with private RSA keys, allowing the use of ephemeral key exchange and without using the low memory setting are affected. An example of this is a wolfSSL TLS server side that uses the suite ECDHE-RSA-AES256-SHA256 having ephemeral key exchange and loading in a private RSA to create the connection, the client side of this connection is not affected. We recommend updating to the most recent wolfSSL release 3.6.8 and renewing all RSA private keys if you meet the affected criteria. If using wolfSSL on the client side this attack is not an issue.

CVE-2015-7744 has been assigned to this vulnerability.

DoS on DTLS:

Recently a researcher (thanks to Sebastian Ramacher from the Institute for Applied Information Processing and Communications at Graz University of Technology) notified wolfSSL of the potential to amplify a DTLS denial of service attack. The original cookie generation callback used a hash of the current socket peer’s IP address and port number. Now the cookie is based on the client’s hello message per the RFC (client IP address, client port number, version, random, cipher suites, compression) and HMACed with an application provided secret.

Only those using DTLS on the server side of a publicly accessible machine are affected. We recommend affected servers to update to release 3.6.8 which now generates an unpredictable cookie using HMAC.

CVE-2015-6925 has been assigned to this vulnerability.

For any questions contact us at facts@wolfssl.com
Link to paper written about the RSA-CRT attack https://people.redhat.com/~fweimer/rsa-crt-leaks.pdf

FIPS 140-2 revalidation testing requires the implemented algorithms to successfully complete the cryptographic algorithm validation process on the target operating environment (algorithm certificates for tested operating environments are here: https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program).

The cryptographic module must also successfully complete operational testing on the operating environment with a FIPS testing laboratory.

The wolfCrypt FIPS 140-2 certificate #2425 will soon include all of the following tested environments:
• Windows 7
• FreeRTOS
• iOS
• Android
• Linux

If you do not see your operating environment of choice, the wolfSSL team can add yours to our list. We accelerate FIPS projects by providing validated cryptography and testing services to our customers.

wolfCrypt has received two certificates since – #2425, #3389

Please contact fips@wolfSSL.com to receive expert guidance on your FIPS 140-2 project.

Lighttpd (pronounced lighty) is a web server that has a small footprint size in comparison to other web servers. Setting up Lighttpd allows for handling HTTP requests and with the addition of TLS/SSL also handling HTTPS requests. The benefit of having a small footprint size is that it takes up less memory for total installation and for each connection made. This allows it to be more scalable and also use less resources.

Combining the small footprint size of wolfSSL with Lighttpd makes for an extremely light weight web server. Perfect for use on IoT devices with constrained amounts of memory and on large servers looking for scalability. With the use of wolfSSL, users can get the progressiveness and solid security that the embedded TLS/SSL library offers on their web servers. To build wolfSSL for use with Lighttpd simply run the configure option “./configure –enable-lighty” from wolfSSL`s main directory, then make and make install.

For a version of Lighttpd that links to the wolfSSL library, or for more information, contact us at facts@wolfssl.com.