RECENT BLOG NEWS

Big news for Linux kernel module developers with crypto requirements! wolfCrypt and wolfSSL are now loadable as modules in the Linux kernel, providing the entire libwolfssl API natively to other kernel modules. For the first time on Linux, the entire TLS protocol stack can be loaded as a module, allowing fully kernel-resident TLS/DTLS endpoints with in-kernel handshaking.

Configuration and building is turnkey via the new --enable-linuxkm option, and can optionally be configured for cryptographic self-test at load time (POST). As with library builds, the kernel module can be configured in detail to meet application requirements, while staying within target capabilities and limitations. In particular, developers can opt to link in only the wolfCrypt suite of low level cryptographic algorithms, or can include the full TLS protocol stack with TLS 1.3 support. When configured for AES-NI acceleration, the module delivers AES256-GCM encrypt/decrypt at better than 1 byte per cycle.

The kernel module configuration leverages our new function-complete “single precision” bignum implementation, featuring state of the art performance and side channel attack immunity. Watch this space — we’ll have a lot more to say about the many advantages of our new bignum implementation!

As a proof of concept, we have retargeted the Linux WireGuard kernel module to use wolfCrypt for all cryptography, with full interoperability, and will soon be sharing more on those results. Kernel module builds of libwolfssl will be supported in wolfSSL release 4.6, and are available immediately in our mainline github repository, supporting the 3.x, 4.x, and 5.x Linux version lines on x86-64.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSL has recently added support for Nginx version 1.7.7. Nginx is a high performance HTTP server and reverse proxy. Just like wolfSSL, Nginx is an open source project serving millions of users around the world. Expanding Nginx support gives users the power to choose their preferred cryptographic and SSL/TLS library. wolfSSL is very customizable, which allows its users to configure it exactly to their exact needs.

Matched with the corresponding patch file, wolfSSL users can use the --enable-nginx configure option to compile wolfSSL with Nginx support. wolfSSL currently has support for the following versions of Nginx:

• Nginx 1.17.5
• Nginx 1.16.1
• Nginx 1.15.0
• Nginx 1.14.0
• Nginx 1.13.12
• Nginx 1.13.8
• Nginx 1.13.2
• Nginx 1.13.0
• Nginx 1.12.2
• Nginx 1.12.1
• Nginx 1.12.0
• Nginx 1.11.13
• Nginx 1.11.10
• Nginx 1.11.7
• Nginx 1.10.3
• Nginx 1.7.7

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSL is up and running and tested on Apple’s new A12Z platform, and with the right options it is blazing fast! The key options that we benchmarked include our out of the box defaults vs some key optimizations described below. Some notes to help you decipher these benchmarks:

1. SP is Single Precision Math. It is a wolfSSL developed math library that is extremely well optimized for ARM environments and cryptographic math calculations.
2. SP ASM is the assembly component of the SP math library.
3. ARMASM is the assembly code functionality provided by ARM. As many of our savvy readers know, we have the best support for ARMv8 cryptography extensions, and they work great!
4. MB/Sec is the number of megabytes of data that you can encrypt or decrypt per second. If you have big files to encrypt/decrypt, then you will really enjoy the power of SP math and the ARMv8 cryptography extensions!
5. This is our first pass of optimizations for these benchmarks. We’ll do more, and we expect that a few more passes of optimizations will yield 20% to 40% more performance on any given cipher.

See below for more details!

To enable SP + SP ASM + ARM ASM and achieve maximum performance on Apple’s A12Z, pass in the following options to configure:
./configure --host=aarch64-apple-darwin --enable-sp --enable-sp-asm --enable-armasm
Note that the host flag is only required if the host is not detected as aarch64 by default. Check config.log after running configure to confirm this.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Both SSL and TLS are terms that refer to protocols designed to secure communications over the Internet. They stand for Secure Socket Layer and Transport Layer Security, respectively.

Historical Background

SSL was designed by Netscape Communications and implemented in their browsers; several vulnerabilities were discovered in SSL, and the version was upgraded to continue revisions in terms of security. However, with the discovery of vulnerabilities due to the POODLE attack, the last specification, SSL 3.0 was also discontinued by the Internet Engineering Task Force (IETF) in 2015. After this, SSL should not be used.

In 1996, before SSL was decommissioned, the IETF started to develop a specification for TLS, and TLS continued to be revised to include countermeasures against new attack methods discovered one after another, with the now widely used TLS 1.2 being established in 2008. The most current standard is TLS 1.3, which was published in August 2018.

SSL and TLS have different names, but the purpose and role are the same, and the two are often used interchangeably. wolfSSL also still uses “SSL” in its company and product names.

Differences in Specifications

Both SSL and TLS provide a means to encrypt and exchange data on the communication path (usually TCP/IP). Major 3 processes are:

• Authenticate the other party to communicate
• Determine a method and key to encrypt communication data
• Encrypt and decrypt communication data

It is said that the difference between the first version of TLS, TLS1.0, and the last version of SSL, SSL3.0, in terms of this feature, was minimal. Therefore, rather than knowing this boundary, it is more meaningful to know how the current TLS1.3 specification has changed.

What is the difference between TLS 1.3 and before?

The following specification changes have been made:

* Sifted through encryption algorithms and change encryption suite notation

* Reduced and sped up packet round trips by reorganizing handshake messages

* Encryption begins earlier in the handshake

Cryptographic suites previously had hundreds of definitions. The number of algorithms has been reduced to 5 by removing the algorithms that are no longer used, limiting them to essential algorithms, and organizing the encryption suite notation. Only the temporary key Diffie-Hellmann remained as the key exchange algorithm. Packet round-trip during handshaking is minimized to one round-trip. Also, encryption is performed in the middle of the handshake. The TLS 1.3 specification is designed to improve both security and communication speed.

Conclusion

Both SSL and TLS are still used interchangeably to refer to handshakes performed on clients and servers. However, SSL as a specification term is now a specification of the past and is not used in actual products. As of 2020, even servers that use TLS 1.1 will receive security warnings from typical browsers. The difference between SSL and TLS will only be questioned when looking back on history.

What’s important as a TLS user is to be aware of the differences between TLS 1.3 and the current mainstream TLS 1.2.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Related page:

TLS 1.3 Protocol Support | Documentation

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.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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!

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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 any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

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 have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.