documented default PCRs don't match actual default PCRs

[EvilBit]

actual default PCRs: 0,2,4 here

documented default PCRs: 0,2,4,6 here and here
In other places, the actual 0,2,4 is documented.

Which ones should it be?

[diabonas]

Good point! I don't think we want PCR 6 because this register measures every suspend to disk event (and fails to calculate the TOTP afterwards accordingly), which I don't think is useful. 0,2,4 (or 0,2,7, if you're using Secure Boot) seems like a good choice.

[EvilBit]

Not sure, but I believe one could argue, that PCR 6 is indeed very essential to protect against evil maid attacks - after all, during S3 / suspend-to-RAM, an evil maid could maliciously manipulate RAM contents to exfiltrate data after resume (they could go as far as disabling any S3 state indicators via ACPI, such as pulsing standby LEDs on certain hardware, and fake a normal boot process on resume from S3 - they control the entry point after all) - so as long as we don't have encrypted and authenticated RAM, a transition to S3 and back should IMHO be considered unsafe. And never actively using S3 as a user doesn't help here, as an attacker could just boot or reset the hardware themselves, enter S3 and manipulate RAM - they could even just swap in RAM prepared on another PC.

tpm2-totp could protect from these kinds of advanced attacks if it seals against all power state changes as measured in PCR 6.

S4 / suspend-to-disk may be marginally better if one has an encrypted and authenticated resume image / swap, but still potentially problematic. (But not sure, if S4 resume is identical to normal boot with respect to TPM measurements - I hope so.)

[diabonas]

Not sure, but I believe one could argue, that PCR 6 is indeed very essential to protect against evil maid attacks - after all, during S3 / suspend-to-RAM, an evil maid could maliciously manipulate RAM contents to exfiltrate data after resume (they could go as far as disabling any S3 state indicators via ACPI, such as pulsing standby LEDs on certain hardware, and fake a normal boot process on resume from S3 - they control the entry point after all) - so as long as we don't have encrypted and authenticated RAM, a transition to S3 and back should IMHO be considered unsafe. And never actively using S3 as a user doesn't help here, as an attacker could just boot or reset the hardware themselves, enter S3 and manipulate RAM - they could even just swap in RAM prepared on another PC.

I'd argue that if an attacker is able to physically manipulate the hardware (as opposed to "just" having physical access without tampering with it), the security that tpm2-totp (and the TPM measured boot as a whole) provides goes out of the window anyway: after all, an attacker could simply talk to the TPM directly outside of the control of the operating system and provide the correct PCR measurements (to e.g. precalculate a large number of TOTPs).

Anyway, if I understand the TCG PC Client Specific Implementation Specification correctly, suspend-to-ram isn't covered by PCR 6 anyway:

Entities that MUST NOT be measured by the BIOS:

1. Resuming from S1 through S3.

YMMV of course, that's why the PCR selection is configurable, but I don't think having PCR 6 as a default for all users is hugely beneficial, the main problem being that it is very confusing when the TOTP doesn't work any more after a suspend-to-disk for no apparent reason.

S4 / suspend-to-disk may be marginally better if one has an encrypted and authenticated resume image / swap, but still potentially problematic. (But not sure, if S4 resume is identical to normal boot with respect to TPM measurements - I hope so.)

I must admit I haven't checked whether an S4 event is actually measured into PCR 6: on Linux, hibernation is basically a full shutdown, and when you turn the device back on, the RAM image is loaded from swap after a normal boot process. I'm not sure whether the operating system communicates to the firmware that this is a S4 instead of a "normal" shutdown.

[EvilBit]

I'd argue that if an attacker is able to physically manipulate the hardware (as opposed to "just" having physical access without tampering with it), the security that tpm2-totp (and the TPM measured boot as a whole) provides goes out of the window anyway:

Hmm, I'd say all threat models that tpm2-totp is supposed to protect against currently, already fall into the category of 'tampering', e.g. reflashing the firmware/Option ROMs, manipulating the ESP, MBR, bootloader, kernel, etc. on disk. I'd say, there is really not much difference between writing to flash or disk on the one hand, and to RAM on the other. ;)
Note that the S3 attack doesn't presume any hardware implant - just temporary physical access for writing, just as for the established threat model. (One could even imagine writing to RAM in-situ (e.g. for soldered RAM), e.g. by pulling CPU reset low while still powering and accessing RAM via pogo pins on PCB pads. Not sure if actually feasible, but reasonable possibility.)

after all, an attacker could simply talk to the TPM directly outside of the control of the operating system and provide the correct PCR measurements (to e.g. precalculate a large number of TOTPs).

