search

uptane / uptane-standard

standard for Uptane
https://uptane.github.io
Other
37 stars 31 forks source link

Securely requesting user consent to apply updates that must go through the cloud #206

Closed jhdalek55 closed 3 years ago

jhdalek55 commented 3 years ago

The following issue was brought to us from the field and it deals with an area that, to my knowledge, has not been discussed in the light of Uptane so far--utilization of mobile devices, and interacting with the cloud, to install update. '

The theoretical scenario is as follows:

A vehicle determines that an update is available and downloads the necessary images. Before they can be installed, the vehicle owner must approve the update. To do so, the owner uses an app running on a mobile device that connects to the supplier's cloud, and not directly to the vehicle. At a high level these are the messages sent:

Vehicle --> Cloud --> Mobile: update ready Mobile --> Cloud --> Vehicle: update approved by user

This provides an opening for an attacker with the ability to deny or spoof these messages, and in turn, deny updates to the vehicle.

How can this vulnerability be defended?

tkfu commented 3 years ago

This is out of scope for Uptane. The guarantee we make for freeze attacks (denial of updates) is only that they are detectable in the face of a MITM, not that they're fully preventable. (Because of course you can trivially deny updates by blocking all network communication.) Freeze attacks are detectable on the vehicle side via metadata expiry; if the vehicle's metadata is expired and it can't get any non-expired valid metadata, you can display that information to the user. They're detectable on the server side via the vehicle manifest, which contains a signed ECU version report from each ECU. (Of course, if keys are compromised, these can be forged.)

So, moving on to the topic of user consent and how it interacts with potential freeze attacks.

Broadly speaking, you can implement user consent in one of two ways. The first, which is assumed here, is to have the consent process happen after the vehicle has already been directed to install the update. If you do it this way, consent is effectively an installation step, albeit one that can hold up the installation for days, weeks, or months. No Uptane guarantees are violated here, because you will still get an accurate vehicle manifest. If your manifest/ECU version report includes some kind of installation status field, you could use it to indicate "waiting for consent".

The second is to ask for consent before the update is downloaded, so the vehicle only gets directed to install the update after the user has consented to the installation. Here too, no Uptane guarantees are violated; the process by which the director chooses to assign updates is specifically out of scope of the standard as per 5.3.2.1 step 5:

The Director [...] determines if the vehicle is already up-to-date, and if not, determines a set of images that should be installed. The exact process by which this determination takes place is out of scope of this Standard.

Basically, if you consider this a vulnerability, it boils down to "how can I establish a cryptographically secure communication channel with a human being?" (or possibly "how can I ensure that my customer's smartphones haven't been compromised?"). Those are extremely difficult problems to solve in the general case, and Uptane doesn't try to solve them.

tkfu commented 3 years ago

Closing this as out of scope. Can be reopened if anyone wants to discuss further whether we should be addressing this is some future release or in the deployment considerations, but I'd argue pretty strongly that this isn't something we want to get into specifying--it increases the moving parts in the system way too much, and can be addressed in other ways and by general best practices.