Subject: [Suit] Common firmware update flaws

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 17 Sep 2020 06:57:23 +0000

Hi all,

In his review, Bob Briscoe suggested to list "common practices that are insecure, and perhaps some common misconceptions about secure firmware update" in the SUIT architecture document.

So far, nobody suggested to include such a list in the architecture document and hence I would like to reach out to the group.

There are different ways to write such a text and the key decisions are:

  1.  Should we include references to published flaws or keep the description abstract?
  2.  Should we include only examples that we later fix with the SUIT manifest? For example, a firmware update can change the nature of a product (e.g. excluding the use of third party printer cartridges).

Question 1: Would you like to have such text to be added?

Question 2: If so, what is your answer to (a) and (b)?

Your feedback is appreciated. Text contributtions are welcome!

Ciao
Hannes

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: Fabien BESSIERES <[email-masked]>
Date: Thu, 17 Sep 2020 20:01:32 +0200

Hi,

Here is my feedback :

Question 1: I believe that the architecture document could include a list
of common practices that are insecure.

Question 2: (a) I don't see any problem in adding directly referenced to
published flaws.
(b) But yes it should be examples that are fixed with the SUIT manifest

I believe that addressing common mistakes/errors/flaws is one of the goals
of the architecture, so it should appear in the document. What do you think
?

Fabien

Le jeu. 17 sept. 2020 à 08:58, Hannes Tschofenig <[email-masked]>
a écrit :

> Hi all,
>
>
>
> In his review, Bob Briscoe suggested to list “common practices that are
> insecure, and perhaps some common misconceptions about secure firmware
> update” in the SUIT architecture document.
>
>
>
> So far, nobody suggested to include such a list in the architecture
> document and hence I would like to reach out to the group.
>
>
>
>    2. Should we include only examples that we later fix with the SUIT
>    manifest? For example, a firmware update can change the nature of a product
>    (e.g. excluding the use of third party printer cartridges).
>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Sep 2020 15:10:42 +0000

Hi Fabien,

Thanks for your feedback.

Here are examples of problems mentioned in the past in our documents/slides:

  *   The most obviously problem, with surfaced with the DDoS attacks by IP connected cameras, was the lack of firmware updates in IoT devices. Bruce Schneier talks about this topic in this blog post https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html
  *   In “IoT Goes Nuclear: Creating a ZigBee Chain Reaction" the authors retrieved a shared symmetric key used by all devices of the same product family to protect the firmware update. Once that key was obtained the researchers were able to update devices with new (malicious) firmware images.
  *   In http://events.ccc.de/congress/2014/Fahrplan/events/6166.html an attack against an implementation of the TR69-based firmware update protocol was described. While the described problem is an implementation bug in the HTTP-server running on the gateways, there is the issue with complex supply chains and passing firmware updates along these chains.
  *   Sometimes firmware updates also change features of a product without the user knowing. Examples include https://boingboing.net/2015/12/14/philips-pushes-lightbulb-firmw.html and https://boingboing.net/2016/09/19/hp-detonates-its-timebomb-pri.html

The information model lists those in a more systematical approach by looking at each manifest element one-by-one. The question for me is whether we will gain from describing the threats in the architecture document again when we have them covered in the information model document. The drawback with the reference to the specific attacks is that often a bundle of techniques are used and you have to read carefully through the write-ups to find the relevant detail.

Ciao
Hannes

From: Fabien BESSIERES <[email-masked]>
Sent: Thursday, September 17, 2020 8:02 PM
To: Hannes Tschofenig <[email-masked]>
Cc: suit <[email-masked]>
Subject: Re: [Suit] Common firmware update flaws

Hi,

Here is my feedback :

Question 1: I believe that the architecture document could include a list of common practices that are insecure.

Question 2: (a) I don't see any problem in adding directly referenced to published flaws.
(b) But yes it should be examples that are fixed with the SUIT manifest
I believe that addressing common mistakes/errors/flaws is one of the goals of the architecture, so it should appear in the document. What do you think ?

Fabien

Le jeu. 17 sept. 2020 à 08:58, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> a écrit :
Hi all,

In his review, Bob Briscoe suggested to list “common practices that are insecure, and perhaps some common misconceptions about secure firmware update” in the SUIT architecture document.

