Top Three Firmware Verification Use Cases: Part 2
This article will explore implementation examples of firmware verification with secure elements.
In part 1 of this series, Top 3 Firmware Verification Use Cases with Secure Elements, we discussed the importance of implementing firmware verification in applications and the code that will be needed. In this part 2, we will get into how to solve the challenges described in part 1.
How Can Microchip’s Microcontrollers Combined with Secure Elements Help?
Immutable boot memory in a microcontroller is a very important feature in any application implementing firmware verification via secure boot and secure firmware upgrade. The latest set of PIC24F Low-Power Microcontrollers (MCUs) and high-performance dsPIC33 Digital Signal Controllers (DSCs) feature Flash OTP by ICSP™ Write Inhibit and CodeGuard™ Security which enable implementing immutable secure boot. ICSP Write Inhibit is an access restriction feature that, when activated, restricts access to all Flash memory via external programmers and debuggers together with read and write protection features. Once activated, ICSP Write Inhibit prevents ICSP Flash programming and erase operations and enables Flash to behave like a One-Time-Programmable (OTP) memory. The CodeGuard security feature enables segmenting of the Flash program memory into two dedicated regions with different privileges. The first memory region is the boot segment which holds the boot loader code implementing firmware verification routine. This boot segment can write protect itself from all self writes, both from itself and the application region of memory. The CodeGuard security together with Flash OTP by ICSP Write Inhibit feature makes the boot loader immutable. As we mentioned before, we must remember in the present context that immutable doesn’t mean inaccessible or unreadable but unmodifiable via remote digital attacks. The second memory region is called the general segment which holds the application image.
The firmware verification code implemented in the boot segment of CodeGuard Flash security, which is not allowed to be changed, issues the ECDSA verify command to the secure element leveraging the CryptoAuthlib library. The TrustFLEX ATECC608 secure element from the Trust Platform for the CryptoAuthentication family, equipped with a secure key storage and hardware based crypto-accelerator, is capable of running the ECDSA verify operation in milliseconds, and it will also securely protect the public key that will be used to perform this cryptographic function on the code signature and/or code digest. The public key is now stored in the immutable secure memory zone of the secure element physically protected leveraging anti-tamper and side channel attack protections. It is much harder now to access and alter the key as well as the code. Check out our software libraries for the PIC24F MCUs and dsPIC33 DSCs supported in MPLAB® Code Configurator (MCC), a free graphical programming environment that generates seamless, easy-to-understand C code to be inserted into your project. The CryptoAuthlib library in MCC simplifies interfacing a TrustFLEX ATECC608 with a PIC24 or a dsPIC33 device and enables implementing various secure functions. You can add firmware verification and secure firmware upgrade capabilities via the MCC 16-bit Bootloader library. For more information, visit our embedded security design center and learn how to implement Secure Boot and OTA. You can also refer to the ShieldsUP security webinar #26: Simplifying secure application designs with dsPIC33 DSCs, PIC24F MCUs and ATECC608 devices
What Does the Transaction Diagram between the MCU and the ATECC608 TrustFLEX Look Like?
The Trust Platform Design Suite (TPDS) software tool is the starting point to begin your journey with Microchip secure elements. When you open the TPDS, you can select your use cases and development platform. The tool will then detail the actual transaction diagrams for the use cases you’ve selected.
For example, here is what the transaction diagram for Firmware Validation looks like between a classic microcontroller and the TrustFLEX ATECC608. It shows how the host MCU calculates a digest of the firmware, sends that digest to the secure element as a challenge, the secure element attempts to cryptographically verify digest+signature with the pre-provisioned public key, and finally receives the response from the secure element. You can see the actual CryptoAuthLib API calls used by the host MCU to communicate with the secure element, such as “atcab_secureboot_MAC”, as well as a simple description of what is actually happens between the MCU and the secure element.
Figure 1: Trust Platform Design Suite V2 transaction diagram of the Firmware validation use case with the TrustFLEX ATECC608
In this scenario, the tool walks you through what needs to happen during:
- The prototyping phase:
- The asymmetric key pair is generated for prototyping purposes by the tool
- The public key is provisioned by the TPDS via your laptop again for prototyping purposes. For production, Microchip offers Secure Key provisioning services
- The code image is signed with the private key to create a signature of the code image
- At boot:
- The host MCU calculates the digest
- Host MCU sends the digest and signature to secure element
- Secure Element validates and responds with valid/invalid
- Host MCU receives the response, indicating the firmware’s validity
- Firmware is authorized to run in the MCU
What If Your Microcontroller Doesn’t Have BootROM Capabilities but You Still Want to Use a Secure Element?
Imagine now that your design is based on a classic 32-bit microcontroller like, for example, the SAMD21 ARM® Cortex® M0+ and there are no BootROM capabilities. This is the situation for the vast majority of designs today, changing to a new microcontroller involves requalification costs and time that’s not always affordable.
In that case, you need to assume your microcontroller code can be changed. If the ECDSA verify command from the microcontroller to the secure element can be altered, what’s the consequence? If the code is still signed and you don’t have the key used for the verification inside your microcontroller, then one device may be affected, but not your whole fleet (assuming you are using a public key infrastructure). This is due to the secure element keeping your public key isolated and it will protect the rest of your fleet. A few questions to think through might include:
- Is it worth spending the time to reverse engineer code to simply turn off one device which you would have to physically access? In most cases, probably not. Can this affect a fleet of devices? Each device would have to be physically accessed which is unpractical. From a remote attack standpoint, likely not if we assume it will take an OTA update to verify a genuinely signed code and none of the keys are in the code.
- In addition, can you trust your contract manufacturer with the cryptographic key that will verify your code? If the answer is no, the secure element doubles its value as Microchip offers a secure key provisioning service to load keys confidentially inside our secure factories to remove exposure of keys at contract manufacturers and bypass the middleman. Plan for the day you will want to change your CM, if the keys are in a secure element, it’s only a matter of changing the shipping address with Microchip.
- Finally, the cost impact in your Profit and Loss (P&L) versus financial risk level is a huge consideration. We have seen our secure elements used by clients because it’s a very cost-effective solution to hold a key. As soon as you load a key in an embedded system, you customized that microcontroller or microprocessor. Imagine your processor is about $3-$5, now you have customized your controllers that are non-cancellable, non-returnable multi-dollar pieces of silicon that are sitting on your shelves. The secure element decreases that financial risk significantly.
Logistic Supply Chain Hurdles and Added Cost of Securely Provisioning “Verification” Keys in the MCU
Microprocessors are generally much more rich in security features than microcontrollers but either of the solutions would need to have a secure physical boundary where both the key and the cryptographic algorithm will be located. Unfortunately, it is a design that is hard to achieve in a cost-effective manner as the secure boundary would have a significant impact on the die cost of the processor or controller. The cost of a monolithic solution is not the only one to add-up but the technical support to fully support such architecture, the various tools to handle multi-user permission and logistics of the supply chain to handle the key provisioning securely continues to increase complexity and risks. Let’s take a look at the problem from a P&L standpoint. Let’s imagine 100,000 units of microprocessors all loaded with keys which makes all those processors custom. Now think about the cost of inventory on your shelves, either you are a distributor, or an OEM, that cost will hit your P&L and increase your project risk across time as projects continuously and naturally are delayed.
A more scalable architecture would be to use a Microchip CryptoAuthentication™ companion device like the ATECC608 TrustFLEX. The keys are isolated in cost effective secure key storage that can ship virtually anywhere in the world (under EAR99 export regulations). The secure key provisioning service eliminates the keys from being exposed to supply chain middlemen reducing the surface of attack.
In conclusion, you need to consider both the security foundation of firmware verification for secure boot, runtime code verification and after an OTA update as well as what are the various supply chain risks and cost when dealing with cryptographic keys. The combination of a secure element such as the ATECC608 next to a microcontroller such as the dsPIC33 DSC or PIC24F MCU with immutable boot capability is a great foundational choice for your design. If the microcontroller doesn’t have bootROM capabilities but relies on a secure element to physically isolate the public key, it is likely that your threat model and risk assessment will validate such architecture in most applications.
Resources:
Getting started with the tools:
Video Education Library: