UC20 amd64 - FDE/Secboot not working

[rahul-tt]

@ijohnson

Hi @ijohnson,

I have a arm64 system. I downloaded pi-kernel snap and add fde-setup and fde-reveal-key to it. Would the process you mentioned to sign the kernel be valid on a arm64 pi-kernel snap too? Would sbsign work on that too?

[ijohnson]

The Raspberry Pi is not a UEFI system so no, you don’t need to sign any EFI assets there

[rahul-tt]

Ok, so how do I enable Secure boot in a non UEFI system with FDE.
I though i had to sign it with a key that generate to enable secure boot.

[ijohnson]

I’m sorry the Rasperry Pi is not a platform we support for FDE so I cannot help you anymore here, perhaps others have more time

[rahul-tt]

Thanks for letting me know

[ogra]

in general, you wont be able to make a Pi4 actually being secured, even if you get something to work as proof of concept … the only way to have an actually secured boot is to have the first loader be signed and be able to verify the keys of the subsequently loaded elements, it is a complete chain where each element needs to secure the following one …

The Pi uses its graphics driver blob to boot (it fires up the GPU first, only then the ARM is started fome the start.elf loader) … this “bootloader” is a proprietary thing that does not support key management nor can you sign it, which in turn compromises the whole secure boot chain …

[rahul-tt]

OK, but i am trying to follow these links to provide a partial encrytion to RPi4. Would that work?

UC20/UC22 full-disk-encryption hook interface

Ubuntu Core 20 and 22 (UC20/UC22) use full disk encryption (FDE) whenever the hardware allows, protecting both the confidentiality and integrity of a device’s data when there’s physical access to a device, or after a device has been lost or stolen. Creating a verifiable boot process on a non-standard (non-UEFI+TPM platform) FDE platform, such as on a Raspberry Pi or other ARM devices, is board-specific and will typically involve creating custom gadget and kernel snaps. UC20/UC22, however, do …

and

edk2-platforms/Platform/RaspberryPi/RPi4 at master · tianocore/edk2-platforms

to create a UEFI firmware for RPI and enable secure boot to get tpm to encrypt the RPI partitions.

[ijohnson]

Even if you are running a UEFI bootloader, there is nothing stopping an attacker from swapping out your UEFI bootloader and inserting themselves into the middle to be able to catch the decryption key because the platform firmware (i.e. the GPU on the rpi) does not support secure boot measurements the same way a more traditional x86 device with integrated secure boot in the BIOS, etc.