We only care about the software not being tampered with, we don't want someone trying to install some kind of backdoor into the device, even if that's unlikely. Software itself can be in plain text, we don't care.Question is if it is per-device secrets that need to be protected, or software/IP.The above are possible but time consuming and possibly expensive to do on a per device basis, and are mitigated by not having shared secrets across a fleet of devices.
Regarding time consuming. Commercial software to find the LUKS password in a memory dump is readily available to anyone that can afford it.
@dividuum and @timg236
Yes, signed EEPROOM bootloader with a public key hash in OTP seems like exactly what I want. While I was researching OTP I saw a notice that said anybody can read OTP, so I assumed that's not the right place to store a secret, but I didn't know the eeprom bootloader can also be signed.
In that case we program a signed eeprom bootloader and program the otp. from that point forward only a signed eeprom will run and it will only load a signed boot.img file, be it U-Boot or Linux. From this point we can trust this file. It could just be a plain text linux image, but for good measure it could be encrypted with LUKS and the same key from otp could be used to unlock it. Am I right ?
Also, can this be done from PI itself ? I've read this tutorial https://pip.raspberrypi.com/categories/ ... -Howto.pdf and it mentions changing a jumper on the board to switch from booting from eMMC to booting from usb, requiring another computer to program the hardware. Hopefully eeprom and otp can be written from Pi itself.
We want to manufacture these machines in a factory so I'm also considering the simplest provisioning mechanism. I thought of doing a network boot into a factory image that would program the signed eeprom image, download and encrypt the real software with luks and reboot.
Statistics: Posted by pseregiet — Wed Jul 24, 2024 11:36 am
