Subject: [Suit] Towards building a secure software update standard for IoT

From: Trishank Karthik Kuppusamy <[email-masked]>
Date: Wed, 8 Nov 2017 00:03:01 -0500

Hello everyone,

I'm a Ph.D. graduate from NYU Tandon who worked on The Update Framework
(TUF) <https://theupdateframework.github.io/>, an open security standard
for building compromise-resilient software repositories. The Linux
Foundation recently named
<https://www.cncf.io/announcement/2017/10/24/cncf-host-two-security-projects-notary-tuf-specification/>
TUF as one of two new security projects hosted by its Cloud Native
Computing Foundation. TUF is being used in production by LEAP
<https://leap.se/en/2014/darkest-night>, VMware, Flynn
<https://flynn.io/docs/development#the-update-framework-%28tuf%29>, Kolide
<https://github.com/kolide/updater>, DigitalOcean
<https://github.com/digitalocean/do-agent/blob/1171266a8c5de9598a0d4b9e9967aeb5bf7df76b/vendor/vendor.json#L27-L51>,
Cloudflare
<https://blog.cloudflare.com/pal-a-container-identity-bootstrapping-tool/>,
CoreOS, and Docker
<https://blog.docker.com/2015/08/content-trust-docker-1-8/>.

I write to this group because I think the design principles behind TUF may
also be useful to secure software updates for IoT. The problem with two
common off-the-shelf systems used to transport updates from repositories
--- or servers used to host and distribute updates --- to devices is that
they are not compromise-resilient
<https://www.usenix.org/conference/nsdi16/technical-sessions/presentation/kuppusamy>
.

The first system, where repositories uses an encrypted transport mechanism
such as SSL / TLS, protects devices from man-in-the-middle attacks.
However, it does not protect devices when the repository itself has been
compromised, because attackers can use the same online SSL / TLS key to
sign and distribute malicious updates. This is true even if the private key
is protected behind a Hardware Security Module (HSM), because the point is
that attackers can use the HSM to sign malicious updates, even without
access to the private key itself.

In order to protect updates at rest, the second system uses an offline key,
typically using GPG or RSA, to sign all updates. Unfortunately, this system
usually suffers from problems with key revocation, or signing for new
metadata about updates on-demand.

TUF uses several design principles
<https://justinsamuel.com/papers/survivable-key-compromise-ccs2010.pdf> to
protect users as much as possible from installing malicious updates, even
if the repository used to serve those updates itself has been compromised:

   1. *Separation of duties*: different types of metadata are signed by
   different roles using different keys, so that a key compromise does not
   necessarily impact the security of the whole system.
   2. *Threshold signatures*: *m* out of *n* signatures may be required to
   sign an update, so that this minimum number of keys must be compromised in
   order to sign malware.
   3. *Implicit and explicit key revocation*: there must be ways to revoke
   and replace keys, because they may be lost or compromised.
   4. *Minimizing risk with offline keys*: metadata may be signed using
   signing keys kept off the repository, so that a repository compromise does
   not immediately result in signed malware.
   5. *Selective delegation of trust*: different developers may be trusted
   to sign for only a subset of updates, so that a developer key compromise
   does not affect all devices. Delegations are also useful for distributing,
   revoking, and replacing public keys belonging to developers.
   6. *Diversity of signing and hashing algorithms*: using multiple
   algorithms allows for surviving a compromise of one of them.

Uptane <https://uptane.github.io/> is a variant of TUF which is especially
designed for automobiles. It allows vehicle manufactures to customize which
updates are installed on which vehicles without compromising security. It
is being integrated by at least three automotive suppliers, including Advanced
Telematic Systems
<https://www.prnewswire.com/news-releases/ats-is-integrating-the-uptane-security-framework-for-over-the-air-software-updates-to-connected-vehicles-628170073.html>,
Lear Corporation, and OTAinfo
<https://www.crunchbase.com/organization/otainfo>.

