How do we address the security issues introduced by the use of aftermarket ECUs?

[jhdalek55]

First introduced at our industry workshop in May, this issue opens discussion on the complicated topic of how the use of aftermarket equipment and services impacts security systems. Aftermarket companies refurbish and reuse equipment following end-of-life support from OEMs. This means introducing ECUs to a vehicle that the OEM has no control over. In addition, because aftermarket suppliers may not have access to the original design, they often reverse engineer the parts to figure out how it works. Such an approach perhaps keeps these suppliers from being able to glean all relevant design information about the ECU.

This is admittedly a broad topic. When introduced at the workshop, several specific points were raised that could each be broken into separate issues:

• How do we deal with aftermarket ECUs that do not have their own Primary? Can they leverage an OEMs Director repository?
• If an aftermarket ECU does have its own Primary, is each capable of controlling a mutually exclusive set of
• Could ownership of Director be delegated to a third party or owner?

I'm opening up this issue so we can begin a dialogue on these and other issues.

[iramcdonald]

Hi, Aftermarket suppliers also manufacture new ECUs that add entirely new features to specific vehicle models that were never offered by the OEMs. Garages (including OEM dealers) regularly install aftermarket ECUs (such as radiators), when the OEM has stopped producing them. It's a fallacy that all aftermarket parts are deficient relative to OEM "official" parts. Older vehicles depend heavily on aftermarket parts. And the newly strengthened Massachusetts Right-to-Repair law complicates both the distribution of ECU firmware updates and the attendant functional safety and cybersecurity issues. 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: [email protected] <[email protected]>(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434*

…

On Mon, Dec 21, 2020 at 9:35 PM Lois Anne DeLong ***@***.***> wrote: First introduced at our industry workshop in May, this issue opens discussion on the complicated topic of how the use of aftermarket equipment and services impacts security systems. Aftermarket companies refurbish and reuse equipment following end-of-life support from OEMs. This means introducing ECUs to a vehicle that the OEM has no control over. In addition, because aftermarket suppliers may not have access to the original design, they often reverse engineer the parts to figure out how it works. Such an approach perhaps keeps these suppliers from being able to glean all relevant design information about the ECU. This is admittedly a broad topic. When introduced at the workshop, several specific points were raised that could each be broken into separate issues: - How do we deal with aftermarket ECUs that do not have their own Primary? Can they leverage an OEMs Director repository? - If an aftermarket ECU does have its own Primary, is each capable of controlling a mutually exclusive set of - Could ownership of Director be delegated to a third party or owner? - — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#200>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE33UO4LTSUNSHKMSKGBHRDSWAAWJANCNFSM4VFAIRSA> .

[jhdalek55]

Thanks for opening up this discussion, @iramcdonald

[jhdalek55]

Can someone with the right privileges flag the milestone for this issue. Let's make it 2.0.0 for now.

[jhdalek55]

At our 3/16 meeting,, it was suggested that we add a mention of these issues to the Deployment pages for our V.1.2.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 #162, #201, and Issue #86 on the Deployment pages.

[jhdalek55]

At our 8/3 meeting, the suggested action was "some text about this issue may be added to the Deployment pages. This will focus only on the problems and will not put forward any solutions." If we are adding this text, we need a volunteer to draft such text.

[jhdalek55]

I can probably cobble together a rough draft for this, based on what we included in the first whitepaper, as long as several people agree to review the content. I'll try to get this done later in the week.

[jhdalek55]

Addressed in part by Deployment PR #116

[jhdalek55]

Since this issue cannot be resolved at this time, can we make a new label, perhaps PENDING, for issues like this for which cannot say when they answered? I would prefer we did not leave issues like this (#162 #198) labeled "2.0.0" on the repo as it gives the appearance that we did not completed these on-time. Failing that can we leave it posted without a version label at all?

[jhdalek55]

Information added to Deployment via PR #116, which was merged on 12/17. Issue remains open however as we monitor pending developments.

[jhdalek55]

During the 10/11 Uptane Standards meeting, we affirmed that while we cannot propose a solution till V.3.0.0 at the earliest (as this would be a major change and possibly a breaking one), we should review the existing text on this topic in the Deployment Best Practices to ensure it is sufficiently clear and current. The current text can be found at https://github.com/uptane/deployment-considerations/blob/master/exceptional_operations.md#aftermarket-ecus

[jhdalek55]

[At the 1/31/22 Uptane Standards meeting, we agreed to tentatively mark this for 2.2.0. The whitepaper on this topic is scheduled to be released at the end of the year and can serve as a precursor to whatever changes are to be integrated here. Can someone change the milestone?

[jhdalek55]

@mnm678 or @trishankatdatadog ---I can't change version numbers on the Standard. Can someone milestone this for V.2.2.0