Secondaries should make note of attacks in ECU Manifests

[awwad]

As allowed for in the Implementation Specification (ECUVersionManifestSigned.securityAttack in table 8.1.2a), Secondaries need to report various attacks to the Director via the ECU Manifest sent to the Primary and bundled in the Vehicle Manifest.

It's not clear which events are worth noting and how.

1: How to note events

• We could establish an integer error code in an enumeration in the project __init__.py file and just send a simple integer error code with no details. This has the advantage of being small, but it would also make debugging tougher. This could be done at a high or low level of granularity.
• We could send a detailed error string. Obviously, this should be more minimal in real application, but as part of the reference implementation, it may be best to make this expressive, to help future implementers have something clear to work from.

2: Which events

I'll probably pick a few of these. There are probably others worth note.

• Unable to validate metadata recently (note which file failed? number?).
• Received an older version of a metadata file than what is present
• Timeserver attestation not validated. (There will probably be a lot of these due to timing issues; it doesn't have to succeed every round, and it would probably be noisy. It's also redundant, since the last two validated times are already logged.)
• Target file delivered but did not validate.
• Unable to retrieve target file from Primary

[awwad]

Note that some amount of this, if not all of it, needs to be in the reference implementation.

You could argue that all of this should be external to Uptane (in demo/OEM code), and indeed the decision of what attack string to put in the ECU Manifest could conceivably happen in Uptane-external code and be passed to the reference implementation's secondary.generate_ecu_version_manifest() call, but that information still has to come from Uptane in some form first. Uptane has to throw exceptions that are meaningful enough to be turned into this and then expect demo/OEM code to handle them appropriately. If we go this direction (rather than having the reference implementation itself populate an attack string to put in the ECU Manifest), then I still need to consider this Issue's question and make sure that the exceptions I currently raise are adequate for this purpose.

[JustinCappos]

I agree with your assessment. The exact information / format should be left to the OEM. The things you list seem smart to have in a demo application.

[awwad]

K. So for immediate purposes: generate errors in the reference implementation, but decide on the attack string (securityAttack in table 8.1.2a of the Imp Spec) in the demo.

(In the code, secondary.py:Secondary::generate_ecu_version_manifest() will accept an optional argument description_of_attacks_observed.)

[awwad]

This is now done as of this commit. I assume things will be added and removed eventually, but it should work now.