wolfSSL adds Silicon Labs Hardware acceleration support

wolfSSL is excited to announce support for using Silicon Labs Hardware acceleration. The EFR32 family of devices support multiple wireless interfaces with hardware cryptographic operations. wolfSSL can now offload cryptographic operations for dramatically increased performance on the Silicon Labs EFR32 family!

Our new support includes hardware acceleration of the following algorithms:

  • RNG
  • AES-CBC
  • AES-GCM
  • AES-CCM
  • SHA-1
  • SHA-2
  • ECDHE
  • ECDSA

The new functionality can be enabled by defining WOLFSSL_SILABS_SE_ACCEL. In user_settings.h More details are available in the README.md in wolfcrypt/src/port/silabs of the wolfSSL tree.

Benchmarks

Benchmark was performed on an EFR32 Gecko 2 (Series 1) using the xGM210P022.

The tests use Simplicity Studio v5 with Gecko SDK 3.0 using Micrium OS 5 and Secure Element Manager.

Algorithm Data Throughput (MB/s)
RNG 1.895
SHA 7.195
SHA-224 7.327
SHA-256 7.334
HMAC-SHA 6.304
HMAC-SHA224 6.329
HMAC-SHA256 6.323
AES-128-CBC-enc 4.897
AES-128-CBC-dec 4.907
AES-192-CBC-enc 4.795
AES-192-CBC-dec 4.805
AES-256-CBC-enc 4.703
AES-256-CBC-dec 4.712
AES-128-GCM-enc 4.463
AES-128-GCM-dec 4.317
AES-192-GCM-enc 4.377
AES-192-GCM-dec 4.235
AES-256-GCM-enc 4.297
AES-256-GCM-dec 4.162
AES-CCM-Enc 4.203
AES-CCM-Dec 4.045

 

ECC operation Average time to complete (ms) Operations per second
ECC 256 key gen 5.929 168.663
ECDHE 256 agree 5.440 183.816
ECDSA 256 sign 6.373 156.902
ECDSA 256 verify 6.727 148.662

Please contact us at facts@wolfssl.com  with any questions you have on wolfSSL, or just give us a call!

wolfSSL Cisco libest Port

With wolfSSL 4.6.0, the cisco/libest EST library has been ported to work with wolfSSL. The Enrollment over Secure Transport (EST) protocol defines “enrollment for clients using Certificate Management over CMS (CMC) [RFC5272] messages over a secure transport.” It uses TLS >1.1 and the Hypertext Transfer Protocol (HTTP) to facilitate secure and authenticated Public Key Infrastructure (PKI) Requests and Responses [RFC5272]. libest is a client and server EST implementation written in C.

To build wolfSSL 4.6.0 for libest:

./configure --enable-libest
make
make install

To obtain a copy of libest that is compatible with wolfSSL, please contact us at support@wolfssl.com.

Once you have a wolfSSL compatible version of libest, to build the library:

./autogen.sh
./configure --enable-wolfssl
make
make install

To run the tests in test/UT configure wolfSSL instead with:

./configure --enable-libest --enable-dsa --enable-oldtls --enable-tlsv10 --enable-sslv3

