RECENT BLOG NEWS

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.

Strong cryptographic algorithms and secure protocol implementations are a vital foundation to securing the Internet of today and tomorrow. Securing over a billion active connections on the Internet today, wolfSSL knows this very well. A recent announcement by the National Security Agency conveyed their plans to transition from recommending the Suite B set of algorithms to a quantum resistant solution.

Suite B is currently specified by NIST and used by NSA’s Information Assurance Directorate in solutions approved for protecting classified and unclassified National Security Systems (NSS).

During the transition phase, the NSA is recommending that the following algorithms and key sizes be used to protect up to TOP SECRET:

Advanced Encryption Standard (AES) with 256-bit keys
Elliptic Curve Diffie-Hellman (ECDH) Key Exhange, with Curve P-384
Elliptic Curve Digital Signature Algorithm (ECDSA), with Curve P-384
Secure Hash Algorithm (SHA-384)
Diffie-Hellman Key Exchange (DH), with a minimum of 3072-bit modulus
RSA, with a minimum of 3072-bit modulus

The wolfSSL embedded SSL/TLS library supports all of the above cryptographic algorithms, curves, and key sizes. In addition to these algorithms, wolfSSL supports the NTRU public key algorithm which is quantum resistant. As of version 3.6.6, wolfSSL includes support for “Quantum-safe hybrid” ciphersuites through the partnership with Security Innovation.

NSA Article: https://www.nsa.gov/what-we-do/cybersecurity/
Ars Technica Article: http://arstechnica.com/security/2015/08/nsa-preps-quantum-resistant-algorithms-to-head-off-crypto-apocolypse/
Wikipedia, Post-Quantum Cryptography: https://en.wikipedia.org/wiki/Post-quantum_cryptography

Version 3.6.6 of the wolfSSL embedded SSL/TLS library has been released and is now available for download. Release 3.6.6 of wolfSSL has bug fixes and new features including:

– OpenSSH, stunnel, and lighttpd Compatibility

OpenSSH compatibility with “–enable-openssh”
stunnel compatibility with “–enable-stunnel”
lighttpd web server compatibility with “–enable-lighttpd”

– SSL 3.0 is now disabled by default

We have previously announced our plans to deprecate and remove support for SSL 3.0 in the wolfSSL library, encouraged to do so by the POODLE attack. With this release, we have disabled SSL 3.0 support by default. Users who still want to use SSL 3.0 can enable it by using the “–enable-sslv3” ./configure option.

– Ephemeral key cipher suites only are now supported by default

To enable static ECDH cipher suites define WOLFSSL_STATIC_DH
To enable static RSA cipher suites define WOLFSSL_STATIC_RSA
To enable static PSK cipher suites define WOLFSSL_STATIC_PSK

– Added QSH (Quantum-Safe Handshake) Extension

wolfSSL, in partnership with Security Innovation, has added support for the proposed “Quantum-safe hybrid” ciphersuite. Having this cipher suite supported in the wolfSSL embedded TLS library allows two parties to use any existing ciphersuite and “quantum-safe” any traffic protected by that ciphersuite. This means that an attacker who records the traffic and later develops a quantum computer cannot go back and crack the session.

Support for QSH extension can be enabled by using the “–enable-ntru” ./configure option.

– SRP is now part of wolfCrypt

SRP is a password authentication and key-exchange protocol suitable for authenticating users and exchanging keys over an untrusted network designed by Thomas Wu at the Computer Science Department of Stanford University.

Support for SRP in wolfCrypt can be enabled with the “–enable-srp” ./configure option.

– Certificate handshake message fragmentation support

Certificate handshake messages can now be sent fragmented if the record size is smaller than the total message size, no user action required.

– DTLS duplicate message fixes

– Visual Studio project files now support DLL and static builds for 32/64bit

For information on compiling wolfSSL with Visual Studio, reference Chapter 2 of the wolfSSL Manual, or the “Using wolfSSL with Visual Studio” webpage.

– Support for new Freesacle I/O

Freescale KSDK and Kinetis Design Studio users can now compile wolfSSL for the new KSDK version of MQX by defining FREESCALE_KSDK_MQX in settings.h or by adding it to the list of preprocessor defines.

– FreeRTOS FIPS support

This release includes FIPS support for FreeRTOS platforms.

This release contains no high level security fixes that requires an update though we always recommend updating to the latest version of wolfSSL.

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.6: https://www.wolfssl.com/

The Cryptographic Module Validation Program (CMVP) has issued FIPS 140-2 Certificate #2425 (most up-to-date certificate: #3389) for the wolfCrypt Module developed by wolfSSL Inc. The CMVP was established by the National Institute of Standards and Technology (NIST) to validate FIPS 140-2 cryptographic modules and oversee the independent laboratories performing the cryptographic module testing.

FIPS 140-2 requires the use of validated cryptography in the security systems implemented by federal agencies to protect sensitive information.

The wolfCrypt Module is a comprehensive suite of FIPS Approved algorithms. All key sizes and modes have been implemented to allow flexibility and efficiency. The wolfCrypt Module was initially tested on Linux, iOS, and Android platforms. FreeRTOS and Windows platforms (including Windows Kernel) will soon be included on the FIPS 140-2 certificate.

“The wolfCrypt Module successfully completed the rigorous FIPS 140-2 Level 1 validation process. This process includes verification of proper documentation, configuration management review, algorithm testing, source code review, operational testing, and coordination with the CMVP,” said Marc Ireland, FIPS Program Manager at InfoGard Laboratories.

