RECENT BLOG NEWS

A Cipher Suite is a set of cryptographic instructions or algorithms that helps secure network connections through Transport Layer Security(TLS)/Secure Socket Layer (SSL). It helps determine how your web server will communicate secure data over HTTPS, and makes sure to secure the communications between client and server.

To start a HTTPS connect, the web server and the client perform what is a SSL handshake. The SSL handshake is a process that leverages various cryptographic functions to achieve a HTTPS connection. During the handshake, the two parties agree on a cipher suite, which is then used to secure the HTTPS connection.

During the handshake, the cipher suite typically uses these algorithms;

• • Key Exchange Algorithm 
    • A method by which keys can be exchanged
    • Ex: RSA, DH, ECDH, ECDHE, PSK
  • Bulk Encryption Algorithm 
    • A method by which symmetric key algorithms will be used to encrypt data
    • Ex: AES, 3DES, CAMELLIA, ARIA
  • Authentication Algorithm 
    • A method that dictates how server authentication and client authentication is implemented
    • Ex: RSA, DSA, ECDSA
  • Message Authentication Code (MAC) Algorithm 
    • A method that determines which connections to use for data integrity checks
    • Ex: SHA, MD5, POLY1305

These ciphers are used at various points of the connection to perform authentication, key generation and exchange, and a checksum to ensure integrity. The client and web server will start by deciding which specific algorithms to use in the cipher suite.

A typical Cipher Suite contains 1 key exchange, 1 bulk encryption, 1 authentication, and 1 MAC algorithm. C

Here is an example from Security Boulevard

“Starting from left to right, ECDHE determines that during the handshake the keys will be exchanged via ephemeral Elliptic Curve Diffie Hellman (ECDHE). ECDSA or Elliptic Curve Digital Signature Algorithm is the authentication algorithm. AES128-GCM is the bulk encryption algorithm: AES running Galois Counter Mode with 128-bit key size. Finally, SHA-256 is the hashing algorithm.”

Why Cipher Suites are Important

Cipher suites are important for ensuring the security, compatibility and performance of the HTTPS connections. The cipher suite is like a recipe that dictates which algorithms to use to make secure and reliable connections. 

• Security – The security level of the HTTPS traffic (or the safety of both server and client data) depends on the cipher suites the web server uses
• Compatibility – The compatibility of the HTTPS traffic (or who has access to errors, warnings etc) depends on the cipher suites the web server uses
• Performance – The performance of the HTTPS traffic (or the page speed) depends on the cipher suites the web server uses.

wolfSSL and Cipher Suites

wolfSSL is modular. We’ve got two key modules: wolfSSL handles all TLS/SSL needs while wolfCrypt handles all cryptographic needs including block ciphers, stream ciphers, message digests, hashing, public key cryptography, certificates, and various helper utilities.  

The wolfCrypt cryptography engine is a lightweight crypto library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments – primarily because of its small size, speed, and feature set.  It is commonly used in standard operating environments as well because of its royalty-free pricing and excellent cross platform support.  wolfCrypt supports the most popular algorithms and ciphers as well as progressive ones such as HC-128, RABBIT, and NTRU.  wolfCrypt is stable, production-ready, and backed by our excellent team of security experts. 

A complete description of wolfCrypt and our ciphers is available here: https://www.wolfssl.com/docs/wolfssl-manual/ch10/.

Conclusion 

Cipher suites are an integral part of how websites function over HTTPS. They are a combination of ciphers used during the SSL/TLS handshake to determine the security settings of an HTTPS connection. Choosing and maintaining the appropriate cipher suites, both in the web server and the client, is important to ensure the security, performance, and compatibility of your HTTPS communications.

For information regarding the use of cipher suites or general inquiries about wolfSSL’s embedded SSL/TLS library contact us at facts@wolfssl.com!

ANNOUNCEMENT:

wolfSSL is  very proud to let our FIPS community know that wolfCrypt has received its’ first two consolidated ACVP vector certificates!

#A894
#A902

Both of these consolidated certificates were for embedded operating environments (OEs’) and wolfSSL will soon be working on adding a Linux 4.4 on ARM OE, CMSIS-RTOS on EFM32 OE, WINCE on ARM OE and more!

BACKGROUND:

As many in the FIPS world are aware NIST retired CAVP (Cryptogrphic Algorithm Validation Protocol) testing on June 30th of 2020, permanently replacing CAVP with ACVP (Automated Cryptographic Validation Protocol), also referred to as ACVTS (Automated Cryptographic Validation Test System).

In order to prepare for this transition NIST offered a “demo server” that Vendors like wolfSSL and FIPS Labs could utilize in standup of the new protocol. Once the transition was completed NIST also setup “production servers” which only FIPS Labs with a trusted certificate issued by NIST can connect to. Production Vectors passing are now the gateway to Algorithm Certification (IE certs like the ones wolfSSL just received!).