The porting of libest to wolfSSL has greatly expanded the compatibility layer. Many new API’s were introduced and old ones have been updated. Additionally, Certificate Signing Request (CSR) generation and parsing has been expanded to meet the needs of the libest library. Some of the new changes include:

  • Parsing a CSR to be used for certificate generation
  • Parsing and generating a limited number of supported CSR attributes
  • Parsing configuration files using NCONF APIs
  • Retrieving the local and peer finished message contents
  • Creating and parsing text databases using TXT_DB API
  • New OpenSSL compatibility layer functions implemented
    • ASN1_get_object
    • d2i_ASN1_OBJECT
    • c2i_ASN1_OBJECT
    • BIO_new_fd
    • BIO_snprintf
    • BUF_strdup
    • BUF_strlcpy
    • BUF_strlcat
    • sk_CONF_VALUE_new
    • sk_CONF_VALUE_free
    • sk_CONF_VALUE_pop_free
    • sk_CONF_VALUE_num
    • sk_CONF_VALUE_value
    • lh_CONF_VALUE_retrieve
    • lh_CONF_VALUE_insert
    • NCONF_new
    • NCONF_free
    • NCONF_get_string
    • NCONF_get_section
    • NCONF_get_number
    • NCONF_load
    • CONF_modules_load
    • _CONF_new_section
    • _CONF_get_section
    • X509V3_conf_free
    • EVP_PKEY_copy_parameters
    • EVP_PKEY_get_default_digest_nid
    • EVP_PKEY_CTX_ctrl_str
    • IMPLEMENT_LHASH_HASH_FN
    • IMPLEMENT_LHASH_COMP_FN
    • LHASH_HASH_FN
    • LHASH_COMP_FN
    • lh_strhash
    • PKCS12_verify_mac
    • i2d_PKCS7_bio
    • SSL_get_finished
    • SSL_get_peer_finished
    • X509_get_ext_by_OBJ
    • i2d_X509_REQ_bio
    • d2i_X509_REQ_bio
    • PEM_read_bio_X509_REQ
    • d2i_X509_REQ
    • X509_REQ_sign_ctx
    • X509_REQ_add1_attr_by_NID
    • X509_REQ_add1_attr_by_txt
    • X509_REQ_get_attr_by_NID
    • X509_REQ_get_attr
    • X509_ATTRIBUTE_get0_type
    • X509_to_X509_REQ
    • X509_get0_extensions
    • X509_get_extensions
    • X509_REQ_get_extensions
    • X509_REQ_get_subject_name
    • X509_REQ_get_pubkey
    • X509_REQ_set_version
    • X509_sign_ctx
    • X509_REQ_print
    • X509_print_fp
    • X509_REQ_print_fp
    • X509_signature_print
    • X509_get0_signature
    • X509_verify
    • X509_REQ_verify
    • X509_REQ_check_private_key
    • X509_delete_ext
    • sk_X509_INFO_shift
    • X509_NAME_delete_entry
    • X509_NAME_print_ex_fp
    • X509_STORE_CTX_get0_parent_ctx
    • X509_REQ_get_X509_PUBKEY
    • BIO_new_connect
    • BIO_set_conn_port
    • BIO_do_connect
    • ASN1_TIME_new
    • ASN1_UTCTIME_new
    • ASN1_UTCTIME_free
    • ASN1_TIME_set
    • ASN1_TIME_set_string
    • ASN1_TIME_to_string
    • a2i_ASN1_INTEGER
    • ASN1_STRING_new
    • ASN1_STRING_free
    • ASN1_STRING_cmp
    • ASN1_UNIVERSALSTRING_to_string
    • DHparams_dup
    • OPENSSL_cleanse
    • sk_OPENSSL_STRING_num
    • sk_OPENSSL_PSTRING_num
    • sk_OPENSSL_PSTRING_value
    • sk_OPENSSL_STRING_free
    • SSL_CTX_set_srp_strength
    • SSL_get_srp_username
    • TXT_DB_read
    • TXT_DB_write
    • TXT_DB_insert
    • TXT_DB_free
    • TXT_DB_create_index
    • TXT_DB_get_by_index

Feel free to contact us at facts@wolfssl.com for additional information and help with using the new features of wolfSSL 4.6.0. These features were added in commit 814ed3f5a68d37dec4ee91e6dace35c7343eec36.

(D)TLS 1.2 Secure Renegotiation Application Data

One of the new features in wolfSSL 4.6.0 is the ability to process application data during a (D)TLS 1.2 secure renegotiation. The new functionality (added in commit 7c89d10e5362ec281ce61ff12f37a091aa124e98) allows users to send and receive their data during the re-handshake process. Sending data can be accomplished, when using non-blocking sockets, by calling the wolfSSL_write API during a secure renegotiation. To read data during a secure renegotiation, use the wolfSSL_read API.

