Subject: Re: [Suit] Firmware Update Paper

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 1 Dec 2019 10:01:18 +0000

Hi David,

This is good feedback and we will  have to take that into account when we work on the new version of the manifest generator/parser.
The code Emmanuel referenced still implements the old version of the manifest format and this year we switched to a new format, which will need to be implemented / is implemented right now.

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of David Brown
Sent: Friday, November 29, 2019 7:36 PM
To: Emmanuel Baccelli <[email-masked]>
Cc: [email-masked]
Subject: Re: [Suit] Firmware Update Paper

On Fri, Nov 29, 2019 at 12:46:42PM +0100, Emmanuel Baccelli wrote:

> The open source implementation stemming from our paper [1] is embedded
> into the RIOT operating system, which is indeed licensed with LGPL.
> The implementation is compliant with draft-ietf-suit-manifest-00 and
> has recently been merged into the main branch of RIOT, see [2].
> Reuse and further contributions to this code base are welcome!
>
> Relicensing this code is not planned as far as I know (@ code co-authors:
> please correct me if I'm wrong).

This is fine.  The authors of the code are free to license the code however they wish.  I just want to make sure it is clear that this code is not useful as a general example, and if the SUIT wishes to have reference code, it will need to be licensed differently.

> Related: we know of several companies, big and small, which use RIOT
> in their IoT products (and thus use software including -- but not
> limited to -- LGPL
> code) and they are quite happy with it.

I'm sure there are a few companies that are willing to use LGPL licensed embedded code, but their existence doesn't negate that there are large numbers of users who will be unable to use (or even look at) this code.

One example is that both Zephyr and MCUboot are licensed under the Apache 2.0 license.  Most parties feel that the Apache 2.0 and the LGPL 2 license are incompatible, and this code cannot be linked together into a single product.  Since I'd like to include SUIT support into MCUboot, this means I'll have to be doing an implementation from scratch.

It's not my place to argue about the licensing of RIOT, but I would like to see reference code for SUIT that can be used as widley as possible, and the licensing of this particular code prevents it from being used for that.

David

_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit
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.

---

From: Brendan Moran <[email-masked]>
Date: Mon, 2 Dec 2019 15:20:18 +0000

Hi David,

The manifest generator that I released previously was apache 2.0-licensed. I don't plan to change that for the next release. I'm also developing a manifest parser which I anticipate being released under the same license.

Best Regards,
Brendan

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of David Brown
Sent: 29 November 2019 18:36
To: Emmanuel Baccelli <[email-masked]>
Cc: [email-masked]
Subject: Re: [Suit] Firmware Update Paper

David

---

From: Szymon Słupik <[email-masked]>
Date: Tue, 3 Dec 2019 08:57:57 +0900

Hi Hannes,

What transport did you use? I could not find that information explicitly
stated in the paper...

Thanks!

Simon

On Tue, Dec 3, 2019 at 12:20 AM Brendan Moran <[email-masked]> wrote:

> Hi David,
>
> The manifest generator that I released previously was apache 2.0-licensed.
> I don't plan to change that for the next release. I'm also developing a
> manifest parser which I anticipate being released under the same license.
>
> Best Regards,
> Brendan
>
> This is fine.  The authors of the code are free to license the code
> however they wish.  I just want to make sure it is clear that this code is
> not useful as a general example, and if the SUIT wishes to have reference
> code, it will need to be licensed differently.
>
> I'm sure there are a few companies that are willing to use LGPL licensed
> embedded code, but their existence doesn't negate that there are large
> numbers of users who will be unable to use (or even look at) this code.
>
> One example is that both Zephyr and MCUboot are licensed under the Apache
> 2.0 license.  Most parties feel that the Apache 2.0 and the LGPL 2 license
> are incompatible, and this code cannot be linked together into a single
> product.  Since I'd like to include SUIT support into MCUboot, this means
> I'll have to be doing an implementation from scratch.
>
> It's not my place to argue about the licensing of RIOT, but I would like
> to see reference code for SUIT that can be used as widley as possible, and
> the licensing of this particular code prevents it from being used for that.
>
> David
>
> 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.
>

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 3 Dec 2019 09:37:19 +0100

Hi Szymon

in the paper [1] for our experiements we used CoAP as transport, over UDP,
6LoWPAN and IEEE 802.15.4 low power radio.

However the open source RIOT implementation which stemmed out also works
out-of-the-box on other link layers too (among others BLE [3], wired [1]
...).

Cheers,

Emmanuel

[1] https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8725488
[2] https://github.com/RIOT-OS/RIOT/tree/master/examples/suit_update
[3] https://github.com/RIOT-OS/RIOT/pull/12391

On Tue, Dec 3, 2019 at 12:58 AM Szymon Słupik <[email-masked]> wrote:

>> The manifest generator that I released previously was apache
>> 2.0-licensed. I don't plan to change that for the next release. I'm also
>> developing a manifest parser which I anticipate being released under the
>> same license.
>>
>> Best Regards,
>> Brendan
>>

---

From: Szymon Słupik <[email-masked]>
Date: Tue, 3 Dec 2019 17:53:00 +0900

Thanks Emmanuel,

So the PHY data rate was 250kb/s, right?

WRT Figure 3 (tIme spent) 38% is signature verification and 60% is
transfer. That seems like signature verification is taking a huge amount
of time... or was it a different data rate?

Best

Simon

On Tue, Dec 3, 2019 at 5:37 PM Emmanuel Baccelli <[email-masked]>
wrote:

>>> One example is that both Zephyr and MCUboot are licensed under the
>>> Apache 2.0 license.  Most parties feel that the Apache 2.0 and the LGPL 2
>>> license are incompatible, and this code cannot be linked together into a
>>> single product.  Since I'd like to include SUIT support into MCUboot, this
>>> means I'll have to be doing an implementation from scratch.
>>>

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 3 Dec 2019 14:04:41 +0100

Hi Szymon

below some more information, since you ask ;)

