3 ms·

"Doesn't have to be your password ... [just a] correct password" So not my password, then who's password? Why not TPM PIN?

by p_ing 2y ago

wat10000 2y ago
Sorry 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 ago
    Of 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.
    - p_ing 2y ago
      Your methods continue to open more methods of attack than TPM + PIN.
      - wat10000 2y ago
        How? With my proposal, if an attacker can obtain your password then they can get in, otherwise they can’t. With TPM + PIN it’s the same, just with your PIN instead.

"Doesn't have to be your password ... [just a] correct password" So not my password, then who's password? Why not TPM PIN?

by 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 ago

Sorry 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 ago
  Of 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.
  - p_ing 2y ago
    Your methods continue to open more methods of attack than TPM + PIN.
    - wat10000 2y ago
      How? With my proposal, if an attacker can obtain your password then they can get in, otherwise they can’t. With TPM + PIN it’s the same, just with your PIN instead.