Digital Signatures and Secure In-Field Updates

[AGlass0fMilk]

Description

• Type: Enhancement
• Related pull request: Reserve and Render header in managed BL mode #5950

---

Enhancement

Reason to enhance or problem with existing solution
SHA256/RSA2048 digital signatures provide a relatively simple way of securing in-field updates. Using the existing, built-in mbedTLS library it should be possible to implement a generic way to verify in-field firmware updates. Implementing this feature for all mbed platforms would simplify and encourage secure firmware upgrades, a huge issue in IoT devices moving forward.

Suggested enhancement

Requirements:

1. Digital signature tools (integrated into mbed-cli)

2. Application information (headers, version numbers, digital signatures, public key, etc) embedded into generated binaries intended for in field updates.

3. A communication-agnostic way of verifying new firmware images (whether it comes from BLE/UART/SPI/I2C or other), associated examples.

4. Support for uVisor integration to protect critical security data (crypto keys, etc)

5. Secure internal/external storage of crypto keys

6. Solution should be usable with mbed Cloud client (currently a private repo, so not sure how to go about making sure the solution is compatible @theotherjimmy). Should not require the use of mbed Cloud/client.

Possible solutions:

• mbed TLS for key and certificate management (I haven't fully researched this yet)

This could be an enhancement to the current managed bootloader system.

I'm opening up an issue at the suggestion of @theotherjimmy to discuss the scope of this possible feature/enhancement.

[theotherjimmy]

Thanks! Let's get some discussion on this.

@JoeTheGuitarist @thegecko @LiyouZhou @sg- @ChiefBureaucraticOfficer
[Mirrored to Jira]

[AGlass0fMilk]

For targets that support it, the Flash IAP driver can be used to reprogram sections of the mcu's memory.

The IFU (in field update) system will use SHA256/RSA-2048 encryption for digital signatures.

Considerations:

• The (256-byte) public key used for decrypting the digital signature must be stored somewhere in the microcontroller's memory. This should preferably be accessible from one location by both the main application and the bootloader. With this in mind, where should the public key be stored? Should it be updateable? Maybe it could be embedded in the bootloader's image somewhere?
• The IFU system should be transport-agnostic, in that it can take in arbitrary size chunks of a new program image from any source (I2C, SPI, BLE, UART, etc)
• There should be provisions for updating both the Bootloader and the Main application
• Signing tools should be built into mbed-cli (I have an existing set of python scripts using the pyCrypto library that take care of generating/encrypting keys and signing application binaries)
• Ideally, the solution shouldn't involve modifying linker scripts at all

I'm trying to think of the best way to start a portable solution. Anyone have any suggestions for HAL abstraction, etc?
[Mirrored to Jira]

[0Grit]

@AGlass0fMilk Weird, was just writing my personal requirements for mcu credential management software when I saw your comment come through.

Do the Key and Configuration Manager (KCM), Factory Configurator Client (FCC), and Factory Configurator Utility (FCU) provide any hints?

Provisioning Devices For Mbed Cloud
Using FCC and KCM in your application

Transport agnosticism was one of my requirements and I think it is extremely important.

[Mirrored to Jira]

[AGlass0fMilk]

@loverdeg-ep I noticed that mbed Cloud supposedly had provisions for firmware updates, but I have never used mbed Cloud and it doesn't seem as open as mbed-os at the moment. If there's an existing solution for managing firmware updates it would be nice to integrate with that. mbed Cloud seems to target devices that can connect to the internet on their own. I feel like this is covers only part of the use cases mbed-os applies to. For my application in particular, the device itself is usually disconnected and periodically syncs using BLE.
[Mirrored to Jira]

[0Grit]

@AGlass0fMilk @theotherjimmy Something tells me it will be hard for outsiders to propose how to store certs/keys until more information regarding Platform Security Architecture and the cortex-m trusted firmware is made public
[Mirrored to Jira]

[0Grit]

@AGlass0fMilk I reccomend reading "Porting The Update Client" and the surrounding documentation for inspiration
[Mirrored to Jira]

[AGlass0fMilk]

@loverdeg-ep I am assuming you have access to the private mbed Cloud repositories. How closely coupled is mbed Cloud (and its update utility) with mbed-os? I don't want to make a redundant system but I feel like this is a common enough task that it should be integrated into mbed-os.

It should also not have to rely on connectivity to mbed Cloud, but would be nice to have it plug into the firmware update management system offered by mbed Cloud.

Maybe mbed Cloud's firmware update system should be integrated into mbed-os and the rest of the cloud solution should be optional as it is now?
[Mirrored to Jira]

[0Grit]

@AGlass0fMilk Unfortunately I do not have access. I'm just inferring from watching the public repositories, and documentation.

But this is beside the point of this issue

• Can you maintain a list of requirements in the issue description?
• Can you maintain a list of possible solutions as well?

@theotherjimmy and crowd can hopefully provide any requirements missed and point in the direction of solutions; whether the exist, and if they are public, private, or proposed internally.

My thinking has always been that it would be nice to have a transport agnostic mbed-client as the interface for this sort of stuff. We could then just use the standard LWM2M objects to trigger updates and changes via serial port or other.

Unfortunately LWM2M is only just now modifying it's transport hitch to support more than coap. Also, LWM2M semantics do not seem binary enough; though I need to look into the CBOR addition.
[Mirrored to Jira]

[AGlass0fMilk]

@loverdeg-ep
I have updated the original issue description. Let me know if you have anything else to add.
[Mirrored to Jira]

[0Grit]

#6267 might be part of a solution for requirement 5

edit: Requirements started from 1 not 0
[Mirrored to Jira]

[theotherjimmy]

#5900 is part of a solution for requirement 5
[Mirrored to Jira]

[theotherjimmy]

I numbered the requirements to remove that ambiguity.
[Mirrored to Jira]

[theotherjimmy]

#5950 Should do most of 1 and 2
[Mirrored to Jira]

[theotherjimmy]

Note for requirement 6: Firmware update with Mbed CLI may require a specific boot loader library.
[Mirrored to Jira]

[0Grit]

@theotherjimmy In terms of implementation; do you see this particular enhancement being

• A 'client' for receiving in-field updates over uart/spi/etc.

or rather

• the actual software that validates an image and changes boot variables/writes program flash

Also, is SOTP "Secure one time programmable"?
[Mirrored to Jira]

[theotherjimmy]

@loverdeg-ep I already incremented your number (it was originally 3)

---

I see the requirement as:

the actual software that validates an image and changes boot variables/writes program flash

It's then up to the user application to provide the image bytes to this library code.

---

For SOTP/NVStore questions, please ask them in #5900
[Mirrored to Jira]

[LiyouZhou]

mbed cloud client with fota now open sourced
https://cloud.mbed.com/
https://github.com/ARMmbed/mbed-cloud-client-example
https://github.com/ARMmbed/mbed-cloud-client
https://github.com/ARMmbed/mbed-bootloader

Cloud services pending.
[Mirrored to Jira]

[adbridge]

Internal Jira reference: https://jira.arm.com/browse/IOTCORE-173

[theotherjimmy]

I think we have probably done everything needed in this ticket with mbed-cloud-client open source, NVStore, Feature Bootloader, and mbed dm.