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

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

Hi Brendan,

To make sure I understand your examples - When you are mentioning "System Validation sequence" - are you referring to SUIT_Command_Sequence suit-validate? In case of "load sequence" mentioned in your last post - does it refer to SUIT_Command_Sequence suit-install?  As I understand, the trick would be to execute suit-validate twice, first time - prior to suit-install, second time, in invocation procedure, prior to suit-load.

Logical steps, applying "lazy installation" on examples from my post would look like:
1.            Staging procedure carried out by the APP.
                - suit-dependency-resolution
                - suit-payload-fetch

2.            Installation procedure carried out by the BL.
                - suit-validate
                - suit-install

3.            Invocation procedure carried out by the BL.
                - suit-validate
                - suit-load
                - suit-invoke


On the other hand, reflecting proposed suit-pre-install-validate, logical steps would look like:

1.            Staging procedure carried out by the APP.
                - suit-dependency-resolution
                - suit-payload-fetch

2.            Installation procedure carried out by the BL.
                - suit-pre-install-validate
                - suit-install

3.            Invocation procedure carried out by the BL.
                - suit-validate
                - suit-load
                - suit-invoke

Getting to conclusion - both solutions ("lazy installation" and introduction of suit-pre-install-validate) would work. The only question is what is simpler, or rather what kind of simplicity should be sacrificed:

  *   Having two dedicated validation sequences - in that case existing specification shall be extended.
  *   Adding extra logic to suit-validate and execute it twice - it will require a more complex content of suit-install.

Obviously, I would prefer to have dedicated suit-pre-install-validate at disposal. I see following benefits of such approach:

  *   Having clear separation of two concerns - validation prior to installation and validation prior to invocation. I would be glad to have similar clarity as it is already achieved for invocation procedure and three available command sequences.
  *   Simplified logic in appropriate sequences, causing that definition (creation) of manifest would be less error prone.
  *   suit-pre-install-validate could be severed after installation, therefore space reserved for installed manifest could be smaller.

I think there is not much more to add to this topic. Based on your and community judgement - existing specification can be extended or we can stay with what is already defined there. Both approaches would functionally work, non-functional aspects would differ.

Referring to your side note (device resilience in update scenarios) - I am glad to talk about it, but I would propose to move it to separated topic.

With Kind Regards,

Sylwester

From: Brendan Moran <[e-mail]>
Sent: Friday, January 12, 2024 3:08 PM
To: Kończyk, Sylwester <[e-mail]>; [e-mail]
Subject: Re: draft-ietf-suit-trust-domains: proposal of new command sequence

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 want to stress again that I'm not fundamentally opposed to adding a new procedure, but I want to be sure that we actually need it. It sounds to me like there's a simpler solution to all the examples that you've provided. The Image Loading sequence has use cases: first, images that need to be moved from NVRAM to RAM prior to execution. Second, lazy installation of images by the bootloader.

Lazy installation works like this:

The following commands are placed into the System Validation sequence:

- Try each
-- Sequence 0
--- Set Component Index (install target)
--- Check Image
-- Sequence 1
--- Set Component Index (install staging)
--- Check Image

In this way, the system validation succeeds if either the install target or install source is correct.

The following commands are placed into the load sequence:
- Set Component Index (install target)
- Try each
-- Sequence 0
--- Check Image
-- Sequence 1
--- Override Parameters directive for Staging Component
--- Copy Directive
--- Check Image

In the system validation step, there are several possible scenarios:

  1.  The staging component matches the known hash, but the install target does not => OK
  2.  The staging and install target components both match the known hash(es) => OK
  3.  The install target component matches the known hash, but the target does not => OK
  4.  Neither the install target nor the staging components match the known hash(es) => FAIL

This is because: in 1, the component is staged, but not installed yet. In 2, the component is staged and has been installed. In 3, the component has been installed, but a new image is now staged. In 4, there is a fault

In the image loading sequence, there are two possibilities:

  1.  The install component matches the known hash => nothing to do
  2.  The install component does not match the known hash => install the staging component

