Category: Uncategorized

Back in January of 2018 wolfSSL added support for use with the Open Whisper Systems Signal Protocol C Library! This means that you can now develop Signal applications using wolfCrypt as the underlying cryptography provider.

For those unfamiliar with the Signal Protocol, it is described on their GitHub page as “A ratcheting forward secrecy protocol that works in synchronous and asynchronous messaging environments.”

wolfSSL also has a JSSE provider that can be used with Android. This can seamlessly replace the default provider, giving all the benefits that come with using wolfSSL. Such as; extra performance boosts, access to our stellar support, and FIPS certifications to name a few items. Instructions on using the wolfSSL JSSE with Android can be found here https://www.wolfssl.com/docs/installing-a-jsse-provider-in-android-osp/.

wolfCrypt Signal Protocol Integration

By design, the Signal Protocol C Library does not depend on any SSL/TLS or cryptography library.  Instead, Signal allows the application to register a crypto provider at runtime.  We recently ported the wolfCrypt cryptography library into the “libsignal-protocol-c” test code and added a CMake configuration to build the libsignal-protocol-c test programs using cryptography from wolfSSL.

With this build option and wolfCrypt integration, Signal application developers can choose to use cryptography from wolfSSL instead of OpenSSL.  Thanks to wolfSSL’s small footprint size, low memory usage, and broad platform support, application developers can more easily use the Signal Protocol C Library on small resource-constrained platforms and embedded systems.

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 team here at wolfSSL is putting together a Sparkplug example that we’d like to share with you! The Sparkplug specification is useful for Industrial IoT system developers building on top of MQTT. Sparkplug defines a set of device states, adds topic naming structures, and defines payload formats. The wolfMQTT client library is perfectly suited to help secure your IIoT project since it is already integrated 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.

You can download the latest release here: https://www.wolfssl.com/download/
Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT
While you’re there, show us some love and give the wolfMQTT project a Star!

Last year wolfSSL fixed 8 vulnerabilities and documented them in the wolfSSL embedded SSL/TLS library release notes. Thanks to all of the researcher reports, and to the dedicated wolfSSL team, the fixes were identified and resolved rapidly. How rapidly you may ask? The average time to get a fix submitted for review on the vulnerabilities listed in 2020 was just over 26 hours.

Thanks to the researchers that submitted reports!

• Gerald Doussot from NCC group
• Lenny Wang of Tencent Security Xuanwu LAB
• Ida Bruhns from Universität zu Lübeck and Samira Briongos from NEC Laboratories Europe
• Alejandro Cabrera Aldaya, Cesar Pereida García and Billy Bob Brumley from the Network and Information Security Group (NISEC) at Tampere University
• Paul Fiterau of Uppsala University and Robert Merget of Ruhr-University Bochum
• Pietro Borrello at Sapienza University of Rome

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 developing a library to handle the location of where crypto operations run amongst multiple cores. For large systems that have many sign/verify operations happening at once this library would be able to distribute those sign/verify requests based on a user’s input. In addition to managing where the operation runs it can be used to plug in hardware acceleration for handling requests that come in. An example use case would be having 3 cores for generic lower priority operations and saving 1 core that has hardware acceleration for fast, real time responses, that would run high priority operations.

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 embedded SSL/TLS library also supports TLS 1.3, FIPS 140-2/3, and DO-178.

The wolfSSL library includes a useful tool for sniffing TLS traffic. This can be used to capture and decrypt live or recorded PCAP traces when at least one of the keys is known. Typically a static RSA ciphersuite would be used, however with TLS v1.3 only Perfect Forward Secrecy (PFS) ciphers are allowed. For TLS v1.3 all cipher suites use a new ephemeral key for each new session.

In order to solve this we added a “static ephemeral” feature, which allows setting a known key that is used for deriving a shared secret. The key can be rolled periodically and synchronized with the sniffer tool to decrypt traffic. This feature is disabled by default and is only recommended for internal or test environments.

As a proof of concept we added this support to Apache httpd to demonstrate real-time decryption of web traffic. We are also working on a key manager to assist with key rolling and synchronization.

A use case that might be interesting is a company internal web server that requires auditing.

The TLS v1.3 sniffer support was added in PR 3044 and officially supported in v4.6.0.
The Apache httpd branch with sniffer and FIPS ready support is here.

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 Qualcomm Hexagon SDK  is used for building code to run on DSP processors. Use of the Hexagon toolchain to offload ECC verify operations has been added to wolfSSL. This can free up the main CPU for other operations or lead to future optimizations with HVX on some algorithms that use vector operations. The Makefile for building with the Hexagon toolchain and a README with more information can be found in the directory wolfssl-4.6.0/IDE/HEXAGON.

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

Trusted Platform Modules (TPM) give us a secure vault for storing keys and secrets. We could also use a TPM as root-of-trust for reporting the health and integrity of our servers or bare metal systems (e.g. IoT). However, TPMs are physical devices. The communication between our software and the TPM happens over a physical interface, typically a SPI bus. This physical interface could be attacked maliciously. For example, IoT and Edge devices are exposed at this risk, because they are deployed in the field. An attacker might physically open the device and try to interfere with the communication between our software and the TPM. To protect from this risk, a TPM offers the capability of parameter encryption.

TPM has the ability to receive commands with their first parameter encrypted. If requested, the TPM could also respond with an encrypted first parameter. Usually, the first parameter is where the most sensitive data of a TPM command is stored. For example, during a TPM2_Create for generating a new key pair, the authValue used as password for the new key is stored in a structure called inSensitive that is the very first parameter of a TPM2_Create command request. All of this should be handled by the TPM stack. Because in order to use parameter encryption a TPM session must be set.

wolfTPM recently added parameter encryption support for protection of man-in-the-middle (MITM) attacks and offers new API wrappers to simplify its use. There is now the wolfTPM2_StartSesssion wrapper to start TPM sessions for parameter encryption and wolfTPM2_SetAuth to make use of this session. Regardless, if you want to use this extra layer of protection or not, the wolfTPM2_CreateKey wrapper accepts the same number of parameters. This way the development cycle is not affected, if you want to add MITM protection to your secure application by using wolfTPM.

TPM supports AES CFB and XOR method for parameter encryption, and wolfTPM supports both. All the encryption and decryption of command parameters is handled by the stack. The secure exchange of secrets for setting up the TPM session for parameter encryption also happens seamlessly from the developer’s perspective.

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 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

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

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

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

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.

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