Yeah, I had already thought about that (the whole 'untrusted time' / pre-computation issue) and wanted to propose an additional feature anyways.
We could allow sealing the TOTP secret not only against the PCRs, but also against a small pre-shared secret, e.g. a short PIN.
That PIN would have to be entered before calculating the TOTP and e.g. measured into an additional application-level PCR.
Doing so would not undermine the "don't enter any secrets before the hardware attested it's integrity to you" maxim, as the PIN is only used for unsealing the TOTP and nothing else. Meaning, after an attestation failure, the PIN would have to be considered compromised (just as the system itself), but no important secrets would've been revealed.
Instead of a PIN, that secret could also be provided automatically via a smartcard, encrypted to the TPM's internal endorsement key, or similar.

Alternatively, one could allow passing an arbitrary, unique timestamp into the TOTP calculation, making it a true challenge-response type authentication. But that would complicate usage with off-the-shelf mobile or token authenticators.
FIDO2 might be an alternative (as they provide unique challenge-response IIRC), but that's somewhat orthogonal to TOTP.

The possibility of a relay attack (i.e. you are presented with a mockup, while the attacker is in possession of the actual hardware) is still open, but has to be considered out-of-scope for the time being and under the current threat model.

Anyway, if I understand the TCG PC Client Specific Implementation Specification correctly, suspend-to-ram isn't covered by PCR 6 anyway:

Entities that MUST NOT be measured by the BIOS:

1. Resuming from S1 through S3.

Hmm, will test that when I have time - man 1 systemd-cryptenroll mentions 'Power state events; changes on system suspend/sleep', but that info is of course not authoritative.

I must admit I haven't checked whether an S4 event is actually measured into PCR 6: on Linux, hibernation is basically a full shutdown, and when you turn the device back on, the RAM image is loaded from swap after a normal boot process. I'm not sure whether the operating system communicates to the firmware that this is a S4 instead of a "normal" shutdown.

Will try to verify as well.

YMMV of course, that's why the PCR selection is configurable, but I don't think having PCR 6 as a default for all users is hugely beneficial, the main problem being that it is very confusing when the TOTP doesn't work any more after a suspend-to-disk for no apparent reason.

Good point, though I'm not sure what's the better tradeoff - user confusion vs. invisible attack vectors :/

[diabonas]

Hmm, I'd say all threat models that tpm2-totp is supposed to protect against currently, already fall into the category of 'tampering', e.g. reflashing the firmware/Option ROMs, manipulating the ESP, MBR, bootloader, kernel, etc. on disk. I'd say, there is really not much difference between writing to flash or disk on the one hand, and to RAM on the other. ;)

The thing is, it's really hard to create a sensible threat model once hardware manipulation in any form is on the table: I don't think there's e.g. a real way to protect against a "buy a completely identical device to the one you want to attack, steal the original device and replace it with the copy, setup the copy to relay the screen of the original device to trick the user into unlocking it" scenario. Clearly that's a bit ridiculous, but it's really hard to know where to stop...

We could allow sealing the TOTP secret not only against the PCRs, but also against a small pre-shared secret, e.g. a short PIN.
That PIN would have to be entered before calculating the TOTP and e.g. measured into an additional application-level PCR.
Doing so would not undermine the "don't enter any secrets before the hardware attested it's integrity to you" maxim, as the PIN is only used for unsealing the TOTP and nothing else. Meaning, after an attestation failure, the PIN would have to be considered compromised (just as the system itself), but no important secrets would've been revealed.

Yeah, I think this would be a useful (optional) feature indeed! Shouldn't be too difficult to implement from the TPM perspective, though obtaining user input within the initramfs might be a bit of a pain.

Instead of a PIN, that secret could also be provided automatically via a smartcard, encrypted to the TPM's internal endorsement key, or similar.

FWIW, I think some Nitrokeys have something similar: IIUC, they do a challenge-response using HOTP where the Nitrokey checks the response and flashes its LED light accordingly. It's a bit different than what you propose because the HOTP input cannot be considered secret, but could be easily modified to use a randomly generated input as the challenge. This would also take care of replay attacks.

Hmm, will test that when I have time - man 1 systemd-cryptenroll mentions 'Power state events; changes on system suspend/sleep', but that info is of course not authoritative.

Will try to verify as well.

That would be awesome! Come to think of it, if PCR 6 only includes suspend to disk, I would be open to having it in the default PCR selection: not every system is guaranteed to have encrypted swap, and replacing the resume image is very easy, so maybe it's better after all to enable PCR 6 by default (and therefore fail attestation after hibernation), unless users actively want to disable it (because they have setup encrypted swap, or don't need the additional security guarantee).