Re: [Suit] draft-ietf-suit-trust-domains: proposal of new command sequence

[Brendan Moran <[e-mail]>]

Hi Sylwester,

I think I understand what you're asking for. I'm not opposed to it, but I want to make sure that we're not adding extra complexity. Please tell me if I understand the scenario correctly.

1. The system is composed of multiple components in at least two trust domains.
2. At least one of the trust domains has secure memory that the other trust domains cannot access (a TEE).
3. The TEE has no network access and cannot download its own payloads. It also does not have a mechanism to stream data from the non-secure world.
4. The TEE has its own manifest processor with a component prefix as described in draft-ietf-suit-trust-domains, Section 6.4.1
5. The TEE manifest has at least *two* dependencies, each with at least one payload.
6. The TEE requires that payloads are staged in NON-secure memory (presumably encrypted).
7. The system does not have enough slots for a rollback in case of a broken install. ("update procedure crashes in the middle of ‘suit-install’ sequence executed on another dependency manifest, leaving the device in incoherent state.")
8. The expected workflow is:
8.a. The update client executes the Root Manifest's dependency resolution sequence, causing downloads of the the TEE's manifest and its dependency/dependencies.
8.b. The update client executes the Root Manifest's payload fetch sequences, causing downloads of all relevant payloads to staging areas.
8.c. When the update client's manifest processor encounters manifests matching the TEE's component prefix, these manifests are sent to the TEE's manifest processor
8.d. The nonsecure manifest processor verifies all payloads (Maybe not? It should have done this during payload-fetch.)
8.e. The TEE's update manifest processor verifies all the payloads that are staged in the non-secure memory
8.f. The Update Client executes the Root Manifest's install step. When the manifest processor encounters manifests matching the TEE's component prefix, these are sent to the TEE manifest processor, which installs them into secure memory
8.g. When the sequence is done, the system reboots, verifying each component to ensure correctness before moving on to loading and invocation.

Please can you let me know if I don't have this scenario defined correctly? If I do have it correct, then I have a few questions:

In view of point 7, how will devices implement the robustness requirements defined in Section 4 of RFC 9019?
> Devices must not fail when a disruption, such as a power failure or network interruption, occurs during the update process.

In view of point 6, How will devices mitigate the TOCTOU vulnerability that exists between 8.e and 8.f? There are many potential TOCTOU vulnerabilities in the manifest processor (one is defined in RFC9124, Section 4.2.18) but they are, largely, mitigated by secure boot and the requirement to hold manifests immutable (RFC 9124, section 4.3.21). There is also an assumption that there is some form of protection (e.g. MPU) that can be applied to mitigate some of these concerns--it's generally not great if executable code is modifiable after a digest check. This, however, is different. When the digest check is done by the TEE, the code is still sitting in the non-secure world. The TEE then returns control to the non-secure world. At that point, anything can happen.

So how do we mitigate this? Well, there's a couple of options:
1. The staging areas that contain the TEE's staged images are assigned to the TEE and remapped into the secure world.
2. The TEE can have control of the MMU/MPU and enforce that the memory is not writable.

If the second option is used, then I could see it working. If point 5., above, is not true, then well-structured manifests (image check *before* process dependency, copy *after* process dependency) should be adequate to prevent an incorrect system state.

The original idea behind multiple manifest processors was that they would each fetch their own payloads and be responsible for their correctness at the end of payload-fetch, in which case there is no need for a pre-install-validate.

If it is mandatory that one manifest processor downloads an image to a staging area and a *different* manifest processor validates it in-situ and installs it, and that the second manifest processor has a manifest with multiple dependencies that have payloads, then I can see how we could need pre-install-validate. Is this your use case?

Best Regards,
Brendan


From: Suit <[e-mail]> on behalf of Kończyk, Sylwester <sylwester.konczyk=[e-mail]>
Date: Wednesday, 20 December 2023 at 07:45
To: [e-mail] <[e-mail]>
Subject: [Suit] draft-ietf-suit-trust-domains: proposal of new command sequence
Hi,

I would like to discuss extension of suit-trust-domains, by adding optional ‘pre-install-validate’ command sequence.

$$SUIT_severable-members-extensions //= (suit- pre-install-validate’ => bstr .cbor SUIT_Command_Sequence)

$$severable-manifest-members-choice-extensions //= ( ? suit- pre-install-validate => bstr .cbor SUIT_Command_Sequence / SUIT_Digest)

Aim of that sequence, executed right before ‘suit-install’ sequence, would be to assess that all payloads required for installation are in place. This is especially important in context of suit-trust-domains, where an update may be organized as Root Manifest and several Dependency Manifests. Lack of ‘pre-install-validate’ may lead to situation where components managed by one of dependency manifests are updated, but update procedure crashes in the middle of ‘suit-install’ sequence executed on another dependency manifest, leaving the device in incoherent state.

Already defined command sequences (suit-validate and suit-payload-fetch, suit-install) cannot help here:

suit-validate – its purpose is not to evaluate coherency of payloads in envelope or 'staging' components, but rather to evaluate the state of components involved in invocation sequences.

suit-payload-fetch – here explanation is more complex. Let’s assume system composed of several security domains, where one domain is responsible for fetching payloads (effectively executing suit-dependency-resolution and suit-payload-fetch) and another (second) domain is responsible for installation (executing suit-install sequence). Let’s also assume that first domain cannot be trusted by the second domain. In that case the second domain require some methods (like ‘pre-install-validate’) to validate completeness of candidate payloads before it starts an update.

suit-install – placing checks at the begin of suit install sequence would not work on systems organized as Root and several Dependency Manifests – in such case validation instructions would be mixed with installation (validation dependency1, installation dependency1, validation dependency2, installation dependency2 and so on)

Summarising, it's not impossible to solve the stated problems by other means, but this solution is in my opinion simple, effective, and hardly increases the complexity of the spec.

Invocation procedure is expressed by three command sequences, addressing separated concerns (suit-verify, suit-load, suit-invoke). Having similar clarity (and separation of concerns) in update procedure would be even more desired.



With Regards,

Sylwester

_______________________________________________
Suit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/suit
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.