RECENT BLOG NEWS

wolfSSL is excited to announce wolfBoot support for Aarch64 platforms with out-of-the box examples for Xilinx ZynqMP and Raspberry Pi 3+.

On the Xilinx Zynq UltraScale+ MPSoC wolfBoot can replace U-Boot to provide enhanced support for feature such as:

• Boot failure detection and use of alternate secondary image.
• Update swapping of partitions.
• Image integrity checking SHA256 or SHA3-384.
• Validation of the signature using ECC P256, ED25519 or RSA (2048-bit or 3072-bit).
• Root of trust options:
  • Key embedded in wolfBoot image partition
  • Key from TPM 2.0 module using wolfTPM (ST33 / SLB95670 / ATTPM20)
  • Key from secure elements such as ST-SAFEA100 and ATECC608A

New Features:

• Added Aarch64 boot/startup support
• Added configuration templates for Raspberry Pi 3 and Xilinx ZynqMP UltraScale+
• Added Xilinx Zynq QSPI bare-metal Driver
• Added NO_XIP option for full ext_flash_* API on all partitions
• Added Xilinx SDK Project Template
• Added support for DTS image partitions
• Added Aarch64 GICv2 initialization code
• Added wolfBoot signing tool in Native C (tools/keytools/sign.c) (and Visual Studio project)
• Added libwolfboot functions:
• int wolfBoot_fallback_is_possible(void);
• int wolfBoot_dualboot_candidate(void);
• Performance improvement to only hash application firmware image once

wolfBoot: https://github.com/wolfSSL/wolfboot/

• Secure element and hardware encryption agnostic
• Support for all operating systems and bare metal configurations
• 24×7 support available

Pull Requests:

• wolfBoot Aarch64 support (Xilinx Zynq and Raspberry Pi)
• Fixes for Zynqmp with BL31 and C signing tool padding

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

Author: Daniel Stenberg (cross posted from daniel.haxx.se)

This is not a command line option of the week post, but I feel a need to tell you a little about our brand new addition!

–write-out [format]

This option takes a format string in which there are a number of different “variables” available that let’s a user output information from the previous transfer. For example, you can get the HTTP response code from a transfer like this:

curl -w 'code: %{response_code}'
https://example.org >/dev/null

There are currently 34 different such variables listed and described in the man page. The most recently added one is for JSON output and it works like this:

%{json}

It is a single variable that outputs a full json object. You would for example invoke it like this when you get data from example.com:

curl --write-out '%{json}' https://example.com -o saved

That command line will spew some 800 bytes to the terminal and it won’t be very human readable. You will rather take care of that output with some kind of script/program, or if you want an eye pleasing version you can pipe it into jq and then it can look like this:

{
    "url_effective": "https://example.com/",
    "http_code": 200,
    "response_code": 200,
    "http_connect": 0,
    "time_total": 0.44054,
    "time_namelookup": 0.001067,
    "time_connect": 0.11162,
    "time_appconnect": 0.336415,
    "time_pretransfer": 0.336568,
    "time_starttransfer": 0.440361,
    "size_header": 347,
    "size_request": 77,
    "size_download": 1256,
    "size_upload": 0,
    "speed_download": 0.002854,
    "speed_upload": 0,
    "content_type": "text/html; charset=UTF-8",
    "num_connects": 1,
    "time_redirect": 0,
    "num_redirects": 0,
    "ssl_verify_result": 0,
    "proxy_ssl_verify_result": 0,
    "filename_effective": "saved",
    "remote_ip": "93.184.216.34",
    "remote_port": 443,
    "local_ip": "192.168.0.1",
    "local_port": 44832,
    "http_version": "2",
    "scheme": "HTTPS",
    "curl_version": "libcurl/7.69.2 GnuTLS/3.6.12 zlib/1.2.11 brotli/1.0.7 c-ares/1.15.0 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) nghttp2/1.40.0 librtmp/2.3"
}

The JSON object

It always outputs the entire object and the object may of course differ over time, as I expect that we might add more fields into it in the future.

The names are the same as the write-out variables, so you can read the –write-out section in the man page to learn more.

Ships?

