After an electronic IoT device has been deployed into the world, it may be necessary to reprogram or update it. But if physical access to the device (or devices) is troublesome or no longer possible, that’s a problem.
Fortunately, over-the-air (OTA) firmware updates are a thing, allowing embedded devices to be reprogrammed over their wireless data connection instead of with a physical hardware device. Security is of course a concern, and thankfully [Refik] explains how to set up a basic framework so that ESP32 OTA updates can happen securely, allowing one to deploy devices and still push OTA updates in confidence.
[Refik] begins by setting up a web server using Ubuntu Linux, and sets up HTTPS using a free SSL certificate from Let’s Encrypt, but a self-signed SSL certificate is also an option. Once that is done, the necessary fundamentals are in place to support deploying OTA updates in a secure manner. A bit more configuration, and the rest is up to the IoT devices themselves. [Refik] explains how to set things up using the esp32FOTA library, but we’ve also seen other ways to make OTA simple to use.
You can watch a simple secure OTA firmware update happen in the video, embedded below. There are a lot of different pieces working together, so [Refik] also provides a second video for those viewers who prefer a walkthrough to help make everything clear. Watch them both, after the break.
> let us get the certificate from our web server.
This is going to end well.
If the cert is signed by a root certificate then it’s not a problem. Yep, it’s signatures all the way down.
That’s great, but who issued the certificate? How did you validate the certificate? Which CAs do you trust? What happens if a CA gets compromised? What happens when the cert expires?
Great article.
Interested about that tombstone shown on the very first picture in the blog…
Signing the firmware itself seems a safer approach. If a server is hacked and the firmware swapped, how will the device know? HTTPS solves a different problem. How do I know my Nvidia Driver is from Nvidia? I can right click and check the certificate. At this point my download source doesn’t matter anymore. Protect the firmware, not the connection.
Indeed, firmware signatures are still needed for security.
Technically the server certificate doesn’t protect the connection/communication at all.
Certificates authenticate the endpoints so you know who you are talking to in order to ensure you are setting up a secure connection with the correct party. (Setting up an encrypted connection with an untrusted party doesn’t help you at all to provide security, so take certificate warning seriously.)
Using HTTPS doesn’t mean you are using encryption at all, although that will be the case in almost all of the circumstances.
The cipher/encryption to use is agreed upon by both endpoints. If the server only offers NULL-encryption and the client accepts, or vice versa, nothing is encrypted. If you harden your server/client, you will ensure not to accept any weak ciphers.
(Also, hardening will ensure the certificate is not part of the cipher/key negotiation in order to avoid decryption of previously recorded communication in case the certificate private key is leaked by using ephemeral keys for encryption.)
In communication the OSI interconnection model is often referenced and it is important to implement security on each individual layer. (You can not secure the application data on the network layer, etc.)
Addendum: It is not an intensionally loaded post. I advocate of course the use of TLS and HTTPS. What I am saying is: Use more than 1 failsafe. And signed firmware is the foundation. Secured connections are the roof. Together you get the idea of a secure building. That’s all friends.
Sorry, this is not for everyone. In the second paragraph it says:”I will describe everything in a step-by-step manner so that anyone can replicate and follow it.” Two sentences later it says the encryption setup is just basic and not production ready. Then it says “make sure your DNS records are properly set:” followed by an image with nothing indicating what the reader is to look for. So, this article assumes a lot of knowledge or that the reader will do a bunch of ancillary research. That said there is good info to be had and it’s great that Hackaday has brought it to us.
Actually the image does have some indication with red arrows, but still no explanation of what they are highlighting.
Toit.io is another option.
To perform secure OTA over the Internet, directly from GitHub Actions workflow you can also use this GitHub template project: https://github.com/husarnet/esp32-internet-ota
How exactly is this secure, apart from the HTTPS connection? There’s nothing about Flash and NVS encryption in the entire article. Anyone with physical access to the device can steal the firmware and make copies of the device.