The wolfSSL examples have been updated to test exchanging application data during a secure renegotiation. To enable and test this new feature, build wolfSSL 4.6.0 with the following commands:

./configure --enable-secure-renegotiation
make

Run the following TLS examples simultaneously in separate windows to demonstrate application data with secure renegotiation:

./examples/server/server -M -m -d -N
./examples/client/client -R -i scr-app-data -N

To run the same tests with DTLS add --enable-dtls to the configure parameters and add -u to both of the example parameters:

./configure --enable-secure-renegotiation --enable-dtls
make
./examples/server/server -M -m -d -N -u
./examples/client/client -R -i scr-app-data -N -u

Users who use secure renegotiation must also expect and handle a new error value. wolfSSL TLS API’s (wolfSSL_connect, wolfSSL_accept, wolfSSL_read, wolfSSL_write) may now return a failure and set the error code to APP_DATA_READY (retrievable by wolfSSL_get_error). This signals to the user that wolfSSL has received application data during a secure renegotiation. The user should immediately call wolfSSL_read to retrieve the received data. If wolfSSL_read is not called immediately after receiving the APP_DATA_READY error code then the data may be dropped if new application data is received. This applies to both TLS and DTLS.

An example connect loop using non-blocking sockets which processes application data during a secure renegotiation:

if ((ret = wolfSSL_Rehandshake(ssl)) != WOLFSSL_SUCCESS) {
    err = wolfSSL_get_error(ssl, 0);
    if (err == WOLFSSL_ERROR_WANT_READ ||
        err == WOLFSSL_ERROR_WANT_WRITE ||
        err == APP_DATA_READY) {
        do {
	    if (err == APP_DATA_READY) {
    	        if ((ret = wolfSSL_read(ssl, reply,
            	    sizeof(reply)-1)) < 0) {
        	    /* HANDLE ERROR */
    	        }
    	        printf("Received message during "
           	       "renegotiation: %s\n", reply);
	    }
	    err = 0;
	    if ((ret = wolfSSL_connect(ssl)) != WOLFSSL_SUCCESS) {
    	        err = wolfSSL_get_error(ssl, ret);
	    }
        } while (ret != WOLFSSL_SUCCESS &&
    	        (err == WOLFSSL_ERROR_WANT_READ ||
        	 err == WOLFSSL_ERROR_WANT_WRITE ||
        	 err == APP_DATA_READY));
	}
}

Please see the example/client/client.c and example/server/server.c files in the wolfSSL directory as a reference for how the APIs may be used. Contact wolfSSL at facts@wolfssl.com with any questions or comments!

Updated wolfSSL Yocto and OpenEmbedded Recipes

We recently validated the compatibility of our “meta-wolfssl” layer with Yocto 3.0 Zeus, and also updated our wolfSSL recipe to match our newest 4.6.0 release! We offer recipes for wolfSSL, wolfSSH, wolfMQTT, and wolfTPM, all available for Yocto Project or OpenEmbedded based projects.

Adding the wolfSSL products to your project happens in just three steps:

  1. Clone the git repo from GitHub into your Yocto/OE sources location:
  2. Add to your build’s bblayers.conf file the following line, in the BBLAYERS section:
    • '/path/to/yocto/poky/meta-wolfssl'
  3. Edit your build’s local.conf and add the following line:
    • IMAGE_INSTALL_append = "wolfssl wolfssh wolfmqtt wolftpm"

Last, build your preferred target using bitbake and the resulted image will have:

  • wolfSSL embedded SSL/TLS library
  • wolfSSH lightweight SSH library
  • wolfMQTT lightweight MQTT Client Library
  • wolfTPM TPM 2.0 Library