The feature landed in this commit. This new functionality will debut in the next pending release, likely to be called 7.70.0, scheduled to happen on April 29, 2020.

Credits

This is the result of fine coding work by Mathias Gumz.

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 now provides support for complete RTCA DO-178C level A certification! wolfSSL will offer DO-178 wolfCrypt as a commercial off -the-shelf (COTS) solution for connected avionics applications. Adherence to DO-178C level A will be supported through the first wolfCrypt COTS DO-178C certification kit release that includes traceable artifacts for the following encryption algorithms:

• SHA-256 for message digest
• AES for encryption and decryption
• RSA to sign and verify a message.
• Chacha20_poly1305 for authenticated encryption and decryption.

The primary goal of this initial release is to provide the proper cryptographic underpinnings for secure boot and secure firmware update in commercial and military avionics. wolfSSL brings trusted, military-grade security to connected commercial and military aircraft. Avionics developers now have a flexible, compact, economical, high-performance COTS solution for quickly delivering FIPS 140-2 validated crypto algorithms can be used in DO-178 mode for combined FIPS 140-2/DO-178 consumption. The wolfCrypt cryptography library FIPS 140-2 validation certificates can be applied to DO-178 uses. 

Optimization Support

We understand that securely rebooting avionic systems has rigorous performance requirements. As such, we’re here to help with cryptographic performance optimizations through our services organization. 

To download and view the most recent version of wolfSSL, the wolfSSL GitHub repository can be cloned from here: https://github.com/wolfssl/wolfssl.git, and the most recent stable release can be downloaded from the wolfSSL download page here: https://www.wolfssl.com/download/.

wolfSSL DO-178 product page: https://www.wolfssl.com/wolfssl-support-178-dal/.

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

Along with the recent release of wolfSSL v4.1.0, wolfSSL has updated its support for the wolfCrypt FIPS Ready version of the wolfSSL library. wolfCrypt FIPS Ready is our FIPS enabled cryptography layer included in the wolfSSL source tree that can be enabled and built. To elaborate on what FIPS Ready really means: you do not get a FIPS certificate and you are not FIPS approved. 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 (POST).

FIPS Ready with curl

(modified from Daniel Stenberg) 

The integration of wolfSSL and curl means that the curl library can also be built using the wolfCrypt FIPS ready library. The following outlines the steps for building curl with FIPS Ready:

1. Download wolfSSL fips ready

2. Unzip the source code somewhere suitable:

$ cd $HOME/src
$ unzip wolfssl-4.1.0-gplv3-fips-ready.zip
$ cd wolfssl-4.1.0-gplv3-fips-ready

3. Build the fips-ready wolfSSL and install it somewhere suitable:

$ ./configure --prefix=$HOME/wolfssl-fips --enable-harden --enable-all
$ make -sj
$ make install

4. Download curl, the normal curl package.

5. Unzip the source code somewhere suitable:

$ cd $HOME/src
$ unzip curl-7.66.0.zip
$ cd curl-7.66.0

6. Build curl with the just recently built and installed FIPS ready wolfSSL version:

$ LD_LIBRARY_PATH=$HOME/wolfssl-fips/lib ./configure --with-wolfssl=$HOME/wolfssl-fips --without-ssl
$ make -sj

7. Now, verify that your new build matches your expectations by:

$ ./src/curl -V

It should show that it uses wolfSSL and that all the protocols and features you want are enabled and present. If not, iterate until it does!

wolfSSL FIPS ready is open source and dual-licensed. More information about building FIPS ready can be found in the FIPS Ready user guide.
More information about wolfSSL and curl can be found on the curl product page.
Details on wolfSSL support for curl is also located on the support page.

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 provides support for various open source projects, including Nginx. For those who are unfamiliar, Nginx is a high-performance, high-concurrency web server. Like wolfSSL, it is also compact, fast, and highly scalable. Additionally, wolfSSL also provides support for TLS 1.3 and features such as OCSP, so Nginx servers can be configured with the latest and most secure protocols.

Nginx and wolfSSL make a likely pairing because they are both lean, compact, fast, and scale well under high volumes of connections. wolfSSL + Nginx is available in a public GitHub repository.  The configure option --enable-nginx will compile the wolfSSL libraries with Nginx support.

