I'm looking to use an encrypted USB drive as a key to unlock my system's root partition. Putting sda3_crypt UUID=5fa565ce-aa25-46f2-b730-e5b26f66db80 /dev/disk/by-label/drive:/key luks,keyscript=/lib/cryptsetup/scripts/passdev in /etc/crypttab works but it's using an unencrypted partition on the drive. I've triedkey UUID=9ed4add0-81e8-41ab-b1fe-0412e879eef0 none luks
sda3_crypt UUID=5fa565ce-aa25-46f2-b730-e5b26f66db80 /dev/mapper/key:/key luks,keyscript=/lib/cryptsetup/scripts/passdev
but it never prompts me for the password to the USB drive's partition. It just doesn't boot. What am I missing?
1 Like
I'm not 100% certain but I doubt it works that way. Either you store the key in plaintext or just use a passphrase... either or there's no sense in having to decrypt a key in order to use it, since you must have something plaintext to unlock the first key in the first place, sounds like unnecessary extra hoops if you ask me.
1 Like
Is this just an experiment, what's wrong with LUKS on its own ?
Maybe if you know you're way around systemd you could get the usb to unlock first and then the other disks but I don't know. The way it normally works is crypttab is read first, then fstab, which means that a file system can't be mounted before the encrypted disks are opened. There is a way around this by editing /etc/default/cryptdisks to include the line CRYPTDISKS_MOUNT="/path/to/key/mount". This will mount the file system containing the key files before crypttab is read. However if the filesystem containing the keys is also encrypted then I don't think it will work as it won't be able to mount a file system on a luks disk before it's been unlocked.
I think you should either just use a password or use keyfiles and remove the usb disk when not needed. Or do what I do and store your keyfiles on a remote server.
1 Like
@Baz @meggerman the reason I'm looking to do this is to effectively have a kind of multifactor authentication. The password would be useless without the flash drive and the flash drive would be useless without the password. Do I need that level of security? Not really but I thought it would be cool if I could get it working.
1 Like
You shouldn't need to mount the file system. In crypttab you can do /dev/blockdevice:/path so assuming you can decrypt it you should be fine. The problem I've noticed is that the system always attempts to decrypt my root partition first even if it isn't the first entry in crypttab. Provided I use password decryption on both it first decrypts my root partition and then decrypts my flash drive even though the order in crypttab is the reverse.
Well, what are the chances that your password will be guessed the first few times ?
It won't be. Like I said. Do I need this level of security? No. Even still I like the idea of it.
1 Like
Well I was going to suggest an alternative was all.
And that would be?
kill switch in LUKS when you enter the wrong password a user set number of times it destroys the LUKS volume rendering the data unrecoverable.
How do you set that up?
It was actually going to be included in part of the LUKS standard features but for some reason they didn't patch it in.
experiment with data you don't mind losing but you can backup the keyslots on another secure container. Not many people know about that patch.
...didn't know you could backup key slots. I've been keeping a copy of the master key in the event I screwed up.
1 Like
Yes you can, cool eh ?
That's actually really nifty. That should be in the upstream code base. I wonder why it's only in Kali?
Perhaps it is seen as tinfoil ?
I hope that's not the reason. I mean even if you don't do this you can just have a reasonably strong password and bruteforce becomes basically useless anyway.
Either way the kill switch is nice because you could go on holiday, intentionally kill it and then return and enter the backup key. But yea I wouldn't use it.
Perhaps that's the reason it's not included because it is a really fringe use case.
Yea maybe. I still don't see the harm in upstreaming it though. Even if most don't use it there will be some that do.