RECENT BLOG NEWS

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/

For more information about the OpenSSL compatibility layer or the wolfSSL embedded SSL/TLS library, contact us today at facts@wolfssl.com!

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!  Contact us at facts@wolfssl.com with any questions or feedback.

wolfSSL will be exhibiting at the Embedded World conference again this year in Nuremberg, Germany! With over 1,100 exhibitors, the Embedded World conference focuses on all things related to embedded systems, offering the embedded community the opportunity to obtain information about new products and innovations, enter into an exchange, and to maintain and develop valuable contacts.

wolfSSL will be located in booth 4-421, specifically:

Hall: Hall 4
Booth #: 4-421
When: February 25-27, 2020

Stop by our booth hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, wolfSSH, wolfBoot, and wolfTPM. Learn about our new progress in the last year with TLS 1.3, FIPS 140-2, DO-178, secure boot and more! This is also a good opportunity to meet the wolfSSL team, ask your questions, and get some free stickers and swag!

For more information about wolfSSL, our products, and future events, please contact facts@wolfssl.com.

wolfSSL will be exhibiting at the RSA Conference again this year in San Francisco, CA! With over 500 sessions scheduled and 650 exhibitors, RSA Conference 2020 brings together the world’s top cybersecurity professionals and business leaders to discuss emerging trends and formulate the best strategies for tackling current and future threats.

wolfSSL will be located in booth 6371, specifically:

Building: North Hall
Booth #: 6371
When: February 24-28, 2020

Stop by our booth hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, wolfSSH, wolfBoot, and wolfTPM.  Learn about our new progress in the last year with TLS 1.3, FIPS 140-2, DO-178, secure boot and more!  This is also a good opportunity to meet the wolfSSL team, ask your questions, and get some free stickers and swag!

For more information about wolfSSL, our products, and future events, please contact facts@wolfssl.com.

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.  Contact us at facts@wolfssl.com with any questions about the wolfSSL embedded SSL/TLS library.  wolfSSL supports TLS 1.3, FIPS 140-2, DO-178, and more!

Do you need SSH support for an embedded device running VxWorks and you have a FIPS 140-2 requirement? wolfSSL has what you need: wolfSSH, an embedded SSH library running on top of our wolfCrypt FIPS library with support for VxWorks. Email us today at fips@wolfssl.com and we will help you integrate wolfSSH into your VxWorks application and walk you through the FIPS process.

#wolfssh #fips #vxworks

The performance of public key algorithms regularly comes up with customers – they are after all the most costly operations.
wolfSSL has you covered with the Single Precision (SP) big number maths library that brings you the best implementations.
But how does it compare to OpenSSL?

Intel x86 64-bit assembly optimised implementations are as fast or faster than OpenSSL for RSA 2048-bit, EC P-256 and X25519.
One major drawback with OpenSSL is the lack of choice if not using assembly code. The C code is significantly slower, especially the elliptic curve operations which can be 15-40 times slower!
wolfSSL has the option to compile in optimised C code. This code is significantly faster and can be configured to meet your resource profile. Lots of memory, the default build is optimised for maximum speed and handily beats OpenSSL C code. Not so much memory, try the small build, it has similar performance to OpensSSL but half the size!

If you don’t have space for specialised code then good news is coming! Later this year a new implementation of MP, our big number math API, will be released that will be faster than the OpenSSL C code and it’s still smaller.

Contact us at facts@wolfssl.com or support@wolfssl.com if you would like to learn more!

We can give you the performance you need and we want to help you!

Team wolfSSL

wolfSSL is looking for a high-energy, motivated individual to drive sales and impact revenue growth in the Midwest region. The primary goal of the Midwest Sales Director is to expand our customer base and grow current customers into larger accounts. This position is remote, preferably close to a major hub such as Chicago, Detroit, Dallas or Austin. You will travel at least once a month to customer meetings, industry meet-ups and relevant conferences (more if you like or if needed for prospective client opportunities).

Responsibilities

• Must be a winner with a great attitude
• Develop and implement sales strategies
• Directly coordinate cross-selling and joint marketing initiatives to maximize exposure and profitability

Qualifications

• Self-motivated, driven and persistent work-ethic
• Excellent written and verbal communication skills
• 5+ years’ software sales experience
• Ability to exercise decisive, agile thinking in a fast-paced industry

Please email facts@wolfssl.com to learn more and apply today!

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 flower we have great! But we can’t tell if the flower was used in a pancake, or a muffin, or bread, in other words we are given access to the flower (the public key) but we can’t derive what the private key is simply by knowing the type of flower 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!