-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add firmware hash/signature check as alternative to HTTPs #65
Comments
Code merged from #66 |
@thinksilicon ... It seems that you have some knowledge in signing the Firmware... Could you explain to me how to protect the Keys inside the ESP32? My understanding is that if you extract the public keys from the ESP32 that you can sign any firmware and thus the additional layer of protection no longer exists. Many thanks.. |
nope, the pubkey can only help you verify stuff (e.g. integrity, authentication) public keys don't need to be protected because they're public if you need a higher level of security, secure boot is probably what you're looking for, but it requires to set custom config values in esp-idf menuconfig, which is not accessible from the Arduino IDE. |
@tobozo .. Cool! Thank you for the explanation. I will explain what I am trying to achieve:
Regarding to your message, the first Goal can be achieved with Signing the Firmware and the second Goal I need to handle secure Boot etc... Or do I need a combination of Secure Boot and Flash Encryption? Am I right? |
I don't know secure boot well enough to provide an answer so I'll leave that to @thinksilicon however you'll have to use esp-idf in order to access the menuconfig and enable secureboot options, which leaves you with two choices:
|
@tobozo .. Many thanks for your explanation. Lets wait for the response of @thinksilicon .. |
This project doesn't handle any of the sucre boot/secure flash options the ESP can provide. As @tobozo mentioned, those features are not directly supported by the Arduino framework. The documentation is fairly good though: You'd create a private+public key to sign your firmware and to provide with the bootloader. Then you'll flash the new bootloader with the public key and on every boot it will verify the signature of your firmware. The public key will be stored in an internal, non accessible flash of the ESP so you cannot extract it, even with access to the hardware. In contrast with this Arduino library: If you have access to the hardware you could overwrite the flash section with your own public key and then upload images you signed with that key. But then, if you already have access to the hardware, you could just flash a new firmware. So this project aims more at the network level, where someone could try to play MITM and inject a bad firmware. |
Thank you for the good and clear words at the end. This library is currently not fitting my requirements. But I hope to see that the secure boot stuff will be integrated soon. I found a good Forum entry which describes how to use secure boot. The main goal was to make it easy USABLe for projects which aren’t based on the IDF.. I will search for the link and update my post here. EDIT: Here is the link, could you give me your opinion about the topic @thinksilicon .. |
Hey,
thanks so much for this library! I was wondering how you'd feel about adding a hash/signature check to the lib as another way to authenticate the new firmware image.
The way I'd see this could be implemented is through a public/private key + digest:
Only piece I don't know here: how can you make Update.h wait for the signature check after the download is complete?
First you'd create your key-pair:
Creating the firmware.img with the embedded signature would be
Signature check on a Linux shell would look like this:
On the ESP32 this would require an additional library for the signature check, but with an embedded implementation of openssl this should be as simple as running rsa_verify() with the firmware file and the public key.
Embedding the signature into the image is not necessary but seems like it would keep things together (and if you implement the version check through HTTP headers it wouldn't make sense to add it to the .json file).
Finally to the reason I think this would be useful:
In a scenario where your webserver uses a Let's Encrypt certificate the cert would change every 3 months. So it's not a good idea to check the update file solely through the SSL certificate. Even if you use a paid cert, browsers are moving forward to shorter and shorter validity periods, currently 1 year is favoured, that might change in future.
With a pub/private key dedicated just to your specific firmware you will be independent of these constraints. You can even go as far as using a different key for each firmware-branch you deploy.
The text was updated successfully, but these errors were encountered: