Commit graph

27 commits

Author SHA1 Message Date
Tuomas Tynkkynen 13b3f3f246 treewide: Mass replace 'openssl}/bin' to refer the 'bin' output 2016-02-01 20:46:16 +02:00
Tuomas Tynkkynen d91c7347d1 treewide: Mass replace 'openssl}/lib' to refer the 'out' output 2016-01-24 10:03:38 +02:00
Thomas Strobel a04a7272aa Add missing 'type', 'defaultText' and 'literalExample' in module definitions
- add missing types in module definitions
- add missing 'defaultText' in module definitions
- wrap example with 'literalExample' where necessary in module definitions
2016-01-17 19:41:23 +01:00
Nikolay Amiantov 12fcfe39db nixos/luksroot: allow to enter passphrase from another console 2015-10-18 18:41:11 +03:00
Nikolay Amiantov 1bd3d9de2a nixos/luksroot: use 'nuke-refs -e' option to simplify things 2015-10-18 18:41:11 +03:00
Jan Malakhovski 6eadb16022 nixos: fix some types 2015-09-18 18:48:50 +00:00
Marcin Falkiewicz c1becad3eb nixos/modules/system/boot/luksroot.nix: allow for LUKS devices with detached header 2015-06-29 17:36:47 +02:00
Eelco Dolstra 6e6a96d42c Some more type cleanup 2015-06-15 18:18:46 +02:00
Eelco Dolstra 28e49dcb41 Style fix 2015-05-04 14:18:14 +02:00
Eelco Dolstra c2bf9c3ee3 Typo 2015-05-04 14:16:19 +02:00
William A. Kennington III 4868649f03 nixos/initrd: Generic library copying 2015-03-28 18:37:29 -07:00
Aristid Breitkreuz 1901f3fe77 fix initrd now that cryptsetup switched to libgcrypt 1.6 2015-03-28 23:59:19 +00:00
Peter Simons 0f2b026bfe nixos/modules/system/boot/luksroot.nix: hyperlinkify an URL in the documentation 2014-12-15 16:31:18 +01:00
Nicolas Pierron 8c19690d99 Remove useless use of optionSet. 2014-08-29 18:43:03 +02:00
Eelco Dolstra f6b4214567 /dev/sda1 -> "/dev/sda1"
Otherwise Nix might try to copy /dev/sda1 under certain circumstances
:-)
2014-08-26 19:30:45 +02:00
Eelco Dolstra 29027fd1e1 Rewrite ‘with pkgs.lib’ -> ‘with lib’
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
2014-04-14 16:26:48 +02:00
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
Moritz Maxeiner 8e74e1fded 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
Moritz Maxeiner 7bf94cadad Add library dependencies explicitly 2014-01-29 18:49:26 +01:00
Moritz Maxeiner e96f58ef5c Implement muli-user authentication for yubikey pba, i.e. multiple users can now share a single luks keyslot.
This is achieved by having multiple lines per storage file, one for each user (if the feature is enabled); each of these
lines has the same format as would be the case for the userless authentication, except that they are prepended with a
SHA-512 of the user's id.
2014-01-29 17:20:05 +01:00
Moritz Maxeiner 20cfaf0faa Change the crypt-storage file to be hex encoded instead of raw binary. To update from the previous configuration, convert your crypt-storage file from raw binary to hex. 2014-01-29 13:58:35 +01:00
Moritz Maxeiner cce9712331 Enable two-factor authentication by default. Add proper descriptions to attributes. 2014-01-29 12:55:32 +01:00
Moritz Maxeiner 45b1ffb8db Cosmetic change to yubikey detection 2014-01-28 20:39:46 +01:00
Moritz Maxeiner 407a770161 Rewrite as a pre-boot authentication module (mostly) comforming to the design specification of
'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'.

Used binaries:
  * uuidgen - for generation of random sequence numbers
  * ykchalresp - for challenging a Yubikey
  * ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise)
  * openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption

Main differences to the specification mentioned above:
  * No user management (yet), only one password+yubikey per LUKS device
  * SHA-512 instead of CRC-16 for checksum

Main differences to the previous implementation:
  * Instead of changing the key slot of the LUKS device each boot,
    the actual key for the LUKS device will be encrypted itself
  * Since the response for the new challenge is now calculated
    locally with openssl, the MITM-USB-attack with which previously
    an attacker could obtain the new response (that was used as the new
    encryption key for the LUKS device) by listening to the
    Yubikey has ideally become useless (as long as uuidgen can
    successfuly generate new random sequence numbers).

Remarks:
  * This is not downwards compatible to the previous implementation
2014-01-28 04:02:51 +01:00
Moritz Maxeiner 333f5caaf9 Implement authentication for a LUKS device with a yubikey (HMAC-SHA1); supports simple challenge-response and two-factor authentication 2014-01-25 03:33:09 +01:00
Eelco Dolstra 8f4c5b05d5 Add a way to define obsolete options that have no replacement 2013-10-23 20:08:22 +02:00
Eelco Dolstra 5c1f8cbc70 Move all of NixOS to nixos/ in preparation of the repository merge 2013-10-10 13:28:20 +02:00
Renamed from modules/system/boot/luksroot.nix (Browse further)