Skip to content
Commit 8e74e1fd authored by Moritz Maxeiner's avatar Moritz Maxeiner
Browse files

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.
parent e96bc485
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment