Jetson Orin OP-TEE Encryption Flow

Hello there,

it’s been days since I’ve been trying to understand exactly what’s going on with the way the OP-TEE and the Encryption of the disk of a Jetson orin works.

The most important diagram that outlines the overall process is this one of course:


Figure 1
The thing that I can’t seem to understand is the relation between that last diagrame and these two:

Figure 2
image
Figure 3

In the figure 1 I get that we are trying to generate the passphrase using the pta, but what exactly is the EKB user-defined key for disk encryption that is used to generate the LUKS key, also in that figure 1 we only talked about the passphrase, where is the master key aka dek that dmcrypt uses to encrypt the disk, and when does the system encrypt it with the passphrase that luks srv generate.

I can’t seem to find the link between the figure 1 and figure 2 I know for sure that the figure 2 only happens once.

Last thing for now is what’s the real purpose of hwkey-agent I saw that it queries the user-defined EKB key from the pta and encrypt or decrypt data from a CA (are we talking about the disk’s data here im confused).

hello elhamriothman,

it looks like an issue following up from Topic 288196.


EKB user-defined key for disk encryption

let’s focus on EKS image, use-defined key is stored in this EKS image.
furthermore, there’re PKC, SBK…etc keys (you may refer to Secure Boot section) to sign/encrypt this EKS image.
you may also visit NVIDIA Jetson Linux 35.5.0 page to download [Driver Package (BSP) Sources] package, please extract nvidia-jetson-optee-source.tbz2 and checking sample script of gen_ekb.
for instance, ./optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh
as you can see… there’re user-defined symmetric key files used by gen_ekb.py to generate EKS image.

when performing $ sudo ROOTFS_ENC=1 ./flash.sh -i "./disk_enc.key" <board> <rootdev>
you’re given disk encryption key file, which should be identical with disk encryption key in the EKB partition you’ve flashed onto the target.

hope this explanation helps.

Oh ok I so the EKB user-defined key is used for the encryption of the disk ( LUKS) and the generation of the passphrase?

It’s just I don’t see the use of dmcrypt in the whole process don’t we use: this

Two types of keys are used for disk encryption:

  • The master key, also known as the Disk Encryption Key (DEK). This key is used for data encryption or decryption when data is transferred between the file system and the disk.The master key is generated by cryptsetup. The default and recommended source for data used to generate the key is /dev/random. The key resides in the LUKS header, and is encrypted by the key derived from the passphrase.
  • The passphrase or password is an input string or pattern supplied by the user to set up disk encryption and lock the disk. The same input is used to decrypt and unlock data stored on the disk.

hello elhamriothman,

per Details of Operation section.

there’s actually single key you should provide to enable disk encryption. it’s user disk encryption key, AKA disk_enc.key in the demonstration.
such passphrase is used by TA/CA, and it’s generated internally.

Hello Jerry,
I don’t understand your reply exactly, so the user disk encryption key is the root key to generate the passphrase and generate the LUKS key?

that’s correct.

Ok intersting I didn’t know that the disk encryption key has two uses,(dmcrypt and the passphrase).

One other thing that confuses me in the documentation:

image

in the flash do we give the cipher EKB content or the Plain ekb ekey file?

Update: I think I understand, we basically flash the disc_enk.key in plain text using the -i option ( which is the Plain EKB key file) and at the same time in the bootloader file we also generate the eks image that contains the disk_enk encrypted. so we basically falsh those two.

ya… as mentioned in previous comment #3, please update EKS image accordingly if you’re using customize disk encryption key.

Yes thank you so much, I understand just one last question before we close this topic:

Here the luks-srv dont give the cryptsetup the disk encryption too, where do we generate the master key?

hello elhamriothman,

did you meant how CA generate passphrase?
actually, CA does not generate an unique passphrase. CA sends the request to LUKS TA. it’s TA to generate passphrase.

I know that, no I mean how does the crypsetup know the disk encryption key, cause it’s in the side of the secure world. but the luks-srv TA only passes the passphrase to the CA. how does the CA know about the disk encryption key without the TA giving it to the CA.

don’t it explained here… Topic 288196.

I see so the disk encryption key is passed to the jetson through the flash tooling…

Also please fix this diagrame it doesn’t match the documentation:

They EKB key is from the PTA and not the hwkey-agent, no idea what’s the hwkey-agent purpose.

where is this diagram came from? I don’t see it in the r35.5.0 Disk Encryption developer guide.

It’s in an older version, cause I was looking for the purpose of hwkey-agent cause I still don’t understand what’s his use in the disk encryption I don’t even think we use it in disk encryption maybe only to generate the ekb image.

hello elhamriothman,

it’s CA sample, hwkey-agent to generate eks.img, and then Trusty to retrieve user_key from eks.img.

Oh ok I see so it’s in the side of the host.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.