wolfSSL also provides FIPS and FIPS ready versions of the wolfCrypt library, meaning Nginx can be built FIPS compliant. More information on wolfCrypt FIPS can be found on the wolfCrypt FIPS FAQ page.

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 wolfMQTT client library has a Microsoft Azure IoT Hub example that demonstrates securely connecting over TLS provided by the wolfSSL embedded SSL/TLS library.

We setup a wolfMQTT IoT Hub on the Azure server for testing. We added a device called `demoDevice`, which you can connect and publish to. The example demonstrates the creation of a SasToken, which is used as the password for the MQTT connect packet. It also shows the topic names for publishing events and listening to `devicebound` messages.

Everyone deserves to have their IoT data secure, and wolfSSL provides the best libraries to accomplish that! Secure-IoT-Love from the wolfSSL team!

You can download the latest release here: https://www.wolfssl.com/download/

Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT

Don’t forget to add a star while you’re there!

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

Is your team looking for a 32-bit MCU that boasts advanced security, performance, and connectivity for your next project in industrial / building automation, automotive or IoT?

Would you like peace of mind knowing that your product solution incorporates the best tested TLS / Cryptography libraries with blazing fast speeds on bare-metal and Amazon FreeRTOS environments?

If so, then check out the embedded-C wolfSSL TLS and wolfCrypt cryptography libraries on the Renesas RA Family of 32-bit MCUs with Arm Cortex-M Core.

wolfSSL is delighted to partner with Renesas to offer examples and solutions for Renesas RA devices.  Quickly get started with a Renesas EK-RA6M3G kit and the wolfSSL example projects.

The team at wolfSSL is excited to help you hit the ground running on your next project. We can also provide additional support through your product development and release cycle. Please feel free to ask us any questions.

More to come…
Progress is being made to support the Renesas RA cryptography accelerators within the wolfCrypt library. The hardware acceleration support will include ECC, RSA, AES, TRNG, and SHA-256 operations with the possibility of more in the future. We will announce support for hardware cryptography and benchmark results soon.

Why wolfSSL?
wolfSSL is a team that has passion and dedication to creating the best supported and best tested secure communication software products with outstanding performance on a host of operating environments.

We want you to focus your product development efforts on your core-features that your customers crave.

wolfSSL ensures peace of mind for your product development team; that their cutting-edge, disruptive innovations won’t be disrupted by malicious hackers.

Allow us to help guide and expedite the necessary process of securing your device and communications.

[wolfSSL General Questions]
Email: facts@wolfssl.com
Phone:  +1 425 245 8247.

[wolfSSL Technical Support]
Email: support@wolfssl.com

[wolfSSL Open Source and Commercial Licensing Questions]
Email: licensing@wolfssl.com

There are many reasons why a user might want to switch from OpenSSL to wolfSSL. In order to facilitate this transition, wolfSSL has an accessible compatibility layer.

Why Migrate?
Why might one want to make this migration and turn on this compatibility in the first place? To start, wolfSSL has numerous benefits over its counterpart, OpenSSL. Some of these include hardware acceleration implementations, progressive adoptions of TLS 1.3 as well as a reduced footprint size. In addition to this, there is the potential to use wolfSSL FIPS. wolfSSL maintains current FIPS support and is used in numerous applications and provides FIPS Ready builds to help get projects ready for FIPS verification. All of this is supported by a team of trained wolfSSL engineers.

What is the wolfSSL OpenSSL compatibility layer?
The wolfSSL OpenSSL compatibility layer is a means to switch applications designed for OpenSSL to wolfSSL. In addition to this, it is constantly expanded with more than 500 commonly used OpenSSL functions. wolfSSL also provides Crypto API support to enable easier migration of projects.

To learn more about migrating from OpenSSL to wolfSSL, visit:
https://www.youtube.com/watch?v=ooom_obeHE8

To read about the OpenSSL compatibility layer, visit:
https://www.wolfssl.com/openssl-compatibility-layer-expansion-3/

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 now supports OpenVPN through the OpenSSL compatibility layer. This support has resulted in an expansion of wolfSSL’s OpenSSL compatibility layer, adding the following API:

