search

solokeys / solo1

Solo 1 firmware in C
https://solokeys.com/
Other
2.29k stars 274 forks source link

Idea: Updateprocedure for bootloader #388

Open jolo1581 opened 4 years ago

jolo1581 commented 4 years ago

Well, because the bootloader cannot be updated at the moment, we might suggest a method how to update also the bootloader by solo-python.

I have an idea, something like two boot stages:

  1. Bootup Stage In bootup stage a small program reads the bootloader address from flash and starts bootloader.
  2. Bootloader Stage The bootloader can start or update the application. Also it can write a new version of bootloader in a second bootloader area. If write process was successfull, the bootloader address is set to bootloader area 2. After reboot the bootup software reads the new address of bootloader and starts the updated version in bootloader area 2.

If the bootloader should now be updated, bootloader area 2 writes the updated version to location of bootloader area 1 and sets address for bootup stage to bootloader area 1.

If the update process stucks the new location address will not be set and the bootup stage will start the old version of the bootloader. This will pervent bricking the device.

One disadvantage is more flash is required, because you need 3 areas for bootloader application.

What do you think about that? Maybe there are better ideas or it is already available in othere projects.

jolo1581 commented 4 years ago

Here a little picture, maybe this helps understanding what i wrote above.

Updateable_Bootloader

conorpp commented 4 years ago

I understand the idea, and like it, but I don't think we can spare the space for both bootloader area 1 & 2. Certainly this would be a reasonable architecture for allowing the bootloader stage to be updated.

We're actively working on a new HW design, and plan to really improve the update process there. It's based on the LPC55S69 microcontroller by NXP. Among other things, it has it's own bootloader ROM that supports:

Any interest in testing this and/or making a diagram/plan of how to best configure the LPC55 boot ROM :)?

jolo1581 commented 4 years ago

@conorpp Sounds good. I will take a look, when I have some free time. Which development board do you use? Do you use something like the nucleo board of the STM32?

conorpp commented 4 years ago

Awesome! We use the "LPCXpresso55S69". Probably best to get it from Digikey or Mouser.

asnelt commented 4 years ago

Ignoring the new HW design for a moment, what about the Readout Protection Level 1 that was brought up in Pull Request #231 and in Issue #71 ?

Sorry for bringing this up again, but from the previous posts it is not clear to me which vulnerabilities arise. For Level 1 it is my understanding that a write in ST DFU cannot be done without triggering a mass erase (by first updating the option bytes). If the selected boot mode is not user flash or debugger access is detected then read and write operations to flash, SRAM2 and backup registers are blocked while the option bytes can still be modified, so a return to level 0 is possible. It would seem the private keys are safe.

When used in conjunction with a verifying bootloader, wouldn't this be secure while still allowing for signed firmware and for bootloader updates? An attacker could replace the bootloader and firmware when getting physical access to the Solo but the victim would notice this immediately since the private keys would be erased in the write process. This would be similar to having the Solo replaced.

jolo1581 commented 4 years ago

When used in conjunction with a verifying bootloader, wouldn't this be secure while still allowing for signed firmware and for bootloader updates?

I think i might be secure, but not very comfortable, because you have to register your solo again every bootloader update.

Yes ist is true, the bootloader shouldn't get an update so often like security updates of application. But I don't know if an erased key is that, what a "normal" user want to have.

asnelt commented 4 years ago

Yes, fair point. This is not particularly user friendly.

For the Solo, Level 1 RDP is still preferable to the Level 2 lock down IMHO. In my verifying bootloader build, I enabled the 5 s button press option to be able to switch to ST DFU easily. This lets me update the bootloader when there are important changes, but having to register my Solo again when I do.

nickray commented 4 years ago

There have been multiple issues with level 1 RDP in the past [1], which is why we went for level 2 for mainline firmware.

[1] e.g. https://www.usenix.org/conference/woot17/workshop-program/presentation/obermaier

asnelt commented 4 years ago

I see. Thanks for the link!

conorpp commented 4 years ago

Still going to be arm based! Somu design is released here ("USB-nano"): https://github.com/solokeys/solo-hw/tree/master/solo

lf94 commented 4 years ago

Still going to be arm based!

I realized and quickly deleted my comment :) Whoops!

Thanks for the link! :)

jolo1581 commented 4 years ago

@conorpp today I received my "LPCXpresso55S69" 😁

conorpp commented 4 years ago

@jolo1581 Great! I opened an issue on our lpc55-hal repository explaining all I know so far :). Feel free to message me on Keybase (conor1), and I'm happy to help you get started. There are a lot of other example programs we've made you can try out to.

If all goes well and/or others want to follow along, we can make another Keybase or Gitter chat.