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

[Brendan Moran <[e-mail]>]

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.