In the experiment you point out (reported in Table 3 and 4 in [1]) the
transfer of the firmware binary + the manifest (totaling ~35kB) took about
11 seconds.
The 802.15.4 radio was used in 2.4GHz band in default mode (we used an
off-the-shelf SAMR21 board [2] for this experiment).
The signature verification was performed with the HACL library (ed25519) on
an ARM Cortex-M0+ and took approx. 7 seconds -- so yes, pretty long indeed,
in this case.

For other microcontrollers and/or with other signature schemes or
alternative implementations/libraries, the speed & memory footprint we
measured are compared in Tables 8, 7 and 6 (see [1]).

As observed in the paper:
    - the time spent on signature verification heavily depends on the type
of microcontroller, on the signature scheme, and on the specific
implementation;
    - crypto's footprint in Flash memory can significantly impact the size
of update binaries which need to be transferred over the network.

Cheers,

Emmanuel

[1] https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8725488
[2] https://github.com/RIOT-OS/RIOT/wiki/Board:-Samr21-xpro

On Tue, Dec 3, 2019 at 9:53 AM Szymon Słupik <[email-masked]> wrote:

> On Tue, Dec 3, 2019 at 5:37 PM Emmanuel Baccelli <
> [email-masked]> wrote:
>
>> Hi Szymon
>>
>> in the paper [1] for our experiements we used CoAP as transport, over
>> UDP, 6LoWPAN and IEEE 802.15.4 low power radio.
>>
>>>> I'm sure there are a few companies that are willing to use LGPL
>>>> licensed embedded code, but their existence doesn't negate that there are
>>>> large numbers of users who will be unable to use (or even look at) this
>>>> code.
>>>>
>>>> It's not my place to argue about the licensing of RIOT, but I would
>>>> like to see reference code for SUIT that can be used as widley as possible,
>>>> and the licensing of this particular code prevents it from being used for
>>>> that.
>>>>
>>>> David
>>>>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Dec 2019 08:23:20 -0500

> 6LoWPAN and IEEE 802.15.4 low power radio.

CoAP Block Mode?

---

From: Emmanuel Baccelli <[email-masked]>
Date: Tue, 3 Dec 2019 15:02:48 +0100

Hi Michael,

in the paper, we implemented and comparatively evaluated various
configurations.
Some configurations use CoAP Block1, others use Block2 (see section IV.C.
in [1]).
For Table 3, CoAP Block1 is used, IIRC.
(Ccing Koen and Kaspar in case they know better).

cheers,

Emmanuel

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Dec 2019 16:57:06 -0500

> CoAP Block Mode?

Hi, I know that you answered, and I actually posted my question before I had
finished all of the paper :-)
(That's a new kind of pie chart you've used...)

As I understand it, in the pure-CoAP scenario you provided an endpoint to
which the SUIT manifest was pushed (using Block1).   The target device then
evaluated the manifest, and if it validated and was new, then it downloaded
the new firmware.

Similarly, the same thing was done with a LwM2M-OTA situation.
Neither situation had any transport security (DTLS), and relied upon the
verification of the manifest.  So we had end-to-end integrity, but no
privacy.

