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

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

Hi Brendan,

I am glad to hear that. I fully agree with your analysis, especially about the need of new Candidate-verification command sequence.

Referring to three options related to introduction of this new command sequence, and especially to associated CDDL snippets - any of those would work. As I understand, now we have to reach an agreement within WG about choosing one of those. Let me add few comments to each option:

Option 1: “If Candidate Verification is present in the manifest, then installation MUST be executed after Candidate Verification” – Right. Perhaps that could be more clear if we would change the order of appearance:

SUIT_Severable_Members_Choice = (
  ? suit-dependency-resolution => bstr .cbor SUIT_Command_Sequence,
  ? suit-payload-fetch => SUIT_Digest / bstr .cbor SUIT_Command_Sequence,
  ? suit-candidate-verification => SUIT_Digest / bstr .cbor SUIT_Command_Sequence,
  ? suit-install => SUIT_Digest / bstr .cbor SUIT_Command_Sequence,
  ? suit-text => SUIT_Digest / bstr .cbor SUIT_Text_Map,
)
… and keep already allocated key values:

suit-dependency-resolution = 15
suit-payload-fetch = 16
suit-candidate-verification = /* any available value */
suit-install = 17

In above case respective sequences are to be executed in order; they are just represented by out-of-order keys.

Also, your idea about changing the suit-install key to 20 would work. As I understand - suit-candidate-verification would be 18 or 19 in that case?

Option 2: It is the least I like. Indeed, suit-install and suit-candidate-installation would be confusing.

Option 3: Seems to be the cleanest from logical point of view (split the Update Procedure into Staging and Installation), but practically, in my personal opinion, it does not bring anything more than option 1.


Best Regards,

Sylwester

-----Original Message-----
From: Brendan Moran <[e-mail]>
Sent: Tuesday, January 23, 2024 2:32 PM
To: Kończyk, Sylwester <[e-mail]>
Cc: Brendan Moran <[e-mail]>; [e-mail]
Subject: Re: [Suit] draft-ietf-suit-trust-domains: proposal of new command sequence

After thinking about this more, I believe that you are right, Sylwester; we cannot merge installation with either staging or invocation in all scenarios. As a result, I believe we need to consider how to insert a candidate verification command sequence into the manifest. While this appears to me to be a core consideration, I do not think it needs to be in the manifest specification itself.

This example shows my justification for adding a new procedure and one or more command sequences. Suppose that you have a device that has the following partitions:

A: Application/Downloader
B: Staging
C: Installer
D: Bootloader
E: Recovery

Suppose that B is substantially smaller than the A image.
=> This is why there is a separate installer

Suppose that C uses a decompression algorithm to reinflate B to A => This is required so that a small B remains adequate for A => This means that C likely needs to be updatable

Suppose that failed installations are handled by E image fetching a new B and attempting install again.

Then,
A performs dependency resolution and image fetch C performs image installation D performs secure boot

Because of the separation of responsibilities, it would be difficult to implement this use case without a clear division between Staging and Installation.

Where we stand today:

Update Procedure
* Dependency-resolution
* Payload-fetch
* Install

What we need:
Staging Procedure
* Dependency-resolution
* Payload-fetch

Installation Procedure
* Candidate-verification
* Candidate-installation

Bear in mind that these procedures do not exist in the metadata; they are logical procedures. The manifest processor must decide which command sequences to invoke and when.



How do we instantiate the new procedure and sequence?
============

I can see three ways to resolve this. The CDDL below is shown in aggregate form, combining the detail present in trust-domains and in the manifest spec.

1. If Candidate Verification is present in the manifest, then installation MUST be executed after Candidate Verification

SUIT_Severable_Members_Choice = (
  ? suit-dependency-resolution => bstr .cbor SUIT_Command_Sequence,
  ? suit-payload-fetch => SUIT_Digest / bstr .cbor SUIT_Command_Sequence,
  ? suit-install => SUIT_Digest / bstr .cbor SUIT_Command_Sequence,
  ? suit-candidate-verification => SUIT_Digest / bstr .cbor SUIT_Command_Sequence,
  ? suit-text => SUIT_Digest / bstr .cbor SUIT_Text_Map,
)

