search

uptane / uptane-standard

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

Device Report - Filename and Hash requirement #177

Closed cwaldren closed 4 years ago

cwaldren commented 4 years ago

5.4.2.1.2. ECU version report:

  • A payload containing: The filename, length, and hashes of its currently installed image (i.e. the non-custom Targets metadata for this particular image)

Why MUST the filename and length of the image be included in the report? That is, why are the hashes not sufficient to uniquely identify the image to the Director?

jhdalek55 commented 4 years ago

Can someone address Casey's question here? Since we at the cut-off point for which issues will be addressed in V.1.1.0, we need to know of there is something here to be resolved. Given the comment of @iramcdonald on issue #174 that any change of a SHALL means a breaking change, if this is undoing a MUST, I believe if it is an issue, it must be held for 2.0..0.

iramcdonald commented 4 years ago

Hi Lois,

I agree that downgrading this MUST (or removing the filename and length fields) is a breaking change and thus any change request goes to v2.0.0.

Casey - I see your point about the hashes, BUT all of the regulatory context (e.g., for mandatory recalls) requires a strong software image identifier and not just a hash. Since short hashes CAN collide, they should not be used by the Director to verify the Manifest from the Primary in the Target Vehicle.

I note that "filename" is a terribly insufficient identifier of a software image version. UNECE WP29 Software Update regulation (in force in January 2021) is much more rigorous. So are all the actual OEM implementations of image repositories that I've seen.

Cheers,

Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted Mobility Solutions WG

Co-Chair - TCG Metadata Access Protocol SG

Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc http://sites.google.com/site/highnorthincmailto: blueroofmusic@gmail.com blueroofmusic@gmail.com(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434

On Mon, Aug 17, 2020 at 11:06 AM Lois Anne DeLong notifications@github.com wrote:

Can someone address Casey's question here? Since we at the cut-off point for which issues will be addressed in V.1.1.0, we need to know of there is something here to be resolved. Given the comment of @iramcdonald https://github.com/iramcdonald on issue #174 https://github.com/uptane/uptane-standard/issues/174 that any change of a SHALL means a breaking change, if this is undoing a MUST, I believe if it is an issue, it must be held for 2.0..0.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/177#issuecomment-674936602, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE33UO5G7W6CY4Y6XJTRHJDSBFBN3ANCNFSM4P73A3EA .

cwaldren commented 4 years ago

Understood. It would be helpful to have the definition of "strong software image identifier" fleshed out somewhere in the standard, as a justification for usage of filename and length. As I read it, it seems the hash + filename + length are in fact used for multiple purposes, which is confusing.

5.4.2.4. Download and verify images

Images SHALL be verified by checking that the hash of the image file matches the hash specified in the Director’s Targets metadata for that image.

5.4.3.4. Verify image

  1. Check that the image filename is valid for this ECU. This MAY be a comparison against a wildcard path, which restricts the ECUs to which a delegation will apply.
  2. Check that the hash of the image matches the hash in the metadata.

The ECU is not using the length in either of these steps; from the ECU's perspective, the potentially weak hash is sufficient for passing validation. But for the Director, we're saying it is not sufficient to uniquely identify the image.

Instead of giving hash + filename + length multiple purposes, I believe a more flexible solution - with potentially stronger security guarantees - would be to add language mandating that the targets metadata include a "strong image identifier".

The primary purpose of this identifier is to be returned to the Director as part of a Device Manifest. The ECU is only required to store it.

For example: 

"firmware_image.bin" {
    "length" : 123,
    "hashes" : {
         "md5" : "f551c8a90b056b872cbcee1d75ed045f",
     }
     "identifier" : "32a9d8e563f5e25b0d10078a5cac3c1791beef69e1b76f235522fa2ff414aff4"
}

The advantages of this type of construction are:

tkfu commented 4 years ago

I think Ira's adequately answered why both hash and length are required. Let me respond to your suggestion about a "strong image identifier":

I believe a more flexible solution - with potentially stronger security guarantees - would be to add language mandating that the targets metadata include a "strong image identifier".

As Ira pointed out, although we say "filename", in practice this can be anything, and is usually quite a lot more rigourous. Exactly what shape that rigour takes is covered by other standards, so I don't think we need to rehash it in Uptane. If you want to use "strong image identifiers", however you choose to define it, there are existing mechanisms to do so in your own implementation. In particular, you could use your image identifier as a filename, or you could include it in custom metadata (note that custom metadata can be added to targets metadata on the repository, ECU version reports, and vehicle version manifests).

  • The ability of the ECU to validate an image is no longer tied to our confidence of what image is installed, from the Director's perspective. The security implications of choosing MD5 here don't "leak" into the Director's report handling logic.

The ECU's ability to validate the image isn't tied to Director's confidence about what image is installed. Uptane doesn't make any prescriptions about how the business logic Director uses to assign images to vehicles should work.