The research group at NYU and I feel that many of the design principles
behind Uptane may be used in the IoT domain, as they appear to be share
some of the same requirements. Despite offering high security, Uptane is
flexible enough to accommodate a wide variety of deployment configurations.
For example, Uptane is agnostic to the precise data encoding format used to
describe metadata, so that ASN.1, CBOR, or XML may be used by different
implementors.

More information about TUF is available at:
https://www.theupdateframework.com/

More information about Uptane, a variant of TUF for automobiles, is
available at: https://uptane.github.io/

My thesis on TUF and Uptane is availabe at:
https://drive.google.com/file/d/0B5-9MEQ0SQN2SjdmdUxueThQNmM/view?usp=sharing

We hope to collaborate with you on designing a secure yet flexible software
update standard for IoT. In particular, we are interested in learning about
unique challenges in this domain that pertain to software updates. We look
forward to hearing from you!

With best regards,
Trishank

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Nov 2017 10:26:32 -0500

Trishank Karthik Kuppusamy <[email-masked]> wrote:
    > (TUF), an open security standard for building compromise-resilient

Awesome, so happy to have you join the discussion!

    > Uptane is a variant of TUF which is especially designed for
    > automobiles. It allows vehicle manufactures to customize which updates
    > are installed on which vehicles without compromising security. It is
    > being integrated by at least three automotive suppliers, including
    > Advanced Telematic Systems, Lear Corporation, and OTAinfo.

Can you tell us a bit about how uptane indicates which vehicles should apply
the update?  Can it get down to a single vehicle?  If so, are there any
privacy protections involved?

    > some of the same requirements. Despite offering high security, Uptane
    > is flexible enough to accommodate a wide variety of deployment
    > configurations. For example, Uptane is agnostic to the precise data
    > encoding format used to describe metadata, so that ASN.1, CBOR, or XML
    > may be used by different implementors.

Very interesting.

I'm reading your github source code.

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

---

From: Brendan Moran <[email-masked]>
Date: Fri, 10 Nov 2017 21:25:21 +0000

Hi Trishank,

On 8 Nov 2017, at 05:03, Trishank Karthik Kuppusamy <[email-masked]<mailto:[email-masked]>> wrote:

Hello everyone,

I'm a Ph.D. graduate from NYU Tandon who worked on The Update Framework (TUF)<https://theupdateframework.github.io/>, an open security standard for building compromise-resilient software repositories. The Linux Foundation recently named<https://www.cncf.io/announcement/2017/10/24/cncf-host-two-security-projects-notary-tuf-specification/> TUF as one of two new security projects hosted by its Cloud Native Computing Foundation. TUF is being used in production by LEAP<https://leap.se/en/2014/darkest-night>, VMware, Flynn<https://flynn.io/docs/development#the-update-framework-%28tuf%29>, Kolide<https://github.com/kolide/updater>, DigitalOcean<https://github.com/digitalocean/do-agent/blob/1171266a8c5de9598a0d4b9e9967aeb5bf7df76b/vendor/vendor.json#L27-L51>, Cloudflare<https://blog.cloudflare.com/pal-a-container-identity-bootstrapping-tool/>, CoreOS, and Docker<https://blog.docker.com/2015/08/content-trust-docker-1-8/>.

I write to this group because I think the design principles behind TUF may also be useful to secure software updates for IoT. The problem with two common off-the-shelf systems used to transport updates from repositories --- or servers used to host and distribute updates --- to devices is that they are not compromise-resilient<https://www.usenix.org/conference/nsdi16/technical-sessions/presentation/kuppusamy>.

We are glad to have your input!

The first system, where repositories uses an encrypted transport mechanism such as SSL / TLS, protects devices from man-in-the-middle attacks. However, it does not protect devices when the repository itself has been compromised, because attackers can use the same online SSL / TLS key to sign and distribute malicious updates. This is true even if the private key is protected behind a Hardware Security Module (HSM), because the point is that attackers can use the HSM to sign malicious updates, even without access to the private key itself.