By using this approach, the bootloader does lazy installation of any app or radio firmware that doesn't match what's already installed. This performs the correct operations in the correct trust domain and does not require a new procedure. Is there a scenario where this is not adequate for your uses?


For Example 1, the lazy installation technique described above appears to satisfy your requirements.

Example 2 is an already-considered example use case for SUIT. The selection of the active image is described in normative language in section 6.1 of draft-ietf-suit-manifest-24: https://www.ietf.org/archive/id/draft-ietf-suit-manifest-24.html#name-manifest-processor-setup. The exact mechanism for marking the "latest valid, authentic manifest" is an implementation detail. Example 2 describes one method for marking the "latest valid, authentic manifest." This is achievable without a change to the specification. If you wish to use the manifest to perform this operation, that is doable using the lazy installation process described above.

As a side note, I am quite concerned about the prospect of bricking a device by failure to verify before install. This implies that there is a dependence on a full and complete image installation. This dependence on a full and complete image installation implies that a power cut, brownout, power hiccup, attacker-controlled-glitch, etc., could cause an invalid block to be written, thus bricking the device. It also raises questions about what happens when a buggy APP is installed. A rollback mechanism should be in place, otherwise, the device may be bricked. Do you have the appropriate mitigations in place to prevent this?

If there is, indeed, a rollback mechanism for resilience, then the trusted integrity check before install is irrelevant. The bootloader will roll back if necessary.

Example 3 is similarly covered by the lazy installation technique described above.

You have asked what the justification is for having 3 sequences in the invocation procedure. The answer is, as usual, coordination between manifests and their dependencies:

  *   All dependency manifests and all images must be present and correct before any image is loaded.
  *   All images that require loading must be loaded before any image is invoked.
So the three sequences enable the manifest processor to verify that all images are present and correct, load the images that require loading, and then invoke any images that require invocation.

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: Friday, 22 December 2023 at 11:14
To: Brendan Moran <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Suit] draft-ietf-suit-trust-domains: proposal of new command sequence
Hi Brendan,

I share your analysis about the need of distinguishing of three procedures (name it: staging, installation, invocation). First - let me try to justify why such distinction is beneficial, on examples. Those examples will base on real use cases.

Example 1:

Simple, memory constrained device, composed of TEE (holding the role of bootloader, name it as BL), and single, non-trusted environment (where regular Application, name it as APP, is executed). Let's also assume, for convenience of discussion, that names APP and BL mean both execution environment and name of the image holding the code executed in that environment.
APP must be executed in place (from NVM, i.e. Flash). NVM is composed of several partitions (slots): staging area (where candidate APP image shall be placed by the Update Client), partition to hold BL image, and partition to hold installed APP image. Functionality responsible for obtaining candidate APP (Update Client), must executed as part of the APP, mainly due to size of protocol stack involved in candidate download.
Let's focus on update scenario for the APP (let's move updateability of BL out of scope of this discussion, for clarity).

Would you agree that following flow correctly describes logical steps:

  1.  Staging procedure is carried out by the APP.

     *   APP downloads candidate APP to staging area.

  1.  Installation procedure is carried out by the BL.

     *   BL verifies candidate APP.
     *   BL copies candidate APP to 'installed APP' partition.

  1.  Invocation procedure (no doubt here) is carried out by the BL.

     *   BL verifies installed APP.
     *   BL invokes the installed APP.

Before going to next example, I would like to focus your attention on step 2a (verification of candidate before actual update start). That verification, for some products, is even more important than verification performed in step 3a. Avoiding verification of candidate image prior to installation increases probability of device bricking. Let me stress it - for discussed use case Candidate image must be verified prior to installation, and, unfortunately, draft-ietf-suit-manifest-24, section 4.2 omits that. Or, rather it addresses it in order useless for described case (let me paste part of the document for readers convenience):

The expected workflow for a Recipient installing an update can be broken down into five steps:

  1.  Verify the signature of the manifest.
  2.  Verify the applicability of the manifest.
  3.  Fetch payload(s).
  4.  Install payload(s).
  5.  Verify image(s)

