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.
" 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?
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.
Thank you JerryChang, I think you answered my question and this is going to work for us. I will try to clarify further:
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
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.
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
(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.
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.