Protecting a product that needs OTA updates

[IVData]

Hi everyone,

I'm working on a product - a custom PCB containing an ESP32 that needs to accept OTA updates, but that I'd like to protect against people copying the flash onto other boards. The situations I'd like to protect against are:

• A user reading the flash and flashing it to another ESP32 to clone the product.
• A user intercepting an OTA update binary and flashing it to another ESP32

My original thinking was to use an authentication chip on the board such as a ATECC508A to store a private key that is checked for authenticity using the esp32. This solves the first concern.

But I'm worried that someone with the knowledge could intercept the OTA binary, and learn enough through debugging/decompiling to bypass the key check entirely.

This seems like a problem that would be common to most products using an ESP32, but I am honestly confused with all of the information out there about securing these chips. I would think that pre-encrypting the OTA binary is the solution, but it seems that almost no-one is doing this, and it's not a supported workflow by espressif.

How do I make sure a product can be secured while being updated OTA?

Thanks

P.S. I am using esp32-arduino right now, but I will happily move to IDF if it's required.

[ESP_Sprite]

Your first point (disallowing copying of flash to a different board to clone the product) is taken care of by Secureboot and flash encryption. These effectively make sure that 1. the binaries that run on the ESP32 are the exact same ones as that you produced, and 2. that the on-flash data is encrypted by a key only known to the ESP32; an external party can still read the flash, but as the binary is encrypted it looks like random noise to them, and flashing it into a second ESP32 is useless as that ESP32 doesn't have the required key.

The second point is a bit less easy to pin down, as there are multiple ways of doing this, depending on your security needs. One of these is to make sure that OTA is done over HTTPS (so only your server and the ESP32 in question can see what's going over the line) and then use a client certificate (preferably one unique cert per device, so you can blacklist units that may still somehow be compromised) to authenticate the ESP32. As the client certificate is stored in encrypted flash, there is no way an outside party can get to it and download a firmware update, and as the communication is over HTTPS, there is no chance of anyone intercepting an update that way either, and as the webserver is configured to only hand out OTA updates to clients which can provide client certificates signed by you, no one else can get to the updates either.

[IVData]

Hi,

Thanks very much for your reply, it's extremely helpful. I think the missing part of the puzzle to me was the client certificate - I couldn't work out otherwise how to secure the downloading of firmware updates.

So if I understand correctly, a user can't copy the flash because it's encrypted with a key that's unable to be extracted from the ESP (I have read about secure boot and flash encryption but I'll look up exactly how to implement them at the time).

A user can't impersonate my product to download an OTA binary because they wont have a client certificate (stored in encrypted flash).

And a user can't impersonate the update server to flash other firmware, because they won't have a signed certificate for my domain.

So it sounds like in this case i don't need any external IC to secure anything at all. I understand the security of secureboot relies on having a later version of ESP32, I will make sure I'm using those too.

[ESP_Sprite]

That's all correct, and indeed, for maximum security you want an ESP32 ECO3 if you implement this. (Which you will probably get if you buy a new ESP32, unless you hit some seller selling you very old stock.) Do note that even for older ESP32s this scheme is pretty secure: if someone somehow manages to copy a device, they also need to copy the client certificate of that particular device. If they then produce multiple copies of your product, you should be able to see that on your OTA server (as multiple IPs try to do OTA with the same client cert at the same time) and ban that client cert.

[IVData]

Thanks very much for your help. Is there a way to provide a client certificate when doing a https ota update via arduino? I can't find any info on doing it.

[ESP_Sprite]

Ideally you want to flash an unique client cert into each and every product you produce. You can do that by embedding it e.g. in a filesystem, raw partition or pre-built NVS partition; the trick is that you need to do it in the factory (or whereever you flash your initial firmware into the chip).

[IVData]

Yeah sorry I wasn't very clear. I meant when the user initiates an update, how do I provide

Code: Select all

HttpsOTA.begin()

with a client cert.

But also seems I've figured it out. I was confused by the example here: https://github.com/espressif/arduino-es ... OTA_Update

Where the ESP provides a "server certificate" to

Code: Select all

HttpsOTA.begin(const char * url, const char * server_certificate, bool skip_cert_common_name_check)

It makes much more sense that that cert is a client one, not a server one

[ESP_Sprite]

From an abstract point of view, you need both. You need some sort of certificate to be able to check if the server you're connecting to is actually your update server, as well as a certificate to prove that you're an original whatever-your-device-is-called to the server. I'm not sure if the Arduino https client supports client certificates, though, you may need to revert to the esp-idf http client for that.

[IVData]

Oooh I see, I was getting confused.

Hopefully I can store the letsencrypt X1 cert on the ESP and use that, along with a client cert, the 2035 expiry of X1 is enough for me.
Then just need to use IDF for the update.