Is it safe to use a backstop metadata version when initializing trust?

[erickt]

While TUF protects against a malicious server tricking a client into rolling back metadata (especially if we can land #106), it doesn't have any protections against an attacker who has local control of the storage device that stores the trusted metadata. In that situation, the attacker could simply replace the trusted metadata with some older version that points at some compromised packages.

On Fuchsia, we support verified boot (see android's documentation for a nice description of it). In short, we establish a chain of trust from a hardware key, which has signed the bootloader, which has signed the kernel, which has signed our critical userspace services. We would like to use this functionality to establish a metadata version backstop to make sure that even if an attacker can modify the local storage, they could only rollback metadata as far back as the backstop version protected by verified boot. If we update this backstop with a high frequency, we can pretty much eliminate the risk of a local rollback attack.

We can think of two approaches for implementing this backstop. First, we can include the backstop metadata in the signed user space image. We would initialize our trust by first loading all the metadata from the immutable signed image, then load the metadata from the mutable storage, then finally load any metadata from the remote repository.

The other idea, but which isn't covered by the spec, we could just bake in the backstop version numbers into the signed user space image. This lets us skip having to actually bake in the metadata in our signed image, which could be useful on a space constrained device. When configured for a backstop, our update flow would be:

• In step 5.2.2 when updating the timestamp metadata, if we don't already have a trusted timestamp file, check if the new timestamp's version number is greater than or equal to the backstop timestamp version.
• In step 5.3.2 when updating the snapshot metadata, if we don't already have a trusted shapshot file, check if the new snapshot's version number is greater than or equal to the backstop snapshot version.
• In step 5.1.9, if the timestamp and / or snapshot keys are rotated, delete the backstop timestamp and metadata backstop versions.

Would this be safe to do? If so, I'd be happy to update the spec (or write a TAP) to reflect this change.

[mnm678]

This sounds like a great idea! If I understand correctly it could also improve security for first time downloaders who do not yet have trusted metadata.

That being said, we should be careful with the wording in any spec change to avoid requiring any specific configuration of clients.

[lukpueh]

This does sound TAP-worthy to me. But I think it could be a very short TAP. :)

[joshuagl]

I really like this idea. It reminds me of @trishankatdatadog's suggestion to include a copy of the root metadata, or at least its hash, in the code.

This approach would be even better in a file that is attested by trusted boot. I'd love to see a TAP for this.

[jku]

This idea is close, but not the same, as the one we've been talking about with regards to pip:

• Pip install will contain an initial copy of the metadata and on first run that initial metadata will be copied into the runtime metadata location
• There may be multiple copies of pip with multiple versions of "initial" metadata. In some cases the initial metadata location can be considered more secure than the runtime location (/usr/lib/ vs ~/)
• The issue is: if runtime metadata location is already populated, how can pip get the benefits of using the already populated runtime metadata while also making sure that runtime metadata matches the initial metadata?

theupdateframework/python-tuf#1168