Must all private keys be unique?

[allen-cain-tm]

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]

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]

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]

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]

Hi, An overarching public standards process rule here: If you either add *or* remove a SHALL, then that's a major change (breaks compatibility). The option for an Uptane Standard v2.0 release this year is NOT on the table. So no Uptane Standard SHALL can be changed (or weakened to CONDITIONAL) in Uptane Standard v1.1.0 release. All - please pay attention to this constraint in discussing the group of Uptane issues that Allen Cain just brought up. Cheers, - Ira (here with my Uptane Steering Committee hat on) *Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted Mobility Solutions WG* *Co-Chair - TCG Metadata Access Protocol SG* *Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>mailto: blueroofmusic@gmail.com <blueroofmusic@gmail.com>(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434*

…

On Thu, Jul 30, 2020 at 11:55 AM Marina Moore ***@***.***> wrote: 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). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#174 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE33UO7VGXNP7CXYMIF3UW3R6GJWLANCNFSM4PK24R7Q> .

[jhdalek55]

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]

@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]

Ok. I'll open the new issue. Just getting started this morning. Lois

…

On Mon, Jan 4, 2021 at 6:16 AM Patti Vacek ***@***.***> wrote: @jhdalek55 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jhdalek55&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=hgBKIqNYIOwzXeBjPUaKRw&m=QW2OtvO1fxYKikmerh_HiC6IoAGN6KbyRzeJQ1WkUJU&s=Ata9EFGbL2RyWW6N5_I2XrgFntrTctRzC4iXdlZcGhY&e=> Looks like I can edit, but what should I edit it to? If you make the new issue, I can rename this one. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_uptane_uptane-2Dstandard_issues_174-23issuecomment-2D753916214&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=hgBKIqNYIOwzXeBjPUaKRw&m=QW2OtvO1fxYKikmerh_HiC6IoAGN6KbyRzeJQ1WkUJU&s=MXCqiH9gGWPhDsexmlf1CtEQg1tFKc9QUevftauSCD4&e=>, or unsubscribe <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADPGUXY2CAOGHUPAO6ENE5LSYGPPLANCNFSM4PK24R7Q&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=hgBKIqNYIOwzXeBjPUaKRw&m=QW2OtvO1fxYKikmerh_HiC6IoAGN6KbyRzeJQ1WkUJU&s=RLr6EkY0Zp7iV0inUhIcts2QQUnhDaZMNIlap1fzq8w&e=> .

[jhdalek55]

@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]

@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]

@pattivacek Thank you.

[mnm678]

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]

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]

Hi, An observation about weakening of crypto protections: Using non-unique ECU private keys for signing images could easily result in tens of thousands (or more) of uses of the same key for each binary image. This could greatly facilitate attacker recovery of the key. In general, there's a darn good reason that private keys should be unique to a single instance of an entity. Cheers, - Ira *Ira McDonald (Musician / Software Architect)* *Chair - SAE Trust Anchors and Authentication TF* *Co-Chair - TCG Trusted Mobility Solutions WG* *Co-Chair - TCG Metadata Access Protocol SG* *Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>mailto: ***@***.*** ***@***.***>(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434*

…

On Tue, Apr 20, 2021 at 6:10 PM Lois Anne DeLong ***@***.***> wrote: 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* — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#174 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE33UO2TXPFMR5FVARL432TTJX3UHANCNFSM4PK24R7Q> .

[allen-cain-tm]

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]

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]

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]

Still seeking a volunteer....

[jhdalek55]

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]

@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]

Hi Lois, Your text and wording make sense to me. I will again say that the use of non-unique signing keys *anywhere* in computer systems is inherently dangerous and invites attacker efforts to acquire those fairly insecure signing keys. I will also remind us that it has been security best practice (and reflected in ISO, TCG, Global Platform, US NIST, etc. standards) for more than twenty years to NEVER use a single key for both proof of identity (i.e., authentication or any subsequent authorization) and signatures. Uptane should explicitly (near-term) strongly recommend this separation of ECU key usage and *require* it in v2.0. My two cents. Cheers, - Ira *Ira McDonald (Musician / Software Architect)* *Chair - SAE Trust Anchors and Authentication TF* *Co-Chair - TCG Trusted Mobility Solutions WG* *Co-Chair - TCG Metadata Access Protocol SG* *Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>mailto: ***@***.*** ***@***.***>(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434*

…

On Fri, Sep 17, 2021 at 12:56 PM Lois Anne DeLong ***@***.***> wrote: @JustinCappos <https://github.com/JustinCappos> @iramcdonald <https://github.com/iramcdonald> @tkfu <https://github.com/tkfu> @trishankatdatadog <https://github.com/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 <https://github.com/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 if I should clarify this one point in the Deployment document. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#174 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE33UO5K7LM3XLLC5TPCZ4TUCNXK5ANCNFSM4PK24R7Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[jhdalek55]

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]

@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.

[jhdalek55]

@mnm678 can you change the milestone label to Future?

[jhdalek55]

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]

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

[jhdalek55]

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]

Closing #174 in favor of #241

[jhdalek55]

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