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).
 * Rehash the response of the yubikey with the passphrase to get the luks key (so a USB-MITM attack on the yubikey itself is not enough to break the system if a passphrase is used).
 * Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random.
 * Length of the new salt in byte is now a parameter (can be set in configuration.nix), defaults to 16 byte.
   Note: Length of the challenge is 64 byte.

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 from unencrypted device (UE).
  2. Calculate the $challenge as 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. Calculate the key for the luks device $k_luks as SHA-512($k_user || $response),
       where "||" denotes concatenation.
    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 /dev/random
  7. Calculate the $new_challenge as SHA-512($new_salt).
  8. Challenge the yubikey with the $new_challenge and receive the $new_response.
  9. Calculate the new key for the luks device $new_k_luks as SHA-512($k_user || $new_response).
 10. Try to change the luks device's key $k_luks to $new_k_luks.
 11. If 10. was successful, write the $new_salt to the UE.

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 his reference implementation over at
   https://github.com/flowolf/initramfs_ykfde