Potential Attest.record changes

[lzrd]

Background

With #1946, the swd task will record a measurement of the active SP flash bank whenever the SP_RESET pin is asserted.

If the RoT swd task is not finished initializing, making it ready to detect SP_RESET, then there will be no measurement recorded until the next time the SP is reset and the RoT is ready.

If the control plane wants an initial or fresher measurement, it can request that the SP reset itself.
This scheme prevents interrupting the SP at some critical time that the RoT would not be aware of.
The control plane, or an individual host, may reboot itself if it needs to be measured by the SP.
In the future, we may choose to carefully sequence RoT and SP power-on boot to avoid this dance but that still leaves the case where RoT firmware has been updated with the SP necessarily still running to help orchestrate the RoT update.

The issue

Given that:

• the RoT and SP can normally be up and running for some time without any entries in the attestation log,
• there is support for the SP to also send measurements to the attestation log,
• the log currently does not identify the source of a measurement

it is important to prevent a buggy or malicious SP image from recording a known good measurement that would imply that the SP was running a trustworthy image. A malicious SP image can boot, query the attestation log, reset the RoT if there is an entry, then record a fake entry into the first slot and proceed, a wolf in sheep's clothing.

Implementation options

To that end we have a few choices (and please add any alternatives that you think of)
0. keep existing implementation

1. tag attestation log entries with their source
2. assign slots to sources
3. prevent any source but the swd task from recording the first measurement

No change

We can delay making changes but I don't see how to avoid changing log semantics to secure the system.

Tagged Entries

In choice one, the attest task labels entries with their source. We have not determined all the measurements that will ever go into the log. There may be motivation for a source-supplied tag as well.

Slot Indices Are Assigned

Number two changes log semantics from being append style to being an array of Option<Measurement>. This choice incurs the burden of managing slot assignments which we may want to change over time.

Assign first slot

Number three is a form of slot assignment and says that the SP is not permitted to make measurements unless it itself has been measured. The record function would check the log size and refuse all but the swd task if the log was empty. (The allowed task list is configurable in app.toml.)

How to limit attestation slot usage

It is highly desirable, even required, to have a trustworthy measurement of every bit of mutable state that affects the behavior of the system at power-on boot or reset at least up to the point of executing applications in the host OS. It is not necessary or even practical for all but of the few early measurements to be recorded with a RoT. That said, there may still be enough to complicate the management of the RoT's attestation log.

The number of attestation log entries ever used can be limited by having SP and higher layers, if any, only record a hash of their set of measurements. Then the attestation log does not need to manage a complex namespace. Each layer would need to be able to produce the measurement set when queried. The measurements are presumed to have been taken at a time when the reporting system can be trusted and has been measured by its predecessor in the chain of trust.

Recommendations

Tentatively: Only the swd task should be allowed to record the first attestation log entry. If any other source attempts to record the first entry, it will be rejected.

However, the problem needs to be discussed to make sure we are properly covering our use cases and security concerns.

[labbott]

"A malicious SP image can boot, query the attestation log, reset the RoT if there is an entry, then record a fake entry into the first slot and proceed, a wolf in sheep's clothing." Does the RoT not try to remeasure on its own power up? This seems like it would also be relying on a race window to try and record something before the attest task managed to measure?

[labbott]

More generally, should we be preventing any sprot commands at all until measurement is complete?

[lzrd]

We don't yet have the RoT measuring the SP on RoT boot. We may find that is safe, but to make a proper measurement, the SP needs to be reset. We need to know that it is safe to reset the SP at arbitrary times before having the RoT measure the SP on its own boot.

[labbott]

We don't yet have the RoT measuring the SP on RoT boot. We may find that is safe, but to make a proper measurement, the SP needs to be reset. We need to know that it is safe to reset the SP at arbitrary times before having the RoT measure the SP on its own boot.

If this is our eventual goal we should be threat modeling from that perspective. I'm not convinced its useful to talk about a malicious SP in conjunction with a known incomplete measurement implementation. If we require outside events for the security of the system to function properly that seems to imply that those outside events become part of our TCB.

We could also add a dedicated API that's only callable from the RoT and then combine that with the rest of the measurement log. We may not know all the measurements we're going to want but if we're going to be implicitly stating that the first log entry is for the SP we could require it at the API level and then reject all outside measurement calls until log.len() > 1

[lzrd]

That's the 3rd option and the one I think is appropriate right now. It doesn't preclude later changes and makes minimal changes to the existing API.