RECENT BLOG NEWS

Hi!  As you may know, we`ve released our GCM code recently.  Our next major open source release, coming in September, will include our ECC implementation.  This will bring wolfSSL into Suite B compliance.  If you need our ECC code before our next release, just contact us at info@yassl.com and we`ll get it into your hands.

We have added the Galois/Counter Mode for AES to wolfSSL. It adds an Authenticated Data with Associated Data (AEAD) cipher to TLS v1.2 where the cipher provides its own message authentication. The following cipher suites are available:

* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_RSA_WITH_AES_256_GCM_SHA384
* TLS_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
* TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256

We offer four different implementations balancing speed versus memory consumption. If available, it will use 64-bit or 32-bit math. For embedded SSL applications, there is a speedy 8-bit version that uses RAM-based lookup tables (8KB per session) that is speed comparable to the 64-bit version and a slower 8-bit version that doesn`t take up any additional RAM.

AES with GCM will be available in our next release. The latest sources are available in our GitHub repository. To enable AES with GCM in wolfSSL, configure the build with the option “–enable-aesgcm”. The configure option may be modified with the options “=word32”, “=table”, or “=small”, i.e. “–enable-aesgcm=table”.

We are very excited to offer this new cipher. Adding AES with GCM makes wolfSSL compatible with NSA Suite B.

yaSSL has released a new case study highlighting how one of our customers, CCww, is using the wolfSSL embedded SSL library to secure GSM / GPRS modem modules. This case study highlights the key requirements CCww had for securing their modules, how wolfSSL was used as a solution, and summarizes CCww’s thoughts on the project.

You can download the case study directly from the yaSSL website at the following location. If you have any questions about using wolfSSL to secure your project, please contact us at info@yassl.com.

yaSSL / CCww Case Study: http://www.yassl.com/files/casestudy/casestudy_yassl_ccww.pdf

We wanted to remind our readers to enter our sweepstakes for a chance to win a New Apple iPad (16GB, Wi-Fi). The sweepstakes will be coming to a close August 1, 2012 (just 9 days away!). For a chance to win, just take our short SSL survey (10 questions) at the following link. The contest is limited to one entry per individual.

Begin the survey, here: http://www.surveymonkey.com/s/585N8LZ (this survey has been closed)

Eligibility: To be eligible to win you must be a legal resident of the fifty (50) United States or the District of Columbia and be at least eighteen (18) years old at the time of entry.

We appreciate your time and feedback! All results and comments will be taken into consideration to improve our products. If you have any questions, please email us at info@yassl.com.

As the first post in our PKCS series, we will be looking at PKCS #1. PKCS #1 is the RSA Cryptography Standard and is defined in RFC 3447 (http://tools.ietf.org/html/rfc3447). It defines standards for implementing public and private keys based on the RSA algorithm including cryptographic primitives, encryption schemes, signature schemes, and ASN.1 syntax for representing the keys and identifying the schemes.

A. Cryptographic Primitives

As stated in the RFC, cryptographic primitives are “basic mathematical operations on which cryptographic schemes can be built. Four different types of cryptographic primitives are defined in PKCS #1: encryption, decryption, signature, and verification.

An encryption primitive produces a ciphertext from a plaintext under the control of a public key. A decryption primitive produces a plaintext from a ciphertext under the control of a corresponding private key. PKCS #1 defines one pair of encryption/decryption primitives, specified as RSAEP and RSADP in RFC 3447, with exponentiation being the main mathematical operation used.

A signature primitive produces a signature from a message under the control of a private key. A verification primitive recovers the message from the signature under the control of the corresponding public key. The specific primitives defined for signature and verification in PKCS #1 are RSASP1 and RSAVP1.

B. Encryption and Signature Schemes

As stated in RFC 3447, “a scheme combines cryptographic primitives and other techniques to achieve a particular security goal.” The two types of schemes defined in PKCS #1 are encryption schemes and signature schemes with appendix. The schemes presented in PKCS #1 are limited in that they only present methods to process data with either a public or private key. They do not include any type of recommendations or steps to handle key management.

Both encryption schemes and signature schemes can be applied in many situations. One example given in RFC 3447 regarding an encryption scheme is usage in a key establishment protocol, where the message contains key material that needs to be delivered from party A to party B confidentially. An example given by the RFC for signature scheme usage could be as a signature algorithm for X.509 certificates. Note that signature schemes with appendix (defined in PKCS#1) are different than signature schemes with message recovery.

C. ASN.1 Syntax

The last item which is defined in PKCS #1 is ASN.1 object identifiers for RSA public and private keys and the RSA public and private key structure. The intended applications of these definitions include X.509 certificates, PKCS #8, and PKCS #12.

The wolfSSL embedded SSL library uses the PKCS #1 standard for RSA public and private keys and RSA operations. For example, if you examine the code, you can see how wolfSSL’s RsaKey type (./cyassl/ctaocrypt/rsa.h) matches up to the RSA key definition in PKCS #1.

To learn more about PKCS #1, you can look through RFC 3447, here:

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

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.

PKCS is a set of “Public Key Cryptography Standards” which were devised and published by RSA Security, Inc. beginning in the 1990s. The PKCS standards encapsulate everything from the RSA algorithm to password-based encryption to standards for certificate requests and cryptographic tokens. Because many of these standards are directly related to SSL/TLS and the wolfSSL embedded SSL library, we will be posting a series of blog posts on these widely-used standards over the next several weeks.

The PKCS Standards include:

PKCS#1 = RSA Cryptography Standard
PKCS#3 = Diffie-Hellman Key Agreement Standard
PKCS#5 = Password-based Encryption Standard
PKCS#6 = Extended-Certificate Syntax Standard
PKCS#7 = Cryptographic Message Syntax Standard
PKCS#8 = Private-Key Information Syntax Standard
PKCS#9 = Selected Attribute Types
PKCS#10 = Certificate Request Standard
PKCS#11 = Cryptographic Token Interface
PKCS#12 = Personal Information Exchange Syntax Standard
PKCS#13 = Elliptic Curve Cryptography Standard
PKCS#14 = Pseudo-random Number Generation
PKCS#15 = Cryptographic Token Information Format Standard

Stay tuned to our blog to learn more about the PKCS standards and how they relate to the wolfSSL embedded SSL library.

Would you like a chance to win a New Apple iPad (16GB, Wi-Fi) directly from yaSSL? We’re conducting a short SSL survey (10 questions) and giving anyone who completes the survey a chance to enter into our drawing. The prize drawing will be held August 1, 2012, and the contest is limited to one entry per individual.

Begin the survey, here: http://www.surveymonkey.com/s/585N8LZ (this survey has been closed)

Eligibility: To be eligible to win you must be a legal resident of the fifty (50) United States or the District of Columbia and be at least eighteen (18) years old at the time of entry.

We appreciate your time and feedback! All results and comments will be taken into consideration to improve our products. If you have any questions, please email us at info@yassl.com.

yaSSL has released a case study highlighting how one of our customers, Cinterion, is using wolfSSL to secure machine-to-machine (M2M) communication modules. This case study highlights the key requirements Cinterion had for securing Machine-to-Machine modules, how wolfSSL was used as a solution to easily secure these modules, and summarizes Cinterion’s thoughts on the project.

Machine-to-Machine communication refers to either wired or wireless communication taking place between devices (such as sensors or meters). To learn more about M2M, you will find the Wikipedia link, below.

You can download the case study directly from the yaSSL website at the following location. If you have any questions about using wolfSSL to secure M2M communication, please contact us at info@yassl.com.

wolfSSL / Cinterion (M2M) Case Study: http://www.yassl.com/files/casestudy/casestudy_yassl_cinterion.pdf
Wikipedia (Machine-to-Machine): http://en.wikipedia.org/wiki/Machine-to-Machine

wolfSSL will soon be getting support for the Cavium NITROX processors, thus enabling wolfSSL users to take advantage of the incredible performance boosts provided by the NITROX family. Cavium’s NITROX processors combine cryptographic acceleration with the latest security algorithms providing an ideal platform for the next generation of security applications.

The NITROX PX family can deliver performance ranging from 500 Mbps to 2.5 Gbps for full IPsec or SSL protocol offload, and anywhere from 4K to 17K RSA operations per second using 1024bit exponent RSA. The NITROX III family can additionally boost IPsec or SSL offload performance to anywhere from 5 Gbps to 40 Gbps, and can provide 35K to 200K RSA operations per second using 1024bit exponent RSA.

Are you interested in using wolfSSL with a Cavium NITROX processor? If so, let us know at info@yassl.com.

NITROX Security Processors: https://www.cavium.com/processor_security.html

Version 2.2.0 of the wolfSSL embedded SSL/TLS library has been released and is now available for download.  This release contains bug fixes, feature enhancements, and is a recommended update for all users. Changes include:

– Initial CRL (Certificate Revocation Lists) support with –enable-crl
– Initial OCSP (Online Certificate Status Protocol) support with –enable-ocsp
– Static ECDH suites including:
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
– SHA-384 support
– ECC client certificate support

For more information on CRL checkout: http://en.wikipedia.org/wiki/Certificate_revocation_list .  More details on OCSP can be found here: http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol .  The example/client has basic usage and the full API will be available in the manual. The addition of SHA-384 support makes wolfSSL even more compatible with other SSL implementations such as OpenSSL.

To download the open source, GPLv2-licensed version of wolfSSL 2.2.0, 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.