Month: February 2020

We often get questions from users of the wolfSSL embedded SSL/TLS library about which certs to load and why. So today we wanted to discuss the following topics:

1. What is a cert chain as seen in a common browser?
2. What is a public key, what is a private key?
3. What is the chain of trust and why is it “trustworthy”?
4. How does one know which certs to load into their application?

What is a cert chain as seen in a common browser?

When we go to a website like www.google.com we see a little green lock that shows it provides security. If we investigate a little further by clicking on that little green lock we might see something like this:

What does each of these items mean? What is “GlobalSign”, what is “GTS CA 101”, and what is “*.google.com”? Well let’s break it down:

• *.google.com (Bottom of the chain) – This is the certificate that has been issued for any domain ending in “google.com”.
• GTS CA 101 (Second cert from the bottom) – This is an intermediate CA certificate (we’ll go more into why an intermediate is necessary in the chain of trust below)
• GlobalSign (The top level cert seen in the browser) – This can be any number of things, depending on the website you are connecting to, this might be another intermediate CA that signed the first intermediate CA. This might be a self-signed root certificate. This could also be a self-signed root CA that is cross-signed. (We’ll cover cross-signing below)

What is a public key, what is a private key?

Certificates contain public keys. Public keys are designed to be distributed. Anyone can have a copy of the public key and all certs contain a copy of the public key that is associated mathematically with their private key. Public keys can not be used to derive the private key. Think of a public key as `the Flour in a cooking recipe. You can have bleached white wheat flour (RSA), whole wheat flour (ECC), or maybe Cornmeal Flour (PSK). So we can tell what kind of flour we have great! But we can’t tell if the flour was used in a pancake, or a muffin, or bread, in other words we are given access to the flour (the public key) but we can’t derive what the private key is simply by knowing the type of flour that was used, the private key has other ingredients we don’t have access to so we can’t derive the private key from the public key. Traditionally public keys are used to “verify” things that have been signed by their corresponding private key. There are cases where a public key can also be used to sign and the private key used to verify that signature.

So why bother going into the details of the keys? Well let’s get back to certs:

The entity certificate (*.google.com) uses the private key it is associated with to sign and verify things during a TLS connection so a copy of that private key has to be present on every server using this cert. So why don’t we just trust this cert? The answer is it can not truly be trusted stand alone, since the private key associated with that certificate is too commonly distributed to be trustworthy all on it’s own. Imagine if just one of the thousands of Google servers became compromised somehow and someone was able to steal the private key for the cert that works on any Google server? Now that bad-actor could start making their own certs using the private key for *.google.com and standing up malicious servers like supertrustyserver.google.com and your browser would automatically trust it if said actor can get you to click on a link that leads to his server, you would just think you are on google.com but the bad actor might be logging everything you enter in the browser while you’re using his server or trying to get your browser to launch scripts in the background that do any manner of things etc. Not a good situation. So to avoid this kind of compromise a need to establish a “chain of trust” was deemed necessary in the early days of the Internet.

What is the chain of trust and why is it “trustworthy”?

With each certificate higher in the chain of trust, theoretically the private key for that cert is more difficult to obtain and the probability of that private key becoming compromised is reduced. The less likely a private key is to be stolen, the more trustworthy it becomes. Private keys associated with Root CA’s being theoretically impossible to steal with rigorous oversight and audit from both government and private sector entities. Private keys for Root CA’s are never supposed to come in contact with the Internet (strictly offline use) and are only accessed in a secure room by a select few individuals.

So the process for creating a chain of trust goes:

1. CA_ROOT_PRIVATE_KEY created in a clean room on a disconnected computer. CA_ROOT_CERTIFICATE created with the private key and signed by the private key (self-signed certificate). Just the CA_ROOT_CERTIFICATE, not the private key, will later be transferred to a connected system from where it can be disseminated to all browser manufacturers for trusting (Chrome, Firefox, Explorer, Safari, Netscape, DuckDuckGo, … etc)).
2. INTERMEDIATE_CA_PRIVATE_KEY created safely (probably a similar process to how the CA_ROOT_PRIVATE_KEY is created in step 1, INTERMEDIATE_CA_CERTIFICATE created FROM INTERMEDIATE_CA_PRIVATE_KEY and signed by CA_ROOT_PRIVATE_KEY.
3. CA_ROOT_PRIVATE_KEY securly stored (subject to oversight) and lock it up never to be touched again except in the event the CA_ROOT_CERTIFICATE is about to expire and needs updated or a new intermediate CA needs to be signed after creation.
4. Distribute the INTERMEDIATE_CA_PRIVATE_KEY for use by employees of the CA organization. This INTERMEDIATE_CA_PRIVATE_KEY is used only by employees of the CA organization at their work stations.
5. Company like Google creates a LEAF_PRIVATE_KEY for their own use and uses that LEAF_PRIVATE_KEY to generate a “Certificate Signing Request”, CSR for short, which they will send to a CA Authority to get a signed and trusted LEAF_CERTIFICATE.
6. Employees of the CA organization receive a Certificate Signing Request (CSR) from a company like Google that wants to have a website google.com be trusted. The certificate signing request tells the CA organization all the specifics of what the LEAF_CERTIFICATE should have in it and what its’ use will be.
7. CA organization employees use the information in the CSR to generate a brand new LEAF_CERTIFICATE and sign that certificate with the INTERMEDIATE_CA_PRIVATE_KEY they have access to.
8. CA organization sends a copy of the INTERMEDIATE_CA_CERTIFICATE and the newly generated LEAF_CERTIFICATE to the requesting organization (in this case Google).

Notice the private keys in this process were never sent over the Internet in any way. Google generated its own LEAF_PRIVATE_KEY but only sent the CSR to the CA. The CA generated all their own private keys and only used them to sign other things but the private keys never left the CA organization. So far so good, none of the private keys have been sent over the Internet (no possibility of being intercepted) and now all the certificates are signed and ready for use. The browsers have received copies of the CA_ROOT_CERTIFICATE that is self signed by a theoretically un-stealable private key. We have a copy of the INTERMEDIATE_CA_CERTIFICATE that is signed by the CA_ROOT_PRIVATE_KEY and we have the newly generated google.com LEAF_CERTIFICATE that is signed by the INTERMEDIATE_CA_PRIVATE_KEY.

Now when we connect to google.com and it signs something with it’s private key we can decide if we trust that signature by testing:

Do we trust this signature from google.com? Don’t know,
Do we trust the google.com LEAF_CERTIFICATE? Don’t know,
Do we trust the INTERMEDIATE_CA_CERTIFICATE? Don’t know,
Do we trust the CA_ROOT_CERTIFICATE? YES!

Since we trust the CA_ROOT_CERTIFICATE and the CA_ROOT_PRIVATE_KEY signed the intermediate CA.. Now can we trust the INTERMEDIATE_CA_CERTIFICATE? YES!

OK and if we trust the INTERMEDIATE_CA_CERTIFICATE and its INTERMEDIATE_CA_PRIVATE_KEY signed the google.com LEAF_CERTIFICATE… Now can we trust google.com LEAF_CERTIFICATE? YES!

Finally since we trust the google.com LEAF_CERTIFICATE now we know we can trust things signed by the LEAF_PRIVATE_KEY associated with that LEAF_CERTIFICATE!

That is the chain of trust.

How does one know which certs to load into their application?

In most cases all that needs to be loaded in your client applications is the CA_ROOT_CERTIFICATE. The RFC for certificate distribution by servers says “Servers MUST send their entire cert chain with the only optional cert being the ROOT CA”. Browsers and clients are already expected to have a copy of the root CA available so the servers do not have to send that during a TLS connection. HOWEVER… and here’s the catch, not all servers follow the spec. When this happens then it falls to the client to track down the cert that signed the last cert in the chain that the server did send and load that cert, and any other certs in the chain of trust up to and including the Root CA.

If you are having issues loading the correct CA certificate into your application, contact us at support@wolfssl.com and we can  help you find the right ones!  wolfSSL also supports TLS 1.3, FIPS 140-2, and DO-178!

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

For more information, please contact facts@wolfssl.com.

 

 

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.

For more information regarding wolfSSL, wolfCrypt, cURL, support packages, or any additional questions, please contact facts@wolfssl.com.

 

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.

For more information on wolfSSL + Nginx, TLS 1.3, OCSP, FIPS, or for any additional questions, contact facts@wolfssl.com.

Online Certificate Status Protocol or OCSP is an Internet protocol that is used to obtain the revocation status of an X.509 digital certificate. An OCSP client will send a status request to an OCSP responder and receive information if the certificate is valid or revoked. A good response shows that the certificate is valid and not revoked. Messages communicated via OCSP are encoded in ASN.1, a set of notations that describe rules and structures in telecommunications and networking, and are usually communicated over HTTP. The OCSP servers are called OCSP responders because of the request/response nature of the transmission between them and the client.

It was created as an alternative to Certificate Revocation Lists (CLR) for maintaining the security of servers and other network resources. It hoped to address certain problems regarding the use of CRLs in public key infrastructure (PKI). OCSP has many advantages over CRL. It overcomes CRL’s prime limitation: the fact that frequent downloads are required to keep things current at the client’s side. OCSP also can provide more timely information regarding the revocation status of a certificate. It also removes the need for clients to retrieve the CRL themselves (better bandwidth management), as well as the fact that OCSP allows users with an expired certificate a grace period (decreasing any downtime with expired certificates).

For this exact reason we added OCSP as a wolfSSL feature back in 2011. In our new release wolfSSL 4.3.0 we have added additional sanity check on OCSP response decoders.

If you have questions about our OCSP support, email us at facts@wolfssl.com.  wolfSSL supports TLS 1.3, FIPS 140-2, DO-178, and more!

We love you,
wolfSSL Team

Are you a MSU Bozeman student interested in the field of Internet security?  If so, wolfSSL will be holding an info session this upcoming Thursday (2/13/2020) at Montana State University in Bozeman, MT!  This info session will introduce wolfSSL as a company, including background information, products, work environment, and summer internship opportunities.  It will also touch on new technologies, such as TLS 1.3!

wolfSSL is an open source Internet security company focused on securing connected devices and applications worldwide!  wolfSSL products include the wolfSSL lightweight SSL/TLS library, wolfCrypt cryptography library, wolfSSH SSH library, wolfMQTT, wolfTPM, and more!

We encourage all students who are interested in Internet security, SSL/TLS, cryptography, embedded security, or software development to attend! Pizza will be served!

wolfSSL Info Session
Thursday, February 13, 2020
Norm Asbjornson Hall, room 149
Montana State University, Bozeman

We look forward to seeing you there! Please contact chris@wolfssl.com with any questions or for more information. To learn more about the wolfSSL lightweight SSL/TLS library, visit our product page or GitHub repository today!

In the latest wolfSSL releases, we have added 200+ new API to our OpenSSL compatibility layer. Many of these new API were added for providing support for Apache HTTP Server.

We are excited to announce that as of version 4.3.0, wolfSSL provides support for the Apache web server with the enable option –enable-apachehttpd.  This means you can now build Apache with the latest, most robust security provided by the wolfSSL SSL/TLS and wolfCrypt libraries.  wolfSSL supports TLS 1.3, FIPS 14-2, DO-178, and more!

If you are interested in building Apache httpd with wolfSSL, please contact us at facts@wolfssl.com for a version of Apache that is compatible.

For comparison between wolfSSL and OpenSSL, visit https://www.wolfssl.com/docs/wolfssl-openssl/.

We love you,
wolfSSL Team

When developing an application that needs to communicate securely with another device TLS is a great option. The framework in place for TLS connections with JAVA is JSSE (Java Secure Socket Extension). JSSE is a set of interfaces that can be called to abstract the TLS process and make it easy for plugging in different security providers while keeping an application unchanged after initial integration. wolfJSSE is an open source implementation of these interfaces that uses the embedded IoT wolfSSL library for it’s cryptography operations. There are many ways to interact with JSSE when adding in security, two of the common ways are with creating a SSL socket or by creating a SSL engine. A simple example of creating and using SSL sockets for both the client and server side can be found in the “examples/provider” directory on the wolfssljni repository located here (https://github.com/wolfSSL/wolfssljni). In addition to interacting with JSSE directly there are packages in JAVA that use it. One such package deals with URL connections and can be used for creating HTTPS connections. An example of a simple HTTPS connection using it can be found in the “java” directory of the wolfSSL examples repository (https://github.com/wolfSSL/wolfssl-examples).

For questions about the use of wolfJSSE, or the wolfSSL lightweight SSL/TLS library, contact facts@wolfssl.com.

The NXP Memory-Mapped Cryptographic Acceleration Unit (mmCAU) is on many Kinetis microcontrollers. It improves symmetric AES and SHA performance as compared to our software based implementation. wolfSSL version 4.2.0 enhanced mmCAU support to use multiple blocks against hardware and optimize to avoid memory copies (memcpy) when possible. This resulted in a 20-78% improvement in performance!

Features:

• Enhancement for NXP mmCAU to process more than one block at a time.
• Added optional buffer alignment detection macro, WC_HASH_DATA_ALIGNMENT, to avoid memcpy.
• Added MD5 and SHA-1 support for XTRANSFORM_LEN to process blocks.
• Cleanups for consistency between algorithms and code commenting.

Improved MMCAU performance: SHA-1 by 35%, SHA-256 by 20% and MD5 by 78%.

NXP K64 MMCAU with wolfSSL v4.2.0:

MD5 8 MB took 1.000 seconds, 7.910 MB/s
SHA 4 MB took 1.005 seconds, 3.644 MB/s
SHA-256 2 MB took 1.006 seconds, 2.306 MB/s

NXP K64 MMCAU with wolfSSL v4.1.0:

MD5 4 MB took 1.004 seconds, 4.450 MB/s
SHA 3 MB took 1.006 seconds, 2.670 MB/s
SHA-256 2 MB took 1.008 seconds, 1.913 MB/s

Changes are in GitHub pull request #2481 and in the wolfSSL v4.3.0 release.
For more information please email us at facts@wolfssl.com.

We love you,
wolfSSL Team

We have added many new features in our new release of wolfSSL 4.3.0. One new feature we have added is a CMS/PKCS #7 callback for signing SignedData raw digests – enabled with the macro HAVE_PKCS7_RSA_RAW_SIGN_CALLBACK and call to function wc_PKCS7_SetRsaSignRawDigestCb().

For those who are unaware PKCS #7 is used to sign and/or encrypt messages under a PKI. Used also for certificate dissemination (for instance as a response to a PKCS #10 message), it formed the basis for S/MIME, which is as of 2010 based on RFC 5652, an updated Cryptographic Message Syntax Standard (CMS). Often used for single sign-on.

For more information on wolfSSL, PKCS #7, TLS 1.3, OCSP, FIPS, or for any additional questions, contact facts@wolfssl.com or support@wolfssl.com!

We love you.

Team wolfSSL