Hello. I want to use Raspberry Pi 5 board for a kiosk product that will be placed in a public place, therefore I want to secure its software from tampering, prevent installing a backdoor and such. I use the term "secure boot" colloquially here, I doesn't have to be THE "Secure Boot" from UEFI world exactly.
I see two possible scenarios
1. All software is in plain text but must be signed. Potential attacker can dump the sd card content but cannot boot any other/modified image.
2. All software is encrypted, attacker can replace sd-card with own content, run any software they want, but they have no access to our original software.
I've done some research into this topic and it appears a complete chain of trust is not possible on rpi5 without additional hardware. I know there's hardware like "LetsTrust TPM" for RPI, but I'm not exactly sure if that's really enough, since we can reprogram the bootloader in EEPROM at any point, right ?
BTW I intend on using Mender for in the fields updates, so my current boot chain is like this
rpi's bootloader - > U-Boot -> Linux (partition A or B)
and I imagine this sort of flow with the encryption and TPM installed
rpi's bootloader - > U-Boot -> Linux + small initramfs (selects the partition and unloks LUKS) -> Linux
I'm not super familiar with TPM so excuse my errors if I make any, but from what I understood, each bootloader should hash the next loader and use that hash as a TPM measurement, all these measurements add up together and if it's what we expect we can unlock the secret. But if we can replace our first bootloader we can patch it so it doesn't jump to original U-Boot. We calculate the hash and send that to the TPM but actually boot a different build of U-Boot, that different build of U-Boot could do the same, hash the original linux+initramfs but launch another and then the hacked initramfs could dump our secret. Right ? I assume there is something that I am missing, otherwise hardware like "Lets trust TPM" would be pointless.
I see two possible scenarios
1. All software is in plain text but must be signed. Potential attacker can dump the sd card content but cannot boot any other/modified image.
2. All software is encrypted, attacker can replace sd-card with own content, run any software they want, but they have no access to our original software.
I've done some research into this topic and it appears a complete chain of trust is not possible on rpi5 without additional hardware. I know there's hardware like "LetsTrust TPM" for RPI, but I'm not exactly sure if that's really enough, since we can reprogram the bootloader in EEPROM at any point, right ?
BTW I intend on using Mender for in the fields updates, so my current boot chain is like this
rpi's bootloader - > U-Boot -> Linux (partition A or B)
and I imagine this sort of flow with the encryption and TPM installed
rpi's bootloader - > U-Boot -> Linux + small initramfs (selects the partition and unloks LUKS) -> Linux
I'm not super familiar with TPM so excuse my errors if I make any, but from what I understood, each bootloader should hash the next loader and use that hash as a TPM measurement, all these measurements add up together and if it's what we expect we can unlock the secret. But if we can replace our first bootloader we can patch it so it doesn't jump to original U-Boot. We calculate the hash and send that to the TPM but actually boot a different build of U-Boot, that different build of U-Boot could do the same, hash the original linux+initramfs but launch another and then the hacked initramfs could dump our secret. Right ? I assume there is something that I am missing, otherwise hardware like "Lets trust TPM" would be pointless.
Statistics: Posted by pseregiet — Tue Jul 23, 2024 1:37 pm — Replies 0 — Views 49