RECENT BLOG NEWS

So, what’s new at wolfSSL? Take a look below to check out the most recent news.
Or sign up to receive weekly email notifications containing the latest news from wolfSSL.

wolfSSL 3.15.3 Now Available

wolfSSL is proud to announce release version 3.15.3 of the wolfSSL embedded TLS library.  This release contains bug fixes and new features, which include:

  • ECDSA blinding added for hardening against side channel attacks
  • Fix for OpenSSL compatibility layer build with no server (NO_WOLFSSL_SERVER) and no client (NO_WOLFSSL_CLIENT) defined
  • Intel assembly instructions support for compatible AMD processors
  • wolfCrypt port for Mentor Graphics Nucleus RTOS
  • Fix added for MatchDomainName() with additional tests added
  • Fixes for building with ‘WOLFSSL_ATECC508A’ defined
  • Fix for verifying a PKCS7 files in BER format with indefinite size

This release of wolfSSL fixes 2 security vulnerability fixes:

Medium level fix for PRIME + PROBE attack combined with a variant of Lucky 13.  Constant time hardening was done to avoid potential cache-based side channel
attacks when verifying the MAC on a TLS packet. CBC cipher suites are susceptible on systems where an attacker could gain access and run a parallel program for inspecting caching. Only wolfSSL users that are using TLS/DTLS CBC cipher suites need to update. Users that have only AEAD and stream cipher suites set, or have built with WOLFSSL_MAX_STRENGTH (–enable-maxstrength), are not vulnerable. Thanks to Eyal Ronen, Kenny Paterson, and Adi Shamir for the report.

