Subject: [Suit] Manifest details ... was RE: WG Review: Software Updates for Internet of Things (suit)

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 6 Nov 2017 08:13:49 +0000

Hi Carsten, Hi Rajesh,

It is good to see that you guys are looking at the details.

* Wouldn't it be great to indicate conditions (~claims) about when the firmware update should be applied?

For sure. That's why we added this functionality in the manifest draft:
https://tools.ietf.org/html/draft-moran-suit-manifest-00#section-3.3

What is the right encoding of the claims? Hard to say (judging from the discussions) on the list.

* Signature checks are computational expensive.

Yes, here some details:
https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/presentations/session7-vincent.pdf

More work being released soon, as presented at the SAAG meeting @ IETF#98:
https://datatracker.ietf.org/meeting/98/materials/slides-98-saag-eembc-iot-security-benchmarks

An alternative is the use of symmetric key algorithms since there are just some devices that cannot do the public key crypto. There wasn't enough time to prepare the draft before the deadline though but the details are probably fairly obvious.

* Wouldn't it be great to do certificate revocation checks?

Yes, that would be awesome but there are challenges. All solutions, OSCP (for example via the multiple OSCP stapling in TLS),  CRLs, short lived certificates, have pros & cons. One recently emerging story is that there are different types of public keys on the device and that you introduce another layer of indirection so that one can switch from manufacturer provided credentials to shorter-lived operational credentials. You will soon be able to read more about this in a nice IPSO publication on IoT device credential management.

* Co-signing

This topic was discussed at the IoTSU workshop and while theoretically possible that multiple parties sign a firmware image it comes at a cost and for that reason I haven't seen it being used in practice for embedded devices.

* Any idea about the timestamp start, granularity, end?

The timestamp indicates when the manifest was created. There are, however, other (potentially optional) conditions/claims that have time information, such as "Apply After" which indicates that the device should not apply the firmware update prior a specific time/date. Are you talking about this time information?

Ciao
Hannes

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: 04 November 2017 18:16
To: Rajesh Kanungo
Cc: [email-masked]
Subject: Re: [Suit] WG Review: Software Updates for Internet of Things (suit)

> I had a simpler problem:  A device may have 10 public keys.  The firmware update arrives with a signature.   How do you use the right public key to verify the signature?

Both CMS and COSE have key identifiers, so that should be solvable.

> Remember that signature checks on these devices (especially energy limited devices) can have a small but not so insignificant drain.

Right.

Re CRLs:

> Unfortunately turns out to be an issue if the headend gets compromised. Utilities have demanded this mechanism.  We do need to revoke older keys and install new public keys.

Indeed.  A CRL can help you with the former, not with the latter.  Any push mechanism that authorizes a new key can also de-authorize an old one.  (If you want to flood the de-authorization, you just need a signed claim that the compromised key is now de-authorized.)

Re actions around an upgrade:

> The crudest thing is a reference to entries in table of actions.  Fairly language independent.  I said fairly because I can foresee format wars ... your favorite …

Which form would these references take?  Text string?  Byte string?

Grüße, Carsten

_______________________________________________
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.