Securing code
-
With the latest FW I understand that it is possible to encrypt the firmware on flash and thus secure the boot.
I have a few questions about how this works:
Will this fix the whole firmware and make it impossible to add new files (except upgrading the whole fw signed with same key)?
If it is possible to add new files to the files can these be run as normal?
If it is possible to add new files is it possible to require then to be "signed" and/or "encryptet" when they are imported? -
Hi Jardar,
I've added some development documentation on the github:https://github.com/pycom/pycom-micropython-sigfox(the bottom of the page).
We should add a section in our official docs, too.
On short, the answers are:Will this fix the whole firmware and make it impossible to add new files (except upgrading the whole fw signed with same key)?
Yes
If it is possible to add new files to the files can these be run as normal?
I don't understand.
- Micropython scripts are being encrypted when they are copied on device (REPL or ftp). This is transparent for user.
- Firmware partitions, they have to be pre-encrypted on the PC, before being OTA updated.
If it is possible to add new files is it possible to require then to be "signed" and/or "encrypted" when they are imported?
I think I answered in the previous question.
-
Thanks. Took a bit of time to follow up on this.
If I understand you right the whole flash is basically encrypted. And you can add new files/FW as "normale" as long as these files are encrypted up front.
In the documentation it states something about limited number of times the FW can be updated. From what I understand this only applies if you do not specifcation the encryption up front. Or basically the limitation is on the number of times you can change the encryption key? So there is not a limitation on file/fw update but just the encryption key?
-
Hi Jardar,
The docs for secure boot are published/duplicated here: https://docs.pycom.io/chapter/advance/encryption.html
Encryption key can't be changed, nor re-generated (that's why they should be kept safe).
The 3 times limitation is valid just in the following case: the firmware binaries are written not-encrypted using USB (uart), and the ESP32 encrypts all the partitions marked as encrypted (and an ESP32 efuse has to burned.In all the other cases, like OTA update, ftp transfer, the encryption/decryption is made transparently, without the encryption counter being increased.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login