[okennedy]

It's been a while since I looked at the technology, but the basic premise is very simple. The TPM basically keeps around a stack of hashes. The BIOS pushes a hash of the bootloader onto the stack. The bootloader pushes a hash of the kernel onto the stack. Then there's a handful of ring 0 cpu instructions for pushing and popping all but the bottom-most entries of the stack that allow the kernel to do whatever it wants, including pushing hashes of application code, hashes of passwords (as in your example), or opening up a similar ability to push/pop upper levels of the stack to the application.

The only check the TPM does when deciding whether to allow the key in one of its registers to be used is whether the stack is in a particular configuration. The TPM doesn't (and in fact can't) directly require passwords (since it has no direct line of communication to the user). However, the BIOS, bootloader, kernel, etc... can all be configured to mix user-provided information like a password into the hash they push into the TPM.

[als0]

TPM keys are protected by policies. A policy can be based on the system state (hashes), a password, or both. There are also complex policies using the Extended Authorization feature. If you don't care about platform state or configuration, then you can just set a key policy with just a password. The TPM will lock you out if you make too many incorrect guesses.

You can in fact put passwords on most TPM internal objects. See this example https://github.com/tpm2-software/tpm2-tools/blob/master/man/...