wolfSSL Support’s Has Speedy Response Times 

wolfSSL provides the most secure embedded SSL/TLS libraries. Our products are run by high-powered, lightweight encryption engines for maximum efficiency and speed. But in the case that a client’s needs are not met, our products are followed by an exceptional support team. 

We have established a channel to hear questions or concerns through support@wolfssl.com. On this platform, we receive over 1400 support inquiries throughout the year that range from simple logistical procedures such as certificate signings to more complex issues users may have such as RSA operations assistance, optimizing performance or build size and more. Upon receiving an inquiry, the appropriate members of the wolfSSL support team are contacted for personal consultation. Instead of forwarding your concerns to a call center where information is ambiguous and answers can be nebulous, we pair you up with individuals who are specialized in your specific area of concern, all of whom have directly contributed to the product itself. Our clients  have their questions answered to the full extent by professionals who understand the product and can explain the process in a concise, cohesive, and intuitive manner.

The speed of wolfSSL support is reflected by the speed of our technologies. On average, our support inquiries are resolved in less than 2 hours. With our premium support package, many wolfSSL support tickets are resolved in under 30 minutes, due to our emphasis on timeliness and getting you connected to the right person. Our fast turnaround times are incredibly beneficial in high-pressure environments and time-sensitive projects.  We offer the type of support that lets you quickly get to a resolution and gets your focus back on your project.

wolfSSL Support is offered at four levels. Depending on the coverage needed, there is a tailored package for you. More details on our packages can be viewed on wolfSSL’s support options page at www.wolfssl.com/products/support-packages/.

To have your own questions answered, or to obtain support for wolfSSL, please contact support@wolfssl.com. Additionally, other general information about the wolfSSL library can be obtained by contacting facts@wolfssl.com.

wolfSSL also supports TLS 1.3! More information can be viewed here: https://www.wolfssl.com/docs/tls13/.

wolfSSL Renesas TSIP Support

The wolfSSL embedded SSL/TLS library supports the Renesas Trusted Secure IP Driver (TSIP) and has been tested on the Renesas RX65N platform.  Using the TSIP driver, wolfSSL can offload supported cryptographic and TLS operations to the underlying Renesas hardware for increased performance.


Supported TSIP Capabilities

wolfSSL has been integrated with the following TSIP capabilities:

  • TSIP driver open/close
  • Random number generation, tested with SP 800-22
  • SHA-1 and SHA-256 hash function support
  • AES-128-CBC and AES-256-CBC support
  • TLS capabilities including:
    • Root CA verification
    • Client and/or Server certificate verification including intermediate certificate verification
    • Support for four TLS cipher suites:
      • TLS_RSA_WITH_AES_128_CBC_SHA256
      • TLS_RSA_WITH_AES_256_CBC_SHA256

FunctionTSIP API
TSIP driver open/closeR_TSIP_Open
Random Number GenerationR_TSIP_GenerateRandomNumber
SHA-1 and SHA-256R_TSIP_Sha1/256Init
AES-128-CBC and AES-256-CBCR_TSIP_Aes128/256CbcEncryptInit
Root CA VerificationR_TSIP_GenerateTlsRsaPublicKeyIndex
Client or Server Certificate VerificationR_TSIP_TlsCertificateVerification
TLS cipher suite support including AES-128-CBC, AES-256-CBCR_TSIP_TlsGeneratePreMasterSecret

The Renesas TSIP driver is outside the scope of the wolfSSL package download and needs to be obtained externally from Renesas.


Building wolfSSL with RX65N and TSIP Support

Support for Renesas RX65N and TSIP can be enabled at compile-time in wolfSSL by defining one or both of the following defines:

WOLFSSL_RENESAS_TSIP – enables Renesas TSIP support

WOLFSSL_RENESAS_RX65N – enables support for Renesas RX65N


wolfSSL TSIP Benchmarks

The following benchmarks show the performance improvement when using hardware cryptography on the Renesas RX65N through the Renesas TSIP driver.

AlgorithmSoftware CryptoTSIP Accelerated Crypto
RNG231.160 KB/s1.423 MB/s
SHA1.239 MB/s22.254 MB/s
SHA-256515.565 KB/s25.217 MB/s

Cipher SuiteSoftware Crypto (sec)TSIP Accelerated Crypto (sec)


Our tests have shown that the implementation of TSIP Accelerated Crypto increased processing speed by an average of 2334%, resulting in 92% faster processing times.


Limitations of TSIP with wolfSSL