Of course, the 802.15.4 network could have L2 security... did you have that?
I'm asking because it's an additional crypto load.

At this point quite a number of people would like to standardized some
transport for SUIT manifests for use in some situations like you have described.
That was deemed outside the scope for the current SUIT effort (and I agreed
with the reasons at the time), and I wouldn't expect everyone to agree to use
it.   Some have expected OCF or another to do something here.

I wonder if there is interest in doing things at the IETF?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Szymon Słupik <[email-masked]>
Date: Wed, 4 Dec 2019 09:55:44 +0900

Hi Emmanuel,

Thanks fo the detailed info.

Some comments of mine in line below

> transfer of the firmware binary + the manifest (totaling ~35kB) took about

[SS] yeah... that 35kB is a bit unrealistic... for production stacks
(including application functionality) we see the FW sizes (uncompressed) to
be in 200kB range. But I take it the times scale linearly, so for 200kB the
transfer time would be about 1 minute. Have you considered the link
saturation during the transfer? In many cases you do not want the transfer
to [significantly] affect the operation of the network, so a strategy to
reduce the transfer duty cycle may be prudent.

> off-the-shelf SAMR21 board [2] for this experiment).

[SS] And that was a single-hop, right? Have you considered multi-hop
transfers over a mesh network?

> The signature verification was performed with the HACL library (ed25519)
> on an ARM Cortex-M0+ and took approx. 7 seconds -- so yes, pretty long
> indeed, in this case.

[SS] Does that scale linearly with image size? Do memory requirements (RAM
usage) increase with the image size?

Best
Simon

On Tue, Dec 3, 2019 at 10:05 PM Emmanuel Baccelli <
[email-masked]> wrote:

> The signature verification was performed with the HACL library (ed25519)
> on an ARM Cortex-M0+ and took approx. 7 seconds -- so yes, pretty long
> indeed, in this case.
>
> measured are compared in Tables 8, 7 and 6 (see [1])..
>
>>>> What transport did you use? I could not find that information
>>>> explicitly stated in the paper...
>>>>
>>>> Thanks!
>>>>
>>>> Simon
>>>>
>>>>> Apache 2..0 license.  Most parties feel that the Apache 2.0 and the LGPL 2

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 4 Dec 2019 12:38:22 +0100

Hi Simon,

Some comments & answers inline.

On Wed, Dec 4, 2019 at 1:56 AM Szymon Słupik <[email-masked]> wrote:

> [...]
> be in 200kB range.

[EB] Just to be clear: we did not make this number up. 35kB is the actual
binary size for a (basic) RIOT configuration including standard CoAP and
crypto functionalities, among others.
That said, indeed, firmware size does depend on the OS, the libraries that
are used, and on the required functionalities.

[SS] Have you considered the link saturation during the transfer? In many
> cases you do not want the transfer to [significantly] affect the operation
> of the network, so a strategy to reduce the transfer duty cycle may be
> prudent.
>
> [..] And that was a single-hop, right? Have you considered multi-hop

[EB] The measurements we made for this paper were in the simplest scenario
you can think of (single hop, and good network conditions).
In other scenarios (multihop, side traffic etc.) results would be
different, delaying network transfer completion time.
Nevertheless I think this does not invalidate the observations made in the
paper,
i.e. that crypto makes up for a significant chunk of the memory and energy
footprints.

> usage) increase with the image size?
[EB] Not really: in the context of this paper, what is signed (and
verified) is a hash of the image, not the image itself.

Best regards,

Emmanuel

>>     - the time spent on signature verification heavily depends on the
>> type of microcontroller, on the signature scheme, and on the specific
>> implementation;
>>     - crypto's footprint in Flash memory can significantly impact the
>> size of update binaries which need to be transferred over the network.
>>
>> Cheers,
>>
>> Emmanuel
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 4 Dec 2019 12:26:39 +0000

The signature verification was performed with the HACL library (ed25519) on an ARM Cortex-M0+ and took approx. 7 seconds -- so yes, pretty long indeed, in this case.

[SS] Does that scale linearly with image size? Do memory requirements (RAM usage) increase with the image size?

[EB] Not really: in the context of this paper, what is signed (and verified) is a hash of the image, not the image itself.

Adding to what Emmanuel said.

The memory requirements very much depend on the selected crypto implementation (and quite naturally the key size). There is also a relationship between the code size and the speed of execution. Code that has been hand-crafted for the specific MCU tends to be faster and consumes less memory than a generic implementation. This is inline with what is being stated in https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/. Needless to say that type of protection offered by an implementation (e.g., side channel attack resistance, such as resistance against remote timing attacks) has an impact on both code size as well as runtime performance.

