Must all ECU identity keys be unique?
jhdalek55 opened this issue · 4 comments
This is a new presentation of an earlier issue (#174) initially raised by @allen-cain-tm on July 28, 2020. Though it went through several permutations, the original writer had started by pointing out that in 5.4.1 "when discussing the ECU key in the Standard, it states that this is a private key unique to the ECU," but in Deployment Considerations, in https://github.com/uptane/deployment-considerations/blob/master/key_management.md#image-repository it only states that "these keys should be unique to the ECU."
Later in the discussion thread, the original author clarifies that this is not just a semantic agreement problem, but noted that "I believe there is benefit in allowing flexibility for an implementer/adopter to design their key management system.
As such, believe it is beneficial for both Standard and Deployment Considerations to allow for this flexibility."
Subsequent discussions on this thread and at least one PR #218 have separated out some of the semantic issues (and at least one more will likely be posted shortly). But, these have not addressed the author's central question, as stated on April 21, 2021, "My intent of changing "SHALL" --> "SHOULD" is to allow OEMs to architect their key management infrastructure in a way that is not restricted by the standard. This allows an OEM to perform their risk analysis and determine appropriate countermeasures based on corresponding risk levels. To aid in this ticket progressing, please allow me to ask.
Does this proposed change "fundamentally break" anything in the Standard, or is this only a question of risk?"
This is the core question that remains unresolved. To make sure this is the issue that is "front and center" I have opened this new issue, and will be closing the original issue.
I think this issue is worth discussing further at a very fundamental level, meaning is it worth even considering the original authors proposal that we make having unique keys optional? Or, because of potential security risks, is this something we just want to say "no" to and leave it at that?
The group decided at its 11/22 meeting that the answer here has to be yes. With that in mind, we decided to close this issue.