Step 5 (from draft-ietf-suit-manifest-24, section 4.2) is pointless. If wrong image was installed at step 4 then it is already too late, at least for system as described in this particular example.

Moreover, even if APP candidate was already verified by Staging procedure, i.e. in hypothetical step 1b, BL cannot trust that and must repeat validation. (I can provide justification for that statement, if needed)



Example 2:

System similar to one described in Example 1, but there are two slots for the APP. Name it: APP_A and APP_B. And let's bring SUIT manifest to the picture. Staging area is still there, but its size is reduced, just to hold candidate manifest (an envelope, without integrated payloads).
Let's assume that initially the app is booted from APP_A, so APP_A is active.

Would you agree that following flow correctly describes logical steps:

  1.  Staging procedure is carried out by the APP (precisely - APP_A).

     *   APP_A downloads candidate manifest to staging area.
     *   APP_A verifies signature of the candidate manifest.
     *   APP_A verifies applicability of the candidate manifest.
     *   APP_A downloads APP_B image directly to APP_B slot (executing instructions encoded in candidate manifest)

  1.  Installation procedure is carried out by the BL.

     *   BL verifies signature of the candidate manifest.
     *   BL verifies applicability of the candidate manifest.
     *   BL verifies APP_B (executing instructions encoded in candidate manifest)
     *   BL overwrites currently installed manifest with candidate manifest (only if previous step is successful).

  1.  Invocation procedure is carried out by the BL.

     *   BL verifies signature of installed manifest.
     *   BL verifies applicability of installed manifest.
     *   BL selects (including verification) APP_A or APP_B, executing instructions encoded in installed manifest.

Why I claim that step 1d is part of staging procedure? Two reasons.  First - image is written to inactive slot, so nature of that slot is similar to staging area. Second - without the step 2d, the content of APP_B is just a bunch of unverifiable bytes. Candidate manifest is the entity which is able to recognize its digest as valid, and installation is concluded at 2d.

And similarly to previous example, I can provide justification why steps 2c and 2d shall be performed by the BL.

Example 3:

More complex, yet still memory - constrained system. BL, APP_A, APP_B, staging area, but additionally another non-trusted environment, this time for the Radio. Name it - RAD. And we have extra requirements - different signing authorities for APP_* and RAD, individual updateability of APP_* and RAD, the need of keeping compatibility between APP_* and RAD.
Making long story short - describing such system as hierarchy of three manifest (ROOT, APP, RAD where APP and RAD are dependencies of ROOT) looks, for me, as perfect fit. Comparing to previous examples - flow would be more complex, but conclusions would be the same:


  *   Staging procedure should be described in respective sequences from candidate manifests, executed by SUIT processor on the APP (or RAD, anyway just on one of those entities)
  *   Installation procedure should be described in respective sequences from candidate manifests, executed by SUIT processor on the BL.
  *   Invocation procedure should be described in respective sequences from installed manifests, executed by SUIT processor on the BL.

Conclusions (actually - my personal view, not facts):


  *   There are systems where staging steps (i.e. execution of suit-payload-fetch) shall be performed by the APP, the installation (i.e. execution of suit-install) shall be performed in context of BL. (I dare to state it applies to majority of devices supporting DFU). So, distinction between Staging and Installation is justified.
  *   Looking at draft-ietf-suit-manifest-24, section 4.2 and CDDL, Invocation Procedure is rich in representation (suit-validate, suit-load, suit-invoke), even if single sequence would be technically sufficient. I guess there is a reason for presence of those three sequences and I wonder what justifies that.
  *   Unfortunately, the Update Procedure (in existing form) is limited to just two sequences (suit-payload-fetch, suit-install), so logical steps like validation of candidate image and the installation have to be described in single sequence (i.e. suit-install). This would work for system described using single manifest but breaks for more complex systems.
  *   In real world, distinct Staging and Installation procedures exist (unless provided examples are invalid), they are just not explicitly reflected in draft-ietf-suit-manifest-24.



