Unlocking disk with keyfile from USB as second factor

This issue follows a discussion on issue #25 in heads-wiki. I'll briefly sum it up here for reference, to keep everything in the same place, even though I'm not sure it's the right way to do things here:

[GittCatt] One more question – is it currently possible to have an additional keyfile for LUKS encryption stored in TPM?

[tlaurion] yes. Its called a Disk Unlock Key and is enforced by setting a boot default under Heads on all boards having a TPM, but Purism ones, by default. […]

[GittCatt] But from what I understand, in the solution described by you, the TPM is in possession of the whole decryption key, but releases it only after I authenticate myself to it. So if there was a way to extract the key from the TPM, the attacker would only need my laptop and would have the whole disk decrypted. […]

@tlaurion then replied and let me reply to that also.

The threat model adressed currently through Heads is the evil maid able to capture the passphrase typed at boot and expecting to be able to clone the disk while owner is away and be able to decrypt the content at their leisure.

Well, I feel that storing the disk unlock key doesn't prevent that fully. If an attacker can sniff my password (by looking over my shoulder, installing a hidden a camera or perhaps even by soldering a keylogger into my laptop's keyboard), it's possible for him to normally boot into the system while I'm away, using that password. LUKS header and firmware measurements would be valid, of course. The only thing that attacker wouldn't be able to do is verifying the TOTP code, which obviously is not necessary.

Maybe it's not exactly “cloning the disk” while I'm away, because attacker can't take my SSD out, clone it on his machine and then follow by decrypting it using the sniffed password, but in most cases it's sufficient to copy the data on a running machine. That wouldn't fly only for forensic purposes, for example, but in this case you could just steal my whole laptop and keep it as evidence as a whole.

I know that if we describe the purpose of Heads as protecting you from the attack performed in a way that you can't easily find out about, it would pass that. I mean, it's easier to find hidden cameras than a modification in firmware, and you can always evade all external threats by moving into a secure room, but the laptop would be carried with you. So we're fine on this end.

But if I would like Heads to protect me from evil maid, period, then it's just doesn't work right now. Even if we exclude all external factors (not contained in the laptop itself), like cameras or electromagnetic leaks, Heads just moves the attacker's focus to electronics more than software. So with Heads, attacker has to resort to things like hidden keylogger, which arguably is even easier to perform than firmware attack. The thing that would make the attacker's job most difficult is that after sniffing the password, he would have to choose between stealing data from a running machine (a bit slower, maybe?) and stealing the whole laptop (instant exposure).

basically, you are talking about something like this https://docs.puri.sm/PureBoot/LibremKeyLUKS.html

I'm not, because it's more or less still the same, it's just shifting the focus from the laptop to a security key. Or even not completely – depending on the implementation, it could be possible to rig the USB port with something that sniffs the contents of the transmission (just like a classic hardware keylogger).

Maybe I don't see that we're talking about two completely different threat models — if so, I would be glad if you could point it out to me. Right now, I can see that my threat model is maybe just slightly different, but still more or less the same.

Start with the linked heads-wiki discussion and the threat-model concerns summarized here. The issue names no files, tests, or entry points, and the desired USB keyfile behavior and acceptance criteria need to be defined before implementation can begin.