I agree. This is why draft-moran-suit-manifest-00 defines an end-to-end security relationship between an update authority (e.g. the OEM) and the target IoT device. This relationship is functionally equivalent to the relationship defined in TUF’s root.json, but it is not as formalised, since IoT device have many different ways of specifying a root key.

In order to protect updates at rest, the second system uses an offline key, typically using GPG or RSA, to sign all updates. Unfortunately, this system usually suffers from problems with key revocation, or signing for new metadata about updates on-demand.

TUF uses several design principles<https://justinsamuel.com/papers/survivable-key-compromise-ccs2010.pdf> to protect users as much as possible from installing malicious updates, even if the repository used to serve those updates itself has been compromised:

  1.  Separation of duties: different types of metadata are signed by different roles using different keys, so that a key compromise does not necessarily impact the security of the whole system.
  2.  Threshold signatures: m out of n signatures may be required to sign an update, so that this minimum number of keys must be compromised in order to sign malware.
  3.  Implicit and explicit key revocation: there must be ways to revoke and replace keys, because they may be lost or compromised.
  4.  Minimizing risk with offline keys: metadata may be signed using signing keys kept off the repository, so that a repository compromise does not immediately result in signed malware.
  5.  Selective delegation of trust: different developers may be trusted to sign for only a subset of updates, so that a developer key compromise does not affect all devices. Delegations are also useful for distributing, revoking, and replacing public keys belonging to developers.
  6.  Diversity of signing and hashing algorithms: using multiple algorithms allows for surviving a compromise of one of them.

Most of these concepts are already covered in draft-moran-suit-manifest-00. We have not explicitly laid out Threshold signatures, nor diversity of signing and hashing algorithms, though there is nothing in draft-moran-suit-manifest-00 that should prevent either of these concepts from working. On constrained devices, diversity of cryptographic primitives is a difficult tradeoff since cryptographic algorithms, particularly asymmetric ones, consume a lot of code space.

We explicitly leave key revocation out of scope. Because we don’t define key provisioning mechanisms, this is a problem that is not solved in draft-moran-suit-manifest-00. Since IoT platforms are so disparate in nature, it is difficult to prescribe the handling of keys, since any specified mechanism may not be practical for a given application.

Uptane<https://uptane.github.io/> is a variant of TUF which is especially designed for automobiles. It allows vehicle manufactures to customize which updates are installed on which vehicles without compromising security. It is being integrated by at least three automotive suppliers, including Advanced Telematic Systems<https://www.prnewswire.com/news-releases/ats-is-integrating-the-uptane-security-framework-for-over-the-air-software-updates-to-connected-vehicles-628170073.html>, Lear Corporation, and OTAinfo<https://www.crunchbase.com/organization/otainfo>.

The research group at NYU and I feel that many of the design principles behind Uptane may be used in the IoT domain, as they appear to be share some of the same requirements. Despite offering high security, Uptane is flexible enough to accommodate a wide variety of deployment configurations. For example, Uptane is agnostic to the precise data encoding format used to describe metadata, so that ASN.1, CBOR, or XML may be used by different implementors.

I agree. I think there is a lot of overlap between our two approaches and there is likely a lot of collaboration we can do.

More information about TUF is available at: https://www.theupdateframework.com/

More information about Uptane, a variant of TUF for automobiles, is available at: https://uptane.github.io/

My thesis on TUF and Uptane is availabe at: https://drive.google.com/file/d/0B5-9MEQ0SQN2SjdmdUxueThQNmM/view?usp=sharing

We hope to collaborate with you on designing a secure yet flexible software update standard for IoT. In particular, we are interested in learning about unique challenges in this domain that pertain to software updates. We look forward to hearing from you!

I think that TUF and Suit cover many of the same goals. I think that our threat models are largely compatible; I’ve just finished sending out the threat model that we used for the suit manifest draft. I fully anticipate that you could construct a TUF endpoint using the Suit manifest.

By the way it is written, I think it is fair to say that TUF is largely aimed at high-bandwidth networks and homogenous thick clients, particularly with human interface. Uptane deals with many of these issues. The problem is different in the IoT space. For example, TUF says:

