Discussion: Boot, TEE, and Security Directions for SPIRIT

[tym2k1]

I wanted to open a bigger-picture discussion around security mechanisms as there were some issues touching on this point (#47, #26) and what role these might (or might not) play in the SPIRIT project. Some folks are aiming for Android, some for Linux (PostmarketOS, etc.), and I think it’s worth aligning on what’s realistic for early prototypes vs. long-term goals.

This is not a blocker for running a minimal Linux or Android system on the RPi4/RPi5 CMs, those will run fine without TEEs or verified boot. But I figured it’s a good moment to talk about the security landscape so we know what’s possible, what’s wishful thinking and what is required for allowing it to be a daily driver.

RPI5 potential hiccups

Trusted Execution Environment (TEE)

A TEE allows for isolation of sensitive data like cryptographic keys and biometric information. For a true secure daily-driver it'd be a beneficial to have as PIN/Password verification that could live there similiar to Gatekeeper in Android that indeed does live within the Trusty TEE.

What’s available in theory:

• Trusty TEE (Google's TEE)
  • Open Source (search for "trusty" repositories)
  • Designed to support Android’s security model
  • Porting Trusty to Pi 5 would be a major effort, since it was never designed
    for this hardware platform
  • To achieve a Google-certified Android would be the way to go. But without such certification many features wouldn't work. GrapheneOS to my knowledge avoids this issue by using Pixel Phones where Trusty and Titan chips are already certified so the non-certified OS can still utilize them
• OP-TEE
  • Open-source and developed by Linaro
  • Widely used on dev boards, academic projects and easily integrated within Linux
  • Much more accessible to experiment with than Trusty
  • There is no maintained Android + OP-TEE integration tree anymore. There used to be an integration with AOSP project
  • OP-TEE hasn't been ported to RPI4/RPI5 but some work has already been done in this regard - plat: rpi5: add basic Raspberry Pi 5 support OP-TEE/optee_os#6854 / https://github.com/joaopeixoto13/OPTEE-RPI4

All other widely deployed TEEs (QSEE, Kinibi, MobiCore, etc.) are proprietary and vendor-specific, and realistically cannot be ported to Raspberry Pi.

Boot

For any security-sensitive feature to be meaningful, the system needs a reliable way to ensure that the software loaded at boot is exactly what it should be. This is where measured, verified, or secure boot mechanisms come in: they provide a chain of trust from power-on to the running OS, cryptographically validating each stage.

The Raspberry Pi 5 supports secure boot, which relies on signed bootloader images stored in the EEPROM and validated by the built-in Broadcom firmware. However it seems that the earliest boot stages are controlled by a closed-source GPU firmware, which limits full auditable verification but that might be considered just a minor drawback.

Minor points

• The datasheet of the currently chosen biometry module Fingerprint Cards AB 100018754 mentioned on wiki specifies that the CMD_IMAGE command with ARG_UPLOAD argument can be used to upload the biometric image from reader to the host. I haven't found information in the datasheet if this can be somehow disabled/fused. This means that, if the hardware is not routed through TEE, fingerprint readings can be easily stolen from userspace which is kind of bad as you can't really re-enroll biometric data.

• Arm TrustZone on Raspberry Pi has a history of being a little finicky with secure/non-secure flag on the axi bus not being wired into the memory controller for RPI3, RPI4 and from my understanding on RPI5 as well. This means that only software protection could be achieved and a compromised kernel could leak data. To achieve the secure/non-secure world isolation a static partioning hypervisor could be used like sel4 or Bao which solved this exact issue for RPI4 and could be ported to RPI5.

• There seems to be some talks about EU regulating hardware/app/OS verification for banking transfers adding some hurdle for potential daily-driving SPIRIT but I couldn't find source for these claims. If the project were to be verified to support such banking uses I'm assuming it'd require the above hardening functionalities.

Future prospects

• GrapheneOS project recently made a statement about Google Pixel locking down support for alternate OS's and it seems they might be interested in an alternative hardware for the project but it would have to support critical security features. As of now it looks that running "secure" Android would require a lot of work.

• Despite locking down alternative OS for Pixel Google has been contributing to the OpenTitan project which in short aims create an Open Source Silicon Root of Trust which serves a similiar purpose to the Google Titan M/M2 chips found in Pixel Phones. If this would to be integrated into the SPIRIT phone it could harden the security. It's also a cool research perspective as OpenTitan is currently in development phase and the SPIRIT could be a great target for it. It's also on the radar of GrapheneOS team

Closing thougts

I’m tossing these ideas out to get the conversation rolling. If I got something wrong just call me out (probably won’t be the last time 😅)
All of this also poses SPIRIT as a cool cybersecurity research target. Really curious to hear what others think and see the project grow <3

EDIT: typo + mentioned sel4

[tom133789]

OP-TEE is a great idear for Ubuntu, But Im not sure abaut Its Android Compadabilaty