Hi Stephen,
I'm sorry for late reply but I was busy with bug fixing lately...
On 8/27/21 1:29 PM, Stephen Feyrer wrote:
Hi Everyone,
That should give you an idea of what the script does but I'll give a
brief explanation for clarity:
1. First it reads this file and gets the time out.
2. The script enters a loop waiting for a USB Yubikey to be detected.
3. Then when it detects a key, the serial number is checked and the
data for that key is read.
4. The script chooses the enabled slot on the Yubikey. If both slots
are enabled then it would choose the first slot, which if it fails
then disable that slot and fail to boot.
5. The password hint is printed as a re-assurance to the user that
their key has been recognised.
6. If a password is required (recommended), ask the user to enter their
password and store in a variable (not the most secure but this is my
first pass at the script).
7. Call GPG to decrypt the seed value using the stored password.
8. Pipe the decrypted value to ykchalresp using the selected slot
9. Pipe the returned value into cryptsetup to open the desired device.
10. Generate a new raw seed value with uuid-gen.
11. Replace the cryptsetup password.
12. Call GPG with the stored password and encrypt the new seed.
13. Write the encrypted seed value over the original.
14. Pass control back to the system.
See what LUKS2 external token handlers (plugins) allow since cryptsetup
2.4.0 upstream release.
There's simple example in cryptsetup sources, see "tokens/ssh" subdirectory.
Also, there are already 3 implementations of LUKS2 external handlers
available in systemd project, for example. For anyone interested, feel
free to look in src/cryptsetup/cryptsetup-tokens sources of systemd for
inspiration/guidance on how to write native cryptsetup LUKS2 plugins.
For example systemd-fido2 token is pretty close to 2fa you have
described above. Provided the hw token is configured to require
PIN/user_presence to release secret. It basically create new LUKS2
keyslot that can be unlocked with key provided only by fido2 token when
user provides right PIN (or touches hw token).
Any extension to LUKS2 token based device activation is expected to
implement utility for binding LUKS2 device to alternative activation
method (LUKS2 token metadata extension). In case of ssh plugin it's
cryptsetup-ssh utility in case of systemd extensions, it's
systemd-cryptenroll utility. Those utilities bind LUKS2 device (write
LUKS2 token json metadata) to some other method how to obtain LUKS2
passphrase (KEK) securely (even remotely).
The second part of each extension is plugin used to unlock such bound
keyslot. libcryptsetup-token-ssh.so for example. cryptsetup library
loads such plugin when it discovers appropriate LUKS2 token assigned to
usable LUKS2 keyslot. The plugin then extracts key from remote
host/yubikey/tpm2 or whatever and libcryptsetup unlocks device with MEK
decrypted from bound keyslot.
Basically anyone can now write LUKS2 extension that plugs-in "cryptsetup
open" command provided the device is LUKS2 format version.
From cryptsetup cli perspective it works as follows:
In before activation by passphrase (interactive query) we try to
activate device using any available token handler in the system
(crypt_activate_by_token & crypt_activate_by_token_pin library API).
Only when no appropriate LUKS2 token can be used to unlock the device we
fall back to passphrase based activation.
So if anyone is willing to implement another 2FA method they're most
welcome to. We'll provide them with help in case anything in
libcryptsetup is missing (or buggy), but we do not plan to implement any
LUKS2 external token implementation in nearterm. We're (upstream) very
limited in workforce.
Regards
O.
_______________________________________________
dm-crypt mailing list -- dm-crypt@xxxxxxxx
To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
