[Suit] MCUboot SUIT discussions

[David Brown <[e-mail]>]

I've written up the following in preparation for today's discussion of
the interaction of the IETF SUIT work, and work to add dual image
support to MCUboot.

# MCUboot and SUIT

- Currently, MCUboot supports a single image.

- Last week's LITE, we discussed requirements for multiple-image
  support:

  - One possibility is to consider the two images as a single unit,
    and always update them together.  If used with delta compression,
    this handles the case of only one image changing by encoding just
    a reference to the unchanged parts.

  - Another possibility is to have the images separate.

    - Two possibilities: independent updates, or both together
      atomically.

      - We need both of these.  Both together would be equivalent to
        treating them as a single unit.

      - Image metadata will need to describe the relationship between
        the images, for example, stating that version A of the first
        image will require version B of the second image.

      - The bootloader (and presumably the image download code) will
        need to determine this relationship, and only perform the
        upgrade when the conditions have been met.

- The IETF SUIT project is working to define a manifest format for
  embedded device firmware upgrades.

  - Among other things, they are addressing the same kinds of issues
    that we have.

  - This is a working group, and participants can influence the
    development of the standard.

- Possible ways for MCUboot to use SUIT.

  - "Ignore" SUIT.  SUIT is defined in such a way that its manifest
    could be used for the download part of the process, and the images
    would still contain the existing TLV information about versions
    and signature.

    - This doesn't address the multiple-image issues.

    - It is likely to be redundant to the metadata contained in the
      SUIT manifest.

    - It may require redundant signing of images, if SUIT is used, as
      the TLV information will also need to contain a signature.

  - Use SUIT instead of TLV for MCUboot

    - Pro: This will address the multiple image format issues

    - Con: There will likely be additional code to parse the
      manifests.  It is unclear how significant this difference will
      be, given that we would have to extend the TLV format to
      describe multiple images.

    - Con: The SUIT manifest format is a work-in-progress, and will
      likely change over time until the standard is formalized.

    - Pro: This addresses one security concern with the current TLV
      format, namely that the TLV data is not covered in the
      signature.  This is fine for now, because the TLV currently only
      contains information about the signature, but if we add
      dependency information, that information would be subject to
      tampering.

- My (David Brown) suggestions:

  - Start by adding support for the "single big image" solution.  This
    shouldn't require manifest changes, and may not require any
    changes to MCUboot.

  - Become more involved with the SUIT working group, to make sure
    MCUboot's needs are considered.

  - Implement a prototype alternate to TLV that works with the SUIT
    manifest format.

    - I recommend a custom parser and signature verification code.
      The existing libraries for these formats generally use malloc
      and are larger, more general code than we need.

    - We should restrict the SUIT manifest to a limited subset of the
      full format.  For examples, a given build may require a specific
      signature type to be present.

    - This should be a compile-time decision, and the TLV code should
      be maintained.

  - My suggestion would be to keep the existing header, but with a
    different magic number, and place the manifest at the end of the
    image, where the current TLV is.

- Ideas for things to extend SUIT with:

  - One of the images to contain the acceptable public keys for the
    other image.