1 commit

Author	SHA1	Message	Date
Moritz Maxeiner	09f9af17b4	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-08 14:59:52 +01:00