Category: Uncategorized

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.

What is CT (Certificate Transparency)? 

Certificate Transparency is from RFC 6962 and is an extension on certificates to create a Merkle Tree (hash tree like with blockchain). The purpose of the tree is to help spot misuses of certificates and to provide a public way to audit the log of certificates issued. It was first implemented by Google in 2013 and required by google in 2017 which was then pushed back to 2018. Google has now been requiring all new certificates that are issued to have CT. The SCT (signed certificate timestamp) for CT can be sent in a TLS extension too, or with OCSP.

This is something we are thinking of adding to our library just to make it easier for users to parse out the information and view it with wolfSSL. Currently, users can get the extension by getting the peer certificate after a connection is complete and using one of the available checkers (google/cloudflare have checkers). It obviously gets more involved if adding the TLS extension (signed_certificate_timestamp) or if implementing a Monitor (application that goes out and does the audit on the certificate).

What are we doing about it?

To make this process easier we are planning on leaving it up to the certificate to contain the SCT and parse it from there.

To get there we are planing on making sure it includes:

– API to get the certificate extension information (people using this will want the hash / signature / timestamp to perform an audit on certificates)

– Checks on the timestamp (must be rejected by client if it is in the future)

– Code in our certificate extension parsing to read the OIDs and store the hash / signature / timestamp

– Testing and documentation (more time on testing since affecting certificate parsing code)

Love it? Star wolfSSL on GitHub.

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

If you pop over to the OpenWrt project site, you’ll stumble upon some excellent news:

“TLS support is now provided by default in OpenWrt images including the trusted CA certificates from Mozilla. It means that wget and opkg now support fetching resources over HTTPS out-of-the-box. The opkg download server is accessed through HTTPS by default. OpenWrt switched from mbed TLS to wolfSSL as the default SSL library, mbed TLS and OpenSSL are still available and can be installed manually.”

This means OpenWrt users can easily benefit from everything keeping wolfSSL ahead of the pack, including our early adoption of TLS 1.3 for top-tier security, uncompromised performance benchmarks, and certifications such as FIPS 140-2 and 3. Learn more about wolfSSL’s advantages over OpenSSL and write to us (facts at wolfSSL.com) to tell us about your OpenWrt projects with wolfSSL!

Love it? Star wolfSSL on GitHub.

Find the OpenWrt announcement 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 acronym CAAM stands for Cryptographic Accelerator and Assurance Module. It is hardware that can be found on many i.MX NXP devices. When used it speeds up the cryptographic algorithms such as ECC and AES. In addition to the performance gained with using the CAAM for cryptographic operations, the application can also increase security by using encrypted keys and secure memory partitions with the CAAM. When describing the keys and blobs used with the CAAM, the term black keys and blobs are used to describe when the key has been encrypted by the hardware. Red keys refer to when a key has not been encrypted and is still in plain text.

wolfSSL has support for the CAAM driver with many IoT OS’s and embedded i.MX devices. Support for additional algorithms, devices and OS’s is continuously being added. There is also support by request if a project calls for something not already implemented or in progress.

What is currently supported in wolfSSL:

OS: QNX (using wolfSSL QNX CAAM driver)
Operations Supported:
– ECC (sign/verify/ecdh), with and without encrypted black keys
– AES-CMAC
– BLOB (red and black)
– TRNG
Notes: Developed on i.MX6 UL

OS: GreenHills Integrity (using wolfSSL CAAM driver)
Operations Supported:
– AES (CCM, ECB, CBC, CTR)
– MD5
– SHA1, SHA224, SHA256
– TRNG
– BLOB (red)
Notes: Developed on i.MX6 Dual/Quad/Solo series

OS: Embedded Linux (using third party cryptodev-linux or af-alg)
Operations Supported:
– AES (ECB, CBC, GCM)
– SHA256

