Conversation
will-v-pi
force-pushed
the
encrypted-improvements
branch
from
4b2f32f to
6ca5a1c
Compare
Update CMake tooling to use 128 byte key files (a 4-way share of the 32 byte key). Also temporarily update the enc_bootloader to deshare this key - the actual fix will need to be in aes.S.
Add data_max_size to prevent overwriting the bootloader with data from flash
Also shrink the space allocated for the bootloader to 32K (plus 8K scratch)
Also switch to random default key
This is not necessary anymore, now picotool writes the AES key to otp json files Fixes #613
CK_JITTER is removed as the enc_bootloader runs from XOSC not ROSC
This includes the changes from #553
This is useful for testing decryption with large files
will-v-pi
force-pushed
the
encrypted-improvements
branch
from
6ca5a1c to
bde13d6
Compare
Add self check (1 == 1), which is only performed on first boot
…e examples compilation passes
| The AES key is stored as a 4-way share in a 128 byte binary file - you can create one with | ||
|
|
||
| ```bash | ||
| dd if=/dev/urandom of=privateaes.bin bs=1 count=128 | ||
| ``` |
There was a problem hiding this comment.
I wonder if it might be worth changing the privateaes.bin filename to make it clearer that it's a key-share and not just a raw AES key? 🤔
| @@ -1,45 +1,31 @@ | |||
| /* MEMORY LAYOUT ASSUMPTIONS | |||
There was a problem hiding this comment.
Is this aes.S the same as the one in raspberrypi/picotool#207 ?
(And if so, do we have any mechanism for ensuring that they stay in sync?)
There was a problem hiding this comment.
Yes (although hasn't been updated with some of the latest changes)
No mechanism to keep them in sync, but the copy in picotool is the authoritative copy so changes should always be made there and copied across
There was a problem hiding this comment.
If the picotool CI is now also building pico-examples, perhaps the picotool CI could also check that these files in the two repos match? (or perhaps it's very unlikely that this file will change in future, so perhaps that'd be overkill)
There was a problem hiding this comment.
That sounds like a good idea, I will add that
Comments and readme
…e examples compilation passes
3 participants
This adds a self-decrypting binary to demonstrate raspberrypi/pico-sdk#2315 and raspberrypi/picotool#207 - it requires both of those so should only be merged once those have been merged
Also fixes #613 in passing, as that is now handled by picotool.