JakeHillion/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
0a256cc0ee
nixpkgs/nixos/modules/system/boot/luksroot.nix

460 lines
15 KiB
Nix
Raw Normal View History

Rewrite ‘with pkgs.lib’ -> ‘with lib’ Using pkgs.lib on the spine of module evaluation is problematic because the pkgs argument depends on the result of module evaluation. To prevent an infinite recursion, pkgs and some of the modules are evaluated twice, which is inefficient. Using ‘with lib’ prevents this problem.
2014-04-14 15:26:48 +01:00
{ config, lib, pkgs, ... }:
Encrypted root support via LUKS svn path=/nixos/trunk/; revision=24459
2010-10-25 01:57:30 +01:00
Rewrite ‘with pkgs.lib’ -> ‘with lib’ Using pkgs.lib on the spine of module evaluation is problematic because the pkgs argument depends on the result of module evaluation. To prevent an infinite recursion, pkgs and some of the modules are evaluated twice, which is inefficient. Using ‘with lib’ prevents this problem.
2014-04-14 15:26:48 +01:00
with lib;
Encrypted root support via LUKS svn path=/nixos/trunk/; revision=24459
2010-10-25 01:57:30 +01:00
let
Making the luks thing of initrd a bit more flexible. I used it to get a ciphered swap, where I could hibernate ciphered. svn path=/nixos/trunk/; revision=32754
2012-03-03 16:07:18 +00:00
luks = config.boot.initrd.luks;
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
openCommand = { name, device, keyFile, keyFileSize, allowDiscards, yubikey, ... }: ''
Making the luks thing of initrd a bit more flexible. I used it to get a ciphered swap, where I could hibernate ciphered. svn path=/nixos/trunk/; revision=32754
2012-03-03 16:07:18 +00:00
# Wait for luksRoot to appear, e.g. if on a usb drive.
# XXX: copied and adapted from stage-1-init.sh - should be
# available as a function.
if ! test -e ${device}; then
echo -n "waiting 10 seconds for device ${device} to appear..."
try isn't used, so use the more compatct seq 10
2012-06-27 14:43:54 +01:00
for try in $(seq 10); do
Making the luks thing of initrd a bit more flexible. I used it to get a ciphered swap, where I could hibernate ciphered. svn path=/nixos/trunk/; revision=32754
2012-03-03 16:07:18 +00:00
sleep 1
if test -e ${device}; then break; fi
Adding an option to luksroot, so it allows to define whether to launch cryptsetup after or before LVM. To allow dmcrypt over lvm and lvm over dmcrypt. svn path=/nixos/trunk/; revision=32784
2012-03-04 21:00:35 +00:00
echo -n .
Making the luks thing of initrd a bit more flexible. I used it to get a ciphered swap, where I could hibernate ciphered. svn path=/nixos/trunk/; revision=32754
2012-03-03 16:07:18 +00:00
done
echo "ok"
fi
LUKS root: Fix key file check Check for null instead of empty string
2012-08-02 10:39:31 +01:00
${optionalString (keyFile != null) ''
LUKS root: Add option for using a key file instead of a passphrase.
2012-05-02 23:37:14 +01:00
if ! test -e ${keyFile}; then
echo -n "waiting 10 seconds for key file ${keyFile} to appear..."
for try in $(seq 10); do
sleep 1
if test -e ${keyFile}; then break; fi
echo -n .
done
echo "ok"
fi
''}
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
open_normally() {
cryptsetup luksOpen ${device} ${name} ${optionalString allowDiscards "--allow-discards"} \
${optionalString (keyFile != null) "--key-file=${keyFile} ${optionalString (keyFileSize != null) "--keyfile-size=${toString keyFileSize}"}"}
}
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
${optionalString (luks.yubikeySupport && (yubikey != null)) ''
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
rbtohex() {
Replace the current Yubikey PBA implementation with the previous one. Rationale: * The main reason for choosing to implement the PBA in accordance with the Yubico documentation was to prevent a MITM-USB-attack successfully recovering the new LUKS key. * However, a MITM-USB-attacker can read user id and password when they were entered for PBA, which allows him to recover the new challenge after the PBA is complete, with which he can challenge the Yubikey, decrypt the new AES blob and recover the LUKS key. * Additionally, since the Yubikey shared secret is stored in the same AES blob, after such an attack not only is the LUKS device compromised, the Yubikey is as well, since the shared secret has also been recovered by the attacker. * Furthermore, with this method an attacker could also bruteforce the AES blob, if he has access to the unencrypted device, which would again compromise the Yubikey, should he be successful. * Finally, with this method, once the LUKS key has been recovered once, the encryption is permanently broken, while with the previous system, the LUKS key itself it changed at every successful boot, so recovering it once will not necessarily result in a permanent breakage and will also not compromise the Yubikey itself (since its secret is never stored anywhere but on the Yubikey itself). Summary: The current implementation opens up up vulnerability to brute-forcing the AES blob, while retaining the current MITM-USB attack, additionally making the consequences of this attack permanent and extending it to the Yubikey itself.
2014-02-03 21:50:17 +00:00
( od -An -vtx1 | tr -d ' \n' )
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
}
hextorb() {
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
( tr '[:lower:]' '[:upper:]' | sed -e 's/\([0-9A-F]\{2\}\)/\\\\\\x\1/gI' | xargs printf )
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
}
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
open_yubikey() {
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
# Make all of these local to this function
# to prevent their values being leaked
local salt
local iterations
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
local k_user
local challenge
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
local response
local k_luks
Replace the current Yubikey PBA implementation with the previous one. Rationale: * The main reason for choosing to implement the PBA in accordance with the Yubico documentation was to prevent a MITM-USB-attack successfully recovering the new LUKS key. * However, a MITM-USB-attacker can read user id and password when they were entered for PBA, which allows him to recover the new challenge after the PBA is complete, with which he can challenge the Yubikey, decrypt the new AES blob and recover the LUKS key. * Additionally, since the Yubikey shared secret is stored in the same AES blob, after such an attack not only is the LUKS device compromised, the Yubikey is as well, since the shared secret has also been recovered by the attacker. * Furthermore, with this method an attacker could also bruteforce the AES blob, if he has access to the unencrypted device, which would again compromise the Yubikey, should he be successful. * Finally, with this method, once the LUKS key has been recovered once, the encryption is permanently broken, while with the previous system, the LUKS key itself it changed at every successful boot, so recovering it once will not necessarily result in a permanent breakage and will also not compromise the Yubikey itself (since its secret is never stored anywhere but on the Yubikey itself). Summary: The current implementation opens up up vulnerability to brute-forcing the AES blob, while retaining the current MITM-USB attack, additionally making the consequences of this attack permanent and extending it to the Yubikey itself.
2014-02-03 21:50:17 +00:00
local opened
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
local new_salt
local new_iterations
local new_challenge
local new_response
local new_k_luks
Implement muli-user authentication for yubikey pba, i.e. multiple users can now share a single luks keyslot. This is achieved by having multiple lines per storage file, one for each user (if the feature is enabled); each of these lines has the same format as would be the case for the userless authentication, except that they are prepended with a SHA-512 of the user's id.
2014-01-29 16:20:05 +00:00
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
mkdir -p ${yubikey.storage.mountPoint}
mount -t ${yubikey.storage.fsType} ${toString yubikey.storage.device} ${yubikey.storage.mountPoint}
Implement muli-user authentication for yubikey pba, i.e. multiple users can now share a single luks keyslot. This is achieved by having multiple lines per storage file, one for each user (if the feature is enabled); each of these lines has the same format as would be the case for the userless authentication, except that they are prepended with a SHA-512 of the user's id.
2014-01-29 16:20:05 +00:00
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
salt="$(cat ${yubikey.storage.mountPoint}${yubikey.storage.path} | sed -n 1p | tr -d '\n')"
iterations="$(cat ${yubikey.storage.mountPoint}${yubikey.storage.path} | sed -n 2p | tr -d '\n')"
challenge="$(echo -n $salt | openssl-wrap dgst -binary -sha512 | rbtohex)"
response="$(ykchalresp -${toString yubikey.slot} -x $challenge 2>/dev/null)"
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
for try in $(seq 3); do
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
${optionalString yubikey.twoFactor ''
echo -n "Enter two-factor passphrase: "
read -s k_user
Implement muli-user authentication for yubikey pba, i.e. multiple users can now share a single luks keyslot. This is achieved by having multiple lines per storage file, one for each user (if the feature is enabled); each of these lines has the same format as would be the case for the userless authentication, except that they are prepended with a SHA-512 of the user's id.
2014-01-29 16:20:05 +00:00
echo
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
''}
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
if [ ! -z "$k_user" ]; then
k_luks="$(echo -n $k_user | pbkdf2-sha512 ${toString yubikey.keyLength} $iterations $response | rbtohex)"
else
k_luks="$(echo | pbkdf2-sha512 ${toString yubikey.keyLength} $iterations $response | rbtohex)"
fi
Implement muli-user authentication for yubikey pba, i.e. multiple users can now share a single luks keyslot. This is achieved by having multiple lines per storage file, one for each user (if the feature is enabled); each of these lines has the same format as would be the case for the userless authentication, except that they are prepended with a SHA-512 of the user's id.
2014-01-29 16:20:05 +00:00
Replace the current Yubikey PBA implementation with the previous one. Rationale: * The main reason for choosing to implement the PBA in accordance with the Yubico documentation was to prevent a MITM-USB-attack successfully recovering the new LUKS key. * However, a MITM-USB-attacker can read user id and password when they were entered for PBA, which allows him to recover the new challenge after the PBA is complete, with which he can challenge the Yubikey, decrypt the new AES blob and recover the LUKS key. * Additionally, since the Yubikey shared secret is stored in the same AES blob, after such an attack not only is the LUKS device compromised, the Yubikey is as well, since the shared secret has also been recovered by the attacker. * Furthermore, with this method an attacker could also bruteforce the AES blob, if he has access to the unencrypted device, which would again compromise the Yubikey, should he be successful. * Finally, with this method, once the LUKS key has been recovered once, the encryption is permanently broken, while with the previous system, the LUKS key itself it changed at every successful boot, so recovering it once will not necessarily result in a permanent breakage and will also not compromise the Yubikey itself (since its secret is never stored anywhere but on the Yubikey itself). Summary: The current implementation opens up up vulnerability to brute-forcing the AES blob, while retaining the current MITM-USB attack, additionally making the consequences of this attack permanent and extending it to the Yubikey itself.
2014-02-03 21:50:17 +00:00
echo -n "$k_luks" | hextorb | cryptsetup luksOpen ${device} ${name} ${optionalString allowDiscards "--allow-discards"} --key-file=-
Implement muli-user authentication for yubikey pba, i.e. multiple users can now share a single luks keyslot. This is achieved by having multiple lines per storage file, one for each user (if the feature is enabled); each of these lines has the same format as would be the case for the userless authentication, except that they are prepended with a SHA-512 of the user's id.
2014-01-29 16:20:05 +00:00
Replace the current Yubikey PBA implementation with the previous one. Rationale: * The main reason for choosing to implement the PBA in accordance with the Yubico documentation was to prevent a MITM-USB-attack successfully recovering the new LUKS key. * However, a MITM-USB-attacker can read user id and password when they were entered for PBA, which allows him to recover the new challenge after the PBA is complete, with which he can challenge the Yubikey, decrypt the new AES blob and recover the LUKS key. * Additionally, since the Yubikey shared secret is stored in the same AES blob, after such an attack not only is the LUKS device compromised, the Yubikey is as well, since the shared secret has also been recovered by the attacker. * Furthermore, with this method an attacker could also bruteforce the AES blob, if he has access to the unencrypted device, which would again compromise the Yubikey, should he be successful. * Finally, with this method, once the LUKS key has been recovered once, the encryption is permanently broken, while with the previous system, the LUKS key itself it changed at every successful boot, so recovering it once will not necessarily result in a permanent breakage and will also not compromise the Yubikey itself (since its secret is never stored anywhere but on the Yubikey itself). Summary: The current implementation opens up up vulnerability to brute-forcing the AES blob, while retaining the current MITM-USB attack, additionally making the consequences of this attack permanent and extending it to the Yubikey itself.
2014-02-03 21:50:17 +00:00
if [ $? == "0" ]; then
opened=true
break
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
else
Replace the current Yubikey PBA implementation with the previous one. Rationale: * The main reason for choosing to implement the PBA in accordance with the Yubico documentation was to prevent a MITM-USB-attack successfully recovering the new LUKS key. * However, a MITM-USB-attacker can read user id and password when they were entered for PBA, which allows him to recover the new challenge after the PBA is complete, with which he can challenge the Yubikey, decrypt the new AES blob and recover the LUKS key. * Additionally, since the Yubikey shared secret is stored in the same AES blob, after such an attack not only is the LUKS device compromised, the Yubikey is as well, since the shared secret has also been recovered by the attacker. * Furthermore, with this method an attacker could also bruteforce the AES blob, if he has access to the unencrypted device, which would again compromise the Yubikey, should he be successful. * Finally, with this method, once the LUKS key has been recovered once, the encryption is permanently broken, while with the previous system, the LUKS key itself it changed at every successful boot, so recovering it once will not necessarily result in a permanent breakage and will also not compromise the Yubikey itself (since its secret is never stored anywhere but on the Yubikey itself). Summary: The current implementation opens up up vulnerability to brute-forcing the AES blob, while retaining the current MITM-USB attack, additionally making the consequences of this attack permanent and extending it to the Yubikey itself.
2014-02-03 21:50:17 +00:00
opened=false
Implement muli-user authentication for yubikey pba, i.e. multiple users can now share a single luks keyslot. This is achieved by having multiple lines per storage file, one for each user (if the feature is enabled); each of these lines has the same format as would be the case for the userless authentication, except that they are prepended with a SHA-512 of the user's id.
2014-01-29 16:20:05 +00:00
echo "Authentication failed!"
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
fi
done
Replace the current Yubikey PBA implementation with the previous one. Rationale: * The main reason for choosing to implement the PBA in accordance with the Yubico documentation was to prevent a MITM-USB-attack successfully recovering the new LUKS key. * However, a MITM-USB-attacker can read user id and password when they were entered for PBA, which allows him to recover the new challenge after the PBA is complete, with which he can challenge the Yubikey, decrypt the new AES blob and recover the LUKS key. * Additionally, since the Yubikey shared secret is stored in the same AES blob, after such an attack not only is the LUKS device compromised, the Yubikey is as well, since the shared secret has also been recovered by the attacker. * Furthermore, with this method an attacker could also bruteforce the AES blob, if he has access to the unencrypted device, which would again compromise the Yubikey, should he be successful. * Finally, with this method, once the LUKS key has been recovered once, the encryption is permanently broken, while with the previous system, the LUKS key itself it changed at every successful boot, so recovering it once will not necessarily result in a permanent breakage and will also not compromise the Yubikey itself (since its secret is never stored anywhere but on the Yubikey itself). Summary: The current implementation opens up up vulnerability to brute-forcing the AES blob, while retaining the current MITM-USB attack, additionally making the consequences of this attack permanent and extending it to the Yubikey itself.
2014-02-03 21:50:17 +00:00
if [ "$opened" == false ]; then
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
umount ${yubikey.storage.mountPoint}
echo "Maximum authentication errors reached"
exit 1
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
fi
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
echo -n "Gathering entropy for new salt (please enter random keys to generate entropy if this blocks for long)..."
for i in $(seq ${toString yubikey.saltLength}); do
byte="$(dd if=/dev/random bs=1 count=1 2>/dev/null | rbtohex)";
new_salt="$new_salt$byte";
echo -n .
done;
echo "ok"
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
new_iterations="$iterations"
${optionalString (yubikey.iterationStep > 0) ''
new_iterations="$(($new_iterations + ${toString yubikey.iterationStep}))"
''}
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
new_challenge="$(echo -n $new_salt | openssl-wrap dgst -binary -sha512 | rbtohex)"
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
new_response="$(ykchalresp -${toString yubikey.slot} -x $new_challenge 2>/dev/null)"
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
if [ ! -z "$k_user" ]; then
new_k_luks="$(echo -n $k_user | pbkdf2-sha512 ${toString yubikey.keyLength} $new_iterations $new_response | rbtohex)"
else
new_k_luks="$(echo | pbkdf2-sha512 ${toString yubikey.keyLength} $new_iterations $new_response | rbtohex)"
fi
Implement muli-user authentication for yubikey pba, i.e. multiple users can now share a single luks keyslot. This is achieved by having multiple lines per storage file, one for each user (if the feature is enabled); each of these lines has the same format as would be the case for the userless authentication, except that they are prepended with a SHA-512 of the user's id.
2014-01-29 16:20:05 +00:00
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
mkdir -p ${yubikey.ramfsMountPoint}
# A ramfs is used here to ensure that the file used to update
# the key slot with cryptsetup will never get swapped out.
# Warning: Do NOT replace with tmpfs!
mount -t ramfs none ${yubikey.ramfsMountPoint}
Implement muli-user authentication for yubikey pba, i.e. multiple users can now share a single luks keyslot. This is achieved by having multiple lines per storage file, one for each user (if the feature is enabled); each of these lines has the same format as would be the case for the userless authentication, except that they are prepended with a SHA-512 of the user's id.
2014-01-29 16:20:05 +00:00
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
echo -n "$new_k_luks" | hextorb > ${yubikey.ramfsMountPoint}/new_key
echo -n "$k_luks" | hextorb | cryptsetup luksChangeKey ${device} --key-file=- ${yubikey.ramfsMountPoint}/new_key
Replace the current Yubikey PBA implementation with the previous one. Rationale: * The main reason for choosing to implement the PBA in accordance with the Yubico documentation was to prevent a MITM-USB-attack successfully recovering the new LUKS key. * However, a MITM-USB-attacker can read user id and password when they were entered for PBA, which allows him to recover the new challenge after the PBA is complete, with which he can challenge the Yubikey, decrypt the new AES blob and recover the LUKS key. * Additionally, since the Yubikey shared secret is stored in the same AES blob, after such an attack not only is the LUKS device compromised, the Yubikey is as well, since the shared secret has also been recovered by the attacker. * Furthermore, with this method an attacker could also bruteforce the AES blob, if he has access to the unencrypted device, which would again compromise the Yubikey, should he be successful. * Finally, with this method, once the LUKS key has been recovered once, the encryption is permanently broken, while with the previous system, the LUKS key itself it changed at every successful boot, so recovering it once will not necessarily result in a permanent breakage and will also not compromise the Yubikey itself (since its secret is never stored anywhere but on the Yubikey itself). Summary: The current implementation opens up up vulnerability to brute-forcing the AES blob, while retaining the current MITM-USB attack, additionally making the consequences of this attack permanent and extending it to the Yubikey itself.
2014-02-03 21:50:17 +00:00
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
if [ $? == "0" ]; then
echo -ne "$new_salt\n$new_iterations" > ${yubikey.storage.mountPoint}${yubikey.storage.path}
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
else
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
echo "Warning: Could not update LUKS key, current challenge persists!"
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
fi
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
rm -f ${yubikey.ramfsMountPoint}/new_key
umount ${yubikey.ramfsMountPoint}
rm -rf ${yubikey.ramfsMountPoint}
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
umount ${yubikey.storage.mountPoint}
}
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
${optionalString (yubikey.gracePeriod > 0) ''
echo -n "Waiting ${toString yubikey.gracePeriod} seconds as grace..."
for i in $(seq ${toString yubikey.gracePeriod}); do
sleep 1
echo -n .
done
echo "ok"
''}
Cosmetic change to yubikey detection
2014-01-28 19:39:25 +00:00
yubikey_missing=true
ykinfo -v 1>/dev/null 2>&1
if [ $? != "0" ]; then
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
echo -n "waiting 10 seconds for yubikey to appear..."
for try in $(seq 10); do
sleep 1
Cosmetic change to yubikey detection
2014-01-28 19:39:25 +00:00
ykinfo -v 1>/dev/null 2>&1
if [ $? == "0" ]; then
yubikey_missing=false
break
fi
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
echo -n .
done
echo "ok"
Cosmetic change to yubikey detection
2014-01-28 19:39:25 +00:00
else
yubikey_missing=false
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
fi
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
Cosmetic change to yubikey detection
2014-01-28 19:39:25 +00:00
if [ "$yubikey_missing" == true ]; then
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
echo "no yubikey found, falling back to non-yubikey open procedure"
open_normally
else
open_yubikey
fi
''}
# open luksRoot and scan for logical volumes
${optionalString ((!luks.yubikeySupport) || (yubikey == null)) ''
open_normally
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
''}
Making the luks thing of initrd a bit more flexible. I used it to get a ciphered swap, where I could hibernate ciphered. svn path=/nixos/trunk/; revision=32754
2012-03-03 16:07:18 +00:00
'';
Adding an option to luksroot, so it allows to define whether to launch cryptsetup after or before LVM. To allow dmcrypt over lvm and lvm over dmcrypt. svn path=/nixos/trunk/; revision=32784
2012-03-04 21:00:35 +00:00
isPreLVM = f: f.preLVM;
preLVM = filter isPreLVM luks.devices;
postLVM = filter (f: !(isPreLVM f)) luks.devices;
Encrypted root support via LUKS svn path=/nixos/trunk/; revision=24459
2010-10-25 01:57:30 +01:00
in
{
options = {
LuksRoot: mitigate DMA key recovery attacks by default.
2013-01-13 09:04:26 +00:00
boot.initrd.luks.mitigateDMAAttacks = mkOption {
Add a way to define obsolete options that have no replacement
2013-10-23 17:22:26 +01:00
type = types.bool;
LuksRoot: mitigate DMA key recovery attacks by default.
2013-01-13 09:04:26 +00:00
default = true;
description = ''
Fix indentation / tabs
2013-07-23 17:56:12 +01:00
Unless enabled, encryption keys can be easily recovered by an attacker with physical
access to any machine with PCMCIA, ExpressCard, ThunderBolt or FireWire port.
More information: http://en.wikipedia.org/wiki/DMA_attack
LuksRoot: mitigate DMA key recovery attacks by default.
2013-01-13 09:04:26 +00:00
Fix indentation / tabs
2013-07-23 17:56:12 +01:00
This option blacklists FireWire drivers, but doesn't remove them. You can manually
load the drivers if you need to use a FireWire device, but don't forget to unload them!
LuksRoot: mitigate DMA key recovery attacks by default.
2013-01-13 09:04:26 +00:00
'';
};
LuksRoot: add more modules to load by default and let users add more or override the list. Added every module mentioned by most popular guides, benchmarks and discussions to make things just work.
2013-01-13 10:44:16 +00:00
boot.initrd.luks.cryptoModules = mkOption {
Add a way to define obsolete options that have no replacement
2013-10-23 17:22:26 +01:00
type = types.listOf types.string;
Fix indentation / tabs
2013-07-23 17:56:12 +01:00
default =
Load LUKS-related kernel modules on demand
2013-10-09 18:11:47 +01:00
[ "aes" "aes_generic" "blowfish" "twofish"
"serpent" "cbc" "xts" "lrw" "sha1" "sha256" "sha512"
(if pkgs.stdenv.system == "x86_64-linux" then "aes_x86_64" else "aes_i586")
Fix indentation / tabs
2013-07-23 17:56:12 +01:00
];
LuksRoot: add more modules to load by default and let users add more or override the list. Added every module mentioned by most popular guides, benchmarks and discussions to make things just work.
2013-01-13 10:44:16 +00:00
description = ''
Fix indentation / tabs
2013-07-23 17:56:12 +01:00
A list of cryptographic kernel modules needed to decrypt the root device(s).
The default includes all common modules.
LuksRoot: add more modules to load by default and let users add more or override the list. Added every module mentioned by most popular guides, benchmarks and discussions to make things just work.
2013-01-13 10:44:16 +00:00
'';
};
Making the luks thing of initrd a bit more flexible. I used it to get a ciphered swap, where I could hibernate ciphered. svn path=/nixos/trunk/; revision=32754
2012-03-03 16:07:18 +00:00
boot.initrd.luks.devices = mkOption {
default = [ ];
Adding an option to luksroot, so it allows to define whether to launch cryptsetup after or before LVM. To allow dmcrypt over lvm and lvm over dmcrypt. svn path=/nixos/trunk/; revision=32784
2012-03-04 21:00:35 +00:00
example = [ { name = "luksroot"; device = "/dev/sda3"; preLVM = true; } ];
* Make the boot.initrd.luks.enable option obsolete. It's enough to see that boot.initrd.luks.devices is non-empty. svn path=/nixos/trunk/; revision=34120
2012-05-15 21:45:01 +01:00
description = ''
Making the luks thing of initrd a bit more flexible. I used it to get a ciphered swap, where I could hibernate ciphered. svn path=/nixos/trunk/; revision=32754
2012-03-03 16:07:18 +00:00
The list of devices that should be decrypted using LUKS before trying to mount the
Encrypted root support via LUKS svn path=/nixos/trunk/; revision=24459
2010-10-25 01:57:30 +01:00
root partition. This works for both LVM-over-LUKS and LUKS-over-LVM setups.
strip trailing whitespace; no functional change svn path=/nixos/trunk/; revision=29285
2011-09-14 19:20:50 +01:00
Making the luks thing of initrd a bit more flexible. I used it to get a ciphered swap, where I could hibernate ciphered. svn path=/nixos/trunk/; revision=32754
2012-03-03 16:07:18 +00:00
The devices are decrypted to the device mapper names defined.
Encrypted root support via LUKS svn path=/nixos/trunk/; revision=24459
2010-10-25 01:57:30 +01:00
Making the luks thing of initrd a bit more flexible. I used it to get a ciphered swap, where I could hibernate ciphered. svn path=/nixos/trunk/; revision=32754
2012-03-03 16:07:18 +00:00
Make sure that initrd has the crypto modules needed for decryption.
Encrypted root support via LUKS svn path=/nixos/trunk/; revision=24459
2010-10-25 01:57:30 +01:00
'';
Adding an option to luksroot, so it allows to define whether to launch cryptsetup after or before LVM. To allow dmcrypt over lvm and lvm over dmcrypt. svn path=/nixos/trunk/; revision=32784
2012-03-04 21:00:35 +00:00
replace list by listOf using same style as for attrsOf
2013-03-14 16:09:21 +00:00
type = types.listOf types.optionSet;
Adding an option to luksroot, so it allows to define whether to launch cryptsetup after or before LVM. To allow dmcrypt over lvm and lvm over dmcrypt. svn path=/nixos/trunk/; revision=32784
2012-03-04 21:00:35 +00:00
options = {
name = mkOption {
example = "luksroot";
type = types.string;
modules/system/boot/luksroot.nix: fixed the descriptions of the options defined in this module svn path=/nixos/trunk/; revision=33927
2012-04-26 13:21:45 +01:00
description = "Named to be used for the generated device in /dev/mapper.";
Adding an option to luksroot, so it allows to define whether to launch cryptsetup after or before LVM. To allow dmcrypt over lvm and lvm over dmcrypt. svn path=/nixos/trunk/; revision=32784
2012-03-04 21:00:35 +00:00
};
device = mkOption {
example = "/dev/sda2";
type = types.string;
* Fix missing semicolon. svn path=/nixos/trunk/; revision=33933
2012-04-26 15:53:58 +01:00
description = "Path of the underlying block device.";
Adding an option to luksroot, so it allows to define whether to launch cryptsetup after or before LVM. To allow dmcrypt over lvm and lvm over dmcrypt. svn path=/nixos/trunk/; revision=32784
2012-03-04 21:00:35 +00:00
};
LUKS root: Add option for using a key file instead of a passphrase.
2012-05-02 23:37:14 +01:00
keyFile = mkOption {
default = null;
example = "/dev/sdb1";
type = types.nullOr types.string;
description = ''
The name of the file (can be a raw device or a partition) that
should be used as the decryption key for the encrypted device. If
not specified, you will be prompted for a passphrase instead.
'';
};
keyFileSize = mkOption {
default = null;
example = 4096;
type = types.nullOr types.int;
description = ''
The size of the key file. Use this if only the beginning of the
key file should be used as a key (often the case if a raw device
or partition is used as key file). If not specified, the whole
<literal>keyFile</literal> will be used decryption, instead of just
the first <literal>keyFileSize</literal> bytes.
'';
};
Adding an option to luksroot, so it allows to define whether to launch cryptsetup after or before LVM. To allow dmcrypt over lvm and lvm over dmcrypt. svn path=/nixos/trunk/; revision=32784
2012-03-04 21:00:35 +00:00
preLVM = mkOption {
default = true;
type = types.bool;
modules/system/boot/luksroot.nix: fixed the descriptions of the options defined in this module svn path=/nixos/trunk/; revision=33927
2012-04-26 13:21:45 +01:00
description = "Whether the luksOpen will be attempted before LVM scan or after it.";
Adding an option to luksroot, so it allows to define whether to launch cryptsetup after or before LVM. To allow dmcrypt over lvm and lvm over dmcrypt. svn path=/nixos/trunk/; revision=32784
2012-03-04 21:00:35 +00:00
};
LUKS root: Add option allowDiscards (for SSD disks)
2012-07-17 12:10:00 +01:00
allowDiscards = mkOption {
default = false;
type = types.bool;
description = ''
Whether to allow TRIM requests to the underlying device. This option
has security implications, please read the LUKS documentation before
activating in.
'';
};
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
yubikey = mkOption {
default = null;
type = types.nullOr types.optionSet;
Enable two-factor authentication by default. Add proper descriptions to attributes.
2014-01-28 22:45:16 +00:00
description = ''
The options to use for this LUKS device in Yubikey-PBA.
If null (the default), Yubikey-PBA will be disabled for this device.
'';
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
options = {
twoFactor = mkOption {
Enable two-factor authentication by default. Add proper descriptions to attributes.
2014-01-28 22:45:16 +00:00
default = true;
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
type = types.bool;
Enable two-factor authentication by default. Add proper descriptions to attributes.
2014-01-28 22:45:16 +00:00
description = "Whether to use a passphrase and a Yubikey (true), or only a Yubikey (false)";
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
};
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
slot = mkOption {
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
default = 2;
type = types.int;
Enable two-factor authentication by default. Add proper descriptions to attributes.
2014-01-28 22:45:16 +00:00
description = "Which slot on the Yubikey to challenge";
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
};
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
saltLength = mkOption {
default = 16;
type = types.int;
description = "Length of the new salt in byte (64 is the effective maximum)";
};
keyLength = mkOption {
default = 64;
type = types.int;
description = "Length of the LUKS slot key derived with PBKDF2 in byte";
};
iterationStep = mkOption {
default = 0;
type = types.int;
description = "How much the iteration count for PBKDF2 is increased at each successful authentication";
};
gracePeriod = mkOption {
default = 2;
type = types.int;
description = "Time in seconds to wait before attempting to find the Yubikey";
};
Replace the current Yubikey PBA implementation with the previous one. Rationale: * The main reason for choosing to implement the PBA in accordance with the Yubico documentation was to prevent a MITM-USB-attack successfully recovering the new LUKS key. * However, a MITM-USB-attacker can read user id and password when they were entered for PBA, which allows him to recover the new challenge after the PBA is complete, with which he can challenge the Yubikey, decrypt the new AES blob and recover the LUKS key. * Additionally, since the Yubikey shared secret is stored in the same AES blob, after such an attack not only is the LUKS device compromised, the Yubikey is as well, since the shared secret has also been recovered by the attacker. * Furthermore, with this method an attacker could also bruteforce the AES blob, if he has access to the unencrypted device, which would again compromise the Yubikey, should he be successful. * Finally, with this method, once the LUKS key has been recovered once, the encryption is permanently broken, while with the previous system, the LUKS key itself it changed at every successful boot, so recovering it once will not necessarily result in a permanent breakage and will also not compromise the Yubikey itself (since its secret is never stored anywhere but on the Yubikey itself). Summary: The current implementation opens up up vulnerability to brute-forcing the AES blob, while retaining the current MITM-USB attack, additionally making the consequences of this attack permanent and extending it to the Yubikey itself.
2014-02-03 21:50:17 +00:00
ramfsMountPoint = mkOption {
default = "/crypt-ramfs";
type = types.string;
description = "Path where the ramfs used to update the LUKS key will be mounted in stage-1";
};
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
storage = mkOption {
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
type = types.optionSet;
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
description = "Options related to the storing the salt";
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
options = {
device = mkOption {
default = /dev/sda1;
type = types.path;
Enable two-factor authentication by default. Add proper descriptions to attributes.
2014-01-28 22:45:16 +00:00
description = ''
An unencrypted device that will temporarily be mounted in stage-1.
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
Must contain the current salt to create the challenge for this LUKS device.
Enable two-factor authentication by default. Add proper descriptions to attributes.
2014-01-28 22:45:16 +00:00
'';
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
};
fsType = mkOption {
default = "vfat";
type = types.string;
Enable two-factor authentication by default. Add proper descriptions to attributes.
2014-01-28 22:45:16 +00:00
description = "The filesystem of the unencrypted device";
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
};
mountPoint = mkOption {
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
default = "/crypt-storage";
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
type = types.string;
Enable two-factor authentication by default. Add proper descriptions to attributes.
2014-01-28 22:45:16 +00:00
description = "Path where the unencrypted device will be mounted in stage-1";
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
};
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
path = mkOption {
default = "/crypt-storage/default";
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
type = types.string;
Enable two-factor authentication by default. Add proper descriptions to attributes.
2014-01-28 22:45:16 +00:00
description = ''
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
Absolute path of the salt on the unencrypted device with
Enable two-factor authentication by default. Add proper descriptions to attributes.
2014-01-28 22:45:16 +00:00
that device's root directory as "/".
'';
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
};
};
};
};
};
Add a way to define obsolete options that have no replacement
2013-10-23 17:22:26 +01:00
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
};
Encrypted root support via LUKS svn path=/nixos/trunk/; revision=24459
2010-10-25 01:57:30 +01:00
};
Add a way to define obsolete options that have no replacement
2013-10-23 17:22:26 +01:00
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
boot.initrd.luks.yubikeySupport = mkOption {
default = false;
type = types.bool;
Enable two-factor authentication by default. Add proper descriptions to attributes.
2014-01-28 22:45:16 +00:00
description = ''
Enables support for authenticating with a Yubikey on LUKS devices.
See the NixOS wiki for information on how to properly setup a LUKS device
and a Yubikey to work with this feature.
'';
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
};
Encrypted root support via LUKS svn path=/nixos/trunk/; revision=24459
2010-10-25 01:57:30 +01:00
};
* Make the boot.initrd.luks.enable option obsolete. It's enough to see that boot.initrd.luks.devices is non-empty. svn path=/nixos/trunk/; revision=34120
2012-05-15 21:45:01 +01:00
config = mkIf (luks.devices != []) {
Encrypted root support via LUKS svn path=/nixos/trunk/; revision=24459
2010-10-25 01:57:30 +01:00
LuksRoot: mitigate DMA key recovery attacks by default.
2013-01-13 09:04:26 +00:00
# actually, sbp2 driver is the one enabling the DMA attack, but this needs to be tested
boot.blacklistedKernelModules = optionals luks.mitigateDMAAttacks
["firewire_ohci" "firewire_core" "firewire_sbp2"];
Making the luks thing of initrd a bit more flexible. I used it to get a ciphered swap, where I could hibernate ciphered. svn path=/nixos/trunk/; revision=32754
2012-03-03 16:07:18 +00:00
# Some modules that may be needed for mounting anything ciphered
Load LUKS-related kernel modules on demand
2013-10-09 18:11:47 +01:00
boot.initrd.availableKernelModules = [ "dm_mod" "dm_crypt" "cryptd" ] ++ luks.cryptoModules;
Encrypted root support via LUKS svn path=/nixos/trunk/; revision=24459
2010-10-25 01:57:30 +01:00
copy only cryptsetup deps to stage-1 and test cryptsetup popt-0.16 and cryptsetup-1.4.1 both generated pkgconfig (in contrast to older versions). The pkgconfig files (popt.pc and cryptsetup.pc) contain references into the store that are not removed by patchelf and stage-1 fails with errors like: "output is not allowed to refer to path `/nix/store/qccjhn063cfv171rcaxvxh0yk96zf7l2-cryptsetup-1.4.1'". Now, only the cryptsetup binaries and its dependencies are copied, determined by ldd. In addition the cryptsetup binary and lvm are tested after patchelf has adjusted the library paths. Thanks to Peter Simons and Eelco Dolstra for giving the rights hints. svn path=/nixos/trunk/; revision=31128
2011-12-28 21:46:40 +00:00
# copy the cryptsetup binary and it's dependencies
Encrypted root support via LUKS svn path=/nixos/trunk/; revision=24459
2010-10-25 01:57:30 +01:00
boot.initrd.extraUtilsCommands = ''
copy only cryptsetup deps to stage-1 and test cryptsetup popt-0.16 and cryptsetup-1.4.1 both generated pkgconfig (in contrast to older versions). The pkgconfig files (popt.pc and cryptsetup.pc) contain references into the store that are not removed by patchelf and stage-1 fails with errors like: "output is not allowed to refer to path `/nix/store/qccjhn063cfv171rcaxvxh0yk96zf7l2-cryptsetup-1.4.1'". Now, only the cryptsetup binaries and its dependencies are copied, determined by ldd. In addition the cryptsetup binary and lvm are tested after patchelf has adjusted the library paths. Thanks to Peter Simons and Eelco Dolstra for giving the rights hints. svn path=/nixos/trunk/; revision=31128
2011-12-28 21:46:40 +00:00
cp -pdv ${pkgs.cryptsetup}/sbin/cryptsetup $out/bin
Add library dependencies explicitly
2014-01-29 17:49:26 +00:00
cp -pdv ${pkgs.libgcrypt}/lib/libgcrypt*.so.* $out/lib
cp -pdv ${pkgs.libgpgerror}/lib/libgpg-error*.so.* $out/lib
cp -pdv ${pkgs.cryptsetup}/lib/libcryptsetup*.so.* $out/lib
cp -pdv ${pkgs.popt}/lib/libpopt*.so.* $out/lib
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
${optionalString luks.yubikeySupport ''
cp -pdv ${pkgs.ykpers}/bin/ykchalresp $out/bin
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
cp -pdv ${pkgs.ykpers}/bin/ykinfo $out/bin
cp -pdv ${pkgs.openssl}/bin/openssl $out/bin
Add library dependencies explicitly
2014-01-29 17:49:26 +00:00
Update to the Yubikey PBA Security-relevant changes: * No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation). * Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user (as the PBKDF2 password), so that if two-factor authentication is enabled (a) a USB-MITM attack on the yubikey itself is not enough to break the system (b) the potentially low-entropy $k_user is better protected against brute-force attacks * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random. * Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte. Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64. * Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte. Example: For a luks device with a 512-bit key, keyLength should be 64. * Increase of the PBKDF2 iteration count per successful authentication added as the parameter "iterationStep", defaults to 0. Other changes: * Add optional grace period before trying to find the yubikey, defaults to 2 seconds. Full overview of the yubikey authentication process: (1) Read $salt and $iterations from unencrypted device (UD). (2) Calculate the $challenge from the $salt with a hash function. Chosen instantiation: SHA-512($salt). (3) Challenge the yubikey with the $challenge and receive the $response. (4) Repeat three times: (a) Prompt for the passphrase $k_user. (b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response. Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength). (c) Try to open the luks device with $k_luks and escape loop (4) only on success. (5) Proceed only if luks device was opened successfully, fail otherwise. (6) Gather $new_salt from a cryptographically secure pseudorandom number generator Chosen instantiation: /dev/random (7) Calculate the $new_challenge from the $new_salt with the same hash function as (2). (8) Challenge the yubikey with the $new_challenge and receive the $new_response. (9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b), but with more iterations as given by iterationStep. (10) Try to change the luks device's key $k_luks to $new_k_luks. (11) If (10) was successful, write the $new_salt and the $new_iterations to the UD. Note: $new_iterations = $iterations + iterationStep Known (software) attack vectors: * A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM attack on the yubikey for the $response (1) or the $new_response (2) will result in (1) $k_luks being recovered, (2) $new_k_luks being recovered. * Any attacker with access to the RAM state of stage-1 at mid- or post-authentication can recover $k_user, $k_luks, and $new_k_luks * If an attacker has recovered $response or $new_response, he can perform a brute-force attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's "luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's luks header and run the brute-force attack without further access to the system. * A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force the yubikey's internal key ("shared secret") without it needing to be present anymore. Credits: * Florian Klien, for the original concept and the reference implementation over at https://github.com/flowolf/initramfs_ykfde * Anthony Thysse, for the reference implementation of accessing OpenSSL's PBKDF2 over at http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
2014-02-05 16:10:59 +00:00
cc -O3 -I${pkgs.openssl}/include -L${pkgs.openssl}/lib ${./pbkdf2-sha512.c} -o $out/bin/pbkdf2-sha512 -lcrypto
strip -s $out/bin/pbkdf2-sha512
Add library dependencies explicitly
2014-01-29 17:49:26 +00:00
cp -pdv ${pkgs.libusb1}/lib/libusb*.so.* $out/lib
cp -pdv ${pkgs.ykpers}/lib/libykpers*.so.* $out/lib
cp -pdv ${pkgs.libyubikey}/lib/libyubikey*.so.* $out/lib
cp -pdv ${pkgs.openssl}/lib/libssl*.so.* $out/lib
cp -pdv ${pkgs.openssl}/lib/libcrypto*.so.* $out/lib
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
mkdir -p $out/etc/ssl
cp -pdv ${pkgs.openssl}/etc/ssl/openssl.cnf $out/etc/ssl
cat > $out/bin/openssl-wrap <<EOF
#!$out/bin/sh
EOF
chmod +x $out/bin/openssl-wrap
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
''}
copy only cryptsetup deps to stage-1 and test cryptsetup popt-0.16 and cryptsetup-1.4.1 both generated pkgconfig (in contrast to older versions). The pkgconfig files (popt.pc and cryptsetup.pc) contain references into the store that are not removed by patchelf and stage-1 fails with errors like: "output is not allowed to refer to path `/nix/store/qccjhn063cfv171rcaxvxh0yk96zf7l2-cryptsetup-1.4.1'". Now, only the cryptsetup binaries and its dependencies are copied, determined by ldd. In addition the cryptsetup binary and lvm are tested after patchelf has adjusted the library paths. Thanks to Peter Simons and Eelco Dolstra for giving the rights hints. svn path=/nixos/trunk/; revision=31128
2011-12-28 21:46:40 +00:00
'';
boot.initrd.extraUtilsCommandsTest = ''
Revert "test we have cryptsetup-1.4.1 in initrd" This reverts commit 025f8c40b40fad50086e8761eee61098d8fb2651. The check was intened for building the initrd of the installer. svn path=/nixos/trunk/; revision=31137
2011-12-28 22:37:38 +00:00
$out/bin/cryptsetup --version
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
${optionalString luks.yubikeySupport ''
$out/bin/ykchalresp -V
Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of 'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'. Used binaries: * uuidgen - for generation of random sequence numbers * ykchalresp - for challenging a Yubikey * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise) * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption Main differences to the specification mentioned above: * No user management (yet), only one password+yubikey per LUKS device * SHA-512 instead of CRC-16 for checksum Main differences to the previous implementation: * Instead of changing the key slot of the LUKS device each boot, the actual key for the LUKS device will be encrypted itself * Since the response for the new challenge is now calculated locally with openssl, the MITM-USB-attack with which previously an attacker could obtain the new response (that was used as the new encryption key for the LUKS device) by listening to the Yubikey has ideally become useless (as long as uuidgen can successfuly generate new random sequence numbers). Remarks: * This is not downwards compatible to the previous implementation
2014-01-28 03:02:51 +00:00
$out/bin/ykinfo -V
cat > $out/bin/openssl-wrap <<EOF
#!$out/bin/sh
export OPENSSL_CONF=$out/etc/ssl/openssl.cnf
$out/bin/openssl "\$@"
EOF
$out/bin/openssl-wrap version
Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication
2014-01-25 02:27:12 +00:00
''}
Encrypted root support via LUKS svn path=/nixos/trunk/; revision=24459
2010-10-25 01:57:30 +01:00
'';
Adding an option to luksroot, so it allows to define whether to launch cryptsetup after or before LVM. To allow dmcrypt over lvm and lvm over dmcrypt. svn path=/nixos/trunk/; revision=32784
2012-03-04 21:00:35 +00:00
boot.initrd.preLVMCommands = concatMapStrings openCommand preLVM;
boot.initrd.postDeviceCommands = concatMapStrings openCommand postLVM;
If enabling luks on initrd, also adding cryptsetup to system packages. I think it's useful. svn path=/nixos/trunk/; revision=32910
2012-03-08 20:49:26 +00:00
environment.systemPackages = [ pkgs.cryptsetup ];
Encrypted root support via LUKS svn path=/nixos/trunk/; revision=24459
2010-10-25 01:57:30 +01:00
};
strip trailing whitespace; no functional change svn path=/nixos/trunk/; revision=29285
2011-09-14 19:20:50 +01:00
}
Reference in New Issue Copy Permalink