Overall, I think the simplicity and understandability of requiring size and hash for validation wins out. "filename" can be absolutely anything an implementor desires, including something like the "strong image identifier" you propose. Additionally, implementations are free to define specific custom metadata fields, and can require them to be present via a POUF, so anyone who finds this useful can feel free to include it. I don't see a strong case for adding it to the standard and making it mandatory for everyone.

The ECU is not using the length in either of these steps; from the ECU's perspective, the potentially weak hash is sufficient for passing validation. But for the Director, we're saying it is not sufficient to uniquely identify the image.

This part is an oversight; I'd say that clients should indeed verify the hash and size. I'll open an issue for that.

cwaldren commented 4 years ago

Thanks, this is quite helpful. Looking back, most of my confusion was due to reading

An ECU version report is a metadata structure that MUST contain the following information:

as implying that no other information could be included in the report, whereas in reality other information - such as including custom metadata - is left unspecified.

For the usage of the term "filename", I'll admit it didn't occur to me that it could be arbitrary and used by the Director; I was definitely thinking of it in the traditional sense (i.e. name of the artifact produced by a build & release system.) This is from reading Section 5.2.7, which makes example references to FILENAME.EXT and acme_firmware.bin.

Therefore, I think it would be useful to implementors to include language similar to TUF's:


3.1.1 Target files

The filenames and the directory structure of target files available from a repository are not specified by the framework. The names of these files and directories are completely at the discretion of the application using the framework.
iramcdonald commented 4 years ago

Hi Casey,

Thanks. I agree that adding the relevant passage from TUF makes sense.

While I realize that TUF came out of a different universe than automotive software, it's unfortunate, IMO, that TUF never required a strong software identifier. The UNECE Software Update regulation (and ITU-T X.1373) certainly requires a strong software identifier. And conflating that with the traditional use of "filename" introduces ambiguity into Uptane Standard.

Cheers,

Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted Mobility Solutions WG

Co-Chair - TCG Metadata Access Protocol SG

Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc http://sites.google.com/site/highnorthincmailto: blueroofmusic@gmail.com blueroofmusic@gmail.com(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434

On Wed, Aug 19, 2020 at 10:42 PM Casey Waldren notifications@github.com wrote:

Thanks, this is quite helpful. Looking back, most of my confusion was due to reading

An ECU version report is a metadata structure that MUST contain the following information:

as implying that no other information could be included in the report, whereas in reality other information - such as including custom metadata - is left unspecified.

For the usage of the term "filename", I'll admit it didn't occur to me that it could be arbitrary and used by the Director; I was definitely thinking of it in the traditional sense (i.e. name of the artifact produced by a build & release system.) This is from reading Section 5.2.7, which makes example references to FILENAME.EXT and acme_firmware.bin.

Therefore, I think it would be useful to implementors to include language similar to TUF's:

3.1.1 Target files

The filenames and the directory structure of target files available from a repository are not specified by the framework. The names of these files and directories are completely at the discretion of the application using the framework.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/177#issuecomment-676872525, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE33UO222XWDQQQJGUIQMWLSBSEPZANCNFSM4P73A3EA .

jhdalek55 commented 4 years ago

Is this issue to be included in the versioned document to accompany 1.1.0? If so, will this be part of it, or should this be flagged for 2.0.0?

iramcdonald commented 4 years ago

Hi Lois,

If we leave the MUST substantially alone in the Standard (as Jon agreed with my comment), we can add words (if anyone has a good suggestion) to the Deployment Considerations in v1.1.0.

Since there are a number of practical approaches to a "strong software identifier" and no obvious consensus among OEMs and suppliers about the format, I think that Jon's made a good point about not trying to be prescriptive in the Standard or Deployment Considerations.

Cheers,

Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted Mobility Solutions WG

Co-Chair - TCG Metadata Access Protocol SG

Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc http://sites.google.com/site/highnorthincmailto: blueroofmusic@gmail.com blueroofmusic@gmail.com(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434

On Sun, Aug 30, 2020 at 7:21 PM Lois Anne DeLong notifications@github.com wrote:

Is this issue to be included in the versioned document to accompany 1.1.0? If so, will this be part of it, or should this be flagged for 2.0.0?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/177#issuecomment-683484009, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE33UO5S73A42YRVTY3DICDSDLNF5ANCNFSM4P73A3EA .

jhdalek55 commented 4 years ago

Should this be closed now? Or should we re-write this to encompass the "should to must" requirement for V.2.0.0?

tkfu commented 4 years ago

I'm calling it closed. We should open a new issue and tag it for 2.0.0 for the "should -> must" change, to keep things clean.

jhdalek55 commented 4 years ago

Issue #181 now addresses the should to must change for 2.0.0.