Clarifying the ECU keys

[jhdalek55]

In addressing a few of the issues raised by closed Standard Issue #174 and newly opened Standard issue #241, it became clear that we need to do a better job in the Deployment Best Practices section in explaining the different types of keys. The existing text, found at https://github.com/uptane/deployment-considerations/blob/master/key_management.md#repository-keys is perhaps not as comprehensive or clear as it should be.

[jhdalek55]

At the 11/22 meeting, we labeled this issue as a priority to address as it is still causing confusion.

[jhdalek55]

Seeking a volunteer to edit/revise this text, or failing that some input as to what this section should be saying. I'll write it if I know what to say.

[jhdalek55]

Again asking for a volunteer to write this PR, or at the very least to highlight the main points that should be part of it.

[trishankatdatadog]

Sorry, I'm not aware of what the precise issues raised were, but happy to review any proposed text!

[jhdalek55]

Particularly look at the subsection in deployment on Key management .

[hexsecs]

Here is the current text. We should be more specific about what ECU keys we are talking about.

ECU keys

If ECU keys are compromised, then the OEM SHOULD manually update vehicles to replace these keys. This is the safest course of action because, after a key compromise, an OEM cannot be sure whether it is remotely replacing keys controlled by attackers or the intended ECUs.

An OEM MAY use the Director repository and its inventory database to infer whether ECU keys have been compromised. This database is used to record vehicle version manifests that list what images an ECU has installed over time. Therefore, an OEM MAY check for any abnormal patterns of installation that could have been caused by an ECU key compromise. Note, however, that this method is not perfect, because if attackers control ECU keys, then they can also use these keys to send fraudulent ECU version reports.

[hexsecs]

The uptane standard states: https://uptane.github.io/papers/uptane-standard.2.0.0.html#build-time-prerequisite-requirements-for-ecus

"An ECU signing key. This is a private key, unique to the ECU, used to sign ECU version reports and decrypt images. An ECU key can be either a symmetric key or an asymmetric key. If it is an asymmetric key, there SHOULD be separate keys for encryption and signing. For the purposes of this Standard, the set of private keys that an ECU uses is referred to as the ECU key (singular), even if it is actually multiple keys used for different purposes."

In my opinion, this is the source of our confusion in both. 1) Why use "ECU key" singular if there could be more than one key? 2) Why did we truncate the name to "ECU key", there are many keys in an ECU?

I propose we change the name to "ECU identity key(s)"

[jhdalek55]

See PR #250 on the Standard issue (https://github.com/uptane/uptane-standard/pull/250) for a partial solution for this issue.

[jhdalek55]

This can be closed once PR #148 on Deployment and PR #250 on the Standards are reviewed and merged.

[jhdalek55]

In the 4/25 Uptane meeting, it was decided we need to do a more thorough revision on how we discuss keys in both the Standard and the Deployment pages . As such we are targeting resolution of this issue for 2.2.0