search

im-tomu / toboot

Bootloader for the EFM32HG Tomu Board
https://tomu.im/
GNU General Public License v3.0
72 stars 28 forks source link

Toboot must clear entire application area #18

Closed gl-sergei closed 6 years ago

gl-sergei commented 6 years ago

I have a security concern. When using Tomu as U2F device, it storing secret key on flash. Someone with physical access to the Tomu board can easily readout that key. He will need to boot into Toboot, upload malicious firmware which gives away secret key via USB, and then upload U2F firmware back, so that owner wouldn't even notice that secret key is stolen. SWD can be disabled and it will be impossible to enable it without erasing flash contents. Toboot must also make sure that new firmware cannot be uploaded without erasing the whole application area. It is also useful to leave few pages which would persist between software updates for the purpose of storing user configuration. These can be part of documented Toboot API. It should also be adviced to not store any sensitive information in this area.

mithro commented 6 years ago

@xobs - FYI

xobs commented 6 years ago

We don't clear the entire application area for a number of reasons. First, we're not sure what's application and what's data. An application may want to save configuration data across firmware versions.

The proposed solution is to set the Configuration Value to disable the Toboot short-to-enter ability. Then when a user wants to update, the U2F program should clear its own keys, set the magic value, and reboot. That way an application can determine what areas to erase and what to keep.

gl-sergei commented 6 years ago

OK. Then I need to come up with a good way to tell U2F firmware to reset itself. I think it may even be the same "short-at-boot"...

gl-sergei commented 6 years ago

Second thought. What if we add another magic value to indicate that entering into bootloader via shorting pads should erase application area. I think there must be a way to get to bootloader even from locked device and adding it to application just makes things more complex and creates duplication of code and features. If we agree on that I volunteer to implement this feature.

gl-sergei commented 6 years ago

Changed u2f firmware to

  1. turn off toboot short-to-boot feature
  2. added short-to-reset feature to erase secret keys and unlock toboot

https://github.com/im-tomu/chopstx/commit/7aed93766fcda67b09b6fa413bde92323402d177

There is now build option (turned off by default) to make u2f firmware to debug-lock the board on first start. It is not on by default because J Link required to unlock device.

Still I would happily throw this patch away if toboot allowed to erase application area.

xobs commented 6 years ago

The v2.0 API includes a 64-bit mask field in the header that allows you to request sectors to be erased. Is that sufficient to implement this request?

gl-sergei commented 6 years ago

I guess yes. Just to make sure. If pages are erased during update, will toboot get the bitmask from the newly loaded program, or from the previous one?

xobs commented 6 years ago

It reads it from the previous image.

Toboot determines what the previous image is by looking at all blocks on the system and selecting the valid header that has the highest "generation" value. It will use that as an image to boot to.

Additionally, when performing an update it will use the existing header as a guideline for what blocks to erase. If you want to erase everything (except Toboot itself), set the value to 0xffffffff ffffffff.

gl-sergei commented 6 years ago

Sounds good! Thank you for implementing that!

xobs commented 6 years ago

This functionality was implemented in API v2.0.