Encrypting a logical partition on the device (nvluks-srv-app, initrd, JP 5.1)

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

With the older trusty and hwkey-app (and not nvhwkey-app) we used to be able to encrypt and then open a logical partition on the disk using a command similar to the following command. I believe in this case hwkeky-app provided a hardware specific key to the crypt setup.

hwkey-app -k -i <(echo ${KEY_LABEL}) -o - -u |
cryptsetup open --key-file -
/dev/${dev_name} mydir

but those options(-k -u) are no longer available with nvhwkey-app.

After some research it looks like a similar function is available via using the nvluks-srv-app

nvluks-srv-app --context-string “${DISK_UUID}” --get-unique-pass | cryptsetup -c
luksOpen <luks_device> <DM_name>

But I see places this in the documentation:

" To prevent any form of attack from extracting the passphrase at boot time (e.g. in the initrd), use the command type LUKS_SRV_TA_CMD_SRV_DOWN. This command instructs luks-srv not to respond to a LUKS_GET command (to get the passphrase) until reboot. This step is crucial to ensure the security of your design. "

So my questions is that is it possible to use this utility (or any other utility) to encrypt a logical partition (and not the entire disk) on the device?

3

hello KavehA,

sorry, I’m not really understand your request about “to encrypt a logical partition”.


let me have clarification as following…

it’s CA (i.e. nvluks-srv-app) can send LUKS_SRV_TA_CMD_SRV_DOWN command to TA for NOT responding to any LUKS_GET passphrase command again until reboot.
this allows the passphrase to be extracted during boot (e.g. in initrd), but then prevents any form of later attack/malicious-code that attempts to obtain the passphrase again.

4

Thank you JerryChang, I think you answered my question and this is going to work for us. I will try to clarify further:

  1. suppose during initrd you are creating logical partitions and you want to make one of those partitions protected via cryptsetup. Can this be done?
    what this means is that
    lvcreate … $LOGIAL_PARTITION_NAME (creates some logical partition)

once this is created
This is now like any other partition, can you open this partition using cryptsetup, in other words would the following command is going to work? Based on your last reply I assume that this is going to work

nvluks-srv-app --context-string “${LOGICAL_PARTITON_UUID}” --get-unique-pass | cryptsetup -c
luksOpen LOGICAL $LOGICAL_PARTITION_NAME $DIRECTORY

  1. How do we send a LUKS_SRV_TA_CMD_SRV_DOWNcommand to TA for NOT responding to any LUKS_GET, is that done automatically or can we control that call?
5

hello KavehA,

you may refer to op-tee examples for reference,
./optee/samples/luks-srv/ta/luks_srv_ta.c
./optee/samples/luks-srv/host/luks_srv_ca.c

6

Thank you JerryChang,
This is very helpful.

  1. I see that we have a generate a unique passphrase inside the host/luks_srv_ca.c (case/option get-unique-pass) and also we have code to generate the unique device passphrase inside the ta/luks_srv_ta.c (line 74). Can you please educate me and let me know what is the difference between these two.

  2. Now I see how to send a LUKS_SRV_TA_CMD_SRV_DOWN signal to the TA (inside host/luks_srv_ca.c) but my original question was on the process flow. is this done automatically after initrd or boot or do we need to send this signal manually, every time after boot, via no-pass-response option as shown inside the host/luks_srv_ca.c

7

hello KavehA,

(1) luks_srv_ca.c doesn’t “generate” the unique passphrase, it sends the request to luks TA, TA generates the passphrase. If you go along the code path, you’ll find actually luks TA doesn’t generate the passphrase as well because it doesn’t know the disk encryption key,
the jetson user key PTA finally does the key generation, i.e. invoke_jetson_user_key_pta

(2) Yes, this is done in “bootloader/l4t_initrd.img”. you may using the command gunzip -c l4t_initrd.img | cpio -id to extract the image, you’ll find a script named “init” in it.
At the bottom of this script, you can find…

# Disable luks-srv TA
nvluks-srv-app -n > /dev/null 2>&1;

This sends the LUKS_SRV_TA_CMD_SRV_DOWN to luks TA so no passphrase will be generated after this is done.
This prevents the passphrase from leaking once the encrypted rootfs is unlocked.

8

Very helpful thank you again. Now I understand that we can mount the file system during initrd:

nvluks-srv-app --context-string “${LOGICAL_PARTITON_UUID}” --get-unique-pass | cryptsetup -c
luksOpen LOGICAL $LOGICAL_PARTITION_NAME $DIRECTORY

and then send a LUKS_SRV_TA_CMD_SRV_DOWN to luks TA at the end of initrd. This way the passphrase can no longer be obtained

Is the idea here that the file system remains mounted and available once initrd is done or does it need to be re-mounted again?

9

hello KavehA,

you may refer to… Using the initial RAM disk (initrd) — The Linux Kernel documentation
and… I’ve also seen below via UART logs.

[   12.174016] Switching from initrd to actual rootfs
10

Thank you JerryChang,
We have our own custom initrd and there is no place in our initrd that we do a
nvluks-srv-app -n > /dev/null 2>&1;

Yet when the device boots and we execute:
nvluks-srv-app --context-string “${LOGICAL_PARTITON_UUID}” --get-unique-pass

we still get a “TEEC_InvokeCommand failed 0xffff0001 origin 0x4”

Do you know why this is happening and what is sending a LUKS_SRV_TA_CMD_SRV_DOWN to luks TA ?

11

hello KavehA,

we may debug this further.
it seems that LUKS_SRV_TA_CMD_SRV_DOWN still sent to LUKS TA despite you uses your own initrd.

could you please try…
(1) Add a debug print in luks_srv_ca.c when sending the LUKS_SRV_TA_CMD_SRV_DOWN
(2) Rebuild the nvluks-srv-app and replace the file in the rootfs
(3) Try again to see whether the print appears, if yes, that means there must be something which sent the LUKS_SRV_TA_CMD_SRV_DOWN.