Subject: [Suit] Reference implementation of SUIT manifest parsing

From: David Brown <[email-masked]>
Date: Tue, 19 Jun 2018 15:48:59 -0600

At the last hackathon, work was done on implementations of the SUIT
manifest format.  One way to describe this kind of work would be as a
reference implementation: something that could be a starting point for
anyone wishing to use SUIT to develop something.

However, I had to limit my involvement in this effort, because some of
the code being used was covered under the LGPL 2.0.

I'm wondering if it would be useful to develop equivalents of this
code under a license that would be usable by a larger audience.  I'm
actually having a pretty hard time understanding how there is any
audience for bootloader code covered under the LGPL.

A few of the reasons that the LGPL doesn't work for me (and I believe
doesn't work for many of the current uses).

  - The FSF considers the Apache 2.0 license to be incompatible with
    the GPLv2 (including the LGPL).

  - The Apache Software Foundation considers GPLv3 to be compatible in
    only one direction (Apache 2.0 code can be linked into an
    otherwise GPLv3 application, but GPLv3 code cannot be brought into
    an Apache 2.0 project).

  - The Apache Software Foundation considers the GPLv2 (including
    LGPL) to be incompatible with the Apache 2.0 license.

  - By Mynewt and Zephyr are licensed under the Apache 2.0 license.
    Mynewt is an Apache project and would fall under their constraints
    of forbidding the including of any code under a GPL license.  The
    Zephyr project requires included code to be under the Apache 2.0
    license, and occasionally will allow other more liberal licensed
    code to be included.

Regardless of the above, I see a conflict between the LGPLv2
requirement that the user be able to modify the LGPLv2 licensed code,
and the general purpose of SUIT to enforce that only authorized images
run on the device.  One of the purposes of a signed manifest is to
restrict the very action that the LGPLv2 requires.

My conclusions:

  - libcose (and any other LGPLv2 code) cannot be used by Zephyr,
    Mynewt, due to policies by these projects.  At best, it would end
    up being something that end users would have to incorporate, and
    SUIT support would not be able to become standard support on these
    platforms.

  - libcose (and any other LGPLv2 code) cannot be used by Zephyr,
    Mynewt, mbed OS, and MCUboot, due to incompatibility between the
    LGPLv2 and the Apache 2.0 license.  (Specifically, I do not
    believe the current mbed OS SUIT work is allowed).

  - Very few of our end users would want to meet the LGPLv2
    requirement allowing end users to replace the firmware.
    Specifically, those users desiring signed manifests to ensure only
    authorized images can be run are likely intending to prohibit end
    users from running their own versions of the code.

I've tried to avoid even looking at the libcose code (and making sure
to look at licenses carefully) since it seems likely that I, or
someone working on Zephyr or MCUboot) will need to implement COSE
support in order to support SUIT.

David

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Jun 2018 13:54:27 +0200

Hi David,

Licenses are a difficult area, and I don’t want to go into details on some of the points that you are making.

But we agree in one observation: It would be good to have a liberally licensed reference implementation of SUIT around.
(This statement explicitly does not detract from the merits of having other implementations, as well.)

What are the components we need for that?

https://github.com/cose-wg/COSE-C is BSD-3-clause licensed, and is based on
https://github.com/cabo/cn-cbor which is MIT licensed.

These make some specific implementation choices that may be right or wrong for your environments.
An alternative CBOR library would be https://github.com/intel/tinycbor which also is MIT licensed; I haven’t checked COSE-C on how hard it would be to do the pull-parser approach there as well.  (I don’t see a big problem with sticking to a tree-based implementation on the generation side.)

We’d need liberally licensed implementations of at least SHA-256 and the ECC algorithms of your choice.
A reference implementation of hash-based signatures would be useful, too (allowing us to relax the reliance on ECC).

Finally, it would be useful to have an example implementation of the actual authorization algorithms that devices are likely to employ — even if we don’t standardize them, it is useful to shape expectations here.

Grüße, Carsten

---

From: David Brown <[email-masked]>
Date: Thu, 21 Jun 2018 05:58:59 -0600

I don't really have an idea on the code size change.

However, I don't think we should use an existing library for the parsing, but write custom processing code for the things we support, similar to how we process the TLV data and the signatures now.  It will be best to not just allow any arbitrary signature type, but specifically require certain specific signature types.

David

On 6/20/18, 9:05 AM, "Tamas Ban" <[email-masked]> wrote:

    Hi David,
    
    Do you have any rough estimate how much will be the code size increased due to the libs for the parsing manifest files in CBOR/COSE format?
    
    Does it need a separate lib for parsing CBOR(i.e: tinycbor, cn-cbor) and a different one to verify COSE signing?
    
    Tamas
    
    -----Original Message-----
    From: dev-mcuboot <[email-masked]> On Behalf Of David Brown
    Sent: 19 June 2018 23:49
    To: suit <[email-masked]>
    Cc: [email-masked]
    Subject: [dev-mcuboot] Reference implementation of SUIT manifest parsing
    
    At the last hackathon, work was done on implementations of the SUIT manifest format.  One way to describe this kind of work would be as a reference implementation: something that could be a starting point for anyone wishing to use SUIT to develop something.
    
    However, I had to limit my involvement in this effort, because some of the code being used was covered under the LGPL 2.0.
    
    I'm wondering if it would be useful to develop equivalents of this code under a license that would be usable by a larger audience.  I'm actually having a pretty hard time understanding how there is any audience for bootloader code covered under the LGPL.
    
    A few of the reasons that the LGPL doesn't work for me (and I believe doesn't work for many of the current uses).

    

    Regardless of the above, I see a conflict between the LGPLv2 requirement that the user be able to modify the LGPLv2 licensed code, and the general purpose of SUIT to enforce that only authorized images run on the device.  One of the purposes of a signed manifest is to restrict the very action that the LGPLv2 requires.
    
    My conclusions:

    
    
    I've tried to avoid even looking at the libcose code (and making sure to look at licenses carefully) since it seems likely that I, or someone working on Zephyr or MCUboot) will need to implement COSE support in order to support SUIT.
    
    David
    
    _______________________________________________
    MCUBoot: a secure, open source bootloader for 32-bit MCUs http://lists.runtime.co/mailman/listinfo/dev-mcuboot_lists.runtime.co
    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.