2013-07-23 17:56:12 +01:00
|
|
|
{ config, pkgs, ... }:
|
2010-10-25 01:57:30 +01:00
|
|
|
|
|
|
|
|
with pkgs.lib;
|
|
|
|
|
|
|
|
|
|
let
|
2012-03-03 16:07:18 +00:00
|
|
|
luks = config.boot.initrd.luks;
|
|
|
|
|
|
2014-01-25 02:27:12 +00:00
|
|
|
openCommand = { name, device, keyFile, keyFileSize, allowDiscards, yubikey, ... }: ''
|
2012-03-03 16:07:18 +00:00
|
|
|
# Wait for luksRoot to appear, e.g. if on a usb drive.
|
|
|
|
|
# XXX: copied and adapted from stage-1-init.sh - should be
|
|
|
|
|
# available as a function.
|
|
|
|
|
if ! test -e ${device}; then
|
|
|
|
|
echo -n "waiting 10 seconds for device ${device} to appear..."
|
2012-06-27 14:43:54 +01:00
|
|
|
for try in $(seq 10); do
|
2012-03-03 16:07:18 +00:00
|
|
|
sleep 1
|
|
|
|
|
if test -e ${device}; then break; fi
|
2012-03-04 21:00:35 +00:00
|
|
|
echo -n .
|
2012-03-03 16:07:18 +00:00
|
|
|
done
|
|
|
|
|
echo "ok"
|
|
|
|
|
fi
|
|
|
|
|
|
2012-08-02 10:39:31 +01:00
|
|
|
${optionalString (keyFile != null) ''
|
2012-05-02 23:37:14 +01:00
|
|
|
if ! test -e ${keyFile}; then
|
|
|
|
|
echo -n "waiting 10 seconds for key file ${keyFile} to appear..."
|
|
|
|
|
for try in $(seq 10); do
|
|
|
|
|
sleep 1
|
|
|
|
|
if test -e ${keyFile}; then break; fi
|
|
|
|
|
echo -n .
|
|
|
|
|
done
|
|
|
|
|
echo "ok"
|
|
|
|
|
fi
|
|
|
|
|
''}
|
|
|
|
|
|
2014-01-28 03:02:51 +00:00
|
|
|
open_normally() {
|
|
|
|
|
cryptsetup luksOpen ${device} ${name} ${optionalString allowDiscards "--allow-discards"} \
|
|
|
|
|
${optionalString (keyFile != null) "--key-file=${keyFile} ${optionalString (keyFileSize != null) "--keyfile-size=${toString keyFileSize}"}"}
|
|
|
|
|
}
|
|
|
|
|
|
2014-01-25 02:27:12 +00:00
|
|
|
${optionalString (luks.yubikeySupport && (yubikey != null)) ''
|
|
|
|
|
|
2014-01-28 03:02:51 +00:00
|
|
|
rbtohex() {
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
( od -An -vtx1 | tr -d ' \n' )
|
2014-01-28 03:02:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
hextorb() {
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
( tr '[:lower:]' '[:upper:]' | sed -e 's/\([0-9A-F]\{2\}\)/\\\\\\x\1/gI'| xargs printf )
|
2014-01-28 03:02:51 +00:00
|
|
|
}
|
2014-01-25 02:27:12 +00:00
|
|
|
|
2014-01-28 03:02:51 +00:00
|
|
|
open_yubikey() {
|
2014-01-25 02:27:12 +00:00
|
|
|
|
2014-01-28 03:02:51 +00:00
|
|
|
mkdir -p ${yubikey.storage.mountPoint}
|
|
|
|
|
mount -t ${yubikey.storage.fsType} ${toString yubikey.storage.device} ${yubikey.storage.mountPoint}
|
2014-01-25 02:27:12 +00:00
|
|
|
|
2014-01-28 03:02:51 +00:00
|
|
|
local uuid_r
|
|
|
|
|
local k_user
|
|
|
|
|
local challenge
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
local opened
|
2014-01-29 16:20:05 +00:00
|
|
|
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
sleep 1
|
2014-01-29 16:20:05 +00:00
|
|
|
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
uuid_r="$(cat ${yubikey.storage.mountPoint}${yubikey.storage.path})"
|
2014-01-25 02:27:12 +00:00
|
|
|
|
2014-01-28 03:02:51 +00:00
|
|
|
for try in $(seq 3); do
|
2014-01-25 02:27:12 +00:00
|
|
|
|
2014-01-28 03:02:51 +00:00
|
|
|
${optionalString yubikey.twoFactor ''
|
|
|
|
|
echo -n "Enter two-factor passphrase: "
|
|
|
|
|
read -s k_user
|
2014-01-29 16:20:05 +00:00
|
|
|
echo
|
2014-01-28 03:02:51 +00:00
|
|
|
''}
|
|
|
|
|
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
challenge="$(echo -n $k_user$uuid_r | openssl-wrap dgst -binary -sha512 | rbtohex)"
|
2014-01-29 16:20:05 +00:00
|
|
|
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
k_luks="$(ykchalresp -${toString yubikey.slot} -x $challenge 2>/dev/null)"
|
2014-01-29 16:20:05 +00:00
|
|
|
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
echo -n "$k_luks" | hextorb | cryptsetup luksOpen ${device} ${name} ${optionalString allowDiscards "--allow-discards"} --key-file=-
|
2014-01-29 16:20:05 +00:00
|
|
|
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
if [ $? == "0" ]; then
|
|
|
|
|
opened=true
|
|
|
|
|
break
|
2014-01-28 03:02:51 +00:00
|
|
|
else
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
opened=false
|
2014-01-29 16:20:05 +00:00
|
|
|
echo "Authentication failed!"
|
2014-01-28 03:02:51 +00:00
|
|
|
fi
|
|
|
|
|
done
|
|
|
|
|
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
if [ "$opened" == false ]; then
|
2014-01-28 03:02:51 +00:00
|
|
|
umount ${yubikey.storage.mountPoint}
|
|
|
|
|
echo "Maximum authentication errors reached"
|
|
|
|
|
exit 1
|
2014-01-25 02:27:12 +00:00
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
update_failed=false
|
|
|
|
|
|
2014-01-28 03:02:51 +00:00
|
|
|
local new_uuid_r
|
|
|
|
|
new_uuid_r="$(uuidgen)"
|
2014-01-25 02:27:12 +00:00
|
|
|
if [ $? != "0" ]; then
|
|
|
|
|
for try in $(seq 10); do
|
|
|
|
|
sleep 1
|
2014-01-28 03:02:51 +00:00
|
|
|
new_uuid_r="$(uuidgen)"
|
2014-01-25 02:27:12 +00:00
|
|
|
if [ $? == "0" ]; then break; fi
|
|
|
|
|
if [ $try -eq 10 ]; then update_failed=true; fi
|
|
|
|
|
done
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
if [ "$update_failed" == false ]; then
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
new_uuid_r="$(echo -n $new_uuid_r | head -c 36 | tr -d '-')"
|
2014-01-25 02:27:12 +00:00
|
|
|
|
2014-01-28 03:02:51 +00:00
|
|
|
local new_challenge
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
new_challenge="$(echo -n $k_user$new_uuid_r | openssl-wrap dgst -binary -sha512 | rbtohex)"
|
2014-01-25 02:27:12 +00:00
|
|
|
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
local new_k_luks
|
|
|
|
|
new_k_luks="$(ykchalresp -${toString yubikey.slot} -x $new_challenge 2>/dev/null)"
|
2014-01-25 02:27:12 +00:00
|
|
|
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
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}
|
2014-01-29 16:20:05 +00:00
|
|
|
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
echo -n "$new_k_luks" | hextorb > ${yubikey.ramfsMountPoint}/new_key
|
|
|
|
|
echo -n "$k_luks" | cryptsetup luksChangeKey ${device} --key-file=- ${yubikey.ramfsMountPoint}/new_key
|
2014-01-29 16:20:05 +00:00
|
|
|
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
if [ $? == "0" ]; then
|
|
|
|
|
echo -n "$new_uuid_r" > ${yubikey.storage.mountPoint}${yubikey.storage.path}
|
|
|
|
|
else
|
|
|
|
|
echo "Warning: Could not update LUKS key, current challenge persists!"
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
rm -f ${yubikey.ramfsMountPoint}/new_key
|
|
|
|
|
umount ${yubikey.ramfsMountPoint}
|
|
|
|
|
rm -rf ${yubikey.ramfsMountPoint}
|
2014-01-25 02:27:12 +00:00
|
|
|
else
|
2014-01-28 03:02:51 +00:00
|
|
|
echo "Warning: Could not obtain new UUID, current challenge persists!"
|
2014-01-25 02:27:12 +00:00
|
|
|
fi
|
|
|
|
|
|
2014-01-28 03:02:51 +00:00
|
|
|
umount ${yubikey.storage.mountPoint}
|
|
|
|
|
}
|
|
|
|
|
|
2014-01-28 19:39:25 +00:00
|
|
|
yubikey_missing=true
|
|
|
|
|
ykinfo -v 1>/dev/null 2>&1
|
|
|
|
|
if [ $? != "0" ]; then
|
2014-01-28 03:02:51 +00:00
|
|
|
echo -n "waiting 10 seconds for yubikey to appear..."
|
|
|
|
|
for try in $(seq 10); do
|
|
|
|
|
sleep 1
|
2014-01-28 19:39:25 +00:00
|
|
|
ykinfo -v 1>/dev/null 2>&1
|
|
|
|
|
if [ $? == "0" ]; then
|
|
|
|
|
yubikey_missing=false
|
|
|
|
|
break
|
|
|
|
|
fi
|
2014-01-28 03:02:51 +00:00
|
|
|
echo -n .
|
|
|
|
|
done
|
|
|
|
|
echo "ok"
|
2014-01-28 19:39:25 +00:00
|
|
|
else
|
|
|
|
|
yubikey_missing=false
|
2014-01-25 02:27:12 +00:00
|
|
|
fi
|
2014-01-28 03:02:51 +00:00
|
|
|
|
2014-01-28 19:39:25 +00:00
|
|
|
if [ "$yubikey_missing" == true ]; then
|
2014-01-28 03:02:51 +00:00
|
|
|
echo "no yubikey found, falling back to non-yubikey open procedure"
|
|
|
|
|
open_normally
|
|
|
|
|
else
|
|
|
|
|
open_yubikey
|
|
|
|
|
fi
|
|
|
|
|
''}
|
|
|
|
|
|
|
|
|
|
# open luksRoot and scan for logical volumes
|
|
|
|
|
${optionalString ((!luks.yubikeySupport) || (yubikey == null)) ''
|
|
|
|
|
open_normally
|
2014-01-25 02:27:12 +00:00
|
|
|
''}
|
2012-03-03 16:07:18 +00:00
|
|
|
'';
|
|
|
|
|
|
2012-03-04 21:00:35 +00:00
|
|
|
isPreLVM = f: f.preLVM;
|
|
|
|
|
preLVM = filter isPreLVM luks.devices;
|
|
|
|
|
postLVM = filter (f: !(isPreLVM f)) luks.devices;
|
|
|
|
|
|
2010-10-25 01:57:30 +01:00
|
|
|
in
|
|
|
|
|
{
|
|
|
|
|
|
|
|
|
|
options = {
|
|
|
|
|
|
2013-01-13 09:04:26 +00:00
|
|
|
boot.initrd.luks.mitigateDMAAttacks = mkOption {
|
2013-10-23 17:22:26 +01:00
|
|
|
type = types.bool;
|
2013-01-13 09:04:26 +00:00
|
|
|
default = true;
|
|
|
|
|
description = ''
|
2013-07-23 17:56:12 +01:00
|
|
|
Unless enabled, encryption keys can be easily recovered by an attacker with physical
|
|
|
|
|
access to any machine with PCMCIA, ExpressCard, ThunderBolt or FireWire port.
|
|
|
|
|
More information: http://en.wikipedia.org/wiki/DMA_attack
|
2013-01-13 09:04:26 +00:00
|
|
|
|
2013-07-23 17:56:12 +01:00
|
|
|
This option blacklists FireWire drivers, but doesn't remove them. You can manually
|
|
|
|
|
load the drivers if you need to use a FireWire device, but don't forget to unload them!
|
2013-01-13 09:04:26 +00:00
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2013-01-13 10:44:16 +00:00
|
|
|
boot.initrd.luks.cryptoModules = mkOption {
|
2013-10-23 17:22:26 +01:00
|
|
|
type = types.listOf types.string;
|
2013-07-23 17:56:12 +01:00
|
|
|
default =
|
2013-10-09 18:11:47 +01:00
|
|
|
[ "aes" "aes_generic" "blowfish" "twofish"
|
|
|
|
|
"serpent" "cbc" "xts" "lrw" "sha1" "sha256" "sha512"
|
|
|
|
|
(if pkgs.stdenv.system == "x86_64-linux" then "aes_x86_64" else "aes_i586")
|
2013-07-23 17:56:12 +01:00
|
|
|
];
|
2013-01-13 10:44:16 +00:00
|
|
|
description = ''
|
2013-07-23 17:56:12 +01:00
|
|
|
A list of cryptographic kernel modules needed to decrypt the root device(s).
|
|
|
|
|
The default includes all common modules.
|
2013-01-13 10:44:16 +00:00
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2012-03-03 16:07:18 +00:00
|
|
|
boot.initrd.luks.devices = mkOption {
|
|
|
|
|
default = [ ];
|
2012-03-04 21:00:35 +00:00
|
|
|
example = [ { name = "luksroot"; device = "/dev/sda3"; preLVM = true; } ];
|
2012-05-15 21:45:01 +01:00
|
|
|
description = ''
|
2012-03-03 16:07:18 +00:00
|
|
|
The list of devices that should be decrypted using LUKS before trying to mount the
|
2010-10-25 01:57:30 +01:00
|
|
|
root partition. This works for both LVM-over-LUKS and LUKS-over-LVM setups.
|
2011-09-14 19:20:50 +01:00
|
|
|
|
2012-03-03 16:07:18 +00:00
|
|
|
The devices are decrypted to the device mapper names defined.
|
2010-10-25 01:57:30 +01:00
|
|
|
|
2012-03-03 16:07:18 +00:00
|
|
|
Make sure that initrd has the crypto modules needed for decryption.
|
2010-10-25 01:57:30 +01:00
|
|
|
'';
|
2012-03-04 21:00:35 +00:00
|
|
|
|
2013-03-14 16:09:21 +00:00
|
|
|
type = types.listOf types.optionSet;
|
2012-03-04 21:00:35 +00:00
|
|
|
|
|
|
|
|
options = {
|
|
|
|
|
|
|
|
|
|
name = mkOption {
|
|
|
|
|
example = "luksroot";
|
|
|
|
|
type = types.string;
|
2012-04-26 13:21:45 +01:00
|
|
|
description = "Named to be used for the generated device in /dev/mapper.";
|
2012-03-04 21:00:35 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
device = mkOption {
|
|
|
|
|
example = "/dev/sda2";
|
|
|
|
|
type = types.string;
|
2012-04-26 15:53:58 +01:00
|
|
|
description = "Path of the underlying block device.";
|
2012-03-04 21:00:35 +00:00
|
|
|
};
|
|
|
|
|
|
2012-05-02 23:37:14 +01:00
|
|
|
keyFile = mkOption {
|
|
|
|
|
default = null;
|
|
|
|
|
example = "/dev/sdb1";
|
|
|
|
|
type = types.nullOr types.string;
|
|
|
|
|
description = ''
|
|
|
|
|
The name of the file (can be a raw device or a partition) that
|
|
|
|
|
should be used as the decryption key for the encrypted device. If
|
|
|
|
|
not specified, you will be prompted for a passphrase instead.
|
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
keyFileSize = mkOption {
|
|
|
|
|
default = null;
|
|
|
|
|
example = 4096;
|
|
|
|
|
type = types.nullOr types.int;
|
|
|
|
|
description = ''
|
|
|
|
|
The size of the key file. Use this if only the beginning of the
|
|
|
|
|
key file should be used as a key (often the case if a raw device
|
|
|
|
|
or partition is used as key file). If not specified, the whole
|
|
|
|
|
<literal>keyFile</literal> will be used decryption, instead of just
|
|
|
|
|
the first <literal>keyFileSize</literal> bytes.
|
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2012-03-04 21:00:35 +00:00
|
|
|
preLVM = mkOption {
|
|
|
|
|
default = true;
|
|
|
|
|
type = types.bool;
|
2012-04-26 13:21:45 +01:00
|
|
|
description = "Whether the luksOpen will be attempted before LVM scan or after it.";
|
2012-03-04 21:00:35 +00:00
|
|
|
};
|
2012-07-17 12:10:00 +01:00
|
|
|
|
|
|
|
|
allowDiscards = mkOption {
|
|
|
|
|
default = false;
|
|
|
|
|
type = types.bool;
|
|
|
|
|
description = ''
|
|
|
|
|
Whether to allow TRIM requests to the underlying device. This option
|
|
|
|
|
has security implications, please read the LUKS documentation before
|
|
|
|
|
activating in.
|
|
|
|
|
'';
|
|
|
|
|
};
|
|
|
|
|
|
2014-01-25 02:27:12 +00:00
|
|
|
yubikey = mkOption {
|
|
|
|
|
default = null;
|
|
|
|
|
type = types.nullOr types.optionSet;
|
2014-01-28 22:45:16 +00:00
|
|
|
description = ''
|
|
|
|
|
The options to use for this LUKS device in Yubikey-PBA.
|
|
|
|
|
If null (the default), Yubikey-PBA will be disabled for this device.
|
|
|
|
|
'';
|
2014-01-25 02:27:12 +00:00
|
|
|
|
|
|
|
|
options = {
|
|
|
|
|
twoFactor = mkOption {
|
2014-01-28 22:45:16 +00:00
|
|
|
default = true;
|
2014-01-25 02:27:12 +00:00
|
|
|
type = types.bool;
|
2014-01-28 22:45:16 +00:00
|
|
|
description = "Whether to use a passphrase and a Yubikey (true), or only a Yubikey (false)";
|
2014-01-25 02:27:12 +00:00
|
|
|
};
|
|
|
|
|
|
2014-01-28 03:02:51 +00:00
|
|
|
slot = mkOption {
|
2014-01-25 02:27:12 +00:00
|
|
|
default = 2;
|
|
|
|
|
type = types.int;
|
2014-01-28 22:45:16 +00:00
|
|
|
description = "Which slot on the Yubikey to challenge";
|
2014-01-25 02:27:12 +00:00
|
|
|
};
|
|
|
|
|
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
ramfsMountPoint = mkOption {
|
|
|
|
|
default = "/crypt-ramfs";
|
|
|
|
|
type = types.string;
|
|
|
|
|
description = "Path where the ramfs used to update the LUKS key will be mounted in stage-1";
|
|
|
|
|
};
|
|
|
|
|
|
2014-01-28 03:02:51 +00:00
|
|
|
storage = mkOption {
|
2014-01-25 02:27:12 +00:00
|
|
|
type = types.optionSet;
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
description = "Options related to the storing the random UUID";
|
2014-01-25 02:27:12 +00:00
|
|
|
|
|
|
|
|
options = {
|
|
|
|
|
device = mkOption {
|
|
|
|
|
default = /dev/sda1;
|
|
|
|
|
type = types.path;
|
2014-01-28 22:45:16 +00:00
|
|
|
description = ''
|
|
|
|
|
An unencrypted device that will temporarily be mounted in stage-1.
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
Must contain the current random UUID to create the challenge for this LUKS device.
|
2014-01-28 22:45:16 +00:00
|
|
|
'';
|
2014-01-25 02:27:12 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
fsType = mkOption {
|
|
|
|
|
default = "vfat";
|
|
|
|
|
type = types.string;
|
2014-01-28 22:45:16 +00:00
|
|
|
description = "The filesystem of the unencrypted device";
|
2014-01-25 02:27:12 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
mountPoint = mkOption {
|
2014-01-28 03:02:51 +00:00
|
|
|
default = "/crypt-storage";
|
2014-01-25 02:27:12 +00:00
|
|
|
type = types.string;
|
2014-01-28 22:45:16 +00:00
|
|
|
description = "Path where the unencrypted device will be mounted in stage-1";
|
2014-01-25 02:27:12 +00:00
|
|
|
};
|
|
|
|
|
|
2014-01-28 03:02:51 +00:00
|
|
|
path = mkOption {
|
|
|
|
|
default = "/crypt-storage/default";
|
2014-01-25 02:27:12 +00:00
|
|
|
type = types.string;
|
2014-01-28 22:45:16 +00:00
|
|
|
description = ''
|
Replace the current Yubikey PBA implementation with the previous one.
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
2014-02-03 21:50:17 +00:00
|
|
|
Absolute path of the random UUID on the unencrypted device with
|
2014-01-28 22:45:16 +00:00
|
|
|
that device's root directory as "/".
|
|
|
|
|
'';
|
2014-01-25 02:27:12 +00:00
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
};
|
2013-10-23 17:22:26 +01:00
|
|
|
|
2014-01-25 02:27:12 +00:00
|
|
|
};
|
2010-10-25 01:57:30 +01:00
|
|
|
};
|
2013-10-23 17:22:26 +01:00
|
|
|
|
2014-01-25 02:27:12 +00:00
|
|
|
boot.initrd.luks.yubikeySupport = mkOption {
|
|
|
|
|
default = false;
|
|
|
|
|
type = types.bool;
|
2014-01-28 22:45:16 +00:00
|
|
|
description = ''
|
|
|
|
|
Enables support for authenticating with a Yubikey on LUKS devices.
|
|
|
|
|
See the NixOS wiki for information on how to properly setup a LUKS device
|
|
|
|
|
and a Yubikey to work with this feature.
|
|
|
|
|
'';
|
2014-01-25 02:27:12 +00:00
|
|
|
};
|
2010-10-25 01:57:30 +01:00
|
|
|
};
|
|
|
|
|
|
2012-05-15 21:45:01 +01:00
|
|
|
config = mkIf (luks.devices != []) {
|
2010-10-25 01:57:30 +01:00
|
|
|
|
2013-01-13 09:04:26 +00:00
|
|
|
# actually, sbp2 driver is the one enabling the DMA attack, but this needs to be tested
|
|
|
|
|
boot.blacklistedKernelModules = optionals luks.mitigateDMAAttacks
|
|
|
|
|
["firewire_ohci" "firewire_core" "firewire_sbp2"];
|
|
|
|
|
|
2012-03-03 16:07:18 +00:00
|
|
|
# Some modules that may be needed for mounting anything ciphered
|
2013-10-09 18:11:47 +01:00
|
|
|
boot.initrd.availableKernelModules = [ "dm_mod" "dm_crypt" "cryptd" ] ++ luks.cryptoModules;
|
2010-10-25 01:57:30 +01:00
|
|
|
|
2011-12-28 21:46:40 +00:00
|
|
|
# copy the cryptsetup binary and it's dependencies
|
2010-10-25 01:57:30 +01:00
|
|
|
boot.initrd.extraUtilsCommands = ''
|
2011-12-28 21:46:40 +00:00
|
|
|
cp -pdv ${pkgs.cryptsetup}/sbin/cryptsetup $out/bin
|
2014-01-29 17:49:26 +00:00
|
|
|
|
|
|
|
|
cp -pdv ${pkgs.libgcrypt}/lib/libgcrypt*.so.* $out/lib
|
|
|
|
|
cp -pdv ${pkgs.libgpgerror}/lib/libgpg-error*.so.* $out/lib
|
|
|
|
|
cp -pdv ${pkgs.cryptsetup}/lib/libcryptsetup*.so.* $out/lib
|
|
|
|
|
cp -pdv ${pkgs.popt}/lib/libpopt*.so.* $out/lib
|
2014-01-28 03:02:51 +00:00
|
|
|
|
2014-01-25 02:27:12 +00:00
|
|
|
${optionalString luks.yubikeySupport ''
|
|
|
|
|
cp -pdv ${pkgs.utillinux}/bin/uuidgen $out/bin
|
|
|
|
|
cp -pdv ${pkgs.ykpers}/bin/ykchalresp $out/bin
|
2014-01-28 03:02:51 +00:00
|
|
|
cp -pdv ${pkgs.ykpers}/bin/ykinfo $out/bin
|
|
|
|
|
cp -pdv ${pkgs.openssl}/bin/openssl $out/bin
|
2014-01-29 17:49:26 +00:00
|
|
|
|
|
|
|
|
cp -pdv ${pkgs.libusb1}/lib/libusb*.so.* $out/lib
|
|
|
|
|
cp -pdv ${pkgs.ykpers}/lib/libykpers*.so.* $out/lib
|
|
|
|
|
cp -pdv ${pkgs.libyubikey}/lib/libyubikey*.so.* $out/lib
|
|
|
|
|
cp -pdv ${pkgs.openssl}/lib/libssl*.so.* $out/lib
|
|
|
|
|
cp -pdv ${pkgs.openssl}/lib/libcrypto*.so.* $out/lib
|
2014-01-28 03:02:51 +00:00
|
|
|
|
|
|
|
|
mkdir -p $out/etc/ssl
|
|
|
|
|
cp -pdv ${pkgs.openssl}/etc/ssl/openssl.cnf $out/etc/ssl
|
|
|
|
|
|
|
|
|
|
cat > $out/bin/openssl-wrap <<EOF
|
|
|
|
|
#!$out/bin/sh
|
|
|
|
|
EOF
|
|
|
|
|
chmod +x $out/bin/openssl-wrap
|
2014-01-25 02:27:12 +00:00
|
|
|
''}
|
2011-12-28 21:46:40 +00:00
|
|
|
'';
|
|
|
|
|
|
|
|
|
|
boot.initrd.extraUtilsCommandsTest = ''
|
2011-12-28 22:37:38 +00:00
|
|
|
$out/bin/cryptsetup --version
|
2014-01-25 02:27:12 +00:00
|
|
|
${optionalString luks.yubikeySupport ''
|
|
|
|
|
$out/bin/uuidgen --version
|
|
|
|
|
$out/bin/ykchalresp -V
|
2014-01-28 03:02:51 +00:00
|
|
|
$out/bin/ykinfo -V
|
|
|
|
|
cat > $out/bin/openssl-wrap <<EOF
|
|
|
|
|
#!$out/bin/sh
|
|
|
|
|
export OPENSSL_CONF=$out/etc/ssl/openssl.cnf
|
|
|
|
|
$out/bin/openssl "\$@"
|
|
|
|
|
EOF
|
|
|
|
|
$out/bin/openssl-wrap version
|
2014-01-25 02:27:12 +00:00
|
|
|
''}
|
2010-10-25 01:57:30 +01:00
|
|
|
'';
|
|
|
|
|
|
2012-03-04 21:00:35 +00:00
|
|
|
boot.initrd.preLVMCommands = concatMapStrings openCommand preLVM;
|
|
|
|
|
boot.initrd.postDeviceCommands = concatMapStrings openCommand postLVM;
|
2012-03-08 20:49:26 +00:00
|
|
|
|
|
|
|
|
environment.systemPackages = [ pkgs.cryptsetup ];
|
2010-10-25 01:57:30 +01:00
|
|
|
};
|
2011-09-14 19:20:50 +01:00
|
|
|
}
|
