Implement secur-ish bootloader

stepansnigirev commented 4 years ago

We are missing a bootloader now. Firmware is always open for reading and writing - it's ok for development but not cool for production. For development we can still keep firmware readable and writable using stlink, but bootloader should be still there.

Let's discuss what we need from the bootloader and how we can get it.

Here are my thoughts:

Bootloader should be able to:

store and protect a unique secret (generated at first boot) that can be used for anti-phishing words on the PIN screen and key encryption/decryption
verify firmware stored in the flash against pubkeys stored in the bootloader
verify and flash new firmware (the firmware should be signed and firmware version should be larger - no downgrades)

The bootloader gets to the update mode if the blue button (user button) is pressed during boot. We can also use the bootloader to enable/disable REPL and pybflash. Can we move PIN code verification to the bootloader? If the PIN code is correct we allow the user to do anything with the device. PIN verification is very security-critical, I would prefer to do it before all the micropython complexity. Does it make sense?

We can use micropython's pyboot, coldcard's bootloader or trezor's bootloader as a starting point.

stepansnigirev commented 4 years ago

Also, C or maybe Rust? =)

gorazdko commented 4 years ago

I have been playing around with the bootloader and tried firmware upgrades using USB communication (over usb micro) and normal binary files:

dfu-util -a 0 -s 0x08008000:leave -D hello_world.bin (source)

I used the standalone bootloader from STM32Cube_FW_F4_V1.24.0 which is where the source files come from also in micropython's mboot.

I would integrate it here in this repo with its own makefile, of course i would reuse as much files from micropython's repo as possible. Once we have this, we can than add the secure functionality as in trezor/coldcard and other stuff, which shouldnt be that hard.

Thoughts?

stepansnigirev commented 4 years ago

Good idea. Let's do it step by step. How should we trigger bootloader to firmware update mode? We could use the user button for example, if it is pressed during boot we can switch to update over USB. Would be nice to have an option to jump to the bootloader from the main firmware as well.

gorazdko commented 4 years ago

yes the button's fine. Ill integrate it step by step. Ill put the steps into the PR once constructed.

gorazdko commented 4 years ago

here is one attempt at having a bootloader project in this repo: https://github.com/gorazdko/specter-diy/tree/bootloader It is functional and works ok.
- i wish i could reuse more files from micropython but there are some challenges (we can discuss on telegram)
another option would be to work ontop of mboot, it works ok, i tested it. But there's a challenge lifting its makefile into this repo, to me a lot looks like magic

What are your thoughts?

stepansnigirev commented 4 years ago

I would probably prefer to work on our own bootloader - exactly how you started it.

What nice features does mboot have? We have a fork of micropython in diybitcoinhardware repo and we could work on top of mboot there if you find mboot useful.

Another question is how to verify the firmware, in particular how to deploy keys to the bootloader. Should it be a static set of keys or do we want to be able to invalidate or update keys stored in the bootloader?

At the end I would like to have a choice:

only to run firmware signed by maintainers of the repository
add your own key ( or keys of trusted developers ) to the bootloader and allow firmware signed by these keys as well
use unsigned firmware with a warning on the display before we boot

@miketlk your input would be very useful here.

gorazdko commented 4 years ago

we could work on top of mboot there if you find mboot useful.

i would prefer working on our own bootloader too. It is a clean subset of mboot without fancy customizable features (dfu over sdcard, i2c, spi...)

Should it be a static set of keys

Thats how coldcard and trezor One do it. Model T on the other hand lets you update the second bootloader with keys because it is using two bootloaders (boardloader and bootloader). Invalidating keys can be done with one bootloader as well, but updating them requires 2 bootloaders.

Going with model T approach is a much bigger project, which would be more suitable for a person who can afford working on it full time. They also use key/signature aggregation.

only to run firmware signed by maintainers of the repository

that would be the default behaviour

use unsigned firmware with a warning on the display before we boot

that option could be turned on by raising a developer flag in a flash sector not occupied by the bootloader nor firmware. And is not included into the signature hash.

add your own key ( or keys of trusted developers ) to the bootloader and allow firmware signed by these keys as well

that's a scary feature. I think the bootloader would have to alert the user with the third party key and make the user responsible for checking the integrity of the key on every boot.

stepansnigirev commented 3 years ago

Added as a submodule: https://github.com/cryptoadvance/specter-bootloader

cryptoadvance / specter-diy

Implement secur-ish bootloader #29