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 /cyassl/ctaocrypt/ecc.h header file and the /ctaocrypt/src/ecc.c source file. Supported ECC cipher suites include:

/* 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!

STM32 and wolfSSL – Hardware Crypto and RNG Support

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 /wolfssl/wolfcrypt/settings.h. You can find the most recent version of wolfSSL on GitHub, here: https://github.com/wolfssl/wolfssl.

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

wolfSSL 2.4.6 is Now Available

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.

Open Source for America

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.

wolfSSL Custom I/O: Handshaking

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.

Posts navigation

1 2 3 163 164 165 166 167 168 169 189 190 191