RECENT BLOG NEWS
wolfSSL, provider of CyaSSL Embedded SSL, releases first embedded TLS and DTLS protocol fix for Lucky Thirteen Attack
Researchers have found a new a new attack vector for TLS 1.1 and 1.2 protocol implementations, which wolfSSL has promptly fixed in its leading embedded TLS product.
In the paper “Lucky Thirteen: Breaking the TLS and DTLS Record Protocols” authors Nadhem AlFardan and Kenneth Paterson present a family of attacks that apply to CBC-mode for TLS (1.1 and 1.2) and DTLS (1.0 and 1.2). All of the attacks are based on a delicate timing analysis of the decryption processing needed in block mode. The various attacks are distinguishing, partial plaintext recovery, and full plaintext recovery in nature. All the attacks exploit the protocol when badly formatted padding is handled during processing. A MAC verification must still be performed on something to prevent existing timing attacks. The RFCs suggest using a zero-length pad which was thought to be safe, but these attacks show that it can be exploited.
There are a few ways to avoid the attack. Using stream ciphers is the simplest. Stream ciphers like ARC4, HC- 128, and RABBIT are not vulnerable because they don`t use block mode and padding. HC-128 and RABBIT are unique to wolfSSL and also have the benefit of being extremely fast. Another way is to use Authenticated Encryption like AES-GCM and AES-CCM instead of block mode with CBC. wolfSSL includes several cipher suites utilizing Authenticated Encryption algorithms. Lastly, wolfSSL implemented the countermeasures suggested in the paper in version 2.5.0 to avoid timing attacks.
Founded in 2004, wolfSSL offers open-source, embedded security solutions that are fast, small, portable and standard compliant including CyaSSL, the C-language SSL library for embedded and RTOS environments; yaSSL, the embedded C++ SSL library; and yaSSL Embedded Web Server, a fast, embeddable, secure web server. Dual licensed, wolfSSL caters to the security applications in industrial automation, smart energy, surveillance, medical, military, telecommunications markets and the open-source community. Distributed worldwide, wolfSSL is headquartered in Bozeman, Montana.
wolfSSL 2.5.0 is Now Available
Release 2.5.0 of the wolfSSL lightweight SSL/TLS library has been released and is now available for download. This release has bug fixes and new features including:
– Fix for TLS CBC padding timing attack identified by Nadhem Alfardan and Kenny Paterson: http://www.isg.rhul.ac.uk/tls/
– Microchip PIC32 (MIPS16, MIPS32) support
– Microchip MPLAB X example projects for PIC32 Ethernet Starter Kit
– Updated CTaoCrypt benchmark app for embedded systems
– 1024-bit test certs/keys and cert/key buffers
– AES-CCM-8 crypto and cipher suites
– Camellia crypto and cipher suites
– Bumped minimum autoconf version to 2.65, automake version to 1.12
– Addition of OCSP callbacks
– STM32F2 support with hardware crypto and RNG
– Cavium NITROX support
CTaoCrypt now has support for the Microchip PIC32 and has been tested with the Microchip PIC32 Ethernet Starter Kit, the XC32 compiler and MPLAB X IDE in both MIPS16 and MIPS32 instruction set modes. See the README located under the
To add Cavium NITROX support do:
./configure –with-cavium=/home/user/cavium/software
pointing to your licensed cavium/software directory. Since Cavium doesn`t build a library we pull in the cavium_common.o file which gives a libtool warning about the portability of this. Also, if you`re using the github source tree you`ll need to remove the -Wredundant-decls warning from the generated Makefile because the cavium headers don`t conform to this warning. Currently wolfSSL supports Cavium RNG, AES, 3DES, RC4, HMAC, and RSA directly at the crypto layer. Support at the SSL level is parital and currently just does AES, 3DES, and RC4. RSA and HMAC are slower until the Cavium calls can be utilized in non blocking mode. The example client turns on cavium support as does the crypto test and benchmark. Please see the HAVE_CAVIUM define.
wolfSSL is able to use the STM32F2 or STM32F4 hardware-based cryptography and random number generator through the STM32F2 Standard Peripheral Library. For necessary defines, see the CYASSL_STM32F2 define in settings.h. Documentation for the STM32F2 Standard Peripheral Library can be found in the following document:
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/DM00023896.pdf
The wolfSSL manual is available online or in PDF format. For build instructions and comments about the new features please check the manual. If you have any question, please contact us at info@yassl.com.
Using wolfSSL in other Open Source Projects
Hi! If you are a long time user of wolfSSL, then you probably know that we actively engage the open source community. Our intention is to create more and better open source software for all to use and enjoy.
What you may not know about is one of our key business policies, which is to provide free support to open source projects that consume our products. So if you are building open source stuff, you are more than welcome to engage our support team for help. The best way to do that is through our support forums. However, if you have an issue that is sensitive, then you are welcome to email us at support@yassl.com.
Camellia Cipher Now Available in wolfSSL
We have added the Camellia-CBC cipher to CTaoCrypt and wolfSSL. The following cipher suites are available for TLS:
• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
Camllia-CBC will be available in our next release. The latest sources are available in our GitHub repository. To enable Camellia-CBC in wolfSSL, configure the build with the option “–enable-camellia”. We are very excited to offer this new cipher. If you are interested in other Camellia cipher suites, including any ECC cipher suites, please contact us at info@yassl.com.
Using Pre-Shared Keys (PSK) with wolfSSL
Ever wondered how to use PSK with the embedded wolfSSL library? PSK is useful in resource constrained devices where public key operations may not be viable. It`s also helpful in closed networks where a Certificate Authority structure isn`t in place. To enable PSK with wolfSSL you can simply do:
$ ./configure --enable-psk
Using PSK on the client side requires one additional function call:
wolfSSL_CTX_set_psk_client_callback()
There`s an example client callback in cyassl/test.h called my_psk_client_cb()
. The example sets the client identity which is helpful for the server if there are multiple clients with unique keys and is limited to 128 bytes. It could also examine the server identity hint in case the client is talking to multiple servers with unique keys. Then the pre-shared key is returned to the caller, here that is simply 0x1a2b3c4d, but it could be any key up to 64 bytes in length (512 bits).
On the server side two additional calls are required:
wolfSSL_CTX_set_psk_server_callback()
wolfSSL_CTX_use_psk_identity_hint()
The server stores it`s identity hint to help the client with the 2nd call, in our server example that`s “cyassl server”. An example server psk callback can also be found in my_psk_server_cb()
in cyassl/test.h. It verifies the client identity and then returns the key to the caller, which is again 0x1a2b3c4d, but could be any key up to 64 bytes in length. If you have any questions about using PSK with TLS please let us know.
Updated API Documentation
We want to let our users and followers know that we recently updated the API documentation for the wolfSSL embedded SSL library. With this update, all functions in the standard wolfSSL build (98) are now documented plus an additional 19 related to various defines related to DTLS, Callbacks, DER-specific, NTRU or OpenSSL extra functions.
You can find the updated API documentation online in Chapter 17 of the wolfSSL Manual, here:
http://yassl.com/yaSSL/Docs-cyassl-manual-17-cyassl-api-reference.html
If you have any questions, please let us know at info@yassl.com.
wolfSSL Now Supports AES with CCM-8
We have added the Counter with CBC-MAC Mode with 8?byte authentication (CCM-8) for AES to wolfSSL. The following cipher suites are available for TLS v1.2:
• TLS_RSA_WITH_AES_256_CCM_8_SHA384
• TLS_RSA_WITH_AES_128_CCM_8_SHA256
AES with CCM-8 will be available in our next release. The latest sources are available in our GitHub repository. To enable AES with CCM-8 in wolfSSL, configure the build with the option “??enable?aesccm”. We are very excited to offer this new cipher. If you are interested in other AES-CCM-8 cipher suites, including any ECC cipher suites, please contact us at info@yassl.com.
Getting started with wolfSSL`s ECC
Release 2.4.6 of wolfSSL is the first to include our ECC implementation publicly. Let`s look at how to get started using the ECC features. First, you`ll need to turn on ECC. With the autoconf system this is simply a configure flag:
./configure –enable-ecc
make
make check
Note the 96 different TLS cipher suites that make check verifies. You can easily use any of these tests individually, e.g., to try ECDH-ECDSA with AES256-SHA you can start our example server like this:
./examples/server/server -d -l ECDH-ECDSA-AES256-SHA -c ./certs/server-ecc.pem -k ./certs/ecc-key.pem
-d disables client cert check while -l specifies the cipher suite list. -c is the certificate to use and -k is the corresponding private key to use. To have the client connect try:
./examples/client/client -A ./certs/server-ecc.pem
where -A is the CA certificate to use to verify the server. To have an OpenSSL client connect the wolfSSL server you could do:
openssl s_client -connect localhost:11111
since wolfSSL uses the port 11111 by default, though this can be changed with the port option -p. To allow the server to bind to any interface instead of the default localhost use the -b option. A full list of options can be seen with -?.
Intro to PKCS #3: Diffie-Hellman Key Agreement Standard
A while back, we started a series on the PKCS standards. Our first post was about PKCS #1, the RSA Cryptography Standard. This is the second post in the PKCS standards series, introducing PKCS #3 – the Diffie-Hellman Key Agreement Standard.
PKCS #3 is the Diffie-Hellman Key Agreement Standard and is currently defined by version 1.4 of the specification, located here: http://www.rsa.com/rsalabs/node.asp?id=2126. It defines a standard enabling two parties to agree on a secret key known only to them (without having prior arrangements). This is done in such a way that even if an eavesdropper is listening to the communication channel on which the key agreement took place, the eavesdropper will not be able to obtain the secret key. After the secret key has been agreed upon by the two involved parties, it may be used in a subsequent operation – such as encrypting further communications between the two parties.
The specification itself defines standards for parameter generation, Phase 1 and 2 of the key agreement, and the object identifier to be used.
A. Parameter Generation
As stated in the specification, “a central authority shall generate Diffie-Hellman parameters, and the two phases of key agreement shall be performed with these parameters.” This central authority will generate several parameters including an odd prime (p) and an integer (g), where the base satisfies 0 < g < p. It may also optionally select an integer (l) which is the private-value length in bits and which satisfies 2^(l-1) <= p.
A. Phase 1
This section of the specification describes the first (of two) phases of the Diffie-Hellman key agreement and contains three steps, namely:
– private-value generation
– exponentiation
– integer-to-octet-string conversion
As stated by the specification, “the input to the first phase shall be the Diffie-Hellman parameters. The output from the first phase shall be an octet string PV, the public value; and an integer x, the private value.” Each party of the key agreement will perform Phase 1 independently of the other party.
I. Phase 2
This section of the specification describes the second phase of the Diffie-Hellman key agreement and contains three steps as well, namely:
– octet-string-to-integer conversion
– exponentiation
– integer-to-octet-string conversion
As stated by the specification, “the input to the second phase shall be the Diffie-Hellman parameters; an octet string PV’, the other entity’s public value; and the private value x. The output from the second phase shall be an octet string SK, the agreed-upon secret key.” As the first step, this step is performed by each party independently as well (but after they have exchanged public values from the Phase 1).
I. Object Identifier
The last item defined in PKCS #3 are two object identifiers to be used with Diffie-Hellman key agreement, pkcs-3 and dhKeyAgreement. The pkcs-3 OID identifies Diffie-Hellman key agreement and is specified as:
pkcs-3 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 3 }
The second OID, dhKeyAgreement, identifies the PKCS #3 key agreement method.
To learn more about PKCS #3, you can look through the specification, here:
http://www.rsa.com/rsalabs/node.asp?id=2126
To learn more about the wolfSSL embedded SSL library, you can download a free GPLv2-licensed copy from the yaSSL download page, https://www.wolfssl.com/download/, or look through the wolfSSL Manual, http://www.yassl.com/yaSSL/Docs-cyassl-manual-toc.html. If you have any additional questions, please contact us at info@yassl.com.
Linux Journal – Elliptic Curve Cryptography
If you are a reader of Linux Journal (http://www.linuxjournal.com/), you may have seen the interesting article in this month’s issue about Elliptic Curve Cryptography written by Joe Hendrix:
http://www.linuxjournal.com/content/january-2013-issue-linux-journal-security
In the article, Joe explains how ECC works (with several descriptive charts), talks about how NIST makes recommendations on the actual security provided by different algorithms with varying bit strengths, and shows readers how to use ECC in the popular OpenSSH application. We enjoyed reading through it.
Beginning with the 2.4.6 release of the wolfSSL embedded SSL library, wolfSSL now has support for ECC cipher suites as well. We have had ECC support internally for quite some time, but have now made it available to our open source user base.
wolfSSL’s open source ECC implementation can be found in the
/* ECDHE suites */
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
/* ECDH suites */
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
/* AES-GCM suites */
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
You can download a GPLv2-licensed copy of wolfSSL from our download page (https://www.wolfssl.com/download/). If you have any questions or would like more information about our ECC implementation or the wolfSSL lightweight SSL library, feel free to let us know at info@yassl.com. We always enjoy hearing from our users!
Weekly updates
Archives
- September 2024 (5)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)