LUKS dictionary attack protection

[DemiMarie]

How to file a helpful issue

The problem you're addressing (if any)

Qubes OS does not support dictionary attack protection for the LUKS passphrase. An attacker with physical access to a Qubes OS system has unlimited attempts to brute force the passphrase.

The solution you'd like

LUKS keys should be protected by tamper-resistent hardware when possible. A discrete TPM can do this, as can a FIDO2 token. Decrypting the drive will require authenticating to the hardware, which will only allow a small number of attempts.

The value to a user, and who that user might be

Users who use lower-entropy passphrases will have protection from brute-force attacks.

Completion criteria checklist

(This section is for developer use only. Please do not modify it.)

[adrelanos]

I hope this would stay optional. While I see the appeal, this can easily introduce new security issues.

For now, we have had "perfect full disk encryption" for years, if not decades. Use a secure cipher (AES-256) (or a cascade like Serpent-Twofish-AES) with a strong password, and you have solid security. There's no need for a TPM. Open Source + LUKS + cryptography + secure passwords are all that’s needed, providing high stability and beautiful simplicity. Involving a proprietary TPM is not strictly necessary.

TPMs are the new, shiny, cool technology. However, TPMs are proprietary and can introduce new security issues.

To justify using a TPM, the threat model must be clearly defined. The implied threat model here might be that users often rely on weak passwords, which are vulnerable to dictionary attacks. That’s a fair point. The suggested use case is to use the TPM to Strengthen Weak Passwords. However, addressing this issue should not come at the expense of users who employ strong passwords. That's why I hope such a feature remains optional.

(It's not the TPM Transparent Encryption use case.)

I have been researching how this could be implemented. The only current solution I found is systemd-cryptsetup. In this case, the key would be stored in the TPM. Hopefully, it remains there and isn't exposed by a future security vulnerability. The key could be protected by a PIN. However, it's not as if "half" the key is stored in the TPM and the other half is provided by the user. A PIN implies limited length, but I could not find the maximum length. If a TPM were compromised and the key extracted, the user PIN would no longer matter. A better approach might involve splitting the key between the TPM and the user password, ensuring that a TPM key extraction vulnerability doesn't fully compromise encryption.

What's suggested here isn’t just about adding brute-force protection. It’s about moving the key from the user's memory to hardware (TPM). Both approaches have their own advantages and disadvantages, and it's crucial for the user to understand the trade-offs involved.

Security isn't the only factor to consider. Usability and data safety are also critical for such an implementation.

What happens if the TPM breaks? There needs to be at least one, ideally two, backup TPMs or another restoration method, such as a strong recovery key that the user must write down and store securely.

If we mandate TPM usage for encryption, will the Qubes Backup tool also integrate TPMs?

There is a Complexity Risk to consider, along with Implementation Issues.

[marmarek]

While I don't fully agree with this quite negative view of the TPM value, I do agree this feature (if implemented at all!) should not be mandatory. There are no plans of implementing it right now, it's just an idea for the backlog, if we ever ran out of other ideas.

What is a better use of TPM is AEM in a multi-factor mode, which doesn't only use TPM as a password brute-force protection, but also protect against a bunch of active attacks like tampering with boot files. It uses a LUKS key which is encrypted with a user-provided password and sealed with TPM. This means, only unmodified system has a chance to try to brute-force the user password to get the actual LUKS key, which significantly slows things down too. And to get to that point, attacker needs to not only steal your computer (not just the disk content, due to TPM), but also your AEM stick. And if you really want to get also brute-force protection from TPM itself, you can add TPM SRK on top of that (but that isn't recommended setup). The downside of this is that AEM has significantly stricter hardware requirements (not only TPM, but also DRTM support).

[DemiMarie]

I agree that measured boot is a much better use of the TPM, and I agree that strong passphrases are much better than weak ones. However, I suspect that most people will not use cryptographically strong passphrases, even though they should, simply because the UX of doing so is very bad. If this is accurate (which is a question for @marmarta), then the TPM is needed to make LUKS secure against high-level attackers.