If you are interested in trying these recipes out, we have a Getting Started document available here:
wolfSSL Getting Started for Yocto and OpenEmbedded

If you have questions about using “meta-wolfssl” in your project, or need tips on getting started with your build, email us at facts@wolfssl.com.

wolfSSL RC2-ECB/CBC Support and Integration with PKCS#12

One of the features included in the new wolfSSL 4.6.0 release is support for RC2-ECB/CBC and its integration into wolfSSL’s PKCS#12 functionality.

RC2-ECB/CBC has been added to wolfCrypt for users who have backwards compatibility requirements and may need to interop with older existing applications or devices. This feature is disabled by default and can be enabled with the “--enable-rc2” configure option.

Along with the addition of RC2, wolfSSL now supports parsing and decoding PKCS#12 bundles generated using pbeWithSHA1And40BitRC2-CBC encryption. By default, OpenSSL generates .p12 bundles with pbeWithSHA1And40BitRC2-CBC encryption when using the pkcs12 command. This change now allows wolfSSL to decode those OpenSSL-generated .p12 bundles.

Contact us at facts@wolfssl.com with any questions, or for assistance getting started with wolfSSL in your project!  The wolfSSL embedded SSL/TLS library supports TLS 1.3, FIPS 140-2 and 140-3, DO-178, and more!

Modern testing of the wolfSSL TLS library

Guest blog, written by Robert Hörr (e-mail: robert (dot) hoerr (at) t-systems (dot) com)
(Security Evaluator of Deutsche Telekom Security GmbH)