> 1.8. Check for a freeze attack.
> The latest known time should be lower than the expiration timestamp in the trusted root metadata file.

An IoT device may not know the time or, if it does, the time may be considered suspect unless a secure time source is available (and indeed this is the solution that Uptane seems to recommend). That creates a new trust relationship that must also be managed. This is far more problematic on an IoT device, since a user would typically not have time set wrong by more than a few hours, which are mostly irrelevant in key rotation schedules. In IoT devices without realtime clocks, they must obtain a trusted time at each power-on for any implicit key revocation, or freeze attack detection to work.

TUF doesn’t specify any way to perform matching of target hardware, but Uptane handles this in the Custom block of Targets.

TUF’s specification requires the existence of a filesystem, however I’m sure you could construct a reasonable TUF endpoint while ignoring this. TUF also specifies a signature verification overhead that is problematic for IoT. Based on the TUF update process outlined here: https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#5-detailed-workflows, I count a minimum of 3 signature verifications for a first-time update:

T * (N + 3) signature verifications

Where:
* there are N intermediate root metadata files,
* there is 1 timestamp file
* there is 1 snapshot file
* there is 1 targets file
* a threshold of T signatures are needed (I’m assuming it’s the same for all files, but this may not be the case)

Even with a relatively modest number of root metadata files, and a small number for T, this could consume a significant quantity of a battery-powered device’s lifetime power budget.

One other consideration for IoT devices is that writing to flash is an expensive operation. This means that it should be limited, particularly when a device may be under attack. This is why we specify metadata that can easily fit in RAM, with no attached payload. This allows signature verification prior to storage on constrained devices.

The tiered metadata approach in TUF is interesting. Previously, I had considered the device-side “policies” of how to apply updates (such as how many signatures to require) to be a firmware problem, but it could be done with signed metadata as well. I think that for the most constrained clients, leaving policies in firmware is likely the best choice, still.

Best Regards,
Brendan
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: Carsten Bormann <[email-masked]>
Date: Sat, 11 Nov 2017 05:43:11 +0800

At the HRPC RG meeting on Friday, there will be talk on Chainiac [1].

I think there is a lot we can learn from the ongoing academic work on software updating.
We do need to find a translation of these principles to the IoT, though, and Brendan has started pointing out some technical considerations.  There may also be differences in the kinds of stakeholders involved which lead to different security workflows.

For SUIT, we may want to layer the approach a bit so we can separate properties of the software update itself from the signed claims we need about (1) its provenance and (2) its appropriateness for installation at the specific device targeted.

Grüße, Carsten

[1]: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/nikitin

---

From: Justin Cappos <[email-masked]>
Date: Fri, 10 Nov 2017 17:55:47 -0500

Good to hear about this!  I'm an author on Chainiac as well as being the
BDFL for TUF.

We're happy to help however we can (join a call, Skype, answer questions
via email, etc.)...

Thanks,
Justin

On Fri, Nov 10, 2017 at 4:43 PM, Carsten Bormann <[email-masked]> wrote:

> We do need to find a translation of these principles to the IoT, though,
> and Brendan has started pointing out some technical considerations.  There
> may also be differences in the kinds of stakeholders involved which lead to
> different security workflows.
>
> For SUIT, we may want to layer the approach a bit so we can separate
> properties of the software update itself from the signed claims we need
> about (1) its provenance and (2) its appropriateness for installation at
> the specific device targeted.
>
> Grüße, Carsten
>

---

From: "David A. Wheeler" <[email-masked]>
Date: Sat, 11 Nov 2017 10:13:36 -0500

>By the way it is written, I think it is fair to say that TUF is largely
>aimed at high-bandwidth networks and homogenous thick clients,
>particularly with human interface. Uptane deals with many of these
>issues. The problem is different in the IoT space...

I think the suit spec should specifically note TUF and uptane, and do a quick comparison of the differences and rationales for them. Many people will want to know the difference is, and why. Making the relationship clear would really help.

--- David A.Wheeler

---