• EC_builtin_curve
• EC_get_builtin_curves
• EC_GROUP_order_bits
• DES_check_key_parity
• EVP_CIPHER_CTX_cipher
• EVP_PKEY_get0_EC_KEY
• HMAC_CTX_new
• HMAC_CTX_free
• HMAC_CTX_reset
• HMAC_size
• RSA_meth_new
• RSA_meth_free
• RSA_meth_set_pub_enc
• RSA_meth_set_pub_dec
• RSA_meth_set_priv_enc
• RSA_meth_set_priv_dec
• RSA_meth_set_init
• RSA_meth_set_finish
• RSA_meth_set0_app_data
• RSA_get_method
• RSA_set_method
• RSA_get0_key
• RSA_set0_key
• RSA_flags
• RSA_set_flags
• RSA_bits
• SSL_CTX_set_ciphersuites
• PEM_read_bio_X509_CRL
• PEM_X509_INFO_read_bio
• X509_NAME_get_index_by_OBJ
• BIO_set_ssl
• ASN1_BIT_STRING_new
• ASN1_BIT_STRING_free
• ASN1_BIT_STRING_get_bit
• ASN1_BIT_STRING_set_bit
• sk_ASN1_OBJECT_num
• sk_ASN1_OBJECT_value
• sk_ASN1_OBJECT_free
• sk_ASN1_OBJECT_pop_free
• sk_X509_OBJECT_num
• sk_X509_OBJECT_value
• sk_X509_OBJECT_delete
• sk_X509_NAME_find
• sk_GENERAL_NAME_free
• sk_ACCESS_DESCRIPTION_free
• EVP_MD_CTX_reset
• EVP_MD_name
• EVP_CIPHER_name
• EVP_CIPHER_mode
• EVP_MD_name
• X509_STORE_get0_objects
• X509_OBJECT_free
• X509_OBJECT_get_type
• EVP_CIPHER_nid
• OpenSSL_version

wolfSSL strives to the best-tested SSL/TLS and cryptography implementation available today.  We are happy to bring wolfSSL support to OpenVPN and excited to help users and customers get going quickly.  The wolfSSL lightweight SSL/TLS library supports TLS 1.3, FIPS 140-2, DO-178, and more!

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’s updated support for OpenSSH v8.1 comes new OpenSSL compatibility layer functionality!

The list of API added to the compatibility layer is:

• EVP_CIPHER_CTX_ctrl is expanded to include the following commands:
  • EVP_CTRL_AEAD_SET_IV_FIXED
  • EVP_CTRL_GCM_SET_IV_FIXED
  • EVP_CTRL_GCM_IV_GEN
• BN_clear
• BN_clear_bit
• OpenSSL_version_num
• ERR_GET_LIB
• SSL_CTX_set1_groups_list
• SSL_set1_groups_list

• DSA_SIG support was added:
  • DSA_SIG_new
  • DSA_SIG_free
  • DSA_do_sign
  • DSA_do_verify

• ECDSA_size
• ECDSA_sign
• EC_GROUP_method_of
• EC_METHOD_get_field_type
• EC_POINT_set_affine_coordinates_GFp
• ECPoint_i2d
• ECPoint_d2i
• EC_POINT_point2oct
• EC_POINT_oct2point
• EC_POINT_point2bn

• Added reference counter to RSA structure
  • RSA_up_ref
• RSAPublicKey_dup
• RSA_get_ex_data
• RSA_set_ex_data
• RSA_get_ex_new_index

Changes made and bug fixed:

• EC_POINT_get_affine_coordinates_GFp now checks if internal coordinates are in Jacobian format and converts to affine coordinates when needed
• Singleton allocated by BN_value_one is now freed in wolfSSL_Cleanup
• Entire EVP_CIPHER_CTX and DH structures are now correctly zeroed at initialization
• Improved initialization vector handling in EVP_CipherInit

In addition to the above, there was also some refactorization done on existing OpenSSL compatibility layer code. Functions have been streamlined to allow for easier maintenance and tests added to ensure the correct functionality of the compatibility layer.

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