We will be exhibiting at RSA again this year. Please visit us at booth 755. We will be talking about our latest releases of wolfSSL embedded SSL, Suite B, Fips 140-2, and answering specific questions for our users. We will be fully staffed with engineering resources at the show, so bring us your most challenging questions!
If you would like to set aside a specific time to chat, then please email us at info@yassl.com.
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.
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 -?.
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.
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!
We would like to announce that the wolfSSL embedded SSL library now has support for hardware-based cryptography and random number generation offered by the STM32F2. Supported cryptographic algorithms include AES (CBC, CTR), DES (ECB, CBC), 3DES, MD5, and SHA1. For details regarding the STM32F2 crypto and hash processors, please see the STM32F2xx Standard Peripheral Library document (linked below).
If you are using the STM32F2 with wolfSSL, you can see substantial speed improvements when using the hardware crypto versus using wolfSSL’s software crypto implementation. The following benchmarks were gathered from the CTaoCrypt benchmark application (ctaocrypt/benchmark/benchmark.c) running on the STM3221G-EVAL board (STM32F2) using the STM32F2 Standard Peripheral Library and FreeRTOS.
wolfSSL Software Crypto, Normal Big Integer Math Library
AES 1024 kB took 0.822 seconds, 1.22 MB/s
ARC4 1024 KB took 0.219 seconds, 4.57 MB/s
DES 1024 KB took 1.513 seconds, 0.66 MB/s
3DES 1024 KB took 3.986 seconds, 0.25 MB/s
MD5 1024 KB took 0.119 seconds, 8.40 MB/s
SHA 1024 KB took 0.279 seconds, 3.58 MB/s
SHA-256 1024 KB took 0.690 seconds, 1.45 MB/s
RSA 2048 encryption took 111.17 milliseconds, avg over 100 iterations
RSA 2048 decryption took 1204.77 milliseconds, avg over 100 iterations
DH 2048 key generation 467.90 milliseconds, avg over 100 iterations
DH 2048 key agreement 538.94 milliseconds, avg over 100 iterations
STM32F2 Hardware Crypto, Normal Big Integer Math Library
AES 1024 kB took 0.105 seconds, 9.52 MB/s
ARC4 1024 KB took 0.219 seconds, 4.57 MB/s
DES 1024 KB took 0.125 seconds, 8.00 MB/s
3DES 1024 KB took 0.141 seconds, 7.09 MB/s
MD5 1024 KB took 0.045 seconds, 22.22 MB/s
SHA 1024 KB took 0.047 seconds, 21.28 MB/s
SHA-256 1024 KB took 0.690 seconds, 1.45 MB/s
RSA 2048 encryption took 111.09 milliseconds, avg over 100 iterations
RSA 2048 decryption took 1204.88 milliseconds, avg over 100 iterations
DH 2048 key generation 467.56 milliseconds, avg over 100 iterations
DH 2048 key agreement 542.11 milliseconds, avg over 100 iterations
As the above benchmarks (and chart) show, the hardware-based algorithms on the STM32 demonstrate significantly faster speeds than that of their software counterparts.
To enable STM32 hardware crypto and RNG support, define STM32F2_CRYPTO and STM32F2_RNG when building wolfSSL. For a more complete list of defines which may be required, please see the WOLFSSL_STM32F2 define in
If you would like to use wolfSSL with STM32 hardware-based cryptography or RNG, or have any questions, please contact us at facts@wolfssl.com for more information.
wolfSSL embedded SSL library
STM32: http://www.st.com/internet/mcu/class/1734.jsp
STM32F2 Standard Peripheral Library documentation: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/DM00023896.pdf
In case you didn`t notice, open source is growing rapidly in government usage. OpensourceforAmerica.org is keeping a helpful list of resources and examples of how open source is both helping government and expanding in usage. See: http://opensourceforamerica.org/projects/mentors/resources/. Our team is proud to participate in and support the growth of open source use in government and military projects! If you`re wondering how the wolfSSL lightweight SSL implementation is used in government and defense projects, just contact us at info@yassl.com.
Version 2.4.6 of the wolfSSL embedded SSL/TLS library has been released and is now available for download. This release contains bug fixes and has a few new features including:
– ECC into main (GPLv2) version
– Lean PSK build (reduced code size, RAM usage, and stack usage)
– FreeBSD CRL monitor support
– wolfSSL_peek()
– wolfSSL_send() and wolfSSL_recv() for I/O flag setting
– CodeWarrior Support
– MQX / MFS / RTCS Support
– Freescale Kinetis support including Hardware RNG
– autoconf builds use jobserver
– cyassl-config
– Sniffer memory reductions
Thanks to Brian Aker for the improved autoconf system, make rpm, cyassl-config, warning system, and general good ideas for improving wolfSSL!
The Freescale Kinetis K70 RNGA documentation can be found in Chapter 37 of the K70 Sub-Family Reference Manual:
http://cache.freescale.com/files/microcontrollers/doc/ref_manual/K70P256M150SF3RM.pdf
To download the open source, GPLv2-licensed version of wolfSSL 2.4.6, please visit our Download Page. If you have any questions or comments or would like more information on commercial versions of wolfSSL, please contact us at info@yassl.com.
For build instructions, a full feature list, API reference, and more, please see the wolfSSL Manual.
Last week we talked about wolfSSL’s custom I/O handling and how to set it up. The following discussion assumes the I/O callbacks are reading and writing into buffers rather calling send() or recv().
A tricky situation is during the handshake. When calling wolfSSL_connect(), the client will send cipher text first and try to receive a response from the server. The send callback will be called and then the receive callback, which will WANT_READ. Application code will have to actually send the first handshake message and wait for the response.
The server receives and sends in reaction. Its receive callback is called, then its send callback, then the receive which will WANT_READ. The application has to send the handshake message.
Both sides receive and send in reaction to each other. When the handshake hasn’t completed, calls to wolfSSL_read() and wolfSSL_send() call wolfSSL_negotiate() which will drive the handshaking. If things are set up right, a call to wolfSSL_read() may return WANT_READ and the cipher-send buffer will have data to be sent to the peer.
One of our favorite tools at yaSSL is valgrind: http://valgrind.org . Originally a memory error detector, it`s now an instrumentation framework for dynamic analysis that also does thread error detection, cache and branch-prediction profiling, and heap profiling. If you`ve never used it, you should. If you are using it, you should probably be using it more.
We recently added an –enable-valgrind option to the wolfSSL lightweight SSL library to encourage us to use it more ourselves. If valgrind is installed on your system all of the wolfSSL tests will be run under it. This allows early detection of difficult to track down errors. The detailed output makes tracking down and fixing errors a relatively simple process.