The following limitations exist when using wolfSSL with Renesas TSIP:

  • TSIP TLS capabilities are fully available only when using one of the TSIP-supported cipher suites.  These cipher suites include:
  • The TSIP TLS capabilities support generation of the normal TLS master secret, but do not support the TLS Extended Master Secret Extension.  TSIP TLS is not available when Extended Master Secret is used.
  • The TSIP TLS certificate verification capability is only available when verifying a certificate signed by “RSA 2048 PSS with SHA-256”.
  • The TSIP TLS capability, common cryptography, is available on client-side only.  Server-side is not currently supported by the TSIP driver.
  • TSIP uses one root CA certificate bundle signature signed by RSA-2048-PSS with SHA-256 available at runtime. When using a different root CA for TSIP TLS capabilities, applications need to call wolfCrypt_Init() to reset the TSIP driver state, then inform TSIP of a new signature and key through the tsip_inform_cert_sign() and tsip_inform_user_keys() APIs.



TSIP (Trusted Secure IP) Module Firmware Integration Technology APPLICATION NOTE Rev. 1.06

TSIP Product Page



More information on using wolfSSL in combination with Renesas and wolfSSL’s support for Renesas can be found here: https://www.wolfssl.com/docs/renesas/

For support and more information about wolfSSL TSIP support, please contact the wolfSSL support team at support@wolfssl.com.

wolfCrypt FIPS 140-3 Update

HI! We have been industrious in moving forward with our FIPS 140-3 efforts! Here’s where we are at now:

  1. We are in the Implementation Under Test part of the NIST process. You can see from the list: https://csrc.nist.gov/projects/cryptographic-module-validation-program/modules-in-process/iut-list that wolfSSL, Apple, and Intel are leading the FIPS 140-3 charge!
  2. NEW AND COOL: RSA 4096 will be inside of our FIPS 140-3 boundary. More bit strength, more security!
  3. NEW AND COOL: ECDSA with SHA-3 will be inside the FIPS 140-3 boundary! Let’s all welcome SHA-3 to the FIPS universe!
  4. Timelines: We have now iterated with our lab a few times, and are approaching completion of all of our pre-lab work. Once the pre-lab work is completed in the next month or so, the Lab’s work begins in earnest, followed by NIST reviews.

We will not be able to get you a FIPS 140-3 wolfCrypt for Christmas this year, due to a little waiting we are doing on ACVP and IG’s, but we endeavor to lead the market with the freshest FIPS code! If everything stays on track, wolfCrypt will be the first general purpose cryptography library to complete FIPS 140-3 testing! Contact us at facts@wolfssl.com with any questions.

Your partners in the best and most progressive FIPS solutions,

Team wolfSSL

What is the difference between SSL and TLS?

This week we are tackling a new series of blog posts on the hottest topics! 

This week’s question is: What is the difference between SSL and TLS? 

TLS stands for Transport Layer Security. On the other hand, SSL stands for Secure Sockets Layer. It is important to note that SSL 2.0 and 3.0 have been deprecated by the Internet Engineering Task Force (IETF) in 2011 and 2015.  Both are cryptographic protocols for securing connections between clients and hosts communication over a computer network. The main differences are apparent when it comes to completing the task of encrypting connections. 

Both SSL and TLS refer to the handshake that occurs between a client and a server. The handshake does not encrypt anything itself but rather securely agrees on the shared encryption type to be used. Additionally the handshake takes part in multiple roundtrips as authentication and key exchange occur. On the other hand, TLS 1.3 has reduced the number of cipher suites available in the protocol, and restructured how the cipher suite “string” is represented. 

In conclusion, while these two terms are still used interchangeably, when considering server configuration there are some significant differences in the architecture and fundamentals of the two protocols that do leave your server at risk, if using SSL, to vulnerabilities, outdated cipher suites and browser security warnings. So, note that in your servers, you should only have TLS protocols enabled to have a secure server. 


Are you new to wolfSSL? 

wolfSSL focuses on providing lightweight and embedded security solutions with an emphasis on speed, size, portability, features, and standards compliance, such as FIPS 140-2 and 140-3, RTCA DO-178C level A certification, and support for MISRA-C capabilities. wolfSSL supports industry standards up to the current TLS 1.3 and DTLS 1.2, is up to 20 times smaller than OpenSSL, offers a simple API, an OpenSSL compatibility layer, is backed by the robust wolfCrypt cryptography library, and much more. Our products are open source, giving customers the freedom to look under the hood.


Contact Us 

Please contact us at facts@wolfssl.com with any questions about the webinar. For technical support, please contact support@wolfssl.com or view our FAQ page. 


Additional Resources 

In the meanwhile, check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL. 


Learn more about TLS and SSL differences here: 


Watch Real-life examples of wolfBoot and wolfTPM! 