My name is Robert Hörr and I am working as a penetration tester at Deutsche Telekom Security GmbH. Pentesting is mostly done on security software, as for instance the wolfSSL TLS library to discover issues like the Heartbleed bug of OpenSSL. I have discovered some issues in the wolfSSL TLS library (see https://www.wolfssl.com/docs/security-vulnerabilities) using my own developed TLS-FAST (Fast Automated Software Testing) framework. In the future my goal is to provide our customers a FAST service to test their software products.

Why are TLS libraries tested?

It is important to check TLS libraries because TLS is one of the most deployed security protocols in the Internet. Typically, there is no client authentication on a standard Internet server by default configuration, to ensure that every Internet user can use it. Hence, any vulnerability in the TLS protocol implementation can be exploited easily. There are many TLS vulnerability entries in the public CVE list and the number is growing constantly.

Which testing approach is used?

The wolfSSL TLS library is a constantly growing project, with more and more functionalities, extensions and TLS versions added to its scope over time. This offers wolfSSL customers maximal flexibility in the use of the wolfSSL TLS library. Because of this growing process, the source code gets more complex. It is hardly possible to check all code paths by a manual source code review. Hence, dynamic automated machine testing must be performed. An efficient way to perform this kind of testing is the code coverage fuzzing approach. This fuzzing variant allows to discover all code paths. The discovering speed depends on the available computing resources. The code paths are checked systematically for memory leaks, buffer overflows, logical issues and so on.

Which tools are used for TLS testing?

Several open source fuzzing tools, which are based on this fuzzing approach, are public available. Some of the most popular ones are AFL, LibFuzzer and HonggFuzz. The community discovered many issues using any of them. Each of these tools has its strengths in certain fuzzing areas, for example HonggFuzz has a higher number of executions per second than the other tools. To benefit from all fuzzers at the same time, I have developed the FAST (Fast Automated Software Testing) framework for TLS libraries, which combines the strengths of several fuzzing tools. Over the time, the following features and approaches have been added to this framework:

  1. Deterministic runs:
    • The entire testing process is deterministic, so that discovered issues can be reproduced easily.
  2. Independence:
    • The testing process is independent from the environment. So that for example the process can be executed on every operating system.
  3. Realistic use:
    • The TLS libraries are used realistically to discover issues occurring in the field. So for example the original source code and the code paths should not be changed.
  4. Detection:
    • All kinds of implementation issues can be discovered by the testing process. For example buffer overflows or memory leaks are detected by the AddressSanitizer.
    • Logical issues or vulnerabilities are discovered by specific TLS tests.
  5. Scalability:
    • The testing process can be scaled linearly by adding more computation and storage resources.
  6. Coverage:
    • Code coverage is used to detect all code paths. If all applicable code paths are identified, the actual testing will start.
  7. Automation:
    • The full testing process runs automatically on a machine. Therefore no manual work is needed anymore.
  8. Flexibility:
    • The framework can be adapted to another tested software. This adaption to a new software takes some hours or days.

How is the wolfSSL TLS library tested?

The wolfSSL TLS library includes several TLS versions, features, extensions and crypto options. The testing focus was mainly defined on the TLS handshake of TLS versions 1.2, 1.3 and their extensions and features, because the TLS handshake implementations include most of the known TLS vulnerabilities (CVEs) and the other TLS versions are not recommended to use anymore.

Currently I am using the TLS-FAST framework for checking the API functions wolfSSL_accept(…) and wolfSSL_connect(…) of the wolfSSL TLS library master branch. This master branch gets the newest updates first. So the master branch must be tested to discover the newly added issues from the updates and to avoid that these new issues are linked into a stable version.

Most issues I have found (see https://www.wolfssl.com/docs/security-vulnerabilities) are located in the parsing process of the TLS messages client_hello and server_hello. These issues were buffer overflows or uninitialized memory. They could be fixed easily by simply adding a sanity check or a memory initialization. For the sake of completeness, it should also be mentioned that the wolfSSL TLS library source code includes about 521,655 lines of code (without comments and blanks). Hence, it is not easy to avoid issues without fuzzing.

What will be fuzzed in the future?

Currently I am testing the wolfSSL TLS library only, but wolfSSL provides further libraries, like wolfCrypt. These libraries interoperate and make use of each other. For example, the wolfSSL TLS library uses functions from the wolfCrypt library. So the other libraries must be tested, too. In the future, I will develop a new FAST framework for each of them. These new FAST frameworks will have the same features and approaches like the TLS-FAST framework. Over the time, new features will be added to these FAST frameworks.

My goal is to provide our customers a FAST framework as a testing service for their software products. This service detects all issues as quickly as possible.


Contact wolfSSL at facts@wolfssl.com with questions about the wolfSSL embedded SSL/TLS library, or to get started with wolfSSL in your project!  wolfSSL supports TLS 1.3, FIPS 140-2/3, DO-178, and much more!

wolfSSL 4.6.0 Now Available

The Christmas release of wolfSSL is available! Get your version 4.6.0 copy by visiting the downloads page on wolfSSL’s website or checking out the release sections on our GitHub repository. A lot of engineering and exciting additions happened in this release. Some of our recent blogs have touched on the new features, this release had our Linux kernel module support, Apache httpd TLS 1.3 support, hardware acceleration additions for the NXP DCP (i.MX RT1060/1062) crypto co-processor, Silicon Labs hardware support and many more new features.

A full list of items in the release can be found in the bundled README.md but the following are a few of the notable changes:

  • Linux Kernel Module! wolfSSL now enables Linux kernel module support with FIPS! 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. (--enable-linuxkm, --enable-linuxkm-defaults, --with-linux-source). Read more in our blog.
  • New Apple A12Z Benchmarks! Build tests and updated instructions for use with Apple’s A12Z chipset. Read more and see benchmarks in our blog!
  • wolfSSL Math Library! Expansion of wolfSSL Single Precision math implementation and addition of a new --enable-sp-math-all build option — includes broader assembly support and is faster.
  • TLS 1.3 fixes and additions! A couple of the additions have been with Sniffer support and adding Apache httpd TLS 1.3 support. We are leading the way with TLS 1.3 sniffing, which is important to a small subset of users such as schools that wish to protect what young kids can view in computer labs.
  • New Hardware Acceleration! Added support for NXP DCP (i.MX RT1060/1062) crypto co-processor and added Silicon Labs hardware acceleration using SL SE Manager.

Fixes


  • Math Library
    • Fix mp_to_unsigned_bin_len out of bounds read with buffers longer than maximum MP
    • Fix for fp_read_radix_16 out of bounds read
    • Fix to add wrapper for new timing resistant wc_ecc_mulmod_ex2 function version in HW ECC acceleration
    • Handle an edge case with RSA-PSS encoding message to hash
  • Compatibility Layer Fixes
    • Fix for setting serial number wolfSSL_X509_set_serialNumber
    • Fix for setting ASN1 time not before / not after with WOLFSSL_X509
    • Fix for order of components in issuer name when using X509_sign
    • Fix for compatibility layer API DH_compute_key
    • EVP fix incorrect block size for GCM and buffer up AAD for encryption/decryption
    • EVP fix for AES-XTS key length return value and fix for string compare calls
    • Fix for mutex freeing during RNG failure case with EVP_KEY creation
    • Non blocking use with compatibility layer BIOs in TLS connections
  • Build Configuration
    • Fix for custom build with WOLFSSL_USER_MALLOC defined
    • ED448 compiler warning on Intel 32bit systems
    • CURVE448_SMALL build fix for 32bit systems with Curve448
    • Fix to build SP math with IAR
    • CMake fix to only set ranlib arguments for Mac, and for stray typo of , -> ;
    • Build with --enable-wpas=small fix
    • Fix for building FIPS Ready using openssl extra
    • Fixes for building with Microchip (min/max and undef SHA_BLOCK_SIZE)
    • Fix for NO_FILESYSTEM build on Windows
    • Fixed SHA-256 support for IMX-RT1060
    • Fix for ECC key generation with NO_TFM_64BIT
  • Sniffer
    • Fixes for sniffer when using static ECC keys. Adds back TLS v1.2 static ECC key fallback detection and fixes new ECC RNG requirement for timing resistance
    • Fix for sniffer with SNI enabled to properly handle WOLFSSL_SUCCESS error code in ProcessClientHello
    • Fix for sniffer using HAVE_MAX_FRAGMENT in “certificate” type message
    • Fix build error with unused “ret” when building with WOLFSSL_SNIFFER_WATCH.
    • Fix to not treat cert/key not found as error in myWatchCb and WOLFSSL_SNIFFER_WATCH.
    • Sniffer fixes for handling TCP `out-of-range sequence number`
    • Fixes SSLv3 use of ECDH in sniffer
  • PKCS
    • PKCS#11 fix to generate ECC key for decrypt/sign or derive
    • Fix for resetting internal variables when parsing a malformed PKCS#7 bundle with PKCS7_VerifySignedData()
    • Verify the extracted public key in wc_PKCS7_InitWithCert
    • Fix for internal buffer size when using decompression with PKCS#7
  • Misc
    • Pin the C# verify callback function to keep from garbage collection
    • DH fixes for when public key is owned and free’d after a handshake
    • Fix for TLS 1.3 early data packets
    • Fix for STM32 issue with some Cube HAL versions and STM32 example timeout
    • Fix mmCAU and LTC hardware mutex locking to prevent double lock
    • Fix potential race condition with CRL monitor
    • Fix for possible malformed encrypted key with 3DES causing negative length
    • AES-CTR performance fixed with AES-NI

Improvements/Optimizations


  • SP and Math
    • mp_radix_size adjustment for leading 0
    • Resolve implicit cast warnings with SP build
    • Change mp_sqr to return an error if the result won’t fit into the fixed length dp
    • ARM64 assembly with clang improvements, clang doesn’t always handle use of x29 (FP or Frame Pointer) in inline assembly code correctly – reworked sp_2048_sqr_8 to not use x29
    • SP mod exp changed to support exponents of different lengths
    • TFM div: fix initial value of size in q so clamping doesn’t OOB read
    • Numerous stack depth improvements with --enable-smallstack
    • Improve cache resistance with Base64 operations
  • TLS 1.3
    • TLS 1.3 wolfSSL_peek want read return addition
    • TLS 1.3: Fix P-521 algorithm matching
  • PKCS
    • Improvements and refactoring to PKCS#11 key look up
    • PKCS #11 changes for signing and loading RSA public key from private
    • Check PKCS#7 SignedData private key is valid before using it
    • Check PKCS#7 VerifySignedData content length against total bundle size to avoid large malloc
  • Compatibility Layer
    • EVP add block size for more ciphers in wolfSSL_EVP_CIPHER_block_size()
    • Return long names instead of short names in wolfSSL_OBJ_obj2txt()
    • Add additional OpenSSL compatibility functions to update the version of Apache httpd supported
    • Add “CCM8” variants to cipher_names “CCM-8” ciphers, for OpenSSL compat
  • Builds
    • Cortex-M SP ASM support for IAR 6.70
    • STM Cube pack support (IDE/STM32Cube)
    • Build option --enable-aesgcm=4bit added for AES-GCM GMULT using 4 bit table
    • Xilinx IDE updates to allow XTIME override for Xilinx, spelling fixes in Xilinx README.md, and add Xilinx SDK printf support
    • Added ED448 to the “all” options and ED448 check key null argument sanity check
    • Added ARC4, 3DES, nullcipher, BLAKE2, BLAKE2s, XChaCha, MD2, and MD4 to the “all” options
    • Added an --enable-all-crypto option, to enable only the wolfCrypt features of --enable-all, combinable with --enable-cryptonly
    • Added the ability to selectively remove features from --enable-all and --enable-all-crypto using specific --disable- options
    • Use Intel intrinsics with Windows for RDSEED and RDRAND (thanks to dr-m from MariaDB)
    • Add option to build with WOLFSSL_NO_CLIENT_AUTH
    • Updated build requirements for wolfSSH use to be less restrictive
    • lighttpd support update for v1.4.56
    • Added batch file to copy files to ESP-IDF folders and resolved warnings when using v4.0 ESP-IDF
    • Added --enable-stacksize=verbose, showing at a glance the stack high water mark for each subtest in the wolfCrypt test app (testwolfcrypt)
  • ECC
    • Performance increase for ECC verify only, using non constant time SP modinv
    • During ECC verify add validation of r and s before any use
    • Always use safe add and dbl with ECC
    • Timing resistant scalar multiplication updated with use of Joye double-add ladder
    • Update mp_jacobi function to reduce stack and increase performance for base ECC build
    • Reduce heap memory use with wc_EccPrivateKeyDecode, Improvement to ECC wc_ecc_sig_to_rs and wc_ecc_rs_raw_to_sig to reduce memory use (avoid the mp_int)
    • Improve StoreECC_DSA_Sig bounds checking
  • OCSP
    • OCSP improvement to handle extensions in singleResponse
    • Support for OCSP request/response for multiple certificates
    • OCSP Must Staple option added to require OCSP stapling response
    • Add support for id-pkix-ocsp-nocheck extension
  • Misc
    • Additional code coverage added for ECC and RSA, PKCS#7, 3DES, EVP and Blake2b operations
    • DTLS MTU: check MTU on write
    • Refactor hash sig selection and add the macros WOLFSSL_STRONGEST_HASH_SIG (picks the strongest hash) and WOLFSSL_ECDSA_MATCH_HASH (will pick the hash to match the ECC curve)
    • Strict certificate version allowed from client, TLS 1.2 / 1.3 can not accept client certificates lower than version 3
    • wolfSSL_get_ciphers_compat(), skip the fake indicator ciphers like the renegotiation indication and the quantum-safe hybrid
    • When parsing session ticket, check TLS version to see whether they are version compatible
    • Additional sanity check for invalid ASN1 padding on integer type
    • Adding in ChaCha20 streaming feature with Mac and Intel assembly build
    • Sniffer build with --enable-oldtls option on

For questions contact us at facts@wolfssl.com. Merry Christmas, Happy New Year, and love to all from wolfSSL!

FIPS certificate #2425 is being added to NIST sunset list: wolfSSL customers can achieve effortless transition to FIPS cert #3389

FIPS 140-2 requires the use of validated cryptography in the security systems implemented by federal agencies to protect sensitive information. The wolfCrypt Module is a comprehensive suite of FIPS Approved algorithms. All key sizes and modes have been implemented to allow flexibility and efficiency.

The National Institute of Standards and Technology (NIST) is sending FIPS cert #2425 into sunset June 2021. For customers who will be impacted, the wolfCrypt Cryptographic Module maintains its #3389 certificate and can be used in conjunction with the wolfSSL embedded SSL/TLS library for full TLS 1.3 client and server support. Upgrade your FIPS cert with wolfSSL to stay afloat and benefit from: 

  • Algorithm support for TLS 1.3!
  • New algorithms such as AES (CBC, GCM, CTR, ECB), CVL, Hash DRBG, DSA, DHE, ECDSA (key generation, sign, verify), HMAC, RSA (key generation, sign, verify), SHA-3, SHA-2, SHA-1, and Triple-DES
  • Hardware encryption support for NXP’s Cryptographic Assistance and Assurance Module (CAAM), NXP Memory-Mapped Cryptographic Acceleration Unit (mmCAU), Intel’s AES-NI, and more
  • Support for secure elements and TPM’s
  • Interoperability with wolfBoot, wolfSSH, and wolfTPM
  • Integration support for third party libraries such as strongswan, nginx, python and more

Contact us to upgrade to FIPS cert #3389 at fips@wolfssl.com

Additional Resources 

Learn more about wolfSSL support for FIPS cert #3389: https://www.wolfssl.com/wolfcrypt-fips-certificate-3389-3/ 

For a list of supported Operating Environments for wolfCrypt FIPS, check our FIPS page: https://www.wolfssl.com/license/fips/ 

Our FIPS Story

wolfSSL is currently the leader in embedded FIPS certificates. We have a long history in FIPS starting with wolfCrypt FIPS 140-2 Level 1 Certificate #2425 as well as wolfCrypt v4 FIPS 140-2 Level 1 Certificate #3389. wolfSSL partners with FIPS experts KeyPair to bring you FIPS consulting services, and high assurance along each step of your FIPS certification process. Additionally, wolfSSL will be the first implementation of FIPS 140-3.

wolfSSL also provides support for a wolfCrypt FIPS Ready version of the library! wolfCrypt FIPS Ready is our FIPS enabled cryptography layer code included in the wolfSSL source tree that you can enable and build. You do not get a FIPS certificate, you are not FIPS approved, but you will be FIPS Ready. FIPS Ready means that you have included the FIPS code into your build and that you are operating according to the FIPS enforced best practices of default entry point, and power on self test.

wolfCrypt FIPS Ready can be downloaded from the wolfSSL download page located here: https://www.wolfssl.com/download/. More information on getting set up with wolfCrypt FIPS Ready can be found in our FIPS Ready User guide here: https://www.wolfssl.com/docs/fips-ready-user-guide/

 

Support for Apache httpd 2.4.46

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 provided patch code for httpd to make it play with wolfSSL. Please contact us for access to our Apache patch files. Importantly, Apache with wolfSSL also supports the latest and greatest TLS version, TLS 1.3.

Don’t hesitate to reach out to facts@wolfssl.com or raise an issue on our GitHub page if you have questions or suggestions!

Loading wolfSSL into the Linux Kernel

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.

For more information about wolfSSL, contact us at facts@wolfssl.com.

Posts navigation

1 2 3