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.

@GittCatt

https://docs.puri.sm/PureBoot/LibremKeyLUKS.html

This implementation depends on the USB Security dongle's GPG User PIN to unlock the LUKS additional slot. So that moves hidden camera capture to having to steal both USB Security dongle and laptop and type the USB Security dongle User PIN to unlock the Disk Container, just like it would be to require an external boot device to boot the system, as per the Anti-Evil maid current implementation from QubesOS, while its measured boot is inside of Heads as it is right now.

I do not have any insight on how to currently implement such thing. If the user has to have a USB Security dongle, external boot medium (Anti Evil Maid stick) the complexity makes it quite inaccessible.

As said in previous ticket and reply, the Disk Unlock Key passphrase use is, if your threat model requires it, to change it at the beginning of each day if required.

Another implementation of such thing would be to combine use the Nitrokey Storage to store the Anti Evil Maid stick content on its encrypted partition. But that doesn't mitigate the translation of trust and problem when that device is lost. There is a choice to take here. I personally love the Disk Unlock Key passphrase more then the LibremKeyLUKS approach. And I prefer to set a new Disk Unlock Key prior of going in untrusted environement and rely on backpack, Lineyard and other quick security fixes like tamper evident nail polish to save my days and change the Disk Unlock Key passphrase once in safe environment again.

This is again links with physical security, but remember that bathroom cameras are kinda restricted everywhere in the world. Changing your passphrase under the blankets before and after going out, typing your Disk Recovery Key passphrase is the best option in my head. If paranoid, I would just get off the SSD drive and carry it separately from my laptop. Most of those threats cannot be properly done with technology without adding more risks and comlexify upgrades and general maintainership of the system.

Open to your thoughts.

Let me start by saying thank you, it really means a lot to have someone to discuss these thoughts with.

Another thing I have to state is what you've probably already noticed — I'm not yet familiar with all the technicalities and implementation details, so I try to reason at, let's say, a big higher level of abstraction. I'm always keen on learning, it's just a bit of a struggle to find good, reliable and accessible resources on all these topics, but maybe I'm not trying hard enough.

Enough with the disclaimers…

From what I understand from the Purism's implementation, it works like this: we generate a random secret that the disk would be encrypted with. Then we encrypt it with the user's public key and store it in… TPM in our case, I assume? Anyway, a place that is “publicly accessible”, let's say (which would mean “without a password”), but it doesn't really matter, since it's encrypted and it's the security dongle that takes care of the decryption.

Now this sounds almost good enough for me. It seems to tick all the boxes I wrote about above. Of course, it doesn't really eliminate the possibility of evil maid attack, does it? But in order to bypass this, the attacker would have to read the memory of a running machine (booted by himself), I think. If the attacker is able to do that, then even authenticating machine to a user via TOTP, which Heads does normally, would be worthless and unreliable. That would raise the question — is it a viable option for the evil maid? A little bit off-topic, but this is worth discussing.

About the external boot medium — I'm not sure why you suggest that. The only thing I wanted from the external stick was to provide a second factor, and now it seems to me that classic keyfile and LibremKeyLUKS are equally good (maybe the latter would be slightly better, but consider what I wrote above).

The rest is all about physical security.

I prefer to set a new Disk Unlock Key prior of going in untrusted environement […]

I would like to be proved wrong, but I think the main assumption in the classic evil maid attack is that you can't really know if a particular environment is or isn't safe (not: trusted). In an original scenario, I wouldn't leave my laptop in the room in the first place, if I knew that the maid might be evil. OK, you might say that the hotel rooms are always risky. Do you consider your own home safe then? If so, change the “evil maid” to an “evil housebreaker”, rinse and repeat. The whole point is being unable to verify if the environment is safe and being protected “just in case”.

The only assumption I think we are allowed to make is that our environment and equipment are safe when we set up all the security precautions — installing Heads, setting up LUKS secrets and so on. Should we be wrong in that one, everything falls apart.

So, about the Unlock Key and Recovery Key — I think we can “safely” assume that when we set up the Disk Recovery Key, we can fully rely on it being unknown. But after going into an untrusted environment, even for a little while? Not so much. So changing it every day would be pointless for me. You set up your key — it's safe. You go to a hotel, possibly abroad, and leave your laptop there — it's not safe. You go back to your own home that is provably secure — it's still not safe, because when you go to a hotel next time, I can harvest the effects of whatever I put inside your laptop. At least that's how I understand evil maid attack. If you see it differently, please describe your point of view, because I think it would be worth discussing as well.

[…] remember that bathroom cameras are kinda restricted everywhere in the world […]

Don't be offended — I am really grateful for taking your time to put some thought in my doubts — but I laughed at that one. If you rely on attacker obeying rules about bathroom cameras, you might as well think that even touching your laptop would be out of question for him. :-)

If paranoid, I would just get off the SSD drive and carry it separately from my laptop.

