> Well, you're comparing hashes to ones online, can't you put the password hash online? (sorry, I am very ignorant of the situation here and am asking stupid simple questions)
If the system is compromised then it can just report the expected password hash. You can't trust a compromised machine to tell the truth.
> I mean, surely the same problem exists for any data stored on the device (keys, hashes, whatever)? If there's a way of storing a key chain securely on the device so it can't be modified by an attacker, can't a password be stored there instead?
Various bits of TPM functionality can be tied to requiring a password, but it's hard to actually turn that into something that's more freedom preserving while still preserving the verifiability. What you want is the ability to re-seal a secret to new values only as long as you have the password available, and I don't /think/ you can construct a system that does that with the features the spec gives you.
> Is that because the manufacturers don't give the option, or because technically there isn't a way of giving the option?
Unclear. There's little commercial incentive for people to come up with elegant solutions to this, and I can't immediately think of a model that would be significantly better than the status quo.
> If the system is compromised then it can just report the expected password hash. You can't trust a compromised machine to tell the truth.
I think the GP's point is that you assume the system can't tell the truth so you do the validation server side rather than client side. Sure, the system could send a different password hash, but as long as you don't publish the correct hashes it's not going to matter if the client sends alternative hashes since that validation happens server side and thus the client wouldn't know what hashes are valid.
If the system is compromised then it can just report the expected password hash. You can't trust a compromised machine to tell the truth.
> I mean, surely the same problem exists for any data stored on the device (keys, hashes, whatever)? If there's a way of storing a key chain securely on the device so it can't be modified by an attacker, can't a password be stored there instead?
Various bits of TPM functionality can be tied to requiring a password, but it's hard to actually turn that into something that's more freedom preserving while still preserving the verifiability. What you want is the ability to re-seal a secret to new values only as long as you have the password available, and I don't /think/ you can construct a system that does that with the features the spec gives you.
> Is that because the manufacturers don't give the option, or because technically there isn't a way of giving the option?
Unclear. There's little commercial incentive for people to come up with elegant solutions to this, and I can't immediately think of a model that would be significantly better than the status quo.