From: Trishank Karthik Kuppusamy <[email-masked]>
Date: Mon, 20 Nov 2017 00:46:55 -0500

Hello Michael,

> Awesome, so happy to have you join the discussion!

Thanks! Sorry for the late reply, I have been OOO...

> privacy protections involved?

In Uptane, a server called the *director repository* is used to indicate
which ECUs on a vehicle installs which updates. You can think of the
director repository as a robot running on the cloud, performing dependency
resolution on behalf of vehicles.

Yes, customization can get down to a single vehicle: two different vehicles
of the same make and model can be instructed to install different updates
(e.g., because one has paid for premium packages, whereas the other has
not).

Could you elaborate on what sort of privacy protections you would need? It
is possible, for example, to use TLS to protect sensitive information from
MitM attacks.

> I'm reading your github source code.

Please let us know if you have questions. Thanks!

---

From: Trishank Karthik Kuppusamy <[email-masked]>
Date: Mon, 20 Nov 2017 01:22:59 -0500

Hello Brendan,

> We are glad to have your input!

Thanks for your feedback! Please accept my apologies for the late reply. I
have been OOO...

> Most of these concepts are already covered in
> draft-moran-suit-manifest-00. We have not explicitly laid out Threshold
> signatures, nor diversity of signing and hashing algorithms, though there
> is nothing in draft-moran-suit-manifest-00 that should prevent either of
> these concepts from working. On constrained devices, diversity of
> cryptographic primitives is a difficult tradeoff since cryptographic
> algorithms, particularly asymmetric ones, consume a lot of code space.
>

Understood. For constrained devices, is there a notion of using a
per-device symmetric key
<https://docs.google.com/document/d/17wOs-T7mugwte5_Dt-KLGMsp-3_yAARejpFmrAMefSE/edit#heading=h.u7thrpsnvihd>
?

We explicitly leave key revocation out of scope. Because we don’t define
> key provisioning mechanisms, this is a problem that is not solved in
> draft-moran-suit-manifest-00. Since IoT platforms are so disparate in
> nature, it is difficult to prescribe the handling of keys, since any
> specified mechanism may not be practical for a given application.
>

Interesting. Do you think we could make a few optional recommendations, for
those who are interested in guidance?

> I think that TUF and Suit cover many of the same goals. I think that our
> threat models are largely compatible; I’ve just finished sending out the
> threat model that we used for the suit manifest draft. I fully anticipate
> that you could construct a TUF endpoint using the Suit manifest.
>

Very good to know!

> aimed at high-bandwidth networks and homogenous thick clients, particularly
> with human interface. Uptane deals with many of these issues. The problem
> is different in the IoT space. For example, TUF says:
>

I am not yet fully aware of all of the differences in the IoT space, which
is why I reached out to this group, and I am confident that we can resolve
them.

An IoT device may not know the time or, if it does, the time may be
> considered suspect unless a secure time source is available (and indeed
> this is the solution that Uptane seems to recommend). That creates a new
> trust relationship that must also be managed. This is far more problematic
> on an IoT device, since a user would typically not have time set wrong by
> more than a few hours, which are mostly irrelevant in key rotation
> schedules. In IoT devices without realtime clocks, they must obtain a
> trusted time at each power-on for any implicit key revocation, or freeze
> attack detection to work.
>

Yes, and we need not make a rigid prescription for this time server.
Implementors may be free to use an external time server (e.g., NTP;
something like the one in Uptane; Google Roughtime), or they may obtain a
trusted time some other way (e.g., on system).

> TUF doesn’t specify any way to perform matching of target hardware, but
> Uptane handles this in the Custom block of Targets.
>

Correct. In fact, Uptane inherits this Custom block of Targets from TUF,
and use it to match images to hardware.

TUF’s specification requires the existence of a filesystem, however I’m
> sure you could construct a reasonable TUF endpoint while ignoring this. TUF
> also specifies a signature verification overhead that is problematic for
> IoT. Based on the TUF update process outlined here: https://github.com/
> theupdateframework/specification/blob/master/tuf-
> spec.md#5-detailed-workflows, I count a minimum of 3 signature
> verifications for a first-time update:
>

