Rollback protection

[fergus-dall]

(This is largely a response to part of this blog post)

Specifically, if disk encryption is bound to an OS vendor (via UKIs that include expected PCR values, signed by the vendor’s public key) there must be a mechanism to lock out old versions of the OS or UKI from accessing TPM based secrets once it is determined that the old version is vulnerable.

To implement this we propose making use of one of the “counters” TPM 2.0 devices provide: integer registers that are persistent in the TPM and can only be increased on request of the OS, but never be decreased. When sealing resources to the TPM, a policy may be declared to the TPM that restricts how the resources can later be unlocked: here we use one that requires that along with the expected PCR values (as discussed above) a counter integer range is provided to the TPM chip, along with a suitable signature covering both, matching the public key provided during sealing.

All this is true, but I think it misses an important subtlety about how TPM counters work. In the TPM2 spec, part 3 (Commands), section 31.2 (NV Counters) we have

When an NV counter is created, the TPM shall initialize the 8-octet counter value with a number that is greater than any count value for any NV counter on the TPM since the time of TPM manufacture.

This seems to exist to prevent the counter from being rolled back using the owner authorization, which can delete and recreate NV indexes (oddly there seems to be no similar protection for the TPM_NT_BITS or TPM_NT_EXTEND types, which present similar issues for their most obvious uses). I haven't checked if this is actually implemented by TPMs as stated, but let's assume it is.

This means we can't assume that a new counter can be set to any specific value during setup, because other users of the TPM may have incremented another counter past that point. This holds for the lifetime of the TPM, so we can't assume this even if we've just cleared the TPM on a new install. This seems to kill any possibility of using counters in a uniform policy intended to apply across many devices. Frustratingly, there seem to be many similar situations that do work:

• If you're signing policies for a single machine you can check what unused counter values are available and sign an appropriate policy
• If you're an enterprise you can use remote attestation during boot, or sign distinct policies for each machine, to accommodate different counter states
• If you're the platform firmware, rather then the OS, you can use the platform authorization to set the TPMA_NV_POLICY_DELETE flag to keep an NV index from being deleted and then use the scheme I lay out below to implement a no-rollback policy
• If you control the owner hierarchy (rather then having to play nice with other users) you can disable the owner authorization and set the owner policy s.t. it can't be used to delete some specific NV index and then do the same

But if you're an OS vendor who has to do stuff in the owner hierarchy, and leave it available for other usage, and want sign things per OS version rather then per install, and want to block rollbacks without clearing the TPM, you just seem to be stuck.

I haven't been able to find a scheme that gets around this issue entirely. If you use counters you get this issue, but if you use any other kind of NV index the owner authorization can be used to clear it and then whatever was used to update it originally can be replayed. Probably the best option available is to accept that the owner authorization can be used to authorize rollbacks and treat it like the disk encryption recovery key i.e. require it to be set to a high entropy value during setup (or a low entropy value with dictionary attack prevention) and not be used in normal operation. This likely also requires storing the primary storage key persistently on the TPM so applications and the OS can use them without the owner authorization, and defining a standard for this so applications know how to use it (or referring to an existing one, if it exists).

In detail, it would look like this:

• During OS development
  • Whenever a new rollback barrier is desired, a new signing key for TPM secrets is generated
  • Each OS build has its PCR values signed with its key and all previous keys
• During setup
  • Owner authorization is requested by the OS installer, and set if it is not already set
  • Generate the primary storage key and store it persistently on the TPM
  • Allocate an NV index at a fixed location with
    • type TPM_NT_ORDINARY
    • length long enough to hold an authorization policy hash
    • attributes TPMA_NV_POLICYWRITE, TPMA_NV_WRITE_STCLEAR, TPMA_NV_AUTHREAD, TPMA_NV_NO_DA
    • an empty authValue (so anyone can read it, which is required to authorize against its contents)
    • authPolicy of PolicyOR(PolicyNvWritten(false), PolicyAuthorizeNV(this NV index, while not write locked))
      • This allows the index to be written once during setup, and otherwise whenever the policy hash in the contents of the NV index is matched
  • Write to the NV index the authorization policy hash for PolicySigned(signing key for TPM secrets for current OS version)
  • Seal secrets (e.g. disk encryption key, systemd credential root key) to PolicyAuthorizeNV(this NV index, write locked) under the persistently stored primary storage key
• During early boot (e.g. in the initrd):
  • Check the value of the NV index to figure out which signature to use
  • If it doesn't correspond to the latest key, authorize using a signature from the older key and write the new policy hash
  • Call NV_WriteLock on the NV index, authorized using the signature from latest key
    • This blocks regular applications with TPM access from changing the policy. The write lock is cleared on next boot.
  • Unseal secrets using the signature from latest key and the persistent primary storage key

If signatures for several different stages of boot with different PCRs are desired, multiple pairs of signing keys and NV indexes can be used (but it might be better to use a TPM_NT_BITS NV index with the attribute TPMA_NV_CLEAR_STCLEAR to reset it on reboot for the same purpose).