That would work only of your attacker must ensure that his actions are not to be seen. Otherwise, wouldn't he just sniff your password and then steal your drive? We already know he is very much informed on your whereabouts. But I may be mixing different threat models again — again, let me know.

Hoping I didn't bore you to death.

@GittCatt Well it seems we have misunderstood each other on which one was the user and which one was the attacker in the precedent example. Else you would not have found it funny ( at least I think! :P )

We have to separate some key concepts and Heads threat modeling :

The Disk Recovery Key passphrase is not the Disk Recovery Key.
The Disk Recovery Key passphrase unlocks LUKS container directly.
You can change a Disk Recovery Key passphrase, while you won't change the encrypted content (Key) unless you cryptsetup-reencrypt the content blindly and then change the LUKS passphrase of a specific slot.
This is why the Disk Recovery Key passphrase needs to be protected and typed the less possible in unsafe space.

When you add a second LUKS unlock key, you add it by entering an actually existing LUKS passphrase/key which permits to create another one that will also unlock the LUKS container.

In the case of slot 0 key defined at OS installation, your passhphrase unlocks the key (Disk Recovery Key passphrase). When using heads to seal a Disk Unlock Key inside of a TPM nvmram space with a passphrase combined with TPM measurements of firmware components including your GPG public key, you set it up by unlocking the LUKS container with your Disk Recovery Key, then you set up a new passphrase to unseal the TPM nvram space (not the LUKS container itself) conditionally of the LUKS header matching with PCRs measurements.

This permits the Disk Unlock Key passphrase to unseal the Disk Unlock key sealed inside of the TPM if LUKS header if BIOS region is intact, which means that this passphrase can only be typed on that computer, mitigating an evil maid to be able to clone your hard drive and decrypt it at leisure later on, while still not mitigating the possibility of your whole computer to be stolen and content decrypted with eavesdropped key presses.

On that later threat model mitigation, it means that a Disk Unlock Key changed/typed by the owner at the bathroom prior of going public, or under the cover prior of going in the hotel lobby in the morning would be compromised if:

That Disk Unlock Key passphrase was eavesdropped (you typed it in public eavesdropped space. Threat model mitigation implies you might want to boot the laptop in safe place and only resume from suspend when roaming since you want to protect the data more then the laptop here.)
Your computer was not with you all the time after having had your Disk Unlock Key passphrase eavesdropped. You might want to improve opsec and have a proper carry on bag.
That your computer used in unsafe space did not have the battery removed when connected on AC to have your data safe from a thief unplugging it and run away. If nobody saw you type the Disk Unlock Key passphrase, the automatic shutoff would clear memory and remove risk of ram cold attack to extract Disk Unlock Key in memory
You were roaming and your Hard drive was stolen at the same time as your laptop and your Disk Unlock Key was eavesdropped.
Your Disk Unlock Key passphrase was eavesdropped and your laptop was stolen in the same day. This is where a second factor would be helpful, with its own subset of limitations.

I'm mixing concepts here to make clear what would be your threat model here.

Adding a second factor implies you would type a PIN to release a secret from the USB Security dongle instead of the TPM (Replacing the release of the key from something inside f the computer to outside of the computer.)

That would imply that if someone eavesdropping that USB Security dongle passphrase could steal your USB Security dongle and laptop and be able to still unlock your laptop, while being able to do maybe more damaging actions from operations offloaded to that USB Security dongle if stolen. That may include being able to boot your laptop by unlocking LUKS encrypted content, but also decrypt your emails, sign content (identity theft) or sign /boot changes.

For the path of having TPM seal/unseal secrets with eavesdropping protection, I have no idea how to push this further. One idea that plays in my mind for a while now is to not show the TTPMTOTP on screen if USB Security dongle remote attestation is in and instead ask the user to type the OTP code to be able to boot the laptop. But here again, we translate the trust into something you have (Your phone) which if unlocked and passphrase eavesdropped would have its own subset of consequences which might be worse (content of phone + laptop).

My personal approach on this is a second LUKS encrypted disk (msata) under the keyboard, where AppVMs content I do not need to have is backuped with wyng-backups. That way, someone seeing me typing my Disk Unlock Key passphrase and stealing my laptop would only be able to access QubesOS deployed AppVMs and their secrets in case of physical access (backpack is still the best prevention). I do not fear an Evil maid being able to clone the content of my laptop when at rest since my threat model doesn't imply someone I trust (but not so much) stealing my laptop on my day to day tasks, while someone I tsut could not be so trustworthy and would want to clone my drive and type eavesdropped passphrase later on. I change my Disk Unlock Key passphrase often enough depending on what the day in front of me implies when I plan to roam and I prepare myself accordingly.

Hope it covers the actual possibilities, limitiations, threat models covered/uncovered and risks of each mitigations.

@GittCatt Waiting for your thoughts feedback.

linuxboot / heads

Unlocking disk with keyfile from USB as second factor #790