Device Report - Filename and Hash requirement
Closed this issue · 11 comments
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?
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.
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
- 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.
- 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:
- 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 Director may freely change the identifier algorithm without affecting, or restricting which ECUs can receive it
- The Director no longer requires the ECU to store potentially redundant information; it just needs to store the identifier and pass it back when requested.
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.
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.
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?
Should this be closed now? Or should we re-write this to encompass the "should to must" requirement for V.2.0.0?
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.