Yes, the TUF and Uptane specifications are written from the point of view
of filesystems, although, as you noted, this assumption is not required
<https://docs.google.com/document/d/17wOs-T7mugwte5_Dt-KLGMsp-3_yAARejpFmrAMefSE/edit#heading=h.7dcdmry3p23d>.
The important point is that different metadata "files" are located in
different locations / addresses (which may be strings or even numbers, as
long as they are unique).

As for the number of signatures, my comment follows.

> Even with a relatively modest number of root metadata files, and a small
> number for T, this could consume a significant quantity of a
> battery-powered device’s lifetime power budget.
>

You are right that for a first-time update, this could be the case.
However, there are a few important observations.

First, T is not the same for all files. For most cases, it could be set to
1.

Second, N may not necessarily be large. Since the root metadata file is not
expected to be frequently updated, it can be safely refreshed every year or
so (unless there has been a compromise).

Thus, a typical update is likely to refresh at most 3 files: timestamp,
snapshot, and targets. However, we should certainly discuss common
configurations of roles to see how large metadata may be.

> One other consideration for IoT devices is that writing to flash is an
> expensive operation. This means that it should be limited, particularly
> when a device may be under attack. This is why we specify metadata that can
> easily fit in RAM, with no attached payload. This allows signature
> verification prior to storage on constrained devices.
>

Indeed. We discuss in Uptane how to reduce writing unnecessary metadata to
flash
<https://docs.google.com/document/d/17wOs-T7mugwte5_Dt-KLGMsp-3_yAARejpFmrAMefSE/edit#heading=h.r1qemrp7yi77>.
It is necessary to cache some metadata, such as version numbers and keys.

> The tiered metadata approach in TUF is interesting. Previously, I had
> considered the device-side “policies” of how to apply updates (such as how
> many signatures to require) to be a firmware problem, but it could be done
> with signed metadata as well. I think that for the most constrained
> clients, leaving policies in firmware is likely the best choice, still.
>

Certainly we should be able to accommodate both approaches.

I look forward to our continued collaboration. Please let us know if you
have more questions!

Best regards,
Trishank

---

From: Trishank Karthik Kuppusamy <[email-masked]>
Date: Mon, 20 Nov 2017 01:24:18 -0500

Hello David,

On Sat, Nov 11, 2017 at 10:13 AM, David A. Wheeler <[email-masked]>
wrote:

>
> I think the suit spec should specifically note TUF and uptane, and do a
> quick comparison of the differences and rationales for them. Many people
> will want to know the difference is, and why. Making the relationship clear
> would really help.
>

I would be happy to help with this effort. Please let me know how I may
contribute.

Best,
Trishank

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 Nov 2017 12:41:10 +0100

(Cleaning up the CCs a bit.)

> On Nov 20, 2017, at 07:22, Trishank Karthik Kuppusamy <[email-masked]> wrote:
> 
> Understood. For constrained devices, is there a notion of using a per-device symmetric key?

Certainly, and for many devices this is a good way to obtain good security while using limited resources.

However, this is not the right way to secure all deployments.

The most important question is: Who holds the other copy of the symmetric key?

* The manufacturer?

Some manufacturers don’t want to have liability for being able to control the devices.
Some very much do want full control, but rather prefer to secure a chain of asymmetric keys instead of a large number of symmetric keys.
(In any case, the asymmetric key will then be used to agree a symmetric key, and unless the device has lots of energy, one may not want to do this very often.  So the manufacturer will often still have to store symmetric keys, but these can then be limited in lifetime and dumped in an emergency.)

* The owner?

Many users are not set up for securely storing keys of this kind.
If the key is stored in a smartphone or general purpose computer, that may get lost or damaged.
Unless special software such as a password manager is used, there is also a good likelihood of key compromise.

In case of loss (or compromise), there needs to be a key replacement mechanism.

