Designating a Primary for Secondary ECUs in Multiple Primary Configuration

[jhdalek55]

This issue splits off from Issue #174, which was actually two unrelated issues in a single package. Here, the question is managing configurations that feature more than one Primary. As explained in the original issue, posted by @allen-cain:

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.

[jhdalek55]

Discussion moved over from Issue #174

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

Comment from Marina
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]

I am strongly in favor of the use of SHALL here (in the Standard and in the Deployment Best Practices). If a given Secondary can install updates from two different Primaries in the same vehicle, then the security posture of that Secondary cannot be deterministic and collisions between competing Prinmaries are inevitable.
Separately, there should be new text (in v2.0) for both Standard and Deployment that multiple Primaries in the same vehicle SHALL coordinate all software update activities and actively avoid unsafe or insecure software update activities.

[mnm678]

I agree with @iramcdonald that we should add a SHALL that each Secondary is associated with a single Primary, but I think requiring the Primaries to coordinate would add unnecessary challenges for aftermarket ECUs, or more generally Primaries that are controlled by different parties.

[iramcdonald]

Hi Marina, Ah - but my point was specifically *about* both Aftermarket and "legacy" Primaries (the latter include so called "self-updaters" such as Infotainment ECUs and Telematics ECUs). For two different OEMs, I've written requirements that multiple Primaries *must* coordinate, or else the safety and security of OTA software updates for the collection of Secondaries cannot be deterministic. This is a key concern in the ISO 24089 Road Vehicles Software Update work-in-progress. A Primary has to check for the "safe vehicle state" (e.g., by coordinating with the Body Controller ECU, who often is responsible for this determination) before forwarding updates. The Primary also must detect and avoid multiple update collisions (e.g., Service Tool and OTA updates, even to different ECUs, because the relevant "safe vehicle state" my differ). A Secondary should only trust any given Primary when cryptographic proof is available that the Primary is legitimate and itself booted correctly. Authentication of communicating ECUs is no longer sufficient. Remote Attestation, when challenged, of the "health" state of an ECU (secure boot and measured boot and runtime integrity of running applications) is the current IETF RATS WG objective and the future best practice that OEMs are now considering. Uptane Deployment Best Practices should be forward looking and inform implementors of future features, rather than just saying how to securely deploy the current companion version of the Uptane Standard. 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: blueroofmusic@gmail.com <blueroofmusic@gmail.com>(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434*

…

On Thu, Jan 28, 2021 at 11:35 AM Marina Moore ***@***.***> wrote: I agree with @iramcdonald <https://github.com/iramcdonald> that we should add a SHALL that each Secondary is associated with a single Primary, but I think requiring the Primaries to coordinate would add unnecessary challenges for aftermarket ECUs, or more generally Primaries that are controlled by different parties. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#201 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE33UOY26UF3JXIH2DJBFELS4GG4HANCNFSM4WJBG3DQ> .

[jhdalek55]

Can someone tag this for V.2.0.0? I'm not able to do that.

[pattivacek]

Can someone tag this for V.2.0.0? I'm not able to do that.

Done.

[jhdalek55]

Can someone take a look at the issue and see if there is an interim step we could take?

[mnm678]

Any change to this part of the standard (reducing the SHALL) will have to wait for 2.0.0. What we can do now is decide if this is something we want to do, and how to specify the coordination between multiple primaries in the deployment considerations.

[jhdalek55]

As of the 4/13 Uptane Standard meeting, it was agreed to add some text about this issue to a new "Emerging Issues" page on the website. Otherwise leave to 2.0.0.

[jhdalek55]

At our 4/13 meeting, it was agreed we should add an "Emerging Issues" page to Deployment Best Practices that would address topics like this one where no definitive solution is on the horizon. PR # 104 opened a file for this page and @jhdalek55 will draft some initial text. In addition to this issue, the text will address Issues #200 and Issue #86 on the Deployment pages.

[jhdalek55]

The consensus was to add some text to the Standard, but as a SHOULD and not a SHALL (i.e. “Secondaries SHOULD only have one . If this text is added, then a rationale for the SHOULD needs to be included in the Deployment section. It was agreed that text should be drafted and the debate can continue from there."

Are we moving forward with this and can we get a volunteer?

[jhdalek55]

We still need a volunteer to draft some text for this.

[jhdalek55]

It was agreed that we should add some text to the Standard stating that, in cases where a system has multiple primaries, each primary SHOULD have its one designated set of secondaries. In the Deployment pages, we should explain that secondaries lack the resources to prioritize between primaries which could prevt secondaries from maintaining compliance.

[iramcdonald]

Hi Lois, Yes. Specifically the Secondaries need to maintain their ISO 26262 Functional Safety and ISO/SAE 21434 Cybersecurity Engineering compliance (for UNECE R155 audits) and ISO 26262 Functional Safety and ISO 24089 compliance (for UNECE R156 audits). Cheers, - Ira PS - Interesting inversion of our original text that a Secondary SHOULD have only one Primary into our discussion sense today that each Primary SHOULD have a disjoint set of Secondaries (not served by any other Primary in the same vehicle). *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, Sep 28, 2021 at 2:08 PM Lois Anne DeLong ***@***.***> wrote: It was agreed that we should add some text to the Standard stating that, in cases where a system has multiple primaries, each primary SHOULD have its one designated set of secondaries. In the Deployment pages, we should explain that secondaries lack the resources to prioritize between primaries which could prevt secondaries from maintaining compliance. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#201 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE33UO3OLL3TGGYJTUJDNADUEIADNANCNFSM4WJBG3DQ> . 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]

We still need text for this issue. I'm not sure I know how to address this issue. Can we please get a volunteer to address this?

[jhdalek55]

Thanks @mnm678 for PR #219 (which needs to be reviewed). We also discussed adding text to the Deployment pages with a justification for this action. Can someone take care of this?

[mnm678]

solved in #219