I bought a new Yubikey, and am currently setting it up to use on my desktop PC. Previously the PC was secured with password only, and I'd like to use the Yubikey as an alternative: instead of using the password, I could instead use the Yubikey plus a short PIN code, but the password must remain as a backup mode.
There are multiple ways of doing this on Linux using PAM configuration. However, a problem arises when I want to apply this technique to my full-disk encryption: I'm using ZFS encryption, which seems to only support one keyslot, so both human entry and the Yubikey process need to produce the same password. Also, I don't want to change and lelearn this password.
My FDE password is a Diceware password, and I understand that the security of this scheme isn't significantly compromised if an adversary knows this fact.
First, I reduce my password to a short bit sequence. For example, the first 13 (=log_2(6^5)) bits represent the first word in the password, the next 13 bits indicate the second, and so on. Alternatively, this representation can have a bit more ambiguity: "how many words are used" could also be encoded in it. I write a program that takes in a sequence of bytes and produces the Diceware password that was encoded by it.
Next, I use the Yubikey's challenge-response mode. This mode allows programming a secret value
s into the key, and then sending it a challenge,
hash(c), and receiving an
r=HMAC(hash(c), s), which is 20 bytes or 160 bits long. I take the distilled password from the previous step,
p, and compute
q=p XOR r, which is then saved in plaintext on disk.
When I want to decrypt my disk, I can either provide my password (or equivalently the
p value) directly, or I can use the Yubikey. In the latter case, I input a PINcode or some short password as
c, then the Yubikey is used to produce
r, and finally this is XOR'd with the plaintext
q to generate the
p used to decrypt the disk. If either the PINcode or the Yubikey secret is wrong, then the generated
p does not produce the correct password and the decryption fails. This whole process runs with a program in the unencrypted pre-boot environment.
What are the security implications of this scheme? My first thought is that maybe the value of
q could be leaking something about the value of
p, but if the bits of
p that aren't used are set to random values, and the
r-values produced by a Yubikey are unpredictable (which they seem to be), then the combination of the two seems just as random.