search

uptane / uptane-standard

standard for Uptane
https://uptane.github.io
Other
36 stars 30 forks source link

Address update atomicity #5

Closed OYTIS closed 6 years ago

OYTIS commented 6 years ago

There is a gap in the current implementation specification concerning the behaviour when some ECUs fail to update. There is a tradeoff between

a. the necessity to update ECUs transactionally, i.e. either update all of the ECUs or leave all of them on their current versions. b. the threat that a single compromised ECU will deny updates to the whole vehicle.

This problem looks relevant for security and should be addressed in Uptane.

iramcdonald commented 6 years ago

Hi,

Firmware OTA packages MUST contain explicit metadata that includes the order of installation of firmware images on multiple ECUs and the dependencies (i.e., whether or not to restore the previous images for all the Target ECUs or only those in the same "atomic cluster" where the update failed).

Cheers,

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434

On Thu, Sep 27, 2018 at 10:35 AM OYTIS notifications@github.com wrote:

There is a gap in the current implementation specification concerning the behaviour when some ECUs fail to update. There is a tradeoff between

a. the necessity to update ECUs transactionally, i.e. either update all of the ECUs or leave all of them on their current versions. b. the threat that a single compromised ECU will deny updates to the whole vehicle.

This problem looks relevant for security and should be addressed in Uptane,

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/5, or mute the thread https://github.com/notifications/unsubscribe-auth/ATe6O8uTlXBEWMaXv5eezxN8325t5XdHks5ufOJPgaJpZM4W8zkR .

OYTIS commented 6 years ago

The goal of Uptane as far as I understand it is to provide end-to-end security from each ECU to the director/images server. In the current version of Uptane spec firmware images for each ECU are listed individually, and there is no way to specify installation instructions. There are multiple ways how we can address it

iramcdonald commented 6 years ago

Hi,

Uptane (or any other OTA architecture/solution) can only actually communicate directly between the Director (OTA Host Server) and the Primary ECU (OTA Master ECU in the vehicle). Only the Primary ECU (OTA Master ECU ) can forward images for their installation to the one or more affected Secondary ECUs (OTA Target ECUs).

The network end-to-end security (e.g., TLS/1.2) is between the Director (OTA Host Server) and Primary ECU (OTA Master ECU). The metadata accompanying an image for a given Secondary ECU (OTA Target ECU) should include signature(s), priority (e.g., immediate versus "do it now"), dependencies (on other ECU updates). But the Primary ECU should also be receiving a package for multiple Secondary ECUs with signature(s) over that package.

IMO, if Uptane ignores all this real world context, then Uptane won't satisfy the needs of OEMs for flexible OTA solutions.

Cheers,

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434

On Fri, Sep 28, 2018 at 11:25 AM OYTIS notifications@github.com wrote:

The goal of Uptane as far as I understand it is to provide end-to-end security from each ECU to the director/images server. In the current version of Uptane spec firmware images for each ECU are listed individually, and there is no way to specify installation instructions. There are multiple ways how we can address it :

  • Make installation instructions part of the standard and list them explicitly in metadata.
  • Leave space for an opaque installation instruction blobs.
  • Drop support for multiple secondary ECUs whatsoever (hopefully not what we want to do).
  • ...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/5#issuecomment-425472253, or mute the thread https://github.com/notifications/unsubscribe-auth/ATe6OxCaPAcbLrdLuLmWg3yD-pQBOfdDks5ufj95gaJpZM4W8zkR .

JustinCappos commented 6 years ago

There is a custom field of the targets metadata that can be used for opaque instructions like this.

Of course, we will not drop support for multiple secondary ECUs.

On Fri, Sep 28, 2018 at 11:25 AM OYTIS notifications@github.com wrote:

The goal of Uptane as far as I understand it is to provide end-to-end security from each ECU to the director/images server. In the current version of Uptane spec firmware images for each ECU are listed individually, and there is no way to specify installation instructions. There are multiple ways how we can address it :

  • Make installation instructions part of the standard and list them explicitly in metadata.
  • Leave space for an opaque installation instruction blobs.
  • Drop support for multiple secondary ECUs whatsoever (hopefully not what we want to do).
  • ...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/5#issuecomment-425472253, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0XD2SDipaBkrD5rM1zsHK8cR3lmHXMks5ufj94gaJpZM4W8zkR .

OYTIS commented 6 years ago

@iramcdonald Having a full installation package delivered to primary, but also having individual firmware images listed in the metadata so that a secondary can verify them would probably the best alignment with current practices. But again it's not clear how it fits with Uptane's current "One ECU <-> One firmware image".

OYTIS commented 6 years ago

@JustinCappos Sometimes these instructions are as safety/security critical as images themselves, so I would argue it is reasonable to have the same set of Uptane (or at least TUF) checks as for firmware images. Also they can be significantly large binary blobs by themselves. On the other hand they can also be generated in runtime and we can't put them into offline-signed images targets metadata. See also https://github.com/uptane/uptane-standard/issues/4

JustinCappos commented 6 years ago

Right, it's totally possible to have some things that only an online party (director) signs and to scope this in a reasonable way with selective delegations. We will clarify this in the deployment guidelines.

Would you look at that point to tell us if you feel there is something missing?

On Tue, Oct 2, 2018 at 10:08 AM OYTIS notifications@github.com wrote:

@JustinCappos https://github.com/JustinCappos Sometimes these instructions are as safety/security critical as images themselves, so I would argue it is reasonable to have the same set of Uptane (or at least TUF) checks as for firmware images. Also they can be significantly large binary blobs by themselves. On the other hand they can also be generated in runtime and we can't put them into offline-signed images targets metadata. See also #4 https://github.com/uptane/uptane-standard/issues/4

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/5#issuecomment-426287614, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0XD-fdhDb77wEFgUVl7S6sAxIvc2rLks5ug3NcgaJpZM4W8zkR .

OYTIS commented 6 years ago

Sure. Would you consider this issue to be out of scope for the aspiring standard?

JustinCappos commented 6 years ago

No, I don't think it is out of scope. In fact, I think the mechanisms we already have support this use case. My plan is to make it clear in the deployment document how to use those mechanisms to handle this case in a secure and usable manner.

On Tue, Oct 2, 2018 at 11:26 AM OYTIS notifications@github.com wrote:

Sure. Would you consider this issue to be out of scope for the aspiring standard?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/5#issuecomment-426316997, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0XD0plSjfASmHXceclSP0asgeutIrZks5ug4WfgaJpZM4W8zkR .

koshelev commented 6 years ago

@JustinCappos could you please elaborate on how existing mechanisms support the use case?

iramcdonald commented 6 years ago

Hi,

Winding back a bit in this thread, any assumption of one ECU <=> one update image is frequently broken in current practice. In addition to the two different flash blocks update (sometimes for different CPU cores in the same ECU), it's common to have an OEM validated firmware image (binary built by the vendor) and a separate OEM created "calibration" file that sets parameters and tolerances.

Cheers,

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434

On Thu, Oct 11, 2018 at 8:59 AM Vladimir Koshelev notifications@github.com wrote:

@JustinCappos https://github.com/JustinCappos could you please elaborate on how existing mechanisms support the use case?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/5#issuecomment-428945589, or mute the thread https://github.com/notifications/unsubscribe-auth/ATe6O_3MiwzoZgRWk-6JxoEqrezHt_a0ks5uj0C7gaJpZM4W8zkR .

mnm678 commented 6 years ago

@koshelev I'm looking into this now and will respond soon.

mnm678 commented 6 years ago

@koshelev

There are two main issues being discussed here: what to do when some ECUs fail to update, and how to specify installation instructions for individual ECUs. These both have possible solutions within the current mechanisms of the spec.

For the first issue, it is addressed in the spec by use of the director role and version manifest. The director role picks updates to be installed together to limit potential conflicts in versions and can specify an order of installation. In addition, after installation the manifest collects the version on each ECU, signed by that ECU, collected by the primary ECU, and sent to the director. If the director notices an issue, they can decide what to do. When updates need to be done atomically, the director specifies this to the primary ECU. The primary ECU then does the updates, and if one of them fails is able to roll back other parts of the atomic update to ensure everything still works. This is only possible when an atomic update is specified by the director to prevent a rollback attack. The combination of these mechanisms allows the spec to reduce the likelihood of a conflict by specifying an order of installation, and to recover from a failed installation by notifying the OEM. I will add a description of this use case to the deployment considerations early next week and would be happy to get some feedback on those changes.

For specifying installation instructions, there is a custom field in the targets metadata that could be used for this purpose. If the ECU expects instructions in this field, it can be used for a variety of purposes, including containing additional security checks for the ECU. In addition the option for dynamic data (issue 4) would be another solution to this issue as it would provide a place to add installation instructions. I will add a description of this use of the custom field of the targets metadata to the deployment considerations so that it is clear that this is one of the intended use cases for this field.

The discussion around this issue has revealed a few important sub issues. I will plan to open new issues for these separate issues and close this one to help clarify the discussion.

trishankatdatadog commented 6 years ago

There are a very good security reasons why we assumed the normal use case of one image per ECU.

The reasons mostly have to do with: (1) how to handle dependencies and conflicts between multiple images per ECU, let alone between ECUs, and (2) how to handle atomic updates of these dependencies.

A lot of these issues have been discussed in the Deployment Consideration document:

In short, while I agree that multiple images per ECU is an important use case in production, it must be carefully thought out.

cajun-rat commented 6 years ago

The one-image-per-ECU certainly makes things easier, but in nearly every case we've found that real systems have multiple images per ECU. In some of these it would be possible to re-engineer the system to avoid it, but those decisions tended to have already been taken by the time we got on the project.

JustinCappos commented 6 years ago

Right, so we'll definitely give guidance in all cases. Most secure is 1 image per ECU.

On Thu, Oct 11, 2018 at 1:11 PM cajun-rat notifications@github.com wrote:

The one-image-per-ECU certainly makes things easier, but in nearly every case we've found that real systems have multiple images per ECU. In some of these it would be possible to re-engineer the system to avoid it, but those decisions tended to have already been taken by the time we got on the project.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/5#issuecomment-429039798, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0XD-r_d3N6WJDCT9i5i3V-jKUuIIftks5uj3uSgaJpZM4W8zkR .

mnm678 commented 6 years ago

I created a new issue to address custom installation instructions. The links posted by @trishankatdatadog seem to address the ability for atomic updates, so I'm going to close this issue. More discussion about custom instructions can happen in the new issue.