3 ms·
It doesn’t have to literally be your password. It could be some one-time proof that the user entered the correct password. This isn’t a replacement for a TPM,
by wat10000 2y ago
It doesn’t have to literally be your password. It could be some one-time proof that the user entered the correct password.
This isn’t a replacement for a TPM, it’s a way to use a TPM in a sensible manner. You have the TPM do the password -> key derivation, which lets you prevent brute force attacks (at least without a TPM vulnerability or physical chip-level attack). I imagine the TPM could also be used to securely tell the OS who did the initial login so it doesn’t have to prompt a second time.
Having a separate PIN means something else to forget and people will tend to choose the easiest option. We’ve barely managed to convince people to put up with having a password at all. If it’s a choice between password or password+PIN, people are going to pick the former. That option should be secure, and it’s not that hard to design a system where it’s more secure than having a separate short PIN.
- p_ing 2y ago> It doesn’t have to literally be your password. It could be some one-time proof that the user entered the correct password. But that means the user is using a different password... so you may as well use a TPM PIN.
- wat10000 2y agoWhat do you mean? A different password from what?
- p_ing 2y ago"Doesn't have to be your password ... [just a] correct password" So not my password, then who's password? Why not TPM PIN?
- wat10000 2y agoSorry to be unclear. Read that as “it doesn’t have to be your password.” As in, the fact that you’ve entered the correct password can be communicated to the OS without actually sending it your password. You can do it more securely than just setting a flag if that’s a concern, although the fact that the disk is readable at all is solid proof that some user’s password was entered correctly, so you don’t have to defend against too much.
- p_ing 2y ago> As in, the fact that you’ve entered the correct password can be communicated to the OS without actually sending it your password Can't communicate with the OS -- the disk is locked. > You can do it more securely than just setting a flag if that’s a concern Now we just wait for a vulnerability in this mini-app stored in unencrypted storage to be able to set some flag and wallah, we bypass the user's password at the OS level.
- wat10000 2y agoOf course you can communicate with the OS. The disk is unlocked at this point, not that you’d want to use persistent storage for this. You’d put the info in RAM. Doing this in a secure fashion doesn’t seem very hard. For example, hash the password in the same way the OS does. Hash that hash with some salt. Put it in memory at some agreed location. The OS can retrieve it, verify the hash and proceed if it matches. And of course erase the message. If you’re worried about replay attacks from someone who can capture the message between login and the OS verifying it, you can add the current time to the hash. If you don’t trust the clock, I’m sure the TPM can produce an ephemeral nonce for both sides to use, or the OS could store a hash of each message after verifying it, and reject any reused message. You’ll never be safe from software vulnerabilities, but this reliably prevents an attacker from reading your disk from a cold boot without knowing or cracking your password.