Secure Boot with RaspberryPi and Trust Zones

[Tombosco]

Hi there,
I have a specific question regarding the security possibilities on the Raspberrypi-Platform.
Is there a way to implement some kind of "secure boot"? Or working with OTP (one time programable) registers.
Our do you have recommendations how it could be implemented in an other way?
We plan to use a PI-Modul with a eMMC and not with SD-Card.
We would like to implement some how an "anti-cloning" usecase.
Do yo have any suggestions for this thematic?
I know, that ARM has so called "trust zones"... It' like a simple OS between the unsecure and secure world.
But is it possible to do a secure boot from a signed u-boot -> signed kernel -> signed Application?

Has anyone experiences?

Thanks for your help.
cheers,
Tom

[rln]

Unfortunately there is no good secure boot or copy protection for Raspberry Pi. Using a CM likely won't help since it can easily be hooked up to a PC via USB. Obfuscation is probably the only available protection mechanism.

[Tombosco]

Hi,

OK, yes I know that with the USB possibility. But, let's say we want to make it as secure as possible...
What would be your suggestion? (of course, "don't use Raspberry..." )
Do you have experience with trust zone?

cheers

[rln]

As far as I know noone has ever gotten TrustZone to work on Raspberry. Likely the Pi Foundation is the only one with knowledge and resources to get that working. The "rest" of us has to resort to either a good-enough obfuscation solution where piracy is sufficiently difficult or a web-based cloud service.

For my own project (which needs to work offline) I'm hiding part of my secret business logic inside the Linux kernel (binary module). Usually that's a big no-no, but doing so makes it a lot harder to copy. The big issue though is staying compliant with Linus license policy.

[fruitoftheloom]

Hi there,
I have a specific question regarding the security possibilities on the Raspberrypi-Platform.
Is there a way to implement some kind of "secure boot"? Or working with OTP (one time programable) registers.
Our do you have recommendations how it could be implemented in an other way?
We plan to use a PI-Modul with a eMMC and not with SD-Card.
We would like to implement some how an "anti-cloning" usecase.
Do yo have any suggestions for this thematic?
I know, that ARM has so called "trust zones"... It' like a simple OS between the unsecure and secure world.
But is it possible to do a secure boot from a signed u-boot -> signed kernel -> signed Application?

Has anyone experiences?

Thanks for your help.
cheers,
Tom

http://linuxgizmos.com/trustzone-tee-te ... erry-pi-3/

https://www.op-tee.org/docs/rpi3/

[n0w4y]

TrustZone implementation on RPi is good for education but offers no security.

The Pi lacks the hardware capabilities that enable TrustZone to
enforce any security separation. Memory on the Pi is a big, flat space.

For secure boot, the Pi has no immutable boot code. Bolting on a TPM or external secure element
is a waste of hardware. Solutions like this are as useless as a bolt-on SE on any system where
there is no OTP lockable, immutable boot code.

If you want secure boot and TrustZone capabilities then use another SoC. The Pi silicon
just can't do it.

[metalmajor]

Hi,

I noticed this discussion and want to ask, due to the last post here, is something like "zymbit" then worth it?

[rln]

Most likely not. Zymbit might be able to raise the bar a bit, but if they advertise a $1000 reward I'm sure their design would be hacked in a few days.

[iii3]

Could someone explain to me why you can't make a secure boot with RaspberryPi? TrustZone does not provide memory security?

[cleverca22]

from what ive heard, the trustzone signals from the arm core, are just not routed to the ram controller

so even if you have a secure trustzone firmware in ram, which restricts access to some key material, any non-trustzone (linux kernel) task can just overwrite the trustzone firmware, or just read the keys directly

secureboot is also not really an option, because the rpi will just boot whatever is on the SD card, and anybody can just remove the card and read the files/config/binaries

there is some undocumented secure-boot-like stuff on the rpi4, that restrict the 1st stage(the bootcode.bin/spi-eeprom level) to being from somebody with keys to sign it

but the publicly available 1st-stage binaries, will just run any 2nd stage file(start4.elf) without validation, so even if security was turned up, an attacker could just downgrade the 1st stage and gain control of the hardware