RECENT BLOG NEWS

wolfTPM is the only TPM 2.0 library designed for baremetal and embedded systems. It also has native Windows and Linux support, alongside a TPM simulator for rapid development and testing.

When it comes to choosing a TPM 2.0 dedicated chip for your project, there are multiple options: Nuvoton NPCT75x, STMicroelectronics ST33, Infineon SLB9670, Microchip ATTPM20P, etc.

Here are our highlights when using ST33 chip with wolfTPM:

• Only wolfTPM supports GPIO control for ST33
  • Depending on the chip variant, a ST33 could offer up to four(4) extra GPIO 
  • The access to these GPIO is protected by the TPM 2.0 authorization
  • Making the GPIO control offered by wolfTPM a great tool for signaling across subsystems for critical, important or security events
  • wolfTPM also provides an open-source example code ready for use

• ST33 has the most Non-volatile memory storage on the market, right now
  • Typically, TPM 2.0 NVRAM storage is limited, this makes ST33  stand out. Multiple certificates and keys can be stored in the ST33 non-volatile memory
  • wolfTPM offers open-source examples on how to securely store secrets and keys in the TPM’s NVRAM

• Using ST33 for Automotive, Industrial, Medical and Aerospace devices with wolfTPM is easy
  • Critical-safety systems often use state machines and RTOS
  • Baremetal and RTOS do not provide driver for TPM 2.0
  • Thanks to wolfTPM’s design, using ST33 without a driver is possible
  • wolfTPM has its own internal TIS layer and direct support for I2C and SPI

• Using ST33 for IoT devices with wolfTPM is highly recommended, because our TPM 2.0 stack is lightweight. In comparison with other libraries, wolfTPM produces 20 times less code and 100 times less memory.
  
• Only ST33 supports AES symmetric operations for encryption and decryption by default, using TPM2_EncryptDecrypt2. Other TPM 2.0 modules support by default only AES CFB for parameter encryption.

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 M1 chip, and with the right options it is blazing fast! We have decided to benchmark our wolfCrypt/wolfSSL libraries on the Apple M1, to show you just how well the the M1 will perform in our standard cryptographic benchmarks.

See below for more details!

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 i.MX RT1060 is a powerful crossover MCU implementation of the Arm Cortex-M7 core, designed and produced by NXP. This MCU contains a TRNG and a data co-processor (DCP). The latter is capable of performing AES encryption and decryption, as well as calculating SHA and SHA256 digest.

Starting from version 4.7.0, wolfSSL provides a port driver that can redirect all the AES and SHA/SHA256 operations to the DCP, which has a number of advantages over the software implementation counterparts, reducing the footprint of the compiled library, improving performance and using less power.

The DCP driver can be enabled via the compile-time flag WOLFSSL_IMXRT_DCP, which delegates all the AES and SHA/SHA256 operations to the hardware co-processor. When this option is enabled, all TLS connections using these algorithms will rely on the hardware to perform the operations.

wolfSSL can also use the TRNG present in this core as an entropy source to seed the DRBG. Support for TRNG on this board can be enabled by adding the compile-time flag FREESCALE_KSDK_2_0_TRNG.

WolfSSL is not the only component in the product family that directly benefits from the presence of these secure elements on this target platform. SSH servers and clients based on wolfSSH will automatically use the accelerators for both SHA and AES when available and compiled in. The port for i.MX-RT1060 of wolfBoot, our secure bootloader, uses the SHA256 hardware acceleration to speed up the verification of the integrity of the firmware image. A full port of wolfBoot for i.MX-RT1060 is available, and its hardware abstraction layer is distributed with wolfBoot since version 1.7.1.

i.MX-RT1060 is a popular choice as edge computing platform, often deployed in combination with a real-time operating system and TCP/IP connectivity. WolfSSL, wolfSSH, wolfBoot and wolfMQTT can be easily added to these scenarios to enable secure communication, secure remote shell and filesystem services, as well as secure boot and remote firmware updates. The extra hardware security provided by DCP and TRNG makes the i.MX-RT1060 a reliable platform to build professional grade security with the latest standards.

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

As some may be aware, wolfSSL added support for strongSwan in April of 2019. The upstream commit can be reviewed here: https://github.com/strongswan/strongswan/pull/133

Users can test the latest development master of wolfSSL with the latest version of strongSwan using the following setup:

wolfSSL Build and Installation Steps

$ git clone https://github.com/wolfSSL/wolfssl.git

$ cd wolfssl
$ ./autogen.sh

$ ./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA"

$ make
$ make check
$ sudo make install

strongSwan Build and Installation Steps

# if the following packages are not already installed:
$ sudo apt-get install flex bison byacc libsoup2.4-dev gperf

$ git clone https://github.com/strongswan/strongswan.git
$ cd strongswan
$ ./autogen.sh

