PiGraham wrote: ↑
Tue Mar 24, 2020 8:58 pm
cleverca22 wrote: ↑
Tue Mar 24, 2020 7:32 pm
it would be far simpler to just patch the program to not check the serial#
and if your using encryption with the serial# as the key, just read the serial# with a different distro, and decrypt it
the ideas i gave, stop them from even knowing the serial#, so they cant do either of the above
So, we agree that a simple key is very crackable.
But secure boot seems to be about ensuring the (UFEI) firmware only boots into signed code (kernel) but something more is required to secure individual userland applications. How do you leave the platform open to makers and students with full root access and also lock down particular applications in a way that is somewhat hacker-proof?
I'm also wondering how a locked-down kernel sits with open source licences. Users are free to build their own version of the OS from source. How do you keep RPi both open and closed?
by default, all of the secureboot stuff is disabled on the rpi 1-3, some users have enabled it, but that effectively bricked the pi, due to lack of understanding for signing
the rpi4 required signed SPI firmware to boot, but it doesnt validate the start4.elf stage, so you loose all security
for both, thats "open" enough to allow developers to play and hack with it
if you wanted proper security, you would need a custom signing key, and enable signature checking, so only an authorzed bootcode.bin can run
then bootcode.bin must be modified to maintain the chain of trust all the way to linux (either open firmware, or ask the foundation, as i said earlier)
and then using that secureboot, you can block reads from the OTP, so you can just put something like a luks password in OTP to protect the real app
the biggest blocker for all of that, is getting an rpi where the signing key hasnt been burned into the OTP, so you can burn your own custom key, which only you know, you would need some special request to the place assembling the pi's, to get them to skip a step while assembling it