Algorithm Certification is a prerequisite to CMVP FIPS 140-2 (and 140-3) validations. This design keeps in place the need for a FIPS lab to achieve algorithm certification but it now allows for Vendors such as wolfSSL to pre-test in advance of requesting production vectors for certification!

USE-CASES:

The ACVP client wolfSSL has developed can do several things:

1. Connect to the demo server, request test vectors for 1 (or many) algorithms, process them, and return the responses ultimately receiving either a “pass” or “fail” result.
   1. Support for testing on full Operating System such as Linux/Windows/Unix
   2. Support for testing on embedded Operating Environments (Yes even those that are barely above bare-metal)!
2. Process JSON files received from a FIPS lab containing production vectors and write out JSON response files for returning to a FIPS lab.
   1. Support for testing on full Operating System such as Linux/Windows/Unix
   2. Support for testing on embedded Operating Environments (even those that are barely above bare-metal)!
3. The wolfSSL ACVP client also has some local known-answer tests it can run to check algorithms without an RNG component IE most bulk encryption algorithms without an integrity check, and hash algorithms. Bulk encryption algorithms with an integrity check, public key algorithms, and the DRBG can only be sanity-checked against the demo server as the outputs are random and can not be simply diffed with a static known-answer test file.

Users who may want to prepare in advance for the possibility of doing a FIPS validation could use the wolfSSL proprietary ACVP client to test their implementations are ready before pulling the trigger on a FIPS effort with a FIPS lab! If you have any questions or are interested in hearing more about the wolfSSL ACVP client or having wolfSSL validate an Operating Environment so that you can win those deals with customers that need a FIPS validated software module, please contact us at support@wolfssl.com or fips@wolfssl.com anytime!

Sources:

https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/cst-lab-transition

For information regarding the use of cipher suites or general inquiries about wolfSSL’s embedded SSL/TLS library contact us at facts@wolfssl.com!

Hi webinar friends!

Join us for our upcoming webinar on December 16th, 2020 with wolfSSL Engineering Manager, Chris Conlon. This webinar will provide attendees with the basics and best practices needed to get started using the wolfSSL TLS library in products and projects into 2021! Topics will include a brief overview of TLS 1.3, wolfSSL package structure, how to build wolfSSL, running the wolfCrypt cryptography test and benchmark applications, wolfSSL basic API usage, tips on debugging, and more! Bring your questions for the Q&A session to follow!

When: Dec 16, 2020 09:00 AM Pacific Time (US and Canada)
Topic: Webinar: Get Started in 2021 with wolfSSL

Register in advance for this webinar:
https://us02web.zoom.us/webinar/register/WN_oh514TxLS76aw90uGjtG5A
After registering, you will receive a confirmation email containing information about joining the webinar.

See you there!

Additional Resources

Please contact us at facts@wolfssl.com with any questions about the webinar. For technical support, please contact support@wolfssl.com or view our FAQ page.

In the meanwhile, check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL.

We at wolfSSL have recently been benchmarking the performance of our core TLS read and write functions, wolfSSL_read and wolfSSL_write. With assembly optimizations enabled, read and write throughput can reach well over 1 GB/s! The data in the charts below was collected using an Intel Core i5-7300HQ CPU @ 2.50GHz and Ubuntu 18.04.4 LTS. Server and client were both run on this machine, with each given exclusive access to its own CPU core. Benchmarking was done for both TLS version 1.2 and 1.3. We picked a few widely used ciphers and measured throughput on the client side of the TLS connection after the handshake was complete, transmitting 1 MB to the server and receiving 1 MB back. For each cipher, we did this 1000 times and averaged the throughput in each direction (RX and TX). We collected data using our crypto library (wolfCrypt) built with assembly optimizations (configure option –enable-intelasm) and without. If you’re looking for a high throughput TLS implementation, check out wolfSSL!

Contact us at facts@wolfssl.com for more information about wolfSSL, or with any questions you may have.

Hi! As our readers know, wolfSSL produces the first embedded TLS library that has begun testing for the new FIPS 140-3 standard, as listed here: https://csrc.nist.gov/projects/cryptographic-module-validation-program/modules-in-process/iut-list

One of the things that is critical to our users is Key Derivation Functions, which are explained here: https://en.wikipedia.org/wiki/Key_derivation_function

Key derivation functions are consumed by TLS 1.2, TLS 1.3, and SSH. We will support KDF’s for all three in our new FIPS 140-3 certificate.

If you have questions on FIPS 140-3 or our progress on the effort, please contact us at facts at wolfssl .com or give us a call.