If physical access to the device is reasonably easy, and also can be limited to the owner (in multi-tenant situations it usually can’t), key replacement can be achieved by a physical connection or by printing a key recovery password on a part of the device that is not visible to an attacker.

(E.g., IKEA prints a representation of the key itself on each Trådfri gateway.  A better way might be to print a password that can be used for setting a new key.)

* What about others?

None of this discusses the need for delegation — the owner may be a company that needs to delegate authorization to employees and contractors.  This can be done by giving them symmetric keys with specific authorizations attached (tickets), or tokens that can be checked by the device with its authorization manager (for which the device may use a symmetric key with the authorization manager, possibly using this key in an offline validation of the token).

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Nov 2017 08:59:27 -0500

Trishank Karthik Kuppusamy <[email-masked]> wrote:
    > Could you elaborate on what sort of privacy protections you would
    > need? It is possible, for example, to use TLS to protect sensitive
    > information from MitM attacks.

While TLS gives us privacy in transit, it does not necessarily provide
privacy at rest.  For instance, imagine the need to carry the firmware update
From vehicle to vehicle on a USB key:  a firmware update that causes recall
requiring an update at the garage.  (Maybe due to a vulnerability in the
online update mechanism!).

Such a key could easily get misplaced or the contents could become table.

Such a firmware update might contain a list of vehicles to which the update
applies.   It would be bad if the list of VINs or EUI-48/64s that that will
accept the update was easily visible from the firmware contents.
At the same time, there is the hassle of finding out what's really on the
(usb) key! ("Do we still need this one? Is the software on it up to date?")

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Nov 2017 09:21:02 -0500

> Such a key could easily get misplaced or the contents could become

ENOTENOUGHCOFFEE.  Should read "become public"
(Not a typo or an autocorrect)

    > (usb) key! ("Do we still need this one? Is the software on it up to

There are ways in which I can see making the list unreadable and yet each
vehicle can be named, but it probably doesn't simultaenously work for the
"legitimate" query of what's on this key.

---

From: Trishank Karthik Kuppusamy <[email-masked]>
Date: Tue, 21 Nov 2017 21:13:06 -0500

Hello Carsten,

On Mon, Nov 20, 2017 at 6:41 AM, Carsten Bormann <[email-masked]> wrote:

> Some very much do want full control, but rather prefer to secure a chain
> of asymmetric keys instead of a large number of symmetric keys.
> (In any case, the asymmetric key will then be used to agree a symmetric
> key, and unless the device has lots of energy, one may not want to do this
> very often.  So the manufacturer will often still have to store symmetric
> keys, but these can then be limited in lifetime and dumped in an emergency.)
>
> * The owner?
>
> If physical access to the device is reasonably easy, and also can be
> limited to the owner (in multi-tenant situations it usually can’t), key
> replacement can be achieved by a physical connection or by printing a key
> recovery password on a part of the device that is not visible to an
> attacker.
>
> (E.g., IKEA prints a representation of the key itself on each Trådfri
> gateway.  A better way might be to print a password that can be used for
> setting a new key.)
>
> * What about others?
>
> None of this discusses the need for delegation — the owner may be a
> company that needs to delegate authorization to employees and contractors.
> This can be done by giving them symmetric keys with specific authorizations
> attached (tickets), or tokens that can be checked by the device with its
> authorization manager (for which the device may use a symmetric key with
> the authorization manager, possibly using this key in an offline validation
> of the token).
>
>
Thanks for your detailed reply!

I don't have much to say here, except to note that my only concern is what
happens when this symmetric key is compromised. Can it be used to
impersonate an OEM and / or an end-device? This is something to think about
when designing any compromise-resilient update mechanism, and recovering
from a key compromise.

Best regards,
Trishank

---

From: Trishank Karthik Kuppusamy <[email-masked]>
Date: Tue, 21 Nov 2017 21:46:32 -0500

> (usb) key! ("Do we still need this one? Is the software on it up to date?")

Yes, I think you're right, there are ways to solve this problem (e.g.,
end-to-end encryption) without hampering with software update security.

Regards,
Trishank