shimun/solo
1
0
Fork 0
Code Issues Pull Requests Releases 1 Wiki Activity

add some security relevant documentation

Browse Source
This commit is contained in:
Conor Patrick
2018-10-14 22:49:48 -04:00
parent f6a21672dd
commit 64c3ea5271
6 changed files with 134 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/signed-updates.md Normal file
View File

@@ -0,0 +1,26 @@
Solo has a bootloader that's fixed in memory to allow for signed firmware updates. It is not a built-in bootloader provided by the chip
manufacturer, it is our own.
On the STM32L442, there is 256 KB of memory. The first 14 KB of memory is reserved for the bootloader.
The bootloader is the first thing that boots, and if the button of the device is not held for 2 seconds, the
application is immediately booted.
Consider the following memory layout of the device.
| 14 KB | 226 KB | 16KB |
|---|---|---|
| --boot-- | -------application------- | --data-- |
Our bootloader resides at address 0, followed by the application, and then the final 16 KB allocated for secret data.
The bootloader is allowed to replace any data in the application segment. When the application is first written to,
a mass erase of the application segment is triggered and a flag in the data segment is set indicating the application
is not safe to boot.
In order to boot the application, a valid signature must be provided to the bootloader. The bootloader will verify the
signature using a public key stored in the bootloader section, and the data in the application section. If the signature
is valid, the boot flag in the data section will be changed to allow boot.
Signature checks and checks to the data section boot flag are made redundantly to make glitching attacks more difficult. Random delays
between redundant checks are also made.