This means authorized OS versions can update the policy to lock out older versions and access secrets, non-authorized OSes can't gain access to secrets or change the policy, and regular applications running under authorized OSes can access secrets but can't change policy, but the owner authorization can override all of this, for better or for worse.

(Separately from most of this, it also seems like we could use an OS/Application API for TPM usage that keeps applications from stepping on each other or needing to know about broader OS policies)

[Foxboron]

cc @diabonas who might have some good insight here

[fergus-dall]

Actually, my overly complicated scheme doesn't work at all. NV indexes are referred to in auth policy hashes by the hash of their public area, and the public area includes their auth policy hash, so you can't use an NV index in its own auth policy.

Fortunately there's a much simpler approach: just use an TPM_NT_EXTEND index in place of a counter. These are basically persistent PCRs that start out with an all-zero value, so an OS vendor can define how they will extend it for each new version (e.g. writing a known version string) and check its value in the policies they sign. The primary drawback compared to a counter (aside from being rollbackable by the owner auth, and needing to manage that) is that it's pretty inconvenient to specify a range of values to allow for limited rollbacks, though you could use PolicyOR or just sign a policy for each value.

[behrmann]

How many of those TPM_NT_EXTEND indices are there? What I wondered about in the rollback protection section was that, considering that @diabonas told us that there are about three counters per TPM, so they're a shared resource, how this would fly with secondhand hardware. If distro A uses version range 100-120 and distro B uses version range 250-300 and the counters cannot be reset (which would make the rollback protection somewhat moot). I can't run distro A, if the previous owner ran distro B.

Maybe I'm wrong, I haven't yet wrapped my head around all the TPM stuff, so maybe my understanding is too simplistic.

[fergus-dall]

Depends on the platform. The "core" standard only requires enough NV space for one counter or bit-field (each 8 bytes long), which isn't enough for even 1 TPM_NT_EXTEND index (min length of 256/8 = 32 bytes), but the specifications for more complex platforms are supposed to mandate at least enough space for 16 counters[0], and the actual PC-Client specification mandates support for "at least 68 indices, with a total minimum data size of 3834 Bytes"[1], which should be plenty unless something else needs a lot of NV storage.

There's a somewhat better discussion of how NV counters work in part 1 of the spec[2], which I probably should have looked at first:

When an NV counter is created, it has no value and the TPMA_NV_WRITTEN attribute will be CLEAR.

On each TPM2_NV_Increment() the TPM checks the TPMA_NV_WRITTEN attribute of the Index. If it is CLEAR, then the TPM will initialize the 8-octet counter value such that the first increment will set a value that is greater than any value that a counter Index with the same Name has had over the lifetime of the TPM. The TPMA_NV_WRITTEN attribute will be SET.

NOTE 1 This check ensures that an Index cannot be deleted and another Index with the same Name defined with a lower value.
NOTE 2 The reference implementation implements this by tracking and using the largest count of any deleted NV Counter. An alternative implementation could track the largest count of any NV Counter, deleted or currently defined.

After checking TPMA_NV_WRITTEN and performing any required initialization operations, the TPM will increment the Counter.

NOTE 3 The TPM will need to maintain a largest-count value. It is not necessary to update this value except when a NV Index is deleted. If the NV Index being deleted has the largest value held by an NV Index, then this value would be copied to the largest-count value. The value of an NV Counter Index after the first increment is larger than the largest-count value.
NOTE 4 Since no counter can ever repeat a previous value ever contained in any NV Counter Index, a counter with a particular Name cannot be rolled back by deleting it and redefining it

(Notes are informative comments, the other text is normative)

It seems very definite that if you have an auth policy that requires a counter to be less than X, and the counter has reached X, that policy must never be satisfied ever again on that TPM, and accordingly there is no way to set the initial value of a counter. (In fact, there's no way to write the index initially without incrementing it!) It doesn't mandate any specific approach to this, but given the limited amount of NV space on a TPM I expect most implementations use a shared counter and would work like you say.

[0] https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf#%5B%7B%22num%22%3A1134%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C69%2C272%2C0%5D
[1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p05p_r14_pub.pdf#%5B%7B%22num%22%3A70%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C33%2C95%2C0%5D
[2] https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf#%5B%7B%22num%22%3A1062%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C69%2C268%2C0%5D

[aplanas]

Can a rollback protection strategy be expressed in terms of TPM2_ClockSet and TPM2_ClockRead? In that sense we can have something that can be like a shared counter between different TPMs

[fergus-dall]

The core feature of the TPM clock AIUI is that it ticks forward as long as the TPM is powered, so this would be not so much a rollback prevention strategy as a way to forcibly expire sufficiently old OS versions once enough time has passed. You could force an expiration early by setting the clock forward, but that seems liable to break multi-boot scenarios and just feels like a misuse of the feature.