I realized while doing that the value of the OemK1 fuse is used to decrypt the EKS partition (A_eks). Since the default value of that fuse is 0000000000000000000000000000000000000000000000000000000000000000, optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh recommends keeping that value when first trying out Disk Encryption.
Now that it works, I understand, we should generate a random key is fused into OemK1 so that it’s not trivial to decrypt the EKS partition.
So I would like to understand if it’s possible to JUST fuse the OemK1 without fusing ANY of the other fuses.
Would a fuse file like this be sufficient to have secure disk encryption working?
Even with Disk Encryption setup with a custom OemK1, if bootloader (and UEFI) secure boot is not enabled, then a threat actor could flash a custom bootloader or kernel image and still be able to read out the EKB and decrypt it right?
I am trying go about this step by step. So once I can get disk encryption working with a custom OemK1, I will look at setting up secure boot.
that’s correct, if someone can manipulate contents of QSPI out of band, FW can be erased to cause denial of service attacks. UEFI variables can be manipulated to use.
please see-also The Threat Model for more details.
I tried this. I have a Jetson Nano setup with disk encryption using a non-zero oem_k1.key (using steps here) . Then I fused the OemK1 fuse using the fuse.xml and omdfuse command above. Here is the output from FSKP when the actual fuse was burnt.
I> FSKP (version: 0.0.0.0-t234-54845784-8e9545b6)
I> t234-A01-1-Silicon (0x12347)
I> Emulation:
I> Entry timestamp: 0x008bedb3
I> Regular heap: [base:0x40040000, size:0x10000]
I> DMA heap: [base:0x173800000, size:0x800000]
I> Task: Crypto init
I> Task: Program CBB PCIE AMAP regions
I> Task: Burn fuses
I> Index : 1 OemK1 size: 32
I> Fuse Blob found
I>
I> Burning fuses
I> 1. Start OemK1 burn
I> 1. OemK1 burnt successfully
W> No handling of CRC-32 for OemK1
I>
I> Successfully burnt fuses as per fuse info
I> Index : 1 OemK1 size: 32
I> Fuse Blob found
I> No RPMB provisioning details is found. Skip RPMB Provisioning.
I> FSKP finished
And now it fails to decrypt the rootfs.
ERROR: fail to unlock the encrypted dev /dev/nvme0n1p2.
Then I was wondering if I needed to change the order and tried to re-flash the EKB image using
Even doing a full flash (using steps here) with the correct oem_k1.key and the eks_t234.img derived from the correct oem_k1.key I am unable to decrypt the disk.
ERROR: fail to unlock the encrypted dev /dev/nvme0n1p2.
I’m attaching the UART boot log. boot-uart.txt (69.7 KB)
is it possible for moving forward to the latest JP-6.1/r36.4.0 for verification?
FYI,
there’re OEM_K1/K2 to derive a root key which is itself used to sign and encrypt the EKB.
in r36.3.0 release version, it was using OEM_K2,
in r36.4.0 (the latest release version) they are both used to open EKB.
furthermore, OEM_K1, it is the root of trust of EKB, and it is used to derive the RPMB key too. OEM_K2, it is to derive the PV encryption key. If you don’t need to encrypt CPUBL with a PV key, you don’t need to care about OEM_K2.
OK. I moved up to JP-6.1/r36.4.0 but I’m getting the same error.
��NOTICE: BL31: v2.8(release):e12e3fa93
NOTICE: BL31: Built : 21:01:44, Sep 12 2024
I/TC:
I/TC: Non-secure external DT found
I/TC: OP-TEE version: 4.2 (gcc version 11.3.0 (Buildroot 2022.08)) #2 Fri Sep 13 04:10:17 UTC 2024 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: Test OEM keys are being used. This is insecure for shipping products!
E/TC:00 00 ekb_extraction_process:404 Tried all EKB_RKs but still can't extract the EKB image.
E/TC:00 00 jetson_user_key_pta_init:1154 jetson_user_key_pta_init: Failed (ffff000f).
E/TC:00 00 call_initcalls:43 Initcall __text_start + 0x001ad560 failed
I/TC: fTPM ID is not enabled.
I/TC: ftpm-helper PTA: fTPM DT or EKB is not available. fTPM provisioning is not supported.
I/TC: Primary CPU switching to normal world boot
��
Jetson UEFI firmware (version 36.4.0-gcid-37537400 built on 2024-09-13T04:02:39+00:00)
....
[ 13.156787] tegra-xudc 3550000.usb: Adding to iommu group 7
[ 13.189660] Cryptsetup version: 2.4.3
[ 18.314325] ERROR: fail to unlock the encrypted dev /dev/nvme0n1p2.
[ 18.316975] Kernel panic - not syncing:
[ 18.316978] Attempted to kill init! exitcode=0x00007f00
[ 18.316983] CPU: 3 PID: 1 Comm: bash Not tainted 5.15.148-tegra #125
we’ve test locally to confirm disk encryption is working.
I also have disk encryption working without fusing. I am seeing the issue when I fuse the OEM_K1 key using odmfuse.sh and then the encryption stopped working.
please also examine your EKS image,
there are 4 magic bytes at the beginning of the EKS image, they are: “EEKB”, if these 4 bytes are wrong, you will see “eks image not correct”.
for instance,