And getting to the point - Procedure I have proposed (suit-pre-install-validate) explicitly address existence of distinct Staging and Installation procedures. It barely increases the complexity of the spec/CDDL. I believe that if there would be an agreement to add it to SUIT spec, it should be added to draft-ietf-suit-manifest. The problem is that it's absence can be workarounded by placing validation commands at the begin of suit-install, so that is why it is difficult to justify its value in context of single manifest. I have mentioned it in context of suit-trust-domains, because workarounding in that environment is not that easy. As I have mentioned in my original message, there are other means to solve the stated problems, but solution I have proposed is, in my opinion simple, effective, and greatly simplifies implementation.




With Regards,

Sylwester


From: Suit <[e-mail]<mailto:[e-mail]>> On Behalf Of Brendan Moran
Sent: Thursday, December 21, 2023 12:22 PM
To: Kończyk, Sylwester <sylwester.konczyk=[e-mail]<mailto:sylwester.konczyk=[e-mail]>>; [e-mail]<mailto:[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,

It sounds like the application you describe is different from what is envisaged by suit-trust-domains, Section 6.4.1. The key discrepancy is that the application you have described does not make use of component prefixes for orchestrating coordinated updates across the TEE/nonsecure boundary.

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.

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

If the two manifest processors are not active at the same time, then the orchestration logic present in the manifest does not apply. It is specifically designed for both manifest processors to be active simultaneously, with one deferring to the other when the manifest prefix dictates that it should.

The partial execution of an Update Procedure (draft-ietf-suit-manifest, section 4.2) followed by the partial execution of that same Update Procedure by a different manifest processor is likely to break a number of assumptions that are present in the design of the manifest.

I think what you are asking for is not, in fact, a new command sequence, but actually to divide the update procedure into a staging procedure and an installation procedure-the original purpose of the separate command sequences was this: staging and installation are separate. However, as you point out, that assumes that they're handled in the same trust domain. Much like secure boot is in a separate trust domain from update and, thus, has a separate procedure (set of command sequences), staging handled by one trust domain with installation handled by another would require a separate procedure.

This would be a very fundamental change to the suit-manifest itself. I'm trying to work out whether adding a whole new procedure in the trust-domains draft is plausible

There's another option, however; the prefetch use-cases line up quite well with a staging procedure:


  1.  Segregated to integrated manifest

     *   A recipient requests an update from its update server.
     *   A transparent proxy intercepts the manifest that is returned.
     *   The proxy fetches the payloads that are referenced by the manifest
     *   The proxy places the payloads in the envelope, with envelope keys that are the original URIs
     *   The proxy hands the whole manifest (including payloads) over to the recipient

  1.  Prefetch Proxy

     *   A recipient requests an update from its update server.
     *   A transparent proxy intercepts the manifest that is returned.
     *   The proxy fetches the payloads that are referenced by the manifest
     *   The proxy stores those payloads locally.
     *   The proxy constructs a new manifest, which overrides the URIs in the original manifest, and includes the original manifest as an integrated dependency. It signs the new manifest.
     *   The proxy hands the new manifest (with integrated dependency) over to the recipient.

In your case, I suspect that 1. would be optimal. Given the operations you have described, I

System is designed to be idempotent. In event of power failure install-sequence from candidate Root manifest is executed from the begin.

It might be possible to replace this approach with a stream-to-secure approach, where the TEE has multiple slots and selects the most recent valid slot on boot. In this case, staging is not necessary, and therefore an extra procedure and/or command sequence is not necessary.

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: Thursday, 21 December 2023 at 06:01
To: Brendan Moran <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Suit] draft-ietf-suit-trust-domains: proposal of new command sequence
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]<mailto:[e-mail]>> On Behalf Of Brendan Moran
Sent: Wednesday, December 20, 2023 4:14 PM
To: Kończyk, Sylwester <sylwester.konczyk=[e-mail]<mailto:sylwester.konczyk=[e-mail]>>; [e-mail]<mailto:[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.
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.
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.