The TPM feature for parameter encryption and HMAC verification has been added to wolfTPM! The TCG TPM 2.0 specification allows protection of the first parameter of a command or response using parameter encryption. When using an authenticated session it also adds HMAC validation to prove the TPM entity is trusted and integrity of command and response.

Encryption is supported using AES CFB or XOR. The authenticated sessions now support salted unbound sessions with HMAC or Policy type.

The effort was integrated in this GitHub pull request: https://github.com/wolfSSL/wolfTPM/pull/129 and is in the wolfTPM v2.0 release.

Features:

• Added AES CFB support
• Added calculation of command hash and HMAC for sessions
• Added response HMAC validation
• Fixes and cleanups for KDFa
• Added KDFa unit test (passes)
• Inlined the param encryption buffers
• Added “-aes” and “-xor” options to most examples to enable parameter encryption
• Refactor of the session authentication
• Fixes for nonce and auth count
• Added support for encrypted RSA salt and salted-unbounded session
• Added innerWrap and outerWrap support for sensitive to private

For more information about using wolfTPM in your product or project, contact us at facts@wolfssl.com!

The wolfSSL team is happy to announce support for the latest version of Apache httpd, 2.4.46, with both our standard and FIPS-compliant code. In addition to building wolfSSL with –enable-apachehttpd, users will also need to add –enable-postauth. To support this latest version, we have added new OpenSSL compatibility functions to wolfSSL, updated our Apache httpd documentation, and implemented patch code for httpd to make it play with wolfSSL.

If you would like access to this documentation and patch file, or have any questions about wolfSSL, contact us at facts@wolfssl.com!

The wolfSSL embedded SSL/TLS library supports the Renesas Trusted Secure IP Driver (TSIP) and has been tested on the Renesas RX65N platform.  Using the TSIP driver, wolfSSL can offload supported cryptographic and TLS operations to the underlying Renesas hardware for increased performance.

Supported TSIP Capabilities

wolfSSL has been integrated with the following TSIP capabilities:

• TSIP driver open/close
• Random number generation, tested with SP 800-22
• SHA-1 and SHA-256 hash function support
• AES-128-CBC and AES-256-CBC support
• TLS capabilities including:
  • Root CA verification
  • Client and/or Server certificate verification including intermediate certificate verification
  • Support for four TLS cipher suites:
    • TLS_RSA_WITH_AES_128_CBC_SHA
    • TLS_RSA_WITH_AES_128_CBC_SHA256
    • TLS_RSA_WITH_AES_256_CBC_SHA
    • TLS_RSA_WITH_AES_256_CBC_SHA256

The Renesas TSIP driver is outside the scope of the wolfSSL package download and needs to be obtained externally from Renesas.

Building wolfSSL with RX65N and TSIP Support

Support for Renesas RX65N and TSIP can be enabled at compile-time in wolfSSL by defining one or both of the following defines:

WOLFSSL_RENESAS_TSIP – enables Renesas TSIP support

WOLFSSL_RENESAS_RX65N – enables support for Renesas RX65N

wolfSSL TSIP Benchmarks

The following benchmarks show the performance improvement when using hardware cryptography on the Renesas RX65N through the Renesas TSIP driver.

Our tests have shown that the implementation of TSIP Accelerated Crypto increased processing speed by an average of 2334%, resulting in 92% faster processing times.

Limitations of TSIP with wolfSSL

The following limitations exist when using wolfSSL with Renesas TSIP:

• TSIP TLS capabilities are fully available only when using one of the TSIP-supported cipher suites.  These cipher suites include:
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA256
• The TSIP TLS capabilities support generation of the normal TLS master secret, but do not support the TLS Extended Master Secret Extension.  TSIP TLS is not available when Extended Master Secret is used.
• The TSIP TLS certificate verification capability is only available when verifying a certificate signed by “RSA 2048 PSS with SHA-256”.
• The TSIP TLS capability, common cryptography, is available on client-side only.  Server-side is not currently supported by the TSIP driver.
• TSIP uses one root CA certificate bundle signature signed by RSA-2048-PSS with SHA-256 available at runtime. When using a different root CA for TSIP TLS capabilities, applications need to call wolfCrypt_Init() to reset the TSIP driver state, then inform TSIP of a new signature and key through the tsip_inform_cert_sign() and tsip_inform_user_keys() APIs.

References

TSIP (Trusted Secure IP) Module Firmware Integration Technology APPLICATION NOTE Rev. 1.06

TSIP Product Page

Support

More information on using wolfSSL in combination with Renesas and wolfSSL’s support for Renesas can be found here: https://www.wolfssl.com/docs/renesas/

For support and more information about wolfSSL TSIP support, please contact the wolfSSL support team at support@wolfssl.com.