Hey wolfSSL friends,
Check out this recording by wolfSSL engineer David Garske who demonstrates multiple live demos of wolfTPM and gives real-life examples of wolfBoot at TPM.dev 2020 Mini Conference Day 1.  Click on the link below to find the slides attached and the video recording!
Click here: https://developers.tpm.dev/posts/9521200?utm_source=manual
To learn more about wolfTPM check out our product manual: https://www.wolfssl.com/products/wolftpm/
Contact Us 
Please contact us at facts@wolfssl.com with any questions about the webinar. For technical support, please contact support@wolfssl.com or view our FAQ page.
Additional Resources 
In the meanwhile, check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL.

Check out Microchip and wolfSSL’s Partner Webinar! 

Shields UP #24: Using wolfSSL and Pre configured TrustFlex ATECC608 Secure Element for TLS Networks

Learn how to implement mutual authentication using X509 certificates with the WolfSSL TLS stack and the TrustFLEX ATECC608 secure element from Microchip’s Trust Platform. We will discuss TLS concepts in the first half of the webinar, and then an expert from WolfSSL will give a hands-on demonstration featuring a SAM D21 Cortex®-M0+ based microcontroller and a WINC1500 Wi-Fi® module to show how easy it is to get started with mutual authentication.

Check out the Github Page: https://github.com/wolfSSL/microchip-atecc-demos

Watch this webinar: https://www.youtube.com/watch?v=bEPG5p7CMzA


Contact Us 

Please contact us at facts@wolfssl.com with any questions about the webinar. For technical support, please contact support@wolfssl.com or view our FAQ page. 


Additional Resources 

In the meanwhile, check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL. 

What is the difference between FIPS 140-2 and FIPS 140-3? 

This week we are tackling the question: what is the difference between FIPS 140-2 and FIPS 140-3? wolfSSL is currently the leader in embedded FIPS certificates and we always want to keep our users up to the date on the latest standards! 

With various specification updates, the newest standard of FIPS 140-3 will include the hardware module, firmware module, software module, hybrid-software module, and hybrid-firmware module and will have no restriction as to the level at which a hybrid module may be validated in the new standard. This is beneficial to vendors with hybrid modules looking to be validated at a higher level than level 1. FIPS 140-2 standard was originally written with all modules as hardware and only later were additional modules added. 

While both FIPS 140-2 and FIPS 140-3  include the four logical interface data input, data output, control input, and status output.  FIPS 140-3 introduces a fifth interface, called the control output interface for the use of output of commands including signals and control data to indicate the state of operation.  Instead of the use of a “trusted path” used in FIPS 140-2, FIPS 140-3 uses a “trusted channel” which is a secure communications link between the cryptographic module and the end point device which is sending data to and receiving data from the module, with the goal of securing unprotected CSPs. In FIPS 140-3, the Level 4 module using a trusted channel must use multi-factor identity-based authentication for all services using the trusted channel.

Instead of requiring module support for crypto officer and user roles with the maintenance role as optional, FIPS 140-3 only requires the crypto officer role. There is a new capability within FIPS 140-3, called the “Self-Initiated Cryptographic Output Capability” where a module can perform cryptographic operations or other approved security functions without any operator intervention. 


Check out our other blogpost on what is new with FIPS 140-3 here: https://www.wolfssl.com/whats-new-fips-140-3/


When it comes to wolfSSL, we are ready to offer the first implementation of FIPS 140-3: 

  • The power-on self-test is changing. It now takes two sets of tests: the Pre-operational Self-Test (POST) and the Conditional Algorithm Self-Test (CAST).
  • The old Known Answer Tests used as a part of the old test are not required to run at startup. They are now conditional tests that must be run right before use of an algorithm. If you don’t use an algorithm, you don’t need to test it. The tests will run automatically on calling any API for an algorithm.
  • The pre-operational self-test is now purely an integrity test of the executable in memory. The algorithms used for this test must be tested first. In our case, HMAC-SHA-256’s CAST is run automatically, then the POST. The POST will be run automatically as wolfCrypt’s default entry point in the code.
  • All the tests may be and should be run periodically during run time. We will provide an API to run tests as desired. In an embedded application, you can run your CAST early before any algorithms are used as some CASTs do take time.


Contact Us 

Please contact us at facts@wolfssl.com with any questions about the webinar. For technical support, please contact support@wolfssl.com or view our FAQ page. 


Additional Resources 

In the meanwhile, check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL. 

Upgrading to Measured Boot using wolfBoot 

At wolfSSL, we work together with our customers to enhance embedded security. This includes providing an embedded MCU TPM, MCU secure boot, and similar security options.

