As a proud partner with ARM, wolfSSL is available as a CMSIS pack! wolfSSL was one of the first libraries available as a MDK5 software pack, which has evolved into CMSIS.
The wolfSSL ARM MDK5 pack supports CMSIS-RTOS by default, providing both the library and example applications. The user can choose to use a different OS as well.
Contact us at facts@wolfssl.com for more information about using the wolfSSL CMSIS pack today.
A question we get asked frequently is what are the build size and memory usage of the wolfTPM portable library. Here we will compare wolfTPM with the other popular TPM2.0 stacks, “ibmtss2” created at IBM and “tpm2-tss” originally created by Intel.
This comparison is interesting, because wolfTPM was built from scratch to be optimized for embedded devices and resource-constrained environments. This gives our TPM2.0 library a small footprint while still providing the features our users want and need.
At the time of writing, the current versions of TPM2.0 libraries is as follows:
wolfTPM is at major version 2.0.0
ibmtss2 is at version 1.5.0
tss2-tpm is at version 3.0.3
The test environment is x86_64 machine, running Ubuntu 20.04.1 LTS, with gcc compiler at version 9.3.0 (from the official Ubuntu 9.3.0-17ubuntu1~20.04 package).
Here are the memory footprint results reported by the GNU Size tool:
| Code (text) | Memory (data) | bss | Total (Dec) | filename |
|---|---|---|---|---|
| 2658649 | 186120 | 186120 | 2879905 | ibmtss keygen |
| 2730620 | 176736 | 33888 | 2941244 | Tpm2-tss keygen |
| 119980 | 1040 | 24 | 121044 | wolfTPM keygen |
Observations
For completeness, below are the configurations used for each TPM2.0 stack:
– tpm2-tss stack (originally created by Intel) was built using
./configure –enable-shared=no –enable-nodl –disable-fapi -disable-tcti-mssim -disable-tcti-swtpm
In details:
tpm2-tss test application: https://github.com/tomoveu/tpm2-tss/tree/size-9
– Ibmtss stack was built using
./configure –disable-tpm-1.2 –disable-rmtpm –disable-shared
In details:
ibmtss test application: https://github.com/tomoveu/ibmtss/tree/ibm-size-3
– wolfTPM was built using
./configure –enable-devtpm –enable-wolfcrypt –disable-shared
In details:
wolfTPM test application: https://github.com/tomoveu/wolfTPM/tree/size-6
If you have any further questions about wolfTPM code sizes, please contact us at facts@wolfssl.com. For a full list of wolfTPM features, please visit the wolfTPM Product Page.
Hi friends! wolfSSL is looking at participating in the GSMA mobile standard ecosystem for IoT SAFE. We bring robust security; what would this mean for your IoT projects?
IoT SAFE is an IoT SIM applet for secure end-to-end communication, developed by the mobile industry with the goal of standardizing and streamlining IoT device security. Learn more about IoT SAFE.
If you have any commentary or feedback please reach out to our team at facts@wolfssl.com!
wolfBoot v1.7.1 is now available for download from the wolfSSL download page. This version includes some important fixes, improved support for hardware platforms and a few new features.
Our IoT-friendly bootloader is now capable of running in secure mode on Cortex-M33 microcontrollers, using TrustZone-M. Measured boot is now available through the integration with wolfTPM.
For more information or for any questions regarding wolfBoot, contact us at facts@wolfssl.com. Don’t forget to check our GitHub Repository for documentation and to stay up to date with our latest developments. And while you are there, please give us a star!
Hi! As our readers know, wolfSSL produces the first embedded TLS library that has begun testing for the new FIPS 140-3 standard, as listed here: https://csrc.nist.gov/projects/cryptographic-module-validation-program/modules-in-process/iut-list
There are a few significant changes coming with FIPS 140-3. Over the years with many specification updates, a few things got a little inconsistent, so these inconsistencies have been brought back in line. wolfSSL is prepared to deliver the first and best implementation of FIPS 140-3, so get ready.
As FIPS 140-3 is the replacement for FIPS 140-2 it is always a good idea to switch over to it as soon as possible. You will also want wolfSSL’s FIPS 140-3 Certificate for many additional reasons that include:
– Merging the FIPS + ISO Standard (see this https://www.corsec.com/fips-140-3/)
– CAST Testing Streamlined – just testing the algos they are actually using.
– Addition of TLS KDF in FIPS Boundary
– Addition of SSH KDF in FIPS Boundary
– Addition of RSA 4096
– Addition of ECDSA + SHA-3
– Removal of insecure algorithms: example Triple DES
Additional Resources
Please visit our website at https://www.wolfssl.com or contact us at facts@wolfssl.com!
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.
wolfSSH version 1.4.6 is now available for download! Some of the notable changes in this version of wolfSSH are fixes for issues that came about from additional fuzz testing using OSS-Fuzz, improved modularity in the build to assist with resource constrained environments, updates for use with MQX, and expansion of the bundled examples. A full list of the changes can be seen in the ChangeLog.md file bundled with wolfSSH.
For questions about wolfSSH contact us at facts@wolfssl.com.
wolfSSL supports embedded customers achieving secure communications in the tightest constraints. For TLS 1.3, this means avoiding certificates and large code size algorithms like RSA and ECC and using Pre-Shared Keys (PSK) with no key exchange.
wolfSSL 4.6.0 has been optimized to be compiled for this configuration only with minimal code and memory usage. This has been achieved by careful exclusion of code across the TLS implementation to only include the parts that are necessary. In fact, the library code can be compiled to less than 50 kB!
If you have any commentary or feedback please reach out to our team at facts@wolfssl.com or support@wolfssl.com!
With the newest release of wolfSSL, you can now set the Intel CPU ID flags rather than let them be discovered. The CPU ID flags indicate which instructions are implemented in the CPU. wolfSSL uses this information to decide which is the fastest optimized implementation that will execute!
wolfSSL’s normal discovery works just fine when running on physical CPUs, but emulation in virtual environments does not always report the true state. In these cases users can call cpuid_set_flag() to enable the flag that is needed. Bugs do occur in CPU implementations and in these cases turning off a flag with cpuid_clear_flag() enables switching to different implementations across potentially a number of different cryptographic algorithms. Alternatively, the exact list of flags that you want can be selected with cpuid_select_flags().
If you have any commentary or feedback please reach out to our team at facts@wolfssl.com or support@wolfssl.com!
The wolfSSL embedded SSL/TLS library supports LwIP, the light weight internet protocol implementation, out of the box! Users should define WOLFSSL_LWIP when compiling wolfSSL, or uncomment the line /* #define WOLFSSL_LWIP */ in wolfssl/wolfcrypt/settings.h to use wolfSSL with LwIP. This will enable wolfSSL’s LwIP port, which uses LwIP’s BSD socket API. LwIP users who are using the native LwIP API can also use wolfSSL by defining HAVE_LWIP_NATIVE, then writing and registering their own Input/Output callbacks.
The focus of LwIP is to reduce RAM usage while still providing a full TCP stack. That focus makes LwIP great for use in embedded systems, the same area where wolfSSL is an ideal match for SSL/TLS needs. An active community exists with contributor ports for many systems.
In addition to LwIP, wolfSSL also supports TLS 1.3, FIPS 140-2/140-3, DO-178C, and more! For help getting started using wolfSSL in your project, contact wolfSSL at facts@wolfssl.com
In this blog series, we are giving our users more details about wolfSSL‘s new SP Math All math library. So far, we have introduced SP Math All, and provided comparisons to both wolfSSL’s normal Big Integer library and wolfSSL’s TFM library. And up next, what about OpenSSL? Is the SP Math All better than OpenSSL?
When compiling OpenSSL, you will get the highly optimized and large implementations by default. wolfSSL already has the Single Precision code that is as good or better! If you choose to compile OpenSSL without assembly then wolfSSL wins again.
Compiling both with no assembly and the SP Math All fast variation (the smaller of the two fast builds) has the following results:
| Architecture: x64 | Percent Faster (wolfSSL vs. OpenSSL) |
|---|---|
| RSA 2048 Sign | 8.27% |
| RSA 2048 Verify | 29.75% |
| ECC P-256 Agree | 20.56% |
| ECC P-256 Sign | 25.31% |
| ECC P-256 Verify | 24.13% |
Better across the aboard! And the size? It is difficult to obtain an accurate number for OpenSSL without writing a custom application. But looking at the size of the BN symbols indicates to us that OpenSSL would be as much as twice the size.
So you can see, the new SP Math All implementation is perfect for all your needs regardless of whether you are developing a memory limited embedded application, other embedded application or a mobile app. And don’t forget that Single Precision implements RSA and ECC algorithms at specific sizes to run blindingly fast in your mobile, desktop or server app and co-exists with SP Math All.
If you have any commentary or feedback please reach out to our team at facts@wolfssl.com or support@wolfssl.com!
