Category: Uncategorized

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?

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

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.  

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

 

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

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

wolfCrypt on CMVP Implementation Under Test List

wolfCrypt has been listed on the CMVP IUT List for FIPS 140-3! We are currently working with our testing lab to get validated as quickly as possible with the new FIPS standard from the NIST.

Among the changes for FIPS 140-3 are conditional algorithm self-tests, where the algorithm self-tests are only performed if used. The pre-operational self-test is now faster, as all the algorithms are not tested until needed. This helps with startup times as the public key self-testing can be time consuming. The self tests can be run at appropriate times for your application startup. Also, there is additional testing of the DRBG entropy sources.

wolfSSL is the first software library on the FIPS 140-3 IUT list for embedded development. We are leaving our competition in the dust.

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

Avionics Systems in Need of New Cybersecurity Testing

The U.S. Government Accountability Office (GAO) has pushed for further guidelines and regulations to ensure security in Avionics Systems. The report indicates potential cyber risks such as data spoofing, outdated systems, long update cycles, and software vulnerabilities. Researches have also highlighted the vulnerabilities to in-flight connectivity systems including the usage of cheap equipment to eavesdrop on satellite signals that may expose in-flight passenger data. wolfSSL is the leader in Cybersecurity for Avionics Systems and can be applied to mitigate risks and vulnerabilities that come with these breaches. See how wolfSSL can be used in your Avionics applications today!

Aviation today article can be found here.

Contact Us

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

Secure wolfMQTT SN with wolfSSL DTLS

The sensor network sub-specification of MQTT does not designate a method for securing the communication between the clients and the gateway. We here at wolfSSL think that is unacceptable! Using the DTLS library of wolfSSL, we would like to protect the sensor data all the way from the client to the gateway, and then from the gateway on to the broker using standard TLS (also from wolfSSL).

Who else is interested in a completely secure, all-in-one solution for MQTT-SN?

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

You can download the latest release here: https://www.wolfssl.com/download/
Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT
While you’re there, show us some love and give the wolfMQTT project a Star!

Using wolfSSL with .NET Core

.NET Core is a .NET implementation that is preferred in situations where cross platform portability is important. Including use in containers and running on environments such as macOS and Linux. wolfSSL has a C# wrapper written for the .NET framework that is fully capable of performing TLS/DTLS connections while using the optimized C code with hardware acceleration. Easy to use examples for a quick start are also bundled with the wolfSSL C# wrapper which can be seen in the directory wolfssl-4.5.0/wrapper/CSharp/ after downloading wolfSSL.

Using Microsoft’s “.NET portability tester” tool to evaluate wolfSSL’s C# implementation resulted in a rating of 95.6% compatible for transitioning over to .NET Core. Showing that the implementation is close, as is, to being able to be used with .NET Core. If using the progressive wolfSSL C# wrapper with .NET Core is something you are interested in.

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’s New in FIPS 140-3?

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:

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

wolfSSL has a long history in FIPS 140-2, starting with wolfCrypt FIPS 140-2 Level 1 Certificate #2425 and surviving Certificate #3389. wolfSSL is helping customers move from Certificate #2425 as NIST is sending it into sunset next year. For those who will be impacted, contact us to get your new cert!

wolfSSL is currently the leader in embedded FIPS certificates. Stay tuned as we support you with the best in FIPS 140-3. Be sure to join us for an upcoming webinar on this topic, details forthcoming! 

Additional Resources 

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

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. 

wolfSSL-NXP Partnership Roundup

NXP® Semiconductors N.V. is one of the wolfSSL partner network members. wolfSSL ships with support for offloading cryptographic operations onto several NXP devices (such as the Coldfire and Kinetis) that include hardware cryptography modules. Examples of these operations include utilizing the Crypto Acceleration Unit (CAU), Memory-Mapped Crypto Acceleration Unit (mmCAU), LP Trusted Crypto (LTC), and more.

Using these hardware cryptography modules leads to increased performance when compared to performing hardware cryptography within software only. These speedups increase algorithm performance greatly, and can range from 1.2 times as fast to 14.5 times as fast! In an embedded and connected world, these speedups can make all the difference for an online device or network application. Additionally, these performance increases are available when wolfSSL is being used to manage TLS 1.3 connections, giving your embedded SSL/TLS application the ability to greatly increase performance and use the most up-to-date versions of the TLS protocol.

Benchmark numbers showing the comparison of hardware crypto vs. software crypto can be viewed on the wolfSSL benchmark page, here: https://www.wolfssl.com/docs/benchmarks/. This page also includes sample benchmark data for the NXP i.MX6, and the TWR-K70F120M devices. More benchmarks, and details about wolfSSL and NXP can be viewed on the wolfSSL website: https://www.wolfssl.com/docs/nxp/

More News on wolfSSL Support for NXP

wolfSSL develops a full suite of products supporting NXP designs. Learn about wolfBoot secure boot and TLS 1.3 firmware update with FreeRTOS and wolfSSL on NXP Freedom Board K64 here. And as with every release cycle, 4.2.0 improved support for crypto hardware performance, now on NXP mmCAU (download the latest wolfSSL version 4.5.0 here!) 

wolfSSL also provisions surviving FIPS certificates that can be leveraged for your i.MX8, i.MX7 and i.MX8 CAAM projects. Stay tuned for upcoming FIPS 140-3 support. Also on the roadmap, upcoming support for NXP’s SE050 hardware security chip. This is an external I2C crypto co-processor chip that supports RSA key sizes up to 4096-bit, ECC curves up to 521 bit and ED25519/Curve25519. If your target is missing, tell us!

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

wolfSSL: https://www.wolfssl.com/

NXP Semiconductors: http://www.nxp.com/

TLS 1.3: https://tools.ietf.org/html/rfc8446

Posts navigation

1 2 3 … 90 91 92 93 94 95 96 … 197 198 199