Today, there is a de-facto standard for IoT security and that is the use of Secure Boot. However, Secure Boot provides us with only a single check over our system image. Therefore, we want to offer our customers the possibility to upgrade from Secure Boot to using Measured Boot with our fully open-source embedded systems secure boot solution, wolfBoot.

During the lifecycle of IoT products there is configuration and user data being updated that also needs protection. Measured Boot provides us the ability to check not only our application image at boot but do so in stages. We could verify the state of our device configuration before applying it. Additionally, we could verify the integrity of the user settings and data before making them available for use, thus increasing the level of certainty in the state of our system before the user starts using it.

To enable this feature, we have already created integration between wolfBoot and wolfTPM. By using a Trusted Platform Module (TPM) we better protect the SecureBoot process, and using an embedded systems TPM is the best way to do it. Would you like us to extend this process to a Measured Boot?

Do you want the capability to check your device configuration before the system starts?

Would you like to check the system state deeper after an update?

Let us know at facts@wolfssl.com

Yours truly,

The wolfSSL Team

Brief comparison of the existing TPM2.0 libraries

This is a comparison of key features in the available open-source stacks for using Trusted Platform Modules(TPM).

TPMs are the most widely available TPM in modern computer systems and it is increasingly seeing adoption for IoT devices and various Embedded Systems. The communication between the TPM and the MCU happens using I2C or SPI bus. Adding a TPM to your systems enables functionalities beyond Secure Boot, such as attestation and TPM seal/unseal.

The main difference between the available TPM stacks is the choice of API interface and environment support. Most stacks are meant to be used in a RichOS environment, such as Linux or Microsoft Windows. Our embedded systems TPM, wolfTPM, has no external dependencies and can be run as part of RTOS or bare metal application, such as medical solutions controlled by a state machine and industrial controllers run in super-loop. 

As mentioned, another notable difference can be found in the API approach. The TSS2 stack created originally by Intel follows strictly the Trusted Computing Group (TCG) specification. Interestingly, the recently added FAPI layer is an abstraction on top of the already existing ESAPI layer, that is an API of the API to offer rich functionalities. WolfTPM took a different approach and allows writing applications with fewer lines of code and complications by using API wrappers. At the same time, wolfTPM, Go-TPM and the IBM TSS all offer API to call TPM commands. 

TPM stack  Interface(s) 

Attestation server

or examples*

Operating Systems
Bare metal Linux  Win 
Infineon/Intel TSS2 ESAPI and FAPI

from the TCG specification

No  Maybe  Yes  Yes 
IBM TPM2.0 TSS  Own API exposing 

1:1 TPM commands 

Yes  No  Yes  Yes 
Google Go-TPM  1:1 TPM commands 

+ mild layer on top  

Yes  No  Yes  Yes 
wolfSSL WolfTPM  Rich API (wrappers) 

+ 1:1 TPM commands 

Yes  Yes  Yes  Yes 


(*) There is a separate project called “CHARRA” by Frauhofer that uses the Infineon/Intel TSS2 for Remote Attestation. The other stacks directly link to own attestation servers or examples. IBM offer “ACS” on Sourceforge and Google have “Go-Attestation” available on GitHub, while “wolfTPM” offers Time and local attestation examples directly in its open-source code.  

Three of the four stacks are written in C and only Google's stack is written in GoLang.  


How is wolfTPM better than the existing TPM stacks and why is it easier?

1. wolfTPM can run on resource constrained MCU, Embedded Systems and devices (IoT, Edge)

2. wolfTPM can be used in Trusted Execution Environments(TEE) and ARM TrustZone

3. wolfTPM does not have external dependencies

4. wolfTPM is the only open-source TPM2.0 stack that can be used in bare metal firmware

4.1 For industrial products using superloop architecture

4.2 For medical devices using state machines

4.3 For safety critical systems that use time scheduler

4.4 In any Real-Time-Operating-System

5. wolfTPM offers high-level wrapper functions to remove the knowledge barrier for newcomers to TPMs

6. wolfTPM maintains backward API compatibility

7. wolfTPM offers wrappers of TPM functions to accelerate development for professionals who want to add more security to their Secure Boot process, such as attestation and TPM seal/unseal

8. wolfTPM cuts R&D cost and time for development thanks to small code base and rich set of examples

9. wolfTPM offers many ready to use examples, like Certificate Signing Request example, Time attestation, and PCR attestation examples

10. wolfTPM is open-source and project development happens completely on GitHub

Extra. wolfTPM is the TPM stack chosen for the tutorial series on Attestation for newcomers at TPM.dev – https://developers.tpm.dev/posts/attestation-part-1

Posts navigation

1 2