You are not logged in.
I am writing cmdline to load the kernel and want to open two disks in a specific order.
On the first disk, I store the key for encrypting the second disk and I want to open it only after entering the password, and the second disk already decrypt with the key, which is stored on the first disk.
But I faced with the limitation that only the last cryptdevice= works when loading the kernel, since this is a global environment variable for the hook.
I solved this by copying the encrypt 'hooks' and 'install' files with different names and changed variable names, but maybe there is some better way?
SOLUTION:
I decided use udev hook and copy encrypt hook to encrypt2 as it was described here:
https://wiki.archlinux.org/index.php/Dm … partitions
But also I recommend replace 'crypto' to 'crypto2' in encrypt2 hook file
Last edited by HardDie (2020-03-10 21:28:26)
Offline
Why do you need to decrypt the second disk in the initrd? Typically the scope of the initrd is specifically to mount the root filesystem (and any ancillary filesystems necessary to boot the system proper, i.e. /usr), which is why you're encountering this problem.
If you're decrypting the second disk using a keyfile stored on the first disk, could you not decrypt it after the initrd has completed?
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
I have such setup
/dev/sda - root partition, encrypted with dm-crypt
/dev/sdb1 - efi boot partition
/dev/sdb2 - key-file
By default, archwiki simply stores the key in /dev/sdb2 and, if someone dumps it, open /dev/sda without any problems.
But I decided to decrypt /dev/sdb2 using luks and set the password only after that I can access the key file.
Offline
Have you explored using the sd-encrypt hook?
Offline
It looks like sd-encrypt not support dm-crypt partitions
As said in wiki:
"The rd.luks parameters only support unlocking detectable LUKS devices. To unlock a plain dm-crypt device or a LUKS device with a detached header, you must specify it in /etc/crypttab.initramfs."
Or this file /etc/crypttab.initramfs located inside /boot/initramfs-linux.img?
Offline
Ok, I figured out with crypttab, you just need to create /etc/crypttab.initramfs and then run mkinitcpio -p linux, it will automatically copy this file inside the initramfs image.
Now I can't find how to rewrite this cmdline command
ryptdevice=/dev/disk/by-id/disk-ID-of-sda:cryptlvm cryptkey=/dev/disk/by-id/disk-ID-of-sdc:0:64 crypto=:aes-xts-plain64:512:0:
to crypttab line
cryptlvm /dev/disk/by-id/disk-ID-of-sda /dev/disk/by-id/disk-ID-of-sdc ???
Offline
Have a look at the manpage crypttab,
in general each line has 4 fields:
name encrypted-device password options
The third field is either a password or a path to a file/device.
the 4th filed has options for
cipher= Specifies the cipher to use.
keyfile-offset= Specifies the number of bytes to skip at the start of the key file.
keyfile-size= Specifies the maximum number of bytes to read from the key file.
size= Specifies the key size in bits. See cryptsetup(8) for possible values and the default value of this option.
Note the remark on keyfile-size: Specifies the maximum number of bytes to read from the key file. See cryptsetup(8) for possible values and the default value of this option. This option is ignored in plain encryption mode, as the key file size is then given by the key size.
Offline
Yes, I saw the man page and tested in different combinations
plain,cipher=aes-xts-plain64,size=512,hash=plain
plain,cipher=aes-xts-plain64,size=64,hash=plain
and others combinations size and keyfile-size 64,512 and set both offset to 0
https://wiki.archlinux.org/index.php/Dm … n#crypttab
Here was described some bug in systemd, because of that I tested with plain and hash=plain but still it doesn't work
Offline
Have a look with "cryptsetup status" at your opened device to confirm your encryption settings.
Last edited by ua4000 (2020-03-08 11:53:54)
Offline
~# cryptsetup status cryptlvm
/dev/mapper/cryptlvm is active and is in use.
type: PLAIN
cipher: aes-xts-plain64
keysize: 512 bits
key location: dm-crypt
device: /dev/sda
sector size: 512
offset: 0 sectors
size: 16777216 sectors
mode: read/write
Offline
I found correct options but it works only when I set file as a key:
cryptlvm /dev/sda /tmp/my.key plain,cipher=aes-xts-plain64,size=512
But then I set /dev/mapper/cryptkey as key it doesn't work, and /dev/dm-0 too
Last edited by HardDie (2020-03-08 13:02:57)
Offline
I have no idey, why this doesn't work - maybe because you are at this time still in initrd ?
But I re-read your 1st post
On the first disk, I store the key for encrypting the second disk and I want to open it only after entering the password, and the second disk already decrypt with the key, which is stored on the first disk.
Why don't you use a simple keyfile from the 1st file system to open the 2nd ?
There is no additionally security using a device over a keyfile (with only root access).
The wiki has an example how to include the keyfile into initramfs
FILES=(/crypto_keyfile.bin)
If you take care of the other security advises there it's safe.
Offline
Okey, I found solution, just put path to key under quotes
cryptolvm /dev/sda '/dev/mapper/cryptokey' plain,cipher=aes-xts-plain64,size=512
Offline
Why don't you use a simple keyfile from the 1st file system to open the 2nd ?
There is no additionally security using a device over a keyfile (with only root access).
The wiki has an example how to include the keyfile into initramfs
FILES=(/crypto_keyfile.bin)
If you take care of the other security advises there it's safe.
I just want it to work as with the ssh key, even if someone stole the key, he could not use it without a password.
Because of that I don't want store it as plain text anywhere.
Offline
Yes, of course, a keyfile *must* be stored inside an encrypted realm, e.g. inside initrd, when the initrd is on an encrypted grub boot partition .
Nevertheless, keep in mind if the system is open and running that the master key is somewhere in memory...
For luks there is a command to display the master key: cryptsetup luksDump --dump-master-key
On plain mode there is most probably also a way...
P.S. If you are happy with your solution please edit your 1st post, and put a [SOLVED] in front of the Subject :-) Thanks!
Offline
Yes, of course, a keyfile *must* be stored inside an encrypted realm, e.g. inside initrd, when the initrd is on an encrypted grub boot partition .
Also I boot from uefi linux image.
I build this image like this:
INITRAMFS="/boot/intel-ucode.img /boot/initramfs-linux.img"
CMDLINE="cryptdevice2=/dev/sda:cryptkey cryptdevice=/dev/sdb:cryptlvm cryptkey=/dev/mapper/cryptkey:0:64 crypto=:aes-xts-plain64:512:0: root=UUID=3270d707-93e4-4a28-9c8b-89f8c0440fef rw quite loglevel=3"cat ${INITRAMFS} > initramfs.img
objcopy \
--add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
--add-section .cmdline=<(echo ${CMDLINE}) --change-section-vma .cmdline=0x30000 \
--add-section .linux=/boot/vmlinuz-linux --change-section-vma .linux=0x2000000 \
--add-section .initrd=initramfs.img --change-section-vma .initrd=0x3000000 \
/usr/lib/systemd/boot/efi/linuxx64.efi.stub arch.efi
And I think I can't encrypt this file.
But thank you for your help!
Offline
If you use grub, you can encrypt the boot partition,
https://wiki.archlinux.org/index.php/Dm … ion_(GRUB)
Offline
If you use grub, you can encrypt the boot partition,
https://wiki.archlinux.org/index.php/Dm … ion_(GRUB)
No, I don't use GRUB, as I said earlier I boot from linux image directry.
Efi support linux image without any bootloader.
After generating arch.efi I copy it to flash drive /EFI/BOOT/BootX64.efi
Offline