Note: the ordering here is the ordering that will occur if we do not alter the suit-install key.

The Staging Procedure is composed of (1. suit-dependency-resolution, 2. suit-payload-fetch) The Install Procedure is composed of (1. suit-candidate-verification, 2. suit-install)

Note that the Install Procedure requires out-of-order processing of elements in the manifest. This could be corrected by changing the suit-install key in the manifest-spec.

This approach is my preference, particularly if we change the suit-install key from 17 to 20. Draft-ietf-suit-manifest is in IETF last call. I believe that, if the working group agrees, this change is small enough to be accepted.

2. A new Candidate Installation command sequence is introduced.
Suit-install may be used as normal. The manifest processor (or relevant ACLs) will determine whether each component can be written from application-level suit-install or the installer-level candidate-installation.

SUIT_Severable_Members_Choice = (
  ? suit-dependency-resolution => bstr .cbor SUIT_Command_Sequence,
  ? suit-payload-fetch => SUIT_Digest / bstr .cbor SUIT_Command_Sequence,
  ? suit-install => SUIT_Digest / bstr .cbor SUIT_Command_Sequence,
  ? suit-candidate-verification => SUIT_Digest / bstr .cbor SUIT_Command_Sequence,
  ? suit-candidate-installation => SUIT_Digest / bstr .cbor SUIT_Command_Sequence,
  ? suit-text => SUIT_Digest / bstr .cbor SUIT_Text_Map,
)

The Staging Procedure is composed of (1. suit-dependency-resolution, 2. suit-payload-fetch, 3. suit-install) The Install Procedure is composed of (1. suit-candidate-verification, 2. suit-candidate-installation)

The overlap between suit-install and suit-candidate-installation may be somewhat confusing. No changes are required to the manifest specification. The Manifest Processor can process all command sequences in-order.

3. Modify the Manifest Specification now to split the Update Procedure into Staging and Installation, add the new candidate verification command sequence, and adjust the corresponding CBOR keys to match.

SUIT_Severable_Members_Choice = (
  ? suit-dependency-resolution => bstr .cbor SUIT_Command_Sequence,
  ? suit-payload-fetch => SUIT_Digest / bstr .cbor SUIT_Command_Sequence,
  ? suit-candidate-verification => SUIT_Digest / bstr .cbor SUIT_Command_Sequence,
  ? suit-candidate-installation => SUIT_Digest / bstr .cbor SUIT_Command_Sequence,
  ? suit-text => SUIT_Digest / bstr .cbor SUIT_Text_Map,
)

The Staging Procedure is composed of (1. suit-dependency-resolution, 2. suit-payload-fetch) The Install Procedure is composed of (1. suit-candidate-verification, 2. suit-candidate-installation)

Summary:

1. creates a tooling question: if the device supports candidate verification, is it mandatory? And, if a manifest processor that supports Candidate-verification receives a manifest that does not contain it, is that a fault? Can we change the suit-install key; incrementing it by 1-3 before we finalise the manifest spec?

2. simplifies the specification update: the Update Procedure remains exactly as it is. The suit-install sequence can be used or not. It makes no difference to the security model: suit-install and suit-payload-fetch have access to all the same commands and component IDs.

3. is not a massive change, but it is quite structural and quite late.
That said, the mechanics of it are minimal. An implementor may not even notice.

Best Regards,
Brendan

