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

["Kończyk, Sylwester" <[e-mail]>]

Hi Brendan,

Thank you for prompt response, let me add clarifications/comments referring directly to your message.


> 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?
This is exactly the case.


> 1. The system is composed of multiple components in at least two trust domains.
Correct.

> 2. At least one of the trust domains has secure memory that the other trust domains cannot access (a TEE).
Correct.

> 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.
TEE has no direct network access but regarding to streaming the data from non-secure world - it varies between end products. In scenario I particularly have in mind the TEE does not stream the data from non-secure world. So, let's assume - Correct.

> 4. The TEE has its own manifest processor with a component prefix as described in draft-ietf-suit-trust-domains, Section 6.4.1
There are some similarities and some differences to deployment described in draft-ietf-suit-trust-domains-05, Section 6.4.1. Indeed, there are two instances of suit processor, one executed in untrusted environment, and another one in TEE, but those processors are not active at the same time. Responsibility of non-TEE processor is to fetch missing dependencies/payloads to staging area, while responsibility of TEE processor is to install candidate update/boot the system.

> 5. The TEE manifest has at least *two* dependencies, each with at least one payload.
Correct, but I would rather rephrase, saying that the 'Root' 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).
Correct.

> 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.")
Correct.

> 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.
Correct.

> 8.b. The update client executes the Root Manifest's payload fetch sequences, causing downloads of all relevant payloads to staging areas.
Correct, but clarification is required here. payload-fetch sequence of the Root manifest is written in a way that it executes process-dependency on dependencies resolved on step 8a.  And those dependency manifests fetch missing payloads to stage area (NON-secure memory). Thanks to that mechanism the ''Non-secure' instance of suit processor is able to fetch missing payloads for all domains, including update candidate for TEE.

> 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
No. The update client executes the Root Manifest's payload fetch sequence, which in turn, may execute directive-process-dependency on ANY of dependencies.

> 8.d. The nonsecure manifest processor verifies all payloads (Maybe not? It should have done this during payload-fetch.)
Author of manifest controls that. I would say that payload-fetch sequence should be written in the way that both detached and integrated payloads are verified against corruption. And yes, payload-fetch sequences are executed in non-secure environment.

> 8.e. The TEE's update manifest processor verifies all the payloads that are staged in the non-secure memory
It shall be done like that, and that is the point. The only sequence at disposal is suit-install, executed in TEE on candidate Root manifest (and respective dependencies via directive-process-dependency).

> 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
No. Once system enters 8e, the Update Client is deactivated. One of reasons is that is to update the 'Executed in Place' Update Client. So steps 8.e and 8.f are performed in TEE.

> 8.g. When the sequence is done, the system reboots, verifying each component to ensure correctness before moving on to loading and invocation.
Correct. Performed by suit processor in TEE.


> 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.
System is designed to be idempotent. In event of power failure install-sequence from candidate Root manifest is executed from the begin.

> In view of point 6, How will devices mitigate the TOCTOU vulnerability that exists between 8.e and 8.f?
(...)
All concerns you have raised are valid (fortunately - addressed). One of security measures are indeed MPUs, making the staging area inaccessible by entities other than TEE during phases 8.e and 8.f, without any gap between 8.e and 8.f
So, candidate manifests and candidate payloads became 'Immutable' at the begin of 8.e.


With Regards,

Sylwester

From: Suit <[e-mail]> On Behalf Of Brendan Moran
Sent: Wednesday, December 20, 2023 4:14 PM
To: Kończyk, Sylwester <sylwester.konczyk=[e-mail]>; [e-mail]
Subject: Re: [Suit] draft-ietf-suit-trust-domains: proposal of new command sequence

You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

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]<mailto:[e-mail]>> on behalf of Kończyk, Sylwester <sylwester.konczyk=[e-mail]<mailto:sylwester.konczyk=[e-mail]>>
Date: Wednesday, 20 December 2023 at 07:45
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[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.