“wolfSSL customers are using our software FIPS cryptographic module in small embedded devices, network appliances, and large server systems,” said Larry Stefonic, Founder and CEO of wolfSSL Inc. “We are committed to adding new platforms and performing custom FIPS validations to offload the certification testing burden from our customers.”

Important differentiators in the wolfCrypt Module include the implementation of a Default Entry Point and DRBG Health Testing.

wolfCrypt implements a Default Entry Point to meet FIPS 140-2 Implementation Guidance 9.10. Many other software FIPS modules require the calling application to initiate the power-on self-tests. Those previously validated modules do not meet current guidance from the CMVP and unnecessary risk is being forced on the users of those modules.

In May 2015, the CMVP provided strict guidance to all of the Testing Laboratories that Health Testing is required for FIPS Approved DRBGs. During the wolfCrypt FIPS validation process, InfoGard Laboratories verified through source code review and operational testing that the DRBG Health Testing (described in SP800-90A Section 11.3) was implemented to the requirements.

Please contact wolfSSL Inc. (fips@wolfssl.com) to accelerate your FIPS 140-2 project.

If you are working on integrating wolfSSL into an application that already has existing logging functionality, but still want access wolfSSL`s built-in debug messaging, you can register a custom logging callback with wolfSSL to output wolfSSL`s detailed debug messaging.

To enable this functionality, add the configure option “–enable-debug” to wolfSSL. Then, in your application simply:
• Include
• Call wolfSSL_Debugging_ON();
• Call wolfSSL_SetLoggingCb(&custom_logging_cb);

The custom logging function provided to wolfSSL_SetLoggingCb should be of type:

void wolfSSL_Logging_cb(const int logLevel, const char *const logMessage);

Adding this logging support will enable wolfSSL debug messaging with general information (including which function is currently executing), notes about function execution and code path, as well as additional information on any errors occurring during execution. It`s a great tool to help track down any bugs you run into when integrating wolfSSL. For more information please see the debugging section in the wolfSSL embedded SSL/TLS manual: http://www.wolfssl.com/docs/wolfssl-manual/ch8/

Thanks to the continued efforts of the Texas Instruments Team there is now a Wiki Page for using the wolfSSL embedded SSL/TLS library with TI-RTOS.
Using wolfSSL with TI-RTOS (PDF)

Members of the wolfSSL team have worked through this wiki and created a step-by-step guide for customers unfamiliar with Code Composer Studio (CCS), SSL/TLS, or TI-RTOS. This guide will assist our customers by exposing them to important parts of the CCS API, ushering them through the setup and familiarization process, and speeding them on their way to development for their own projects.

This guide can be found in the wolfssl-examples repository on github under the tirtos_ccs_examples directory:
https://github.com/wolfSSL/wolfssl-examples/blob/master/tirtos_ccs_examples/README.md

On applications using ECC with wolfSSL where total memory footprint is a secondary factor to performance, consider enabling fixed point ECC with wolfSSL. This configure option generates a large lookup table for use with ECC that can increase performance time by as much as 5 times. This comes at the cost of runtime memory, but can be well worth it, especially when doing many ECC key operations.

To enable this option with wolfSSL, at compile time append “–enable-fpecc” to your list of ./configure options.

To read more about the math behind fixed point ECC, please see this article: http://www.mdpi.com/1424-8220/13/7/9483 which discusses the potential size advantages and disadvantages of fixed point ECC.

Researchers Clemens Hlauschek, Markus Gruber, Florian Fankhauser, and Christian Schanes of Germany`s Research Industrial Systems Engineering are presenting a TLS Man in the Middle attack at this week’s USENIX conference in Washington D.C: https://www.usenix.org/system/files/conference/woot15/woot15-paper-hlauschek.pdf .  This is a protocol level attack that has a few requirements; a static (EC)DH cipher suite, client authentication with a static (EC)DH private key, and the injection of a known certificate/key pair into the client.  The wolfSSL embedded SSL library does support static ECDH cipher suites, whereas static DH cipher suites are not supported.  While client authentication is supported in wolfSSL ecdsa_fixed_ecdh is not supported, meaning yaSSL / CyaSSL / wolfSSL are not vulnerable to the attack.

We still recommend the use of our max strength build to ensure the highest level of security, max strength ensures Perfect Forward Secrecy cipher suites only: http://www.wolfssl.com/wolfSSL/Blog/Entries/2015/7/10_wolfSSL_Max_Strength_Build.html .  The next release of wolfSSL disables all static cipher suites by default and documents their use as deprecated and insecure as the paper suggests.

Please contact wolfSSL by email at facts@wolfssl.com, or call us at 425 245 8247 if you have any security related questions.

We are pleased to announce that wolfCrypt now has support for SRP6a (Secure Remote Password Protocol version 6a).

SRP is a password authentication and key-exchange protocol suitable for authenticating users and exchanging keys over an untrusted network designed by Thomas Wu at the Computer Science Department of Stanford University.

The SRP implementation can be enabled with either:

./configure –enable-srp

OR

defining WOLFCRYPT_HAVE_SRP if you’re not using autotools.

The wolfCrypt SRP documented api can be found directly in the srp.h file in our repository at github.

If you have any questions about using SRP with wolfCrypt or the wolfSSL embedded SSL/TLS library please let us know at facts@wolfssl.com.