Secure identifiers for hardware and software in vehicles

[jhdalek55]

There has been considerable efforts over the past few years to develop consistent and appropriate identifiers for both hardware and software components. Traditionally, a supplier-name-prefixed serial numbers, such as a VIN number, has been used to identify ECUs, but this method does not acknowledge the differing nature of ECUs. Given that not all ECUs share the same resources (as @iramcdonald observed, "an ECU that does nothing but adjust the seat belt does not need symmetric cryptography"), what does an identifier actually need to share? In the software realm, the use of IETF Standard for Concise Software Identification Tags that are more secure than current supplier/OEM proprietary software version info is becoming commonplace. Concise SWID (CoSWID) tags, according to IETF's Datatracker (https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/), "supports a similar set of semantics and features as SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory efficient format."

This issue does not call for immediate action, but serves as a reminder to stay abreast of emerging standards and regulations looking at the issue of hardware and software identifiers, and to make the appropriate changes to the Standard and or the Deployment pages once a clearer consensus on secure identifiers emerges. (i.e.pending developments in evolving standards).

Note that with opening of this issue, I will be removing Issue #s 86 and 87 on the Deployment pages. The relevant content requested to answer these issues was added to Deployment Best Practices with PR #117.

[jhdalek55]

Can someone give this the milestone label "future"? @mnm678 perhaps?

[tkfu]

As discussed in the 2022/05/10 standards meeting call:

• ECU serial numbers are definitely a question for deployment considerations. It's not clear, though, what should be added there, or what challenges need to be addressed. This would be a good topic for the USA industry workshop.
• CoSWID tags, however, are an excellent idea that could easily be included in the standard as a SHOULD. But exactly where and how in the Targets metadata the CoSWID tags are included should be a question for each specific implementation. This could be specified in the implementation's POUF.

[jhdalek55]

This issue was discussed at the 10/11 Uptane meeting. The consensus was we follow the suggestion in the second bullet point of @tkfu comments from 5/10 and make a place in the Standard to discuss the use of CoSWID tags as a SHOULD. The milestone can then be set for this portion of the issue for V. 2.1.0 A Pull Request to make these changes is requested. Can we get a volunteer?

[jhdalek55]

Still seeking a volunteer to draft a PR for this.

[iramcdonald]

Hi Lois, I'm not volunteering, but making a couple of observations: 1) ECU Serial Number is essentially a free-form string. To make it very meaningful (and reasonably unique), it should be prefixed with a manufacturer name (Supplier rather than meaningless OEM). 2) CoSWID - has been stalled in IETF process nonsense for over a year. It's been blocked in the RFC Editor queue since 20 July 2022 on a required IANA response, so there's still not an RFC to reference (which we need). 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 Wed, Nov 16, 2022 at 11:39 AM Lois Anne DeLong ***@***.***> wrote: Still seeking a volunteer to draft a PR for this. — Reply to this email directly, view it on GitHub <#230 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE33UO6MFHZD7MRBI4WEZX3WIUE37ANCNFSM5KJQC7BQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jhdalek55]

@iramcdonald ...thanks for the input.

[jhdalek55]

At the 1/31/23 Standards meeting, it was agreed that we would set the milestone for 2.2 because the IETF is not immediately publishing a CoSWID RFC. Can someone change this milestone? thanks.

[jhdalek55]

Repeating my request from 1/31/23, can someone change the milestone to 2.2.0. We might as well wait till later in the year when we might be able to add the information from IETF about CoSWID RFC.