On Wed, Jan 17, 2024 at 1:31 PM Brendan Moran <[e-mail]> wrote:
>
> Hi Sylwester,
>
> I think I haven't been completely clear on this. Please see my comments inline.
>
> Best Regards,
> Brendan
>
> On Wed, Jan 17, 2024 at 7:23 AM Kończyk, Sylwester
> <sylwester.konczyk=[e-mail]> wrote:
> > 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.
>
> [BM] For lazy installation, I am referring exclusively to the elements
> of the Invocation Procedure.
> By "System Validation sequence," I meant suit-validate.
> By "load sequence," I meant suit-load.
>
> Suppose there is a device that has a staging area (Component ID
> ["Staging"]) and an active firmware (Component ID ["Active"]). A
> manifest (JSON-style) that would satisfy your needs is as follows:
>
> {
>     "suit-authentication-wrapper" : "omitted",
>     "suit-manifest" : {
>         "suit-common": {
>             "suit-components" : [
>                 ["Staging"],
>                 ["Active"]
>             ],
>             "suit-shared-sequence" : [
>                 "suit-directive-set-component-index", 0,
>                 "suit-directive-override-parameters", {
>                     "suit-parameter-image-digest" : "<Staging image digest>"
>                 },
>                 "suit-directive-set-component-index", 1,
>                 "suit-directive-override-parameters", {
>                     "suit-parameter-image-digest" : "<Installed image digest>"
>                 }
>             ]
>         },
>         "suit-payload-fetch" : [
>             "suit-directive-set-component-index", 0,
>             "suit-directive-override-parameters", {
>                 "suit-parameter-uri" : "https://suit.example/lazy-install.bin"
>             },
>             "suit-directive-fetch", 2,
>             "suit-condition-image-match", 2
>         ],
>         "suit-validate" : [
>             "suit-directive-set-component-index", 1,
>             "suit-directive-try-each", [
>                 [
>                     "suit-directive-set-component-index", 1,
>                     "suit-condition-image-match", 2
>                 ],
>                 [
>                     "suit-directive-set-component-index", 0,
>                     "suit-condition-image-match", 2
>                 ]
>             ]
>         ],
>         "suit-load": [
>             "suit-directive-set-component-index", 1,
>             "suit-directive-try-each", [
>                 [
>                     "suit-condition-image-match", 2
>                 ],
>                 [
>                     "suit-directive-override-parameters", {
>                         "suit-parameter-source-component" : 0
>                     },
>                     "suit-directive-copy", 2,
>                     "suit-condition-image-match", 2
>                 ]
>             ]
>         ],
>         "suit-invoke":[
>             "suit-directive-set-component-index", 1,
>             "suit-directive-invoke", 2
>         ]
>     }
> }
>
> As you can see, each time the device boots, the bootloader uses
> suit-validate to check whether EITHER the active image is correct OR
> the staged image is correct. If EITHER condition is true, then it
> proceeds to suit-load. During suit-load, the manifest directs the
> bootloader to determine whether the active image is correct. If it is
> not, the bootloader (having already verified that the staged image is
> correct) copies the staged image into the active image component. Once
> the copy is finished, the bootloader verifies that the active image is
> correct. Then, it proceeds to suit-invoke. suit-invoke simply invokes
> the active image, having already verified that it is correct.
>
> >
> >
> >
> > 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
> >
>
> [BM]: Step 2 not needed.
>
> > 3.            Invocation procedure carried out by the BL.
> >
> >                 - suit-validate
> >
> >                 - suit-load
> >
> >                 - suit-invoke
>
> ... SNIP ...
>
> >
> > 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.
>
> [BM]: The specification would be slightly more complex. I don't know
> if it is enough additional complexity to be an issue. The bigger
> problem is that suit-install could exist in one of two procedures.
> This leads to some implementation challenges that I find quite
> concerning. Changing this requires a change to the Manifest
> Specification. It seems that it would be safer to add two sequences:
> one pre-install-validation sequence and a separate,
> post-validation-install sequence, then group both of these in a
> separate procedure--would these new sequences be severable? I would
> assume so since they are not needed once installation has completed;
> that said, they should be minimal in size, which makes the value of
> severing them questionable.
>
> > Adding extra logic to suit-validate and execute it twice - it will require a more complex content of suit-install.
>
> [BM]: As I described above, suit-install is not executed twice.
> suit-load is used instead.
>
> >
> >
> > 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.
>
> [BM]: As described above, suit-load is for loading images into their
> executable locations, post validation. While suit-load can be used for
> loading into volatile RAM, it can also be used for loading into NVRAM.
> This seems to be your use case.
>
> My big question is whether you see sufficient semantic difference,
> between this type of loading operation and a discrete installation
> step, that we would require a whole new procedure. I'm definitely open
> to that, I just want to be sure we have covered the alternatives
> first.