RECENT BLOG NEWS

Did you know that the wolfSSL embedded SSL/TLS library has support for the Digital Signature Algorithm (DSA)? Many of us in security are familiar with Ron Rivest, Adi Shamir, and Leonard Adleman (RSA). DSA is a public key operation like RSA. When using keys of the same length RSA and DSA are considered to be of equivalent strength.

DSA is faster than RSA at decryption and signature generation.

Why might this matter to you? If you are designing an application that will use encryption and decryption, you might want to consider which operation it will do most frequently. For heavy decryption and light encryption, the more optimal public key operation by performance would be DSA.

More details on DSA can be found on the DSA wikipedia page.

For more information about DSA support in wolfSSL and wolfCrypt, please reference Section 10.5.4 of the wolfSSL Manual.  Please contact us at facts@wolfssl.com with any questions.

Have you heard about the recent ChaCha20-Poly1305 AEAD supported by wolfSSL embedded SSL/TLS and are wondering how secure it is? It`s comprised of two ciphers: ChaCha20 and Poly1305, designed to be constant time, making it naturally resistant to timing attacks. The AEAD is being used by many notable companies that also trust it for their security, such as Google Chrome and Apple’s HomeKit. ChaCha20-Poly1305 has gone through security analysis and is considered secure.

To view a formal security analysis done on Adam Langley`s IETF protocol using ChaCha20-Poly1305 seehttps://eprint.iacr.org/2014/613.pdf

For added analysis done on Salsa (what ChaCha is based from) see section 5 from http://cr.yp.to/snuffle/salsafamily-20071225.pdf

For any questions about wolfSSL please contact us at facts@wolfssl.com

wolfSSL has a new release out, version 3.7.0. In this release we have added features and bug fixes to the wolfSSL embedded SSL/TLS library and further increased its ease of use on platforms in the realm of IoT, with the addition of a Rowley Crossworks example. Along with additions for Rowley there has been an update to the MDK5-ARM and FreeRTOS project keeping wolfSSL at the cutting edge of embedded TLS/SSL.

Some of the features added to our TLS and wolfCrypt layer are: the IDEA cipher, an example of plugging in user choice of external RSA cryptography, and support for the ALPN, which allows making connections over HTTP2.

For a full list of features, and to try them out, download wolfSSL 3.7.0 from the download page, or follow our development branch on GitHub.

For more information about wolfSSL contact us at facts@wolfssl.com

MQTT (Message Queuing Telemetry Transport) is a light weight open messaging protocol that was developed for constrained environments such as M2M (Machine to Machine) and IoT (Internet of Things), where a small code footprint is required. MQTT is based on the Pub/Sub messaging principle of publishing messages and subscribing to topics. The protocol efficiently packs messages to keep the overhead very low. The MQTT specification recommends TLS as a transport option to secure the protocol using port 8883 (secure-mqtt). Constrained devices can benefit from using TLS session resumption to reduce the reconnection cost.

We have posted an example implementation of MQTT with TLS (MQTTS) on mbed:
https://developer.mbed.org/users/wolfSSL/code/HelloMQTTS/
https://developer.mbed.org/users/wolfSSL/code/MQTTS/

wolfSSL is also working on an open source secure MQTT client for IoT security that will be released soon which will work seamlessly with the wolfSSL embedded SSL/TLS library.

The MQTT Version 3.1.1 Specification can be found here on OASIS:
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html

wolfSSL has become a Champion of National Cyber Security Awareness Month (NCSAM), joining a growing global effort among colleges and universities, businesses, government agencies, associations, nonprofit organizations and individuals to promote online safety awareness.

Celebrated every October, National Cyber Security Awareness Month was created as a collaborative effort between government and industry to ensure everyone has the resources needed to stay safer and more secure online.

Coordinated and led by the National Cyber Security Alliance (NCSA) and the Department of Homeland Security, NCSAM has grown exponentially since its inception, reaching consumers, small and medium-sized businesses, corporations, educational institutions and young people across the nation and internationally. This year marks the 12th year of NCSAM.

The SHA-3 Standard (FIPS PUB 202) is now included in Annex A: Approved Security Functions for FIPS PUB 140-2, Security Requirements for Cryptographic Modules.

SHA-3 Hash Algorithms (SHA3-224, SHA3-256, SHA3-384, SHA3-512) and SHA-3 Extendable-Output Functions (XOF) (SHAKE128, SHAKE256) are FIPS Approved and may be implemented in a FIPS 140-2 cryptographic module. The SHA-3 functions are based on the Keccak algorithm selected by NIST as the winner of the SHA-3 competition.

wolfSSL is performing early testing of SHA-3 through the Cryptographic Algorithm Validation Program (CAVP) at NIST.

Please contact fips@wolfSSL.com if your project plans include SHA-3.

Since version 3.6.6, wolfSSL has had continually improving support for stunnel, a lightweight TLS proxy, designed to add SSL/TLS encryption to unsecured applications without changes to the program`s source code. Licensed under GNU GPLv2 and with an alternative commercial option, stunnel can be utilized to secure a host of different applications, including: mail exchange (SMTP, IMAP, POP3), web hosting (HTTP), remote shell, and virtually any other unprotected protocol desired.

Porting stunnel to use wolfSSL`s embedded SSL/TLS library means taking advantage of wolfSSL`s minimal footprint and high speed crypto implementation to increase performance and decrease required resources when compared to the previous SSL library. Not only that, but using wolfSSL with stunnel combines these benefits with the peace of mind that your application is secured by a progressive, transparent and stable SSL/TLS library, known for its quality, integrity and efficiency.

To build wolfSSL for use with stunnel, simply configure wolfSSL with:

$ ./configure --enable-stunnel

from wolfSSL`s main directory, then make and make install.

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

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