Category: Uncategorized

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.

On Thursday, June 11th, Facebook open-sourced a new software development tool called Infer–a next generation static analyzer. Static analysis is the process of using a tool to scan for bugs in source code without actually running a program. Infer has the ability to detect null pointer access errors, as well as resource and memory leaks. Facebook estimates that Infer can catch up to 80% of these errors.

At wolfSSL we were quick to adopt this new opportunity to validate our code, and we ran Infer against the wolfSSL embedded SSL/TLS library codebase. The results were good:

$ inferTraceBugs
No issues found

As you can see, infer did not find any additional errors in wolfSSL`s codebase, giving us one more reason to be confident in the safety and quality of our code.

Going forward, we will integrate Facebook`s Infer into our arsenal of code analysis and testing tools. We run these tools throughout the development cycle to help ensure that we only release the safest possible product.

To read more about infer, visit fbinfer.com.

As stated in the TLS 1.1 and 1.2 protocol definitions (RFC 4346, RFC 5246), “The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications.” TLS 1.2 is an improvement to the TLS 1.1 standard, but how exactly do they differ? What was changed in TLS 1.2 to warrant a new version of the protocol?

Listed below are the changes made to both version 1.1 and 1.2 of the TLS protocol. TLS 1.2 support is making headway in more and more new projects today. The wolfSSL embedded SSL/TLS library fully supports SSL 3.0 (disabled at runtime by default), TLS 1.0, TLS 1.1, and TLS 1.2.

A. TLS 1.1

This protocol was defined in RFC 4346 in April of 2006, and is an update to TLS 1.0. The major changes are:

– The Implicit Initialization Vector (IV) is replaced with an explicit IV to protect against Cipher block chaining (CBC) attacks.
– Handling of padded errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
– IANA registries are defined for protocol parameters
– Premature closes no longer cause a session to be non-resumable.

RFC 4346: http://tools.ietf.org/html/rfc4346#section-1.1

A. TLS 1.2

This protocol was defined in RFC 5246 in August of 2008. Based on TLS 1.1, TLS 1.2 contains improved flexibility. One of the primary goals of the TLS 1.2 revision was to remove the protocol’s dependency on the MD5 and SHA-1 digest algorithms. The major differences include:

– The MD5/SHA-1 combination in the pseudorandom function (PRF) was replaced with cipher-suite-specified PRFs.
– The MD5/SHA-1 combination in the digitally-signed element was replaced with a single hash. Signed elements include a field explicitly specifying the hash algorithm used.
– There was substantial cleanup to the client`s and server`s ability to specify which hash and signature algorithms they will accept.
– Addition of support for authenticated encryption with additional data modes.
– TLS Extensions definition and AES Cipher Suites were merged in.
– Tighter checking of EncryptedPreMasterSecret version numbers.
– Many of the requirements were tightened
– Verify_data length depends on the cipher suite
– Description of Bleichenbacher/Dlima attack defenses cleaned up.
– Alerts must be sent in many cases
– After a certificate_request, if no certificates are available, clients now MUST send an empty certificate list.
– TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite.
– Added HMAC-SHA256 cipher suites.
– Removed IDEA and DES cipher suites. They are now deprecated.

RFC 5246: http://tools.ietf.org/html/rfc5246

C. Goals of the TLS Protocol

– Cryptographic security: TLS should be used to establish a secure connection between two parties.
– Interoperability: Independent programmers should be able to develop applications utilizing TLS that can successfully exchange cryptographic parameters without knowledge of one another`s code.
– Extensibility: TLS seeks to provide a framework into which new public key and bulk encryption methods can be incorporated as necessary. This will also accomplish two sub-goals: preventing the need to create a new protocol (and risking the introduction of possible new weaknesses) and avoiding the need to implement an entire new security library.
– Relative efficiency: Cryptographic operations tend to be highly CPU intensive, particularly public key operations. For this reason, the TLS protocol has incorporated an optional session caching scheme to reduce the number of connections that need to be established from scratch. Additionally, care has been taken to reduce network activity.

Resources:
If you would like to read more about SSL or TLS, here are several resources that might be helpful:
wolfSSL Manual (https://www.wolfssl.com/wolfSSL/Docs-wolfssl-manual-toc.html)
TLS – Wikipedia (http://en.wikipedia.org/wiki/Transport_Layer_Security)
SSL vs TLS – What`s the Difference? (http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html)
Cisco – SSL: Foundation for Web Security (http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html)

If you have any questions or would like to talk to the wolfSSL team about more information, please contact facts@wolfssl.com.

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.

The super-fast NTRU algorithm, featuring efficient key generation, encryption, and decryption, is a quantum computer resistant algorithm currently being used with the quantum-safe ciphersuite. By using a one-time NTRU key to encrypt extra secret material, the handshake allows users to continue using their existing ciphersuites (which may be necessary for certificate support or because they have regulations that require it) while at the same time benefiting from the true long-term security that NTRU gives. Because NTRU is fast, the additional processing load from the use of this ciphersuite is low. The ciphersuite is provably as secure as classical ciphersuites. Users can use it without concern that it is reducing their security, making this genuinely a zero-risk, near-zero-cost approach to obtaining protection against government or other actors, now and in the future.

“We`re excited to continue our partnership with wolfSSL and applaud wolfSSL`s vision in being first to market with this innovative, future-proof approach,” said William Whyte, Chief Scientist at Security Innovation. “wolfSSL has a name for being best in the field for embedded devices; with this approach, WolfSSL is enabling their customers to protect data on any device, not just now but for years to come.”

To view and use the quantum safe handshake extensions first download and install NTRU (which an Open Source version can be found at https://github.com/NTRUOpenSourceProject/ntru-crypto) then download the most recent wolfSSL from GitHub ( https://github.com/wolfSSL/wolfssl ) and compile using ./configure –with-ntru. The QSH ciphersuite specification will be available from the IETF website the week of July 19th. A security proof for the approach is provided in https://eprint.iacr.org/2015/287.

For more information about the implementation or use contact wolfSSL at facts@wolfssl.com

wolfSSL (formerly CyaSSL) recently added a build option called “Max Strength”. This build option forces most cipher suites to be disabled at compile time to prevent their accidental use during run time. Options such as MD5, 3DES, and ARC4 are left out of the build completely.

The cipher suites that are enabled by default have Perfect Forward Security (PFS) and Authenticated ciphers (AEAD). The remaining suites have the AEAD ciphers including at least one of AES-GCM, AES-CCM, or CHACHA-POLY1305; ECDHE or DHE; ECDSA or RSA; SHA-256 and SHA-384. The minimum allowed DHE key bit-size is set to 2048 bits.

To enable the maximum strength build with wolfSSL, on the configure command line add the option “–enable-maxstrength”, or add “#define WOLFSSL_MAX_STRENGTH” to your settings.h file.

OpenSSL released a security advisory on July 9th 2015: https://www.openssl.org/news/secadv_20150709.txt .  Some wolfSSL embedded TLS users are probably wondering if similar security fixes are required in wolfSSL.  The answer to that is no.  Specifically, Alternative chains certificate forgery (CVE-2015-1793) is an OpenSSL implementation bug.  Faulty logic allowed untrusted certificates to appear as trusted.  Since wolfSSL, CyaSSL, and yaSSL embedded SSL libraries have a completely different code base from OpenSSL we do not share this defect.

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