Massflash with Generic password and per-device key replacement : How is the reencryption key chosen?

[cleng]

Hello,

Following this post, I am reposting the different question in different threads.

@JerryChang

here’s command-line of gen_ekb.py tool to generate an EKS image file,
as you can see…

$ python3 gen_ekb.py -chip t234 -oem_k1_key oem_k1.key \
        -in_sym_key sym_t234.key \
        -in_sym_key2 sym2_t234.key \
        -in_auth_key auth_t234.key \
        -out eks_t234.img

it also uses OEM_K1, which is one of fuse variable.
please see-also Jetson Orin Fuse Specification for details.

Here my question is, in a massflash scenario, with a generic password and per device key replacement. How is the new key generated. In a classical flash, the encryption is based on the eks and an user chosen password (the sym2_t234 key). As showed in this image. The encryption is then based on the oem_k1 fuse value and thus the encryption is unique to the device.

When using a generic password and reencryption, How is the new key generated ? What value is used to construct it since the new key is chosen on the device and not with gen_luks_password.py script? Is the new key chosen based on the fuse of the board ?

Kind regards,
cleng,

[JerryChang]

hello cleng,

it’s still using sym2_t234.key, but images encrypted by the generic passphrase flag to ignore ECID.
since ECID has ignored, you may using single image deploy to multiple devices.

[cleng]

Hello JerryChang,

Okay if I understood, the key of encryption is the same for every flashed device since they are all using sym2_t234.key ?

Normally, in the doc It is said that the generic key is then replaced by a per-device unique one .

But since, with the generic passphrase, the ECID is ignored. How does the generic password is replaced with an unique passphrase ? And how is the new key created ? What is it based on ?

[JerryChang]

hello cleng,

don’t the documentation mentioned the steps, Replacing the Generic Key with the Per-device Unique Key at First Boot?

[cleng]

Hello @JerryChang,

Just so you know, I have read the doc, multiple times. Hence, if there is a miscomprehension on my part it is not due to the fact that I have not read the documentation.

I did not quite catch your last post, Don’t what the documentation?

Also I re-read the doc Replacing the Generic Key with the Per-device Unique Key at First Boot, and it is clearly mentioned at step 4.

4. Verify that the device is encrypted by a generic key.
   If Yes, replace the generic key with the per-device unique key.
   If No, skip the key replacement process.

Then, it is said here that the generic key shall be replace with a per-device unique one.
So, I allow myself to repost the questions of my previous post :

• But since, with the generic passphrase, the ECID is ignored. How does the generic password is replaced with an unique passphrase ? How does the device create a unique key ?
• What is the key based on ? What is the per-device value that is used to create the unique key.

[JerryChang]

hello cleng,

>> Q1
it’s initrd to replace generic passphrase with unique passphrase.

BTW,
here’s an example of querying a unique per-device passphrase.
you may dig into public release sources, $public_sources/r36.4.0/Linux_for_Tegra/source/atf_and_optee/optee/samples/luks-srv/README
for instance, $ luks-srv-app -u -c "${DISK_UUID}"

>> Q2
A disk encryption key is created by yourself, such disk encryption key is aligned with the key, i.e. sym2_t234.key in EKS image.

[cleng]

Hello @JerryChang ,

Thanks your for answer ! I am going to review the README of the optee sources

@JerryChang

>> Q1
it’s initrd to replace generic passphrase with unique passphrase.

I uncompressed the initrd of my massflash to try to understand what really happens in the init script. From what you explained, the luks-srv-app is responsible to query the passphrase (as clearly explained in the docs) but it is also use to generate the new passphrase with the command : nvluks-srv-app -g -c "${crypt_disk_uuid}" > /etc/pk

So correct me if I am wrong : The re-encrytion is based on the disk uuid and the generic sym2_t234 key ?

@JerryChang

>> Q2
A disk encryption key is created by yourself, such disk encryption key is aligned with the key, i.e. sym2_t234.key in EKS image.

Just, for Q2, when I create a massflash, I create only 1 disk encryption key (sym2_t234). Also there, 1 EKS image for the massflash. Therefore, that cannot be this key that is used to re-encrypt the disk with a per-device unique passphrase.

From your previous post, I understand the re-encryption is done with the disk uuid and maybe the sym2_t234 ?

[JerryChang]

hello cleng,

please refer to Topic 288196,
gen_luks_passphrase.py is a tool at host side to generate passphrase for disk encryption when you create encrypted images.
nvluks-srv-app is a tool to run at device side to get passphrase generated from TEE at initrd stage for disk decryption.
they are different tools running for different purposes, but the output passphrase should be aligned or disk decryption will fail.