nixpkgs/nixos/modules/system/boot/luksroot.nix

472 lines
16 KiB
Nix
Raw Normal View History

{ config, lib, pkgs, ... }:
with lib;
let
luks = config.boot.initrd.luks;
openCommand = { name, device, header, keyFile, keyFileSize, allowDiscards, yubikey, ... }: ''
# 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..."
for try in $(seq 10); do
sleep 1
if test -e ${device}; then break; fi
echo -n .
done
echo "ok"
fi
${optionalString (keyFile != null) ''
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
''}
open_normally() {
echo luksOpen ${device} ${name} ${optionalString allowDiscards "--allow-discards"} \
${optionalString (header != null) "--header=${header}"} \
${optionalString (keyFile != null) "--key-file=${keyFile} ${optionalString (keyFileSize != null) "--keyfile-size=${toString keyFileSize}"}"} \
> /.luksopen_args
cryptsetup-askpass
rm /.luksopen_args
}
${optionalString (luks.yubikeySupport && (yubikey != null)) ''
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 22:50:17 +01:00
( od -An -vtx1 | tr -d ' \n' )
}
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 17:10:59 +01:00
( tr '[:lower:]' '[:upper:]' | sed -e 's/\([0-9A-F]\{2\}\)/\\\\\\x\1/gI' | xargs printf )
}
open_yubikey() {
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 17:10:59 +01:00
# Make all of these local to this function
# to prevent their values being leaked
local salt
local iterations
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 17:10:59 +01: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 22:50:17 +01: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 17:10:59 +01:00
local new_salt
local new_iterations
local new_challenge
local new_response
local new_k_luks
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 17:10:59 +01:00
mkdir -p ${yubikey.storage.mountPoint}
mount -t ${yubikey.storage.fsType} ${toString yubikey.storage.device} ${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 17:10:59 +01: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)"
for try in $(seq 3); do
${optionalString yubikey.twoFactor ''
echo -n "Enter two-factor passphrase: "
read -s k_user
echo
''}
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 17:10:59 +01: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
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 22:50:17 +01:00
echo -n "$k_luks" | hextorb | cryptsetup luksOpen ${device} ${name} ${optionalString allowDiscards "--allow-discards"} --key-file=-
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 22:50:17 +01:00
if [ $? == "0" ]; then
opened=true
break
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 22:50:17 +01:00
opened=false
echo "Authentication failed!"
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 22:50:17 +01:00
if [ "$opened" == false ]; then
umount ${yubikey.storage.mountPoint}
echo "Maximum authentication errors reached"
exit 1
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 17:10:59 +01: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"
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 17:10:59 +01:00
new_iterations="$iterations"
${optionalString (yubikey.iterationStep > 0) ''
new_iterations="$(($new_iterations + ${toString yubikey.iterationStep}))"
''}
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 17:10:59 +01:00
new_challenge="$(echo -n $new_salt | openssl-wrap dgst -binary -sha512 | rbtohex)"
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 17:10:59 +01:00
new_response="$(ykchalresp -${toString yubikey.slot} -x $new_challenge 2>/dev/null)"
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 17:10:59 +01: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
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 17:10:59 +01: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}
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 17:10:59 +01: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 22:50:17 +01: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 17:10:59 +01:00
if [ $? == "0" ]; then
echo -ne "$new_salt\n$new_iterations" > ${yubikey.storage.mountPoint}${yubikey.storage.path}
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 17:10:59 +01:00
echo "Warning: Could not update LUKS key, current challenge persists!"
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 17:10:59 +01:00
rm -f ${yubikey.ramfsMountPoint}/new_key
umount ${yubikey.ramfsMountPoint}
rm -rf ${yubikey.ramfsMountPoint}
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 17:10:59 +01: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"
''}
2014-01-28 20:39:25 +01:00
yubikey_missing=true
ykinfo -v 1>/dev/null 2>&1
if [ $? != "0" ]; then
echo -n "waiting 10 seconds for yubikey to appear..."
for try in $(seq 10); do
sleep 1
2014-01-28 20:39:25 +01:00
ykinfo -v 1>/dev/null 2>&1
if [ $? == "0" ]; then
yubikey_missing=false
break
fi
echo -n .
done
echo "ok"
2014-01-28 20:39:25 +01:00
else
yubikey_missing=false
fi
2014-01-28 20:39:25 +01:00
if [ "$yubikey_missing" == true ]; then
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
''}
'';
isPreLVM = f: f.preLVM;
preLVM = filter isPreLVM luks.devices;
postLVM = filter (f: !(isPreLVM f)) luks.devices;
in
{
options = {
boot.initrd.luks.mitigateDMAAttacks = mkOption {
type = types.bool;
default = true;
description = ''
2013-07-23 18:56:12 +02: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 is available at <link xlink:href="http://en.wikipedia.org/wiki/DMA_attack"/>.
2013-07-23 18:56:12 +02: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!
'';
};
boot.initrd.luks.cryptoModules = mkOption {
2015-06-15 18:18:46 +02:00
type = types.listOf types.str;
2013-07-23 18:56:12 +02:00
default =
[ "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")
2013-07-23 18:56:12 +02:00
];
description = ''
2013-07-23 18:56:12 +02:00
A list of cryptographic kernel modules needed to decrypt the root device(s).
The default includes all common modules.
'';
};
boot.initrd.luks.devices = mkOption {
default = [ ];
example = literalExample ''[ { name = "luksroot"; device = "/dev/sda3"; preLVM = true; } ]'';
description = ''
The list of devices that should be decrypted using LUKS before trying to mount the
root partition. This works for both LVM-over-LUKS and LUKS-over-LVM setups.
The devices are decrypted to the device mapper names defined.
Make sure that initrd has the crypto modules needed for decryption.
'';
type = types.listOf types.optionSet;
options = {
name = mkOption {
example = "luksroot";
2015-08-17 19:52:45 +02:00
type = types.str;
description = "Named to be used for the generated device in /dev/mapper.";
};
device = mkOption {
example = "/dev/sda2";
2015-08-17 19:52:45 +02:00
type = types.str;
description = "Path of the underlying block device.";
};
header = mkOption {
default = null;
example = "/root/header.img";
2015-08-17 19:52:45 +02:00
type = types.nullOr types.str;
description = ''
The name of the file or block device that
should be used as header for the encrypted device.
'';
};
keyFile = mkOption {
default = null;
example = "/dev/sdb1";
2015-08-17 19:52:45 +02:00
type = types.nullOr types.str;
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.
'';
};
preLVM = mkOption {
default = true;
type = types.bool;
description = "Whether the luksOpen will be attempted before LVM scan or after it.";
};
allowDiscards = mkOption {
default = false;
type = types.bool;
description = ''
Whether to allow TRIM requests to the underlying device. This option
2015-05-04 14:12:49 +02:00
has security implications; please read the LUKS documentation before
activating it.
'';
};
yubikey = mkOption {
default = null;
type = types.nullOr types.optionSet;
description = ''
The options to use for this LUKS device in Yubikey-PBA.
If null (the default), Yubikey-PBA will be disabled for this device.
'';
options = {
twoFactor = mkOption {
default = true;
type = types.bool;
2015-05-04 14:16:03 +02:00
description = "Whether to use a passphrase and a Yubikey (true), or only a Yubikey (false).";
};
slot = mkOption {
default = 2;
type = types.int;
2015-05-04 14:16:03 +02:00
description = "Which slot on the Yubikey to 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 17:10:59 +01:00
saltLength = mkOption {
default = 16;
type = types.int;
2015-05-04 14:16:03 +02:00
description = "Length of the new salt in byte (64 is the effective maximum).";
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 17:10:59 +01:00
};
keyLength = mkOption {
default = 64;
type = types.int;
2015-05-04 14:16:03 +02:00
description = "Length of the LUKS slot key derived with PBKDF2 in byte.";
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 17:10:59 +01:00
};
iterationStep = mkOption {
default = 0;
type = types.int;
2015-05-04 14:16:03 +02:00
description = "How much the iteration count for PBKDF2 is increased at each successful authentication.";
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 17:10:59 +01:00
};
gracePeriod = mkOption {
default = 2;
type = types.int;
2015-05-04 14:16:03 +02:00
description = "Time in seconds to wait before attempting to find the Yubikey.";
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 17:10:59 +01: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 22:50:17 +01:00
ramfsMountPoint = mkOption {
default = "/crypt-ramfs";
2015-08-17 19:52:45 +02:00
type = types.str;
2015-05-04 14:16:03 +02:00
description = "Path where the ramfs used to update the LUKS key will be mounted during early boot.";
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 22:50:17 +01:00
};
2014-08-29 18:43:03 +02:00
/* TODO: Add to the documentation of the current module:
Options related to the storing the salt.
*/
storage = {
device = mkOption {
default = "/dev/sda1";
type = types.path;
description = ''
An unencrypted device that will temporarily be mounted in stage-1.
Must contain the current salt to create the challenge for this LUKS device.
'';
};
fsType = mkOption {
default = "vfat";
2015-08-17 19:52:45 +02:00
type = types.str;
2015-05-04 14:16:03 +02:00
description = "The filesystem of the unencrypted device.";
2014-08-29 18:43:03 +02:00
};
mountPoint = mkOption {
default = "/crypt-storage";
2015-08-17 19:52:45 +02:00
type = types.str;
2015-05-04 14:16:03 +02:00
description = "Path where the unencrypted device will be mounted during early boot.";
2014-08-29 18:43:03 +02:00
};
path = mkOption {
default = "/crypt-storage/default";
2015-08-17 19:52:45 +02:00
type = types.str;
2014-08-29 18:43:03 +02:00
description = ''
Absolute path of the salt on the unencrypted device with
that device's root directory as "/".
'';
};
};
};
};
};
};
boot.initrd.luks.yubikeySupport = mkOption {
default = false;
type = types.bool;
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.
'';
};
};
config = mkIf (luks.devices != []) {
# 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"];
# Some modules that may be needed for mounting anything ciphered
boot.initrd.availableKernelModules = [ "dm_mod" "dm_crypt" "cryptd" ] ++ luks.cryptoModules;
# copy the cryptsetup binary and it's dependencies
boot.initrd.extraUtilsCommands = ''
2015-03-29 01:15:41 +01:00
copy_bin_and_libs ${pkgs.cryptsetup}/bin/cryptsetup
cat > $out/bin/cryptsetup-askpass <<EOF
#!$out/bin/sh -e
if [ -e /.luksopen_args ]; then
cryptsetup \$(cat /.luksopen_args)
killall cryptsetup
else
echo "Passphrase is not requested now"
exit 1
fi
EOF
chmod +x $out/bin/cryptsetup-askpass
${optionalString luks.yubikeySupport ''
2015-03-29 01:15:41 +01:00
copy_bin_and_libs ${pkgs.ykpers}/bin/ykchalresp
copy_bin_and_libs ${pkgs.ykpers}/bin/ykinfo
copy_bin_and_libs ${pkgs.openssl}/bin/openssl
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 17:10:59 +01:00
2015-03-29 01:15:41 +01:00
cc -O3 -I${pkgs.openssl}/include -L${pkgs.openssl}/lib ${./pbkdf2-sha512.c} -o pbkdf2-sha512 -lcrypto
strip -s pbkdf2-sha512
copy_bin_and_libs pbkdf2-sha512
2015-03-29 01:15:41 +01:00
mkdir -p $out/etc/ssl
cp -pdv ${pkgs.openssl}/etc/ssl/openssl.cnf $out/etc/ssl
2015-05-04 14:16:03 +02:00
cat > $out/bin/openssl-wrap <<EOF
#!$out/bin/sh
export OPENSSL_CONF=$out/etc/ssl/openssl.cnf
$out/bin/openssl "\$@"
2015-05-04 14:16:03 +02:00
EOF
chmod +x $out/bin/openssl-wrap
''}
'';
boot.initrd.extraUtilsCommandsTest = ''
$out/bin/cryptsetup --version
${optionalString luks.yubikeySupport ''
$out/bin/ykchalresp -V
$out/bin/ykinfo -V
$out/bin/openssl-wrap version
''}
'';
boot.initrd.preLVMCommands = concatMapStrings openCommand preLVM;
boot.initrd.postDeviceCommands = concatMapStrings openCommand postLVM;
environment.systemPackages = [ pkgs.cryptsetup ];
};
}