It would be interesting to also analyze the heap requirements. As written in the paper, we focused only on the stack size.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Dec 2019 14:00:50 -0500

Szymon Słupik <[email-masked]> wrote:
    > saturation during the transfer? In many cases you do not want the transfer to
    > [significantly] affect the operation of the network, so a strategy to reduce
    > the transfer duty cycle may be prudent.

I also agree with your question, and with the need to do the updates at a
lower priority.  6tisch has a whole bunch of mechanism here.

It occurs to me now that the development of an update protocol over 802.15.4
(which I mentioned in another email in this thread) might be appropriately
done in the 6tisch WG, since I actually think that the bandwidth and
scheduling of the update is probably the critical part.
SUIT has the security done... so we have the HOW.  We just have the WHEN.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Dec 2019 14:02:29 -0500

> usage) increase with the image size?

I guess what we want to know is how much of that 7s time was the ED25519 operation, and
how much time was the hash calculation.  Only the hash calculation would
scale with the image size.

---

From: Szymon Słupik <[email-masked]>
Date: Thu, 5 Dec 2019 10:30:30 +0900

All,

Thanks for the helpful answers.

Michael,

>
>
>
> *It occurs to me now that the development of an update protocol over
> 802.15.4(which I mentioned in another email in this thread) might be
> appropriatelydone in the 6tisch WG, since I actually think that the
> bandwidth andscheduling of the update is probably the critical part.SUIT
> has the security done... so we have the HOW.  We just have the WHEN.*

One other approach to explore, very applicable to FW updates, is multi-hop
multicast, as in many scenarios you are updating more than one device, and
many of them are identical (like lights on a big parking lot).

--Simon

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Dec 2019 09:33:47 -0500

mcr> It occurs to me now that the development of an update protocol over
    mcr> 802.15.4
    mcr> (which I mentioned in another email in this thread) might be
    mcr> appropriately
    mcr> done in the 6tisch WG, since I actually think that the bandwidth and
    mcr> scheduling of the update is probably the critical part.
    mcr> SUIT has the security done... so we have the HOW. We just have the WHEN.

    > many of them are identical (like lights on a big parking lot).

I agree that this is an important aspect to explore.
It requires that each hop is able to buffer the entire firmware update in a
way that does not break the hash of it.  If the firmware is execute in place
and/or if the device is designed such that the bootstrap code validates the
firmware on each boot, then keeping the firmware image in that form may not
be a big imposition.

We also did MPL ("mipple", RFC7733) in the ROLL WG, which would allow for
the "download" of the firmware to be multicast.  There are bandwidth, CPU and
network scheduling tradeoffs of each, which I think 6tisch is most capable to
consider.   That's why I think that it's not a HOW anymore, but a WHEN.

---

From: Koen <[email-masked]>
Date: Fri, 6 Dec 2019 21:20:45 +0100

Hi all,
> scale with the image size.

The time we measured spent on hashing (SHA256)is comparatively small for
the typical firmware sizes.It takes ~4ms per kB to hashon the platform
used in the paper. Even with a 200kB binary,it takes just a fraction
(~10%) of the time needed for signature verification and a tinier
fraction if the binary is smaller.

Best regards,
Koen Zandberg

---

From: Szymon Słupik <[email-masked]>
Date: Sat, 7 Dec 2019 09:38:31 +0900

> fraction if the binary is smaller.

Yes, that was actually my point, that with larger file sizes and in real
mesh network scenario (multi-hop, not saturating the links) and more
realistic file sizes (say 200kB), the transfer will be taking significantly
more than the other operations.

Thanks!

--Simon

---

From: David Brown <[email-masked]>
Date: Wed, 11 Dec 2019 10:51:27 -0700

On Wed, Dec 04, 2019 at 12:26:39PM +0000, Hannes Tschofenig wrote:

> The signature verification was performed with the HACL library (ed25519) on an
> ARM Cortex-M0+ and took approx. 7 seconds -- so yes, pretty long indeed, in
> this case.

In MCUboot, we ended up using the fiat crypto library (ed25519).  It
does have a fairly large code footprint (about 18k), but does an
ed25519 signature verification in 28ms (Cortex M4, 120Mhz).  Most
other smaller libraries were giving times like seen above, on the
order of tens of seconds.  For reference, libsodium ends up being
about 130k of code, and was about 14ms for the verification.

David