What version of snapd are you creating this image with?
For any new install with FDE in Intel, you have to reset the TPM first. You will have to do that before any install attempt on the same device.
Are you using the standard
pc gadget, or you’re own custom gadget ? Can we see your model assertion ?
Sorry, I cannot share the assertion here. I am using a custom gadget. The main difference with standard one is ‘prepare-device’ script.
Well, the gadget is likely where the issue is in this case.
Without knowing all the differences with the reference x86 gadget it will be hard to give you any advice I think. Using an efi executable signed with the incorrect keys can lead to that error, but I’m sure there are many other reasons. It’s probably a good idea to examine all the differences between the reference gadget and your own.
It appears, for some reason the key to unlock your data volume was not retrieved from the TPM. Perhaps there are more log lines before that error that can help.
This could provide some inspiration, where I had a similar error, but as I already said the reasons could be many, and could therefor be different: Changes in shim-signed packaging and breakages in UC20 secured grade model images on amd64
Thanks Just, will take a look into the logs. I upgraded BIOS to support Secure Boot and then enabled Secure Boot in BIOS. I also found there is an EFI partition in hardware. I saw grub64.efi and bootx64.efi. Are they used to boot UC20? I’m not sure how the EFI boot works since there are 2 places having *.efi files.
sorry, missed the msg It is 2.52.1 on snapd stable channel.
I also tried this image, https://cdimage.ubuntu.com/ubuntu-core/20/stable/current/ubuntu-core-20-amd64+intel-iot.img.xz, and got the same error.
Update: sorry, FDE didn’t work before. I installed the image and then enabled Secure Boot in BIOS so it started successfully without FDE.
Update again: The error should be from this line, https://github.com/snapcore/secboot/blob/e3a397e2da905022392bf3b429d6892e9cc4f070/efi/secureboot_policy.go#L1034, but no idea how to work around it…
I am trying UC20 with fde on arm64 machine and I get
secboot_tpm.go:77: checking if secure boot is enabled… secboot_tpm.go:79: secure boot not enabled: not a supported EFI system taskrunner.go:271: [change 2 "Setup system for run mode" task] failed: cannot encrypt device storage as mandated by model grade secured: not a supported EFI system
May I ask how you enabled secure boot . I get a /dev/tpm0 port but during first boot TPM was not mentioned at all.
@rahul-tt note that if you are on arm64 and do not have UEFI, then you cannot take advantage of the automatic FDE, and instead need to implement full disk encryption hooks in your kernel snap. This is not yet fully documented, but you can take a look at examples in the snapd codebase: https://github.com/snapcore/snapd/blob/master/tests/nested/manual/uc20-fde-hooks/task.yaml and the hook itself: https://github.com/snapcore/snapd/blob/master/tests/lib/fde-setup-hook/fde-setup.go
Also please note do NOT use the code verbatim from those hooks - the “encryption” implemented there is just XOR’ing bytes to test that the hooks work, it is not a secure implementation.
I did add fde-setup hook and added fde-revel-key into initrd/usr/bin. I have compiled the kernel and created an image. But I want to boot the image in Secure boot. I am following this documentation
But I am not able to quiet follow the procedure explained. Could you help me with this process.
I have created keys to sign the image. But when signing it requires PE/COFF image and I am not able to understand what that is.
$ signing-tool --sign --private-key=./private/archive-subkey-private.key --cert=./archive-subkey-public.crt --ca=./master-public.pkcs7 <PE/COFF image>
@rahul-tt where do you see the information from that page where it says to use
signing-tool? I’m not familiar with that tool, when I need to resign EFI assets like grub, or kernel.efi to test secure boot with snakeoil keys for development I use this command:
sbattach --remove "$gadgetdir/shim.efi.signed" SNAKE_OIL_DIR=/usr/lib/ubuntu-core-initramfs/snakeoil sbsign --key "$SNAKE_OIL_DIR/PkKek-1-snakeoil.key" --cert "$SNAKE_OIL_DIR/PkKek-1-snakeoil.pem" --output "$gadgetdir/shim.efi.signed" "$gadgetdir/shim.efi.signed"
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?
The Raspberry Pi is not a UEFI system so no, you don’t need to sign any EFI assets there
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.
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
Thanks for letting me know
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 …
OK, but i am trying to follow these links to provide a partial encrytion to RPi4. Would that work?
to create a UEFI firmware for RPI and enable secure boot to get tpm to encrypt the RPI partitions.
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.