Benchmarks using the CAAM with wolfSSL can be found on the benchmark page located here (https://www.wolfssl.com/docs/benchmarks/).

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 embedded systems community has long sought a top quality, super flexible, made-with-love IDPS. Today, wolfSSL answers the call, with our first preview release of wolfSentry, the IDPS (Intrusion Detection and Prevention System) for embedded and IoT systems.

Included in this preview are

• Support for Linux, BSD, MacOS X, and Deos, on 32 and 64 bit x86 and PPC targets.
• Programmatic insertion, deletion, and enumeration of static firewall rules.
• Evaluation of static firewall rules, with prefix and wildcard matching, enabling basic application call-ins.
• Integration into wolfSSL, using a new --enable-wolfsentry option, demonstrating simple pre-negotiation filtering of new connections.

Because this is a preview release, many capabilities are only partially implemented. Configuration and querying by textual blobs, dynamic defenses, plugin actions, and thread safety, are coming soon.

Follow this blog and our GitHub for the latest, as we will make quick work of these features!

Also coming soon is support for more target ecosystems, including AUTOSAR, FreeRTOS, VxWorks, QNX and other key embedded environments.

We particularly seek to enable researchers with this release. Let us know what you think, or ask us about our plans, and we’ll respond. We want wolfSentry to be fully vetted by the best in the OSS community.

Download wolfSentry now from https://github.com/wolfSSL/wolfsentry, and tell us what your IDPS priorities are!

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)

Friends of mine know that I’ve tried for a long time to get confirmation that curl is used in space. We’ve believed it to be likely but I’ve wanted to get a clear confirmation that this is indeed the fact.

Today GitHub posted their article about open source in the Mars mission, and they now provide a badge on their site for contributors of projects that are used in that mission.

I have one of those badges now. Only a few other of the current 879 recorded curl authors got it. Which seems to be due to them using a very old curl release (curl 7.19, released in September 2008) and they couldn’t match all contributors with emails or the authors didn’t have their emails verified on GitHub etc.

According to that GitHub blog post, we are “almost 12,000” developers who got it.

While this strictly speaking doesn’t say that curl is actually used in space, I think it can probably be assumed to be.

Here’s the interplanetary curl development displayed in a single graph:

See also: screenshotted curl credits and curl supports NASA.

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 our new release of wolfSentry people might wonder how it compares to Suricata. Suricata is an open source IDS / IPS / NSM engine. While it seems that Suricata is in rivalry with wolfSentry, our embedded IDPS; they actually have a synergy, it would make sense for sophisticated users to deploy both of them.

Suricata:

• The distribution tarball is 29 MB
• The build tree with minimal featureset is 536 MB
• The binary installation image is 35 MB, of which 34.5 MB is the Suricata binary executable (dynamically linked)
• The main executable depends on 18 special purpose libraries not included in the distribution.
• Suricata depends on Python
• It only runs on Unix-like and Windows OSs, and its firewalling (host protection) depends on host OS facilities.

Suricata is a heavyweight, infrastructural IDS platform.  It has to duplicate the logic, and a lot of the processing, of the protocols/libraries/applications that it is monitoring and protecting.

Suricata can do a lot of powerful things, including protecting endpoints that can’t protect themselves, and protecting endpoints before they’re attacked, by blocking bad actors at the first opportunity, when they’ve only had time to attack a first protected endpoint.

wolfSentry

By comparison, wolfSentry has a much smaller footprint. 

• The distribution tarball is 36 K.
• The build tree is 2.5 MB, with all features and debugging symbols enabled.
• libwolfsentry.a is 339 K, and the biggest example executable is 443 K, or 84 K stripped, and uses no libraries beyond libc (which it barely uses).
• It is designed to integrate directly with network-facing applications/libraries to block bad traffic, and it can optionally integrate with host firewall facilities, via plugins.
• It can run on bare metal, in which case the firewall functions can be directly integrated into the network stack of the application.

wolfSentry isn’t infrastructural, it’s on the endpoints, and it’s intended to be integrated with the endpoint applications/libraries to leverage them to the fullest.

Comparison and Synergy

The synergy between wolfSentry and Suricata infrastructural IDPSs is to have wolfSentry (via a plugin) notify the external IDPS when it detects bad traffic that the external IDPS might not be able to detect.  This can enable clever stuff like blocking the bad traffic inside the network, before it even reaches the endpoint, and of course blocking the bad traffic for all the protected endpoints at once.

This raises an obvious worry about Suricata being compromised, because by nature it is directly exposed to the network, and is highly privileged.  Suricata addresses this by doing lots of fuzz testing etc. to build confidence.  However, because they have a 29 MB distribution tarball, there is a higher likelihood for things to fall through the cracks.

An advantage of wolfSentry is wolfSentry doesn’t require the endpoint to trust anyone else, nor anyone else to trust the endpoint.  It’s a freestanding, high-efficiency self-defense system.

Ultimately, while there are some comparisons and different uses between the two, the best course of action would be to use wolfSentry and Suricata together for the best secure IDPS.

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