Medium level fix for a ECDSA side channel attack. wolfSSL is one of over a dozen vendors mentioned in the recent Technical Advisory “ROHNP” by author Ryan
Keegan. Only wolfSSL users with long term ECDSA private keys using our fastmath or normal math libraries on systems where attackers can get access to the machine using the ECDSA key need to update. An attacker gaining access to the system could mount a memory cache side channel attack that could recover the key within a few thousand signatures. wolfSSL users that are not using ECDSA private keys, that are using the single precision math library, or that are using ECDSA offloading do not need to update. (blog with more information: https://www.wolfssl.com/wolfssl-and-rohnp/)

For more information, please contact info@wolfssl.com. You can see the full change log in the source archive from our website at www.wolfssl.com or at our GitHub repository.

wolfSSL in stunnel TLS Proxy

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 info@wolfssl.com.

wolfMQTT connects with IBM’s Watson IoT Platform

With the latest wolfMQTT v1.1 release you can easily connect your devices running wolfMQTT to IBM’s Watson IoT Platform. Trying out wolfMQTT is simple using the provided MQTT client example and your IBM Cloud account. The default example provides a link to the IBM Quickstart broker where you can view a graph generated by the data without an account.

As a side note, wolfMQTT uses the wolfSSL embedded SSL/TLS library for SSL/TLS support.  Since wolfSSL supports TLS 1.3, your wolfMQTT-based projects can now use MQTT with TLS 1.3 with a supported broker!

You can download the latest release from our website or clone on GitHub. For more information please email us at info@wolfssl.com.

wolfSSL now has lwIP support

The wolfSSL (formerly CyaSSL) embedded SSL library supports lwIP, the light weight internet protocol implementation, out of the box.  The user merely needs to define WOLFSSL_LWIP or uncomment the line /* #define WOLFSSL_LWIP */ in os_settings.h to use wolfSSL with lwIP.  

The focus of lwIP is to reduce RAM usage while still providing a full TCP stack.  That focus makes lwIP great for use in embedded systems, the same area where wolfSSL is an ideal match for SSL/TLS needs.  An active community exists with contributor ports for many systems.  Give it a try and let us know if you have any suggestions or questions.

For the latest news and releases of lwIP, you can visit the project homepage, here: http://savannah.nongnu.org/projects/lwip/

Intro to PKCS #5: Password-Based Cryptography Specification

Our third post in our PKCS series, we will be looking at PKCS  #5. PKCS #5 is the Password-Based Cryptography Specification and is currently defined by version 2.0 of the specification. It is defined in RFC 2898 http://tools.ietf.org/html/rfc2898. It applies a pseudorandom function, such as a cryptographic hash, cipher, or HMAC to the input password or passphrase along with a salt value and repeats the process many times to produce a derived key, which can then be used as a cryptographic key in subsequent operations. The added computational work makes password cracking much more difficult, and is known as key stretching.

A. Key Derivation Functions

A key derivation function produces a derived key from a based key and other parameters. In a password-based key derivation function, the base key is a password and the other parameters are a salt value and an iteration count.

Two functions are specified below: PBKDF1 and PBKDF2. PBKDF2 is recommended for new applications; PBKDF1 is included only for compatibility with existing applications, and is not recommended for new applications.

B. PBKDF1

PBKDF1 applies a hash function, which shall be MD2, MD5 or SHA-1, to derive keys. The lengths of the derived keying bounded by the length of the hash function output, which is 16 octets from MD2 and MD5 and 20 octets from SHA-1.

Steps:

1. If dkLen > 16 for MD2 and MD5, or dkLen > 20 for SHA-1, output “derived key too long” and stop.

2. Apply the underlying hash function Hash for c iterations to the concatenation of the password P and

    the salt S, then extract the first dkLen octets to produce a derived key DK:

T_1 = Hash (P || S) ,

T_2 = Hash (T_1) ,

T_c = Hash (T_{c-1}) ,

DK = Tc<0..dkLen-1>

3. Output the derived key DK.

C. PBKDF2

PBKDF2 applies a pseudorandom function to derive keys. The length of the derived key is essentially unbounded. However, the maximum effective search space for the derived key may be limited by the structure of the underlying pseudorandom function.

Steps:

1. If dkLen > (2^32 – 1) * hLen, output “derived key too long” and stop.

2. Let l be the number of hLen-octet blocks in the derived key, rounding up, and let r be the number of octets

    in the last block:

l = CEIL (dkLen / hLen) ,

r = dkLen – (l – 1) * hLen .

Here, CEIL (x) is the “ceiling” function, i.e. the smallest integer greater than, or equal to, x.

3. For each block of the derived key apply the function F defined below to the password P, the salt S, the

    iteration count c, and the block index to compute the block:

T_1 = F (P, S, c, 1) ,

T_2 = F (P, S, c, 2) ,

T_l = F (P, S, c, l) ,

where the function F is defined as the exclusive-or sum of the first c iterates of the underlying pseudorandom  function PRF applied to the password P and the concatenation of the salt S and the block index i:

F (P, S, c, i) = U_1 \xor U_2 \xor … \xor U_c

where

U_1 = PRF (P, S || INT (i)) ,

U_2 = PRF (P, U_1) ,

U_c = PRF (P, U_{c-1}) .

Here, INT (i) is a four-octet encoding of the integer i, most significant octet first.

4. Concatenate the blocks and extract the first dkLen octets to produce a derived key DK:

DK = T_1 || T_2 ||  …  || T_l<0..r-1>

5. Output the derived key DK.

To learn more about PKCS #5, you can look through the specification, here:

http://tools.ietf.org/html/rfc2898

D. CyaSSL Support

CyaSSL supports both PBKDF1 and PBKDF2. The header file can be found in <cyassl_root>/cyassl/ctaocrypt/pwdbased.h and the source file can be found in <cyassl_root>/ctaocrypt/src/pwdbased.c of the CyaSSL library. When using these functions, they must be enabled when CyaSSL is configured. This is done by:

./configure –enable-pwdbased

The functions:

int PBKDF1(byte* output, const byte* passwd, int pLen,
           const byte* salt, int sLen, int iterations, int kLen,
           int hashType);
int PBKDF2(byte* output, const byte* passwd, int pLen,
           const byte* salt, int sLen, int iterations, int kLen,
           int hashType);

CyaSSL also supports PKCS12

int PKCS12_PBKDF(byte* output, const byte* passwd, int pLen,
                 const byte* salt, int sLen, int iterations,
                 int kLen, int hashType, int purpose);

To learn more about the CyaSSL embedded SSL library, you can download a free GPLv2-licensed copy from the wolfSSL download page, http://wolfssl.com/yaSSL/download/downloadForm.php, or look through the CyaSSL Manual, https://www.wolfssl.com/docs/wolfssl-manual/.  If you have any additional questions, please contact us at info@wolfssl.com.

What is a Stream Cipher?

A stream cipher encrypts plaintext messages by applying an encryption algorithm with a pseudorandom cipher digit stream (keystream). Each bit of the message is encrypted one by one with the corresponding keystream digit. Stream ciphers are typically used in cases where speed and simplicity are both requirements. If a 128 bit block cipher such as AES were to be used in place of a stream cipher where it was encrypting messages of 32 bit blocks, 96 bits of padding would remain. This is an inefficient approach and one reason why a stream cipher would be preferred, since they operate on the smallest possible unit.

Some common stream ciphers include RC4 (which has been shown to be vulnerable to attacks), Salsa20, ChaCha (a seemingly better variant of Salsa20), Rabbit, and HC-256, among others. Block ciphers can be used in stream mode to act as a stream cipher. If a block cipher is run in CFB, OFB, or CTR mode, it does not require additional measures to handle messages that aren’t equivalent to the length of multiples of the block size and eliminates the padding effect.

For information on the stream ciphers that can be implemented with CyaSSL or to learn more about the wolfSSL lightweight, embedded SSL library, go to wolfssl.com or contact us at info@wolfssl.com.

References

[1] Stream cipher. (2014, November 19). In Wikipedia, The Free Encyclopedia. Retrieved 16:19,
December
19, 2014, from http://en.wikipedia.org/w/index.php?title=Stream_cipher&oldid=634494612.
Most recent version:
https://en.wikipedia.org/wiki/Stream_cipher

[2] Margaret Rouse. Stream Cipher. (2005). Available URL:
http://searchsecurity.techtarget.com/definition/stream-cipher.

[3] Block cipher mode of operation. (2014, December 12). In Wikipedia, The Free
Encyclopedia. Retrieved 17:13, December 19, 2014, from
http://en.wikipedia.org/w/index.php?title=Block_cipher_mode_of_operation&oldid=637837298.
Most recent version:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

When to use Pre Shared Key (PSK) Cipher Suites

PSK cipher suites are a superb choice in low resource environments where both ends of the connection can be controlled. With PSK, each side of the connection has an already agreed upon key to use rather than agreeing on one during the TLS handshake. This reduces resource consumption for each session using PSK.

For example, on one of wolfSSL’s test machines the cipher suite DHE-PSK-AES128-CBC-SHA256 has an average connection time of 3.498 milliseconds with a peak byte usage of 6,335. On the same machine a similar cipher suite DHE-RSA-AES128-SHA256, not using PSK, has an average connection time of 7.146 milliseconds and peak byte usage of 19,431. wolfSSL always recommends using ephemeral keys (DHE or ECDHE) to maintain forward secrecy but in an ultra limited resource environment, memory and speed can be further improved by using a static PSK cipher suite such as PSK-AES128-CBC-SHA.

In addition to RAM reduction, using PSK can reduce the library footprint size as well. One of the smallest wolfSSL builds to date has been the LeanPSK build, which comes in at around 21kB.  For comparison, a typical build on an embedded, optimized compiler will be 60-100kB.

For information regarding the use of PSK cipher suites or general inquiries about wolfSSL’s embedded SSL/TLS library contact us!

Wikipedia: https://en.wikipedia.org/wiki/TLS-PSK

Differences between TLS 1.2 and TLS 1.3 (#TLS13)

With the release of TLS 1.3, there are promises of enhanced security and speed. But how exactly do the changes from TLS 1.2 to TLS 1.3 cause these improvements? The following is a list of differences between TLS 1.2 and 1.3 that shows how the improvements are achieved.
 
wolfSSL is among one of the first libraries to support TLS 1.3. Below are the major differences between TLS 1.2 and TLS 1.3

TLS 1.3

This protocol was defined in an Internet Draft in April of 2017. TLS 1.3 contains improved security and speed. The major differences include:

• The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.

• A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.

• Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.

• All handshake messages after the ServerHello are now encrypted.

• Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.

• The handshake state machine has been restructured to be more consistent and remove superfluous messages.

• ECC is now in the base spec  and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.

• Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.

• TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.

• Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.
 
Internet Draft: https://tools.ietf.org/html/draft-ietf-tls-tls13-28
 
Resources:

If you would like to read more about SSL or TLS, here are several resources that might be helpful:

TLS – Wikipedia (http://en.wikipedia.org/wiki/Transport_Layer_Security)
SSL versus TLS – What`s the Difference? (http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html)
Differences Between SSL and TLS Protocol Versions (http://www.wolfssl.com/differences-between-ssl-and-tls-protocol-versions/)
Cisco – SSL: Foundation for Web Security (http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html)

What is a Block Cipher?

A block cipher is an encryption method that applies a deterministic algorithm along with a symmetric key to encrypt a block of text, rather than encrypting one bit at a time as in stream ciphers. For example, a common block cipher, AES, encrypts 128 bit blocks with a key of predetermined length: 128, 192, or 256 bits. Block ciphers are pseudorandom permutation (PRP) families that operate on the fixed size block of bits. PRPs are functions that cannot be differentiated from completely random permutations and thus, are considered reliable, until proven unreliable.

Block cipher modes of operation have been developed to eliminate the chance of encrypting identical blocks of text the same way, the ciphertext formed from the previous encrypted block is applied to the next block. A block of bits called an initialization vector (IV) is also used by modes of operation to ensure ciphertexts remain distinct even when the same plaintext message is encrypted a number of times.

Some of the various modes of operation for block ciphers include CBC (cipher block chaining), CFB (cipher feedback), CTR (counter), and GCM (Galois/Counter Mode), among others. Above is an example of CBC mode.

Where an IV is crossed with the initial plaintext block and the encryption algorithm is completed with a given key and the ciphertext is then outputted. This resultant cipher text is then used in place of the IV in subsequent plaintext blocks.

For information on the block ciphers that are implemented in wolfSSL or to learn more about the wolfSSL lightweight, embedded SSL library, go to wolfssl.com or contact us at info@wolfssl.com.

References

[1] Pseudorandom permutation. (2014, November 23). In Wikipedia, The Free Encyclopedia.
Retrieved 22:06, December 18, 2014, from 
http://en.wikipedia.org/w/index.php?title=Pseudorandom_permutation&oldid=635108728.
Most recent version:
https://en.wikipedia.org/wiki/Pseudorandom_permutation

[2] Margaret Rouse. (2014). Block Cipher [Online]. Available URL:
http://searchsecurity.techtarget.com/definition/block-cipher.

[3] Block cipher mode of operation. (2014, December 12). In Wikipedia, The Free
Encyclopedia. Retrieved 22:17, December 18, 2014, from
http://en.wikipedia.org/w/index.php?title=Block_cipher_mode_of_operation&oldid=637837298
Most recent version:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

[4] Wikimedia. (2014). Available URL:
http://upload.wikimedia.org/wikipedia/commons/d/d3/Cbc_encryption.png.

A Comparison of Differences in TLS 1.1 and TLS 1.2

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.2 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, TLS 1.2, and TLS 1.3.

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)
Differences between SSL and TLS versions: (https://www.wolfssl.com/differences-between-ssl-and-tls-protocol-versions/)
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 info@wolfssl.com.

Posts navigation

1 2 3 4 72 73 74

Weekly updates

Archives

Latest Tweets