Avoid entering passphrase for encrypted partition at boot time

[jdiegodelgado]

Hi,

I have encrypted an external partition of an SSD that is attached to my Jetson. This encrypted partition was permanently mounted on the Jetson /etc/fstab.

But every time that I reboot the board I have to manually enter the passphrase using the serial logs:

Please enter passphrase for disk APP_ENC (hpi) on /mnt/capturemodes:

Is there a way to avoid entering this passphrase manually?
I mean, is there a way that the partition could read the passphrase from an specified path?

Best,

[linuxdev]

I don’t know of a way, but I’ll suggest that if nobody can answer, then editing an initrd can do this. In the past when SLIP/PPP was common (in the days when dinosaurs wandered the planet and used dialup), the “dip” program (or similar) was used to recognize command lines and respond with a scripted answer (it’s fairly simple, but it would respond for example with the speed setup, and then a password when it saw the password prompt).

If you truly need the partition encrypted though, beware that most any automatic password is the same as not being encrypted (including if you find a way to place the password in some sort of protected location; an exception might be a USB thumb drive since that can be removed).

[jdiegodelgado]

Hi @linuxdev ,

Thanks for your quick reply. I Agree with you, is better to have a normal partition than having an encrypted one that uses an automatic password. But the ideas of using a thumb drive to decrypt the partition or storing the password in a safe place sound really good.

Have you ever seen something like this, using a Jetson Xavier AGX?
So I can use that as an example or a guide.

Best,

[linuxdev]

Not in a long time (since before Jetsons). However, I’ve often looked at modifications to initial ramdisks for performing edits such as passwords. Normally an initrd would be used if you needed a rootfs for a filesystem type which is not built in (integrated) to the Linux kernel itself, or even if the initrd itself does not know how to read from such a filesystem. So far as I’m concerned, encryption is just a filesystem on top of a filesystem. That makes the initrd the perfect place for such a thing.

The initrd could be used to look for a specific password file on a USB thumb drive. You’re probably thinking of secure storage directly on the Jetson itself, but aside from the authentication key during early boot (which is more or less a black box), you’re not going to be able to read that memory later on. If the system always reads that hidden memory, then you essentially are not encrypting, because all boots which are properly signed will automatically load the password anyway. Granted, if you were to use dd to copy the raw bits of the partition, then this would help, but so long as it is mounted, then someone wanting that would just read the ext4 (or other standard partition filesystem type) device anyway.

Thumb drives are a nice idea. I’d want to find some method of making sure documents and files in the thumb drive are not automatically copied when plugging it in to a strange system though. You could eliminate this on Windows just by using ext4 on the thumb drive. Not hard to get around if you want the thumb drive to not be accessible as well on another Linux machine, but this could have a simple password, while the encryption password could be enormous and random. Or you could even invent your own filesystem type and have this available to the initrd. Maybe you could even put the key at some exact offset in unpartitioned space of the thumb drive, with a signature, e.g., old MBR style drives end the MBR with 0x55 0xaa; you could copy those two bytes, the file, and 0x55 0xaa to the end within non-partitioned space, and just “know” to look there and verify ID bytes. Anyone partitioning the thumb drive would “sort of” destroy the password if they did not know it was there. Even so, reading binary bytes at an offset doesn’t even require a filesystem driver. An initrd could easily do that if USB drivers are already loaded.