Re: [Suit] draft-ietf-suit-architecture-01

[Brendan Moran <[e-mail]>]

Hi David,

I think there’s insufficiently precise language somewhere in the architecture document. This is absolutely not the intent of the architecture. Locally-initiated rollback is a necessary feature for guaranteeing the reliability of a device.

The specific threat we’re trying to defend against is:

  1.  Device X has firmware A.
  2.  Firmware Authority releases firmware B
  3.  Device X is updated to firmware B
  4.  Malicious actor finds vulnerability in firmware A that is no longer present in firmware B.
  5.  Malicious actor reissues firmware A to device X
  6.  Device X reverts to firmware A
  7.  Malicious actor exploits device using firmware A.

This means that it is dangerous to have any remote triggers for rollbacks without strong guarantees of authenticity.

So, how do we prevent this scenario while providing a lightweight way to trigger an authentic rollback?

I think this is actually an optimisation problem. Is the client smart enough to look for a local copy of a resource before fetching it remotely? Does this need to be addressed in the manifest directly? I haven’t seen a compelling argument for that yet.

Notwithstanding the above, the way to refer to a “built-in” image is to refer to it by uri: file:///, for example. I don’t think there’s a uri namespace for numerically addressed storage (raw flash). I should note that URIs are optional. That is intended for use when a device knows where to look for updates without being told, and behaviour is implementation-defined. An appropriate approach to a manifest that has no URI is to walk through available sources of resources by cost, checking if they have the specified payload (by hash). The lowest cost is the local storage, which would solve this problem, I think.

Does that address the problem?

Thanks,
Brendan


On 3 Jul 2018, at 16:59, David Brown <[e-mail]<mailto:[e-mail]>> wrote:

I had an interesting conversation with someone building a device (a battery powered device, where network traffic is expensive). When they update the firmware, they keep the previous version around, and have an ability to roll back to that version in case there are issues.

I presented the argument that the correct answer is to re-release the older firmware, with a new higher monotonic value. Their counterargument was that this was costly in terms of power, because it requires the image to be resent.

I think the best answer here is to have them issue a new manifest that describes this old image (the one kept around), that has a new monotonic value. That way, only the manifest has to be sent (something has to be sent to tell the device to revert the image anyway). I think this model is covered in our current docs, since we don’t really define how a “built-in” image is referred to.

But, this does make me realize that there are times that things can be spelled out clearly, usually for security reasons, that end up getting disabled due to what someone thinks is a practical reason. I agree that preventing rollback is important for security, but I’ve found myself arguing against these practical cases multiple times.

I wonder if it would be worth writing up a use case to capture this particular revert case, and how that can be addressed with the model we currently have.

David

From: Suit <[e-mail]<mailto:[e-mail]>> on behalf of Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 3, 2018 at 8:59 AM
To: Denis <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Suit] draft-ietf-suit-architecture-01

Hi Denis,

I think the risk of installing an old firmware version is covered in the information model document, which goes into the details of what a manifest has to contain. See Section 3.2.1 of https://tools.ietf.org/html/draft-ietf-suit-information-model-01

There are essentially three types of documents the working group is aiming to produce: an architecture document, the information model for the manifest and one or multiple serialization formats. You have been looking at the architecture but the appropriate document to read is the information model spec.

Ciao
Hannes

From: Suit [mailto:[e-mail]] On Behalf Of Denis
Sent: 03 July 2018 11:59
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [Suit] draft-ietf-suit-architecture-01

Hannes,

It is well known that software updates are often done to address a security issue. The same applies
to firmware updates. The current draft is lacking to address protections against the downloading of
an old firmware version. The threat should be mentioned in the security considerations section.

The main body of the document should mention mechanisms to prevent the replay of an old version
of the firmware.

Denis


Hi all,

I have just submitted version -01 of the architecture document. I have incorporate feedback from the working group, such as

  *   New terminology,
  *   Updates on the operating modes
  *   New architecture figures,
  *   New use cases (by David Brown)


Here is the new version:
https://tools.ietf.org/html/draft-ietf-suit-architecture-01

Here is the diff:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-suit-architecture-01.txt

Feedback is appreciated.

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

[e-mail]<mailto:[e-mail]>

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