Re: [Suit] Improvements to draft-moran-suit-manifest-03

[Amyas Phillips <[e-mail]>]

I have another use case for you Brendan:

A project wants to send its firmware images encrypted, and wants a trusted
boot process.

Faced with this, my first thought might be that I'm going to have the
bootloader validate the manifest.

What should we recommend?

I can see lots of ways of doing it:
1. Encrypt the firmware image, then create the manifest. Store the
encrypted firmware on the target device and on each start have the
bootloader validate the manifest and encrypted firmware, before decrypting
the firmware into a location from where it can be run. This is the model
more-or-less implied in the manifest specification. It works for devices
that can afford to decrypt the image to an executable location on each
start, e.g. execute-from-RAM devices.
2. Reverse the order of signing and encryption: first create the manifest,
then encrypt the firmware image. Have the receiving process on the device
decrypt the image and store the decrypt and the manifest in NVRAM for the
bootloader to validate. This saves devices from having to decrypt and
install the firmware image on each start. Receiving processes can
potentially also decrypt images into storage as they arrive, saving on
NVRAM. This approach is in effect a wrapper around SUIT.
3. Create a manifest for the bootloader's use and package it up with the
firmware. Encrypt this package as a new payload and mint another manifest
for the use of the retrieving process.  Have the retrieving process
assemble the package, validate it and then decrypt it into the appropriate
location for the bootloader.
4. Create a manifest for the bootloader's use. Encrypt the firmware image
and create a second manifest for the retrieving process's use, this time
including a dependency on the first manifest. Have the retrieving process
retrieve, validate, decrypt and install the firmware image. Have it also
retrieve and install the first manifest.
5. Relax the requirement for the bootloader to validate a manifest. Maybe
it doesn't really need to. I can't see any benefits to having a bootloader
validate manifests except that it seems tidier to use manifests for all our
validation needs. Instead of that simply sign the firmware image, in
whatever way the bootloader expects. Then encrypt the signed object and
ship it under a manifest. Have the receiving process validate it and
decrypt it into the appropriate location for the bootloader.
6. Rely on channel security for confidentiality. Relying on encrypted
channels nets you confidentiality without having to leave space on each
device to store encrypted images for validation. This may often be
acceptable but is against one of the SUIT design principles as I understand
them: channel-independence.   I think SUIT can recognise it as an option
but not rely on it for in-scope usecases.

My vote is for option 5.

Many thanks
Amyas Phillips







On Thu, 31 Jan 2019 at 13:27, Brendan Moran <[e-mail]> wrote:

> Following IETF103, I have been collecting more use cases and user stories
> to influence the development of the manifest.
>
> Three points have become very clear:
>
> First, the processing tree is too complicated. There are many possible
> configurations that would never be used. There is plenty of room for error.
> In reality, the configurations that seem to be usable are all the
> combinations of these three operations:
> * decrypt
> * decompress
> * unpack (delta, relocate, hex, etc.)
>
> I have yet to find a use-case where these operations do not appear in this
> order, or where there is another operation that is missing from this list.
>
> That being the case, a processing tree, while very general-purpose is
> extra overhead that is not needed. With that in mind, I would like to
> propose changing the payload model back to something more conventional.
>
> The payload-installation-info structure contains information about
> * where to store the firmware image (install-component),
> * where to retrieve it (uris),
> * whether the firmware image is encrypted and with what algorithm
> (encrypt-info),
> * whether a compression algorithm has been applied to the firmware image
> and what algorithm has been used (compression-algorithm),
> * whether the image is a binary diff or requires relocation (unpack), and
> * an indication whether these fields may be overridden by an authorized
> party (allow-override).
>
> Here is a proposed CDDL snippet for draft-moran-suit-manifest-04:
>
> payload-installation-info = {
>    install-component => component-identifier,
>    ? allow-override => bool,
>    ? uris => uri-list,
>    ? encrypt-info => COSE_Encrypt0 / COSE_Encrypt,
>    ? compression-algorithm => compression-algorithm-ids,
>    ? unpack => [
>        unpack-algorithm : unpack-algorithm-ids, ; binary diff, or
> relocation, or binary-to-text algorithm identifier
>        ? unpack-arguments : bytes                 ; private config for the
> unpack algorithm selected
>    ]
> }
>
> This should be much easier to understand and implement.
>
>
> The second point is that regen-info is frequently misunderstood and
> misused. After some discussion with suit participants, it’s become clear
> that the regen-info block should be represented as a dedicated “digest
> algorithm” which solves the same problem as the regen-info block currently
> does. When incorporated with the changes recommended by Jim Schaad, the
> result is that we replace COSE_Digest with SUIT_Digest and we remove
> regen-info. Here is a CDDL snippet that represents SUIT_Digest:
>
> SUIT_Digest = [
>    digest-algorithm-id: int,
>    digest: bytes,
>    ? digest-extra-info: bytes
> ]
>
> Any needed regen-info can then be contained in the digest-extra-info
> section with an appropriate algorithm identifier.
>
>
> The third point of clarity is that we need to do some work in making the
> manifest easier to parse and process in a constrained environment. I don’t
> have a simple change to enable that, but we’re working on it.
>
> Best Regards,
> Brendan
> 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.
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit
>