uptane/uptane-standard

Must all private keys be unique?

allen-cain-tm opened this issue · 28 comments

allen-cain-tm commented
  1. Uniqueness of ECU Private Key
    When discussing the ECU key in the Standard, Section 5.4.1 states this is a private key unique to the ECU....
    On this topic, the Deployment Considerations states These keys should be unique to the ECU.

    Proposal: Ensure consistency by allowing the ability for these keys to not be unique per ECU in the Standard.

2) Multiple Primary Scenarios
The Standard and Deployment Considerations have both been expanded to allow for a vehicle to have multiple Primaries.
The Standard Section 5.4.2 states If multiple such Primaries are included within a vehicle, each Secondary ECU SHALL have a single Primary responsible for providing its updates.
The Deployment Considerations states If multiple Primaries are active in the vehicle at the same time, then each Primary SHOULD control a mutually exclusive set of Secondaries, so that each Secondary is controlled only by one Primary.

Proposal: Modify the Standard to allow for multiple Primaries to interact with a Secondary.
Proposed wording: If multiple such Primaries are included within a vehicle, each Secondary ECU **SHOULD** have a single Primary responsible for providing its updates

JustinCappos commented

Uniqueness of ECU Private Key
When discussing the ECU key in the Standard, Section 5.4.1 states this is a private key unique to the ECU....
On this topic, the Deployment Considerations states These keys should be unique to the ECU.

Proposal: Ensure consistency by allowing the ability for these keys to not be unique per ECU in the Standard.

Is there a reason we wouldn't just update the deployment considerations? The standard is messier to change and I as far as I know MUST is the right term here.

allen-cain-tm commented

Uniqueness of ECU Private Key

Is there a reason we wouldn't just update the deployment considerations? The standard is messier to change and I as far as I know MUST is the right term here.

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.

mnm678 commented 
2\. **Proposal:** Modify the Standard to allow for multiple Primaries to interact with a Secondary.
    Proposed wording: `If multiple such Primaries are included within a vehicle, each Secondary ECU **SHOULD** have a single Primary responsible for providing its updates`

I think the choice to make this a SHALL in the standard was intentional to ensure that each Secondary ECU does not get conflicting updates from different Primaries, and to ensure that the Director has a consistent view of the ECUs in a vehicle. If we changed it to a SHOULD, I think we would need to add some clarification (possibly in the deployment considerations) about how to handle these events if an ECU communicates with multiple primaries. That being said, we should certainly resolve the conflict between deployment considerations and the standard (using either the SHALL or the SHOULD).

iramcdonald commented
jhdalek55 commented

In our meeting on 12/8, it was agreed that this should be split into two issues: one would focus on the uniqueness of private keys, while the other suggests a wording change to better frame the issues of working with multiple primaries. I can open a new issue, but I can't seem to edit this one to change the title. Can someone assist in breaking these up. They both can be set for V.2.0.0./

pattivacek commented

@jhdalek55 Looks like I can edit, but what should I edit it to? If you make the new issue, I can rename this one.

jhdalek55 commented

@pattivacek OK, this took me longer than expected, but I have opened Issue #201 to address the multiple Primary issue. Can you change this one now to be just about ECU private keys?

pattivacek commented

@pattivacek OK, this took me longer than expected, but I have opened Issue #201 to address the multiple Primary issue. Can you change this one now to be just about ECU private keys?

Done.

jhdalek55 commented

@pattivacek Thank you.

mnm678 commented

Back to the key uniqueness issue: When would an ECU key not be unique to the ECU? And would a non-unique key mess up the signing of the ECU version report?

For the image encryption case, I don't see any problem with allowing non-unique ECU keys at the OEM's discretion, but I think duplicate keys for signing may introduce a replay attack for version reports.

jhdalek55 commented

As of 4/13/21, This issue remains unresolved as the group has not developed a consensus on whether we want to have non-unique keys for signing. Therefore, this is deferred for the moment

iramcdonald commented
allen-cain-tm commented

Hi @iramcdonald , @mnm678 , @jhdalek55

Thank you for your comments and valuable feedback.
Completely understand that this request/issue must be deferred to v2.0 to ensure we do not impact backwards compatibility.

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?

Thank you -

mnm678 commented

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?

The Uptane uses ECU key to refer to a key performing 2 main functions:

  • Signing the ECU version report
  • Decrypting images

In the second case, the uniqueness can certainly be left up to the OEM. Encrypted images are supported by Uptane, but don't really affect the authenticity checks.

In the first case, it looks like a replay attack would be prevented by the use of the "ECU's unique identifier (e.g., the serial number)" in the version report, so the only question is whether the duplicate key could be used to impersonate a vehicle. This would depend on the attack's ability to get the private key and serial number used in a particular vehicle. What do others think here?

jhdalek55 commented

This issue was discussed at our meeting on 7/20/21. @mnm678 @iramcdonald, correct this summary if it is not correct. Part of the problem seems to be that the term "private key" can be interpreted in different ways, one of them being a generic term for an identifier. Private keys must be unique. "Secret key" might be a better choice in some instances. What is needed is some clarifying text and perhaps some renaming within the text. We could use a volunteer to submit a PR to provide the necessary clarification.

jhdalek55 commented

Still seeking a volunteer....

jhdalek55 commented

Can someone please step in here and draft some new text that changes "private key" to "secret key" when used as a generic terms for an identifier?

jhdalek55 commented

@JustinCappos @iramcdonald @tkfu @trishankatdatadog or anyone else we cares to comment.

I just did a quick search in the Standard and the instance cited at the beginning of this issue thread (is the only place where the phrase "private key" is used. (and the term does not seem to appear in the Deployment Best Practices. Given that, do we need to make this wording change in this one instance? Wouldn't private key be the correct term in this instance?

As for the second phrase specifically mentioned in the original post from @allen-cain-tm ....
"ECU key(s), to sign the ECU's version reports, and optionally to decrypt images. These keys should be unique to the ECU, and the public keys will need to be stored in the Director repository's inventory database"....
It seems we can make the distinction between "private key" and "secret key" here by editing the second sentence as follows "While the signing keys, also known as 'private keys' are required to be unique to the ECU to avoid replay attacks, the keys used to decrypt images need not be unique."

Of course I believe this is still side-stepping the original issue of whether signing keys should be unique, but please let me know if I should clarify this one point in the Deployment document.

iramcdonald commented
jhdalek55 commented

Note: This should probably be "re-flagged" for Version 3.0.0, as we only partially addressed the issue with PR#218. I would recommend we change the title to "Must all private keys be unique?"

jhdalek55 commented

@mnm678 Can you either close this issue and re-open a new one, or just re-name it as "Must all private keys be unique?" PR #218 addressed only a small wording issue. We have yet to resolve the bigger issue about non-unique private keys.

  • 👍1
jhdalek55 commented

@mnm678 can you change the milestone label to Future?

jhdalek55 commented

After a good deal of discussion, it was decided this question should be rewritten. In addition there needs to be a separate issue added to the Deployment pages to make sure all understand the distinct difference between the types of keys.

jhdalek55 commented

See note above and resolved as directed. Then close this issue.

jhdalek55 commented

This is being closed so the core question can be more explicitly stated. I am making one more semantic change that relates to this issue and then I will be closing it.

jhdalek55 commented

Closing #174 in favor of #241

jhdalek55 commented

I guess I don't have the ability to close this issue. Can someone help me with this?

  • 👍1