Ciao
Hannes

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
[email-masked]<mailto:[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: Russ Housley <[email-masked]>
Date: Mon, 21 Sep 2020 11:25:57 -0400

Also https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8259A.pdf <https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8259A.pdf>

> On Sep 21, 2020, at 11:10 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Fabien, 
>  
> The most obviously problem, with surfaced with the DDoS attacks by IP connected cameras, was the lack of firmware updates in IoT devices. Bruce Schneier talks about this topic in this blog post https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html <https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html>
> In “IoT Goes Nuclear: Creating a ZigBee Chain Reaction" the authors retrieved a shared symmetric key used by all devices of the same product family to protect the firmware update. Once that key was obtained the researchers were able to update devices with new (malicious) firmware images.
> In http://events.ccc.de/congress/2014/Fahrplan/events/6166.html <http://events.ccc.de/congress/2014/Fahrplan/events/6166.html> an attack against an implementation of the TR69-based firmware update protocol was described. While the described problem is an implementation bug in the HTTP-server running on the gateways, there is the issue with complex supply chains and passing firmware updates along these chains.
> Sometimes firmware updates also change features of a product without the user knowing. Examples include https://boingboing.net/2015/12/14/philips-pushes-lightbulb-firmw.html <https://boingboing.net/2015/12/14/philips-pushes-lightbulb-firmw.html> and https://boingboing.net/2016/09/19/hp-detonates-its-timebomb-pri.html <https://boingboing.net/2016/09/19/hp-detonates-its-timebomb-pri.html>
>  
> From: Fabien BESSIERES <[email-masked] <mailto:[email-masked]>> 
> To: Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>
> Cc: suit <[email-masked] <mailto:[email-masked]>>
> Le jeu. 17 sept. 2020 à 08:58, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> a écrit :
> Hi all,
>  
> Should we include references to published flaws or keep the description abstract?
> Should we include only examples that we later fix with the SUIT manifest? For example, a firmware update can change the nature of a product (e.g. excluding the use of third party printer cartridges).
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/suit <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. _______________________________________________
> Suit mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/suit <https://www.ietf.org/mailman/listinfo/suit>

---

From: Brendan Moran <[email-masked]>
Date: Mon, 21 Sep 2020 16:50:27 +0000

Hi Fabien, Hi Hannes,

A list of common practices that are insecure was originally brought up in the TSVART review of draft-ietf-suit-architecture (https://datatracker.ietf.org/doc/review-ietf-suit-architecture-11-tsvart-lc-briscoe-2020-08-09/). I don’t understand what purpose it serves because this is exactly the point of the information model. Or, more specifically, the threat model that is in the information model. It lists all firmware-update-specific attacks (that we could think of, but it’s pretty exhaustive). I’d rather avoid the duplication caused by adding a threat model to the architecture when there’s already a threat model in the information model.

See below for more.

Best Regards,
Brendan

> On 17 Sep 2020, at 19:01, Fabien BESSIERES <[email-masked]> wrote:
>
> Hi,
>
> Here is my feedback :
>

[BJM]
I don’t understand what purpose this would have. Common insecure practices are well covered already. You can find a full threat model in the companion to the architecture: the information model. (https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/)

This doesn’t exclusively list anti-patterns, but it does list threats, which are intimately related to anti-patterns.

If you would like examples of real-world attacks that exploit insecure practices in IoT devices, we can reference Annex D of the ENISA baseline security requirements for IoT devices. If you would like a list of good practices, we can reference Annex A of the ENISA baseline security requirements for IoT devices.

https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot
[/BJM]

> I believe that addressing common mistakes/errors/flaws is one of the goals of the architecture, so it should appear in the document. What do you think ?

[BJM] as above, I think this is already well-covered. Unless we’ve got something new to add, should we not just reference the information model and the ENISA baseline security requirements for IoT devices?

> Fabien
>
> Le jeu. 17 sept. 2020 à 08:58, Hannes Tschofenig <[email-masked]> a écrit :
> Hi all,
>
>
>
> • Should we include references to published flaws or keep the description abstract?
> • Should we include only examples that we later fix with the SUIT manifest? For example, a firmware update can change the nature of a product (e.g. excluding the use of third party printer cartridges).
>
>

---

From: Fabien BESSIERES <[email-masked]>
Date: Tue, 22 Sep 2020 19:02:18 +0200

Hi,

The information model is a well written document and, indeed, it is already
covering common insecure practice. I agree with Brendan on all points.
Maybe the architecture could include a reference, something like :
"security considerations/threat model are described in
[I-D.ietf-suit-information-model]", this way it could be clearer for the
reader.

Regards,
Fabien

Le lun. 21 sept. 2020 à 18:50, Brendan Moran <[email-masked]> a
écrit :

> Hi Fabien, Hi Hannes,
>
> A list of common practices that are insecure was originally brought up in
> the TSVART review of draft-ietf-suit-architecture (
> https://datatracker.ietf.org/doc/review-ietf-suit-architecture-11-tsvart-lc-briscoe-2020-08-09/).
> I don’t understand what purpose it serves because this is exactly the point
> of the information model. Or, more specifically, the threat model that is
> in the information model. It lists all firmware-update-specific attacks
> (that we could think of, but it’s pretty exhaustive). I’d rather avoid the
> duplication caused by adding a threat model to the architecture when
> there’s already a threat model in the information model.
>
> See below for more.
>
> Best Regards,
> Brendan
>
> > Question 1: I believe that the architecture document could include a
> list of common practices that are insecure.
>
> [BJM]
> I don’t understand what purpose this would have. Common insecure practices
> are well covered already. You can find a full threat model in the companion
> to the architecture: the information model. (
> https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/)
>
> This doesn’t exclusively list anti-patterns, but it does list threats,
> which are intimately related to anti-patterns.
>
> If you would like examples of real-world attacks that exploit insecure
> practices in IoT devices, we can reference Annex D of the ENISA baseline
> security requirements for IoT devices. If you would like a list of good
> practices, we can reference Annex A of the ENISA baseline security
> requirements for IoT devices.
>
>
> > I believe that addressing common mistakes/errors/flaws is one of the
> goals of the architecture, so it should appear in the document. What do you
> think ?
>
> [BJM] as above, I think this is already well-covered. Unless we’ve got
> something new to add, should we not just reference the information model
> and the ENISA baseline security requirements for IoT devices?
>
> > Fabien
> >
> > • Should we include only examples that we later fix with the SUIT