# if packages are missing autogen.sh must be re-run

$ ./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem
$ make
$ make check
$ sudo make install

wolfSSL has had interest in enabling FIPS 140-2/140-3 support with strongSwan so our engineers verified everything is working with the wolfCrypt FIPS 140-2 validated Module!

The steps wolfSSL used for testing are as follows:

Testing was done using the wolfSSL commercial FIPS release v4.7.0 which internally uses the wolfCrypt v4.0.0 FIPS 140-2 validated Crypto Module. It was located in the /home/user-name/Downloads directory on the target test system, Linux 4.15 Ubuntu 18.04 LTS running on Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz.

1. wolfSSL was configured and installed with these settings:

./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA -DFP_MAX_BITS=8192" --enable-ed25519 --enable-curve25519 --enable-fips=v2 --enable-intelasm --prefix=$(pwd)/../fips-install-dir
 make
 make install

2. A custom install location was used which equated to /home/user-name/Downloads/fips-install-dir and the configuration for strongSwan accounted for this.
3. strongSwan was cloned to /home/user-name/Downloads with “git clone https://github.com/strongswan/strongswan.git”
4. StongSwan was configured and installed with these settings:

./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem --prefix=$(pwd)/../strongswan-install-dir wolfssl_CFLAGS="-I$(pwd)/../fips-install-dir/include" wolfssl_LIBS="-L$(pwd)/../fips-install-dir/lib -lwolfssl"
 make
 make install
 make check

5. In the make check stage of the test, it was observed that 1 test was failing.

 Passed 34 of 35 'libstrongswan' suites
 FAIL: libstrongswan_tests
 ==================
 1 of 1 test failed
 ==================

6. Reviewing the logs it was apparent one of the RSA tests was failing.
7. Upon further debugging it turned out the failure was a test in strongSwan that was attempting to create an RSA key size of 1536-bits.

Running case 'generate':
 DEBUG: key_sizes[_i] set to 1024
 + PASS
 DEBUG: key_sizes[_i] set to 1536
 - FAIL
 DEBUG: key_sizes[_i] set to 2048
 + PASS
 DEBUG: key_sizes[_i] set to 3072
 + PASS
 DEBUG: key_sizes[_i] set to 4096
 + PASS

wolfSSL has a function RsaSizeCheck() which in FIPS mode will specifically reject any non FIPS RSA key sizes so this failure was not only expected, but it is a good thing for those wanting to use strongSwan in FIPS mode and ensure only FIPS-validated RSA key sizes will be supported!

wolfSSL is pleased that with the latest release of wolfSSL v4.7.0 and the wolfCrypt FIPS 140-2 module validated on FIPS certificate 3389, strongSwan support is working splendidly and wolfSSL engineers will be making efforts to ensure continued support into the future!

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

At wolfSSL, we have been developing a TPM stack with customers for many years called wolfTPM, a portable, open-source TPM 2.0 stack with backward API compatibility, designed for embedded use. It is highly portable, and has native support for Linux and Windows. RTOS and bare metal environments can take advantage of a single IO callback for SPI hardware interface, no external dependencies, and compact code size with low resource usage.

wolfTPM offers API wrappers to help with complex TPM operations like attestation and examples to help with complex cryptographic processes like the generation of Certificate Signing Request (CSR) using a TPM.

Due to wolfTPM’s portability, it is generally very easy to compile on new platforms.

Here are a few reasons to use wolfTPM over other secure elements:

1) It is based on a widely accepted standard TCG TPM 2.0.

2) There are many chip vendors options and they are pin compatible.

3) Support for RSA. All TPM’s support at least RSA 2048 (the STSAFE and ATECC do not).

4) More NV storage

5) Measured Boot (PCR’s)

6) Advanced Policy management

7) Seal/unseal data based on private key or PCR state.

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

Love it? Star wolfSSL on GitHub.

As a Cybersecurity company we have to make sure all of our products are state of the art. As such we make sure to be proactive, so that our products are always the best they can be. Being an open source company, we like to keep our users, customers, and followers up to date on our successes.  As such, we have compiled an exhaustive list of all of wolfSSL`s current and upcoming firsts.

wolfSSL Current Firsts:

• First Open Source Dual Licensed TLS (GPLv2/Commercial)
• First TLS to adopt fuzz testing; now sporting 7 internal nightly fuzz testers and 2 external fuzz testers
• First TLS 1.2 implementation
• First DTLS 1.2 implementation
• First TLS to support quantum resistant encryption (PQC) …in 2010!  We used NTRU.
• First TLS 1.3 implementation
• First MQTT SN implementation
• First MQTT 5.0 implementation
• First IETF SUIT Secure Boot implementation 
• First TLS 1.3 Sniffer
• First DO 178 DAL A certified crypto library
• First TPM 2.0 stack designed for baremetal and embedded systems – wolfTPM

Upcoming firsts:

• First FIPS 140-3 software library certificate for general purpose use
• First DTLS 1.3 implementation

Users should consider the vibrancy of their TLS provider.  If you want or need the best TLS, then you should look no farther than wolfSSL, the market leader.  Who is winning?  wolfSSL is, that’s who!

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

Love it? Star wolfSSL on GitHub.

As many people know, the OpenSSL project is struggling with FIPS, as of October 2020, OpenSSL has no active FIPS 140 validation. OpenSSL had plans to restore it’s FIPS validation with OpenSSL 3.0, however they ran into significant delays, and since FIPS 140-2 testing ends September 2021, OpenSSL ultimately decided to focus their efforts on FIPS 140-3 standards.

This means that OpenSSL users will not have a supported package for the indefinite future. This is a big issue for companies that rely on security. 

To fill this breach, wolfSSL has integrated our FIPS-certified crypto module (wolfCrypt) with OpenSSL as an OpenSSL engine. This means that:

1. OpenSSL users can get a supported FIPS solution, with packages available up to the 24×7 level,
2. The new wolfCrypt FIPS solution supports algorithms used in TLS 1.3, meaning your OpenSSL-based project can support TLS 1.3,
3. You can support hardware encryption with your project, as the new wolfCrypt solution has full hardware encryption support, as provided by native wolfCrypt!

Additionally, should you be using one of the OpenSSL derivatives like BoringSSL, we can also support you.

wolfEngine is structured as a separate standalone library which links against wolfSSL (libwolfssl) and OpenSSL.  wolfEngine implements and exposes an OpenSSL engine implementation which wraps the wolfCrypt native API internally.  Algorithm support matches that as listed on the wolfCrypt FIPS 140-2 certificate #3389.

wolfEngine is compiled by default as a shared library called libwolfengine which can be dynamically registered at runtime by an application or OpenSSL through a config file.  wolfEngine also provides an entry point for applications to load the engine when compiled in a static build.

The current wolfCrypt FIPS engine for OpenSSL has been tested on Linux with OpenSSL 1.0.2h and 1.1.1b inside OpenSSL apps (s_client, s_server, etc) and several popular Open Source packages – including cURL, stunnel, nginx, OpenLDAP, and OpenSSH!

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

Love it? Star wolfSSL on GitHub.

WolfSSL continues to extend and improve our TPM 2.0 portable library. wolfTPM is the only TPM 2.0 Stack designed for baremetal and embedded systems use.

In just two months we added six new wolfTPM examples. At the end of March, we released wolfTPM version 2.1.0 that added three new examples:

• NVRAM examples
  • Using the TPM as a Secure Storage
  • We now have code samples to demonstrate storing asymmetric or symmetric keys in the TPM’s NVRAM.
  • Our examples use parameter encryption to protect from Man-in-the-middle attacks and the code is open-source.
    
• Symmetric key operations
  • We expanded our open-source TPM key generation example
  • Supported are all symmetric key modes:
    • AES CFB
    • AES CTR
    • AES CBC
  • Also supported are the different symmetric key sizes:
    • 128
    • 196 (depends on the TPM vendor)
    • 256
  • For example, to create a TPM symmetric AES CFB key with 128 bits, it is necessary to just run the following command:
    

    ./examples/keygen/keygen -sym=aescfb128

• STM32CubexMX I2C HAL:
  • Per customer request, we added new HAL IO Callback examples for the popular STM32CubeMX. We already had support for SPI, and now we also support I2C out-of-the-box for STM32CubeMX projects.

We did not stop here; we added three more examples in April and May, that are already available on our GitHub repository, of wolfTPM:

• Seal and Unseal example
  • This is one of the unique capabilities of the TPM 2.0 in contrast with other Secure Elements and Hardware Security Modules. The ability to seal secrets. There are two variants:
    • Seal a secret inside a TPM key
    • Seal a secret against PCR values
  • We now have an example on how to seal and unseal a secret from a TPM key. 
  • This provides Secure Storage for sensitive data, because TPM keys can only be loaded by the TPM chip.
    
• Extra GPIO Support
  • Per customer request, we added support for configuring the available TPM GPIO that the user can control. These GPIO are useful to signal security events, because the access to them is protected using TPM authorization.
    
• Remote Attestation examples
  • Remote Attestation is another unique capability that is enabled when using a TPM. Often, this process is specific to the needs of the customer. However, there are common elements and we added examples for these parts of the Remote Attestation process.
  • We added code examples of how to perform Make and Activate Credential to establish the initial trust between systems for Remote Attestation.

This way wolfTPM now has over 20 examples on how to use TPM 2.0. The code of our examples is open-source and can be accessed directly on our GitHub repository of wolfTPM.

Additional information on wolfTPM can be found on the wolfTPM product 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.

Love it? Star wolfSSL on GitHub.

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/

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.