Support updates that are not bound to an ECU in very limited cases

[JustinCappos]

Having updates that are bound to a specific ECU prevents a director's metadata from being replayed by a malicious party. However, there are some circumstances where it is desirable for piece of director metadata to be used by many ECUs across different vehicles.

For example, 1) location focused updates (e.g., maps). --- Note, this could be a situation where having a third repository sign metadata makes some degree of sense 2) a situation where all vehicles need an update and you wish to keep the signing keys offline (e.g., factory flashing of an ECU). --- In this case, the version number should be set to an extremely low number, likely to minimum possible value, to ensure this metadata cannot be replayed to vehicles in the field.

[zabbal]

I think it might make sense to split this into 2 issues because the 2 use-cases are vastly different:

• the factory ECU is something which happens once, it's the same kind of image which Uptane normally handles
• maps update is something which happens regularly, it's not firmware-related etc.

I think those should be discussed separately as they might have different fesibility, security requirements etc.

[jhdalek55]

This issue was tabled shortly before we finalized the Standard. @JustinCappos, do you still believe its an issue that requires addressing? If so, how should we move forward with this?

[JustinCappos]

I'd like to discuss this issue in a forthcoming meeting. I'd like us to have smaller discussions over a few weeks and on this list as it seems this is more contentious and so I don't want to rush this through.

I think it might make sense to split this into 2 issues because the 2 use-cases are vastly different:

• the factory ECU is something which happens once, it's the same kind of image which Uptane normally handles
• maps update is something which happens regularly, it's not firmware-related etc.

I think those should be discussed separately as they might have different fesibility, security requirements etc.

I understand the use cases are different, but we happen to use a common mechanism in TUF to address both cases. The fact that we decided in Uptane not to support this actually surprised me a bit when I learned about it. If we decide we don't want to use this mechanism in one case or the other, then let's split it out for sure. First, I'd like to hear more a little more detail about why this mechanism doesn't work for at least one of those problems though. :)

[jhdalek55]

We can open this discussion at our Tuesday meeting and then continue it on the discussion threads, here or on the mailing list.

The agenda already has time allocated for brainstorming the next set of work to be done on the standard, so please bring this up.

Lois

[iramcdonald]

Hi,

Third use case (from IEEE 1609 WAVE/DSRC):

Current local policy updates (triggered by geolocation changes which also sometimes already trigger maps updates in current vehicles). Cross a state or national border and vehicle laws and regulations change. So do the automotive safety infrastructure authoritative servers for ITS registration and root certificates.

Cheers,

• Ira

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434 (until May 2020) 203 W Oak St Elletsville, IN 47429 phone is TBD

On Sat, Jan 4, 2020 at 3:50 PM Justin Cappos notifications@github.com wrote:

I'd like to discuss this issue in a forthcoming meeting. I'd like us to have smaller discussions over a few weeks and on this list as it seems this is more contentious and so I don't want to rush this through.

I think it might make sense to split this into 2 issues because the 2 use-cases are vastly different:

• the factory ECU is something which happens once, it's the same kind of image which Uptane normally handles
• maps update is something which happens regularly, it's not firmware-related etc.

I think those should be discussed separately as they might have different fesibility, security requirements etc.

I understand the use cases are different, but we happen to use a common mechanism in TUF to address both cases. The fact that we decided in Uptane not to support this actually surprised me a bit when I learned about it. If we decide we don't want to use this mechanism in one case or the other, then let's split it out for sure. First, I'd like to hear more a little more detail about why this mechanism doesn't work for at least one of those problems though. :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/120?email_source=notifications&email_token=AE33UO7UX45SZXJQPEBUFT3Q4DZC7A5CNFSM4H3KITAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIDAC4Y#issuecomment-570818931, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE33UO5VZHMFREBIZONRFQTQ4DZC7ANCNFSM4H3KITAA .

[JustinCappos]

So is this something where both updates need to have already been downloaded and the system should switch to the right version? Is this something where one would keep wiping and reinstalling as you cross state lines?

On Sun, Jan 5, 2020 at 5:43 PM iramcdonald notifications@github.com wrote:

Hi,

Third use case (from IEEE 1609 WAVE/DSRC):

Current local policy updates (triggered by geolocation changes which also sometimes already trigger maps updates in current vehicles). Cross a state or national border and vehicle laws and regulations change. So do the automotive safety infrastructure authoritative servers for ITS registration and root certificates.

Cheers,

• Ira

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434 (until May 2020) 203 W Oak St Elletsville, IN 47429 phone is TBD

On Sat, Jan 4, 2020 at 3:50 PM Justin Cappos notifications@github.com wrote:

I'd like to discuss this issue in a forthcoming meeting. I'd like us to have smaller discussions over a few weeks and on this list as it seems this is more contentious and so I don't want to rush this through.

I think it might make sense to split this into 2 issues because the 2 use-cases are vastly different:

• the factory ECU is something which happens once, it's the same kind of image which Uptane normally handles
• maps update is something which happens regularly, it's not firmware-related etc.

I think those should be discussed separately as they might have different fesibility, security requirements etc.

I understand the use cases are different, but we happen to use a common mechanism in TUF to address both cases. The fact that we decided in Uptane not to support this actually surprised me a bit when I learned about it. If we decide we don't want to use this mechanism in one case or the other, then let's split it out for sure. First, I'd like to hear more a little more detail about why this mechanism doesn't work for at least one of those problems though. :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < https://github.com/uptane/uptane-standard/issues/120?email_source=notifications&email_token=AE33UO7UX45SZXJQPEBUFT3Q4DZC7A5CNFSM4H3KITAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIDAC4Y#issuecomment-570818931 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AE33UO5VZHMFREBIZONRFQTQ4DZC7ANCNFSM4H3KITAA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/120?email_source=notifications&email_token=AAGRODYYT4Y5R2TZJGR6GELQ4JPBPA5CNFSM4H3KITAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIEBPEQ#issuecomment-570955666, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGRODZ5U4XZC36IJJ7B6IDQ4JPBPANCNFSM4H3KITAA .

[iramcdonald]

Hi Justin,

From my IEEE 1609 colleagues, I think the typical mode would be wiping and reinstalling policies/regulations as you cross state or national borders.

This is a current topic in IEEE 1609, because it would be desirable that the actual ITS registration and root certificate servers would already be known by the vehicle (although that obviously falls apart if you ship your vehicle by boat to another continent).

Similar to detailed maps and road conditions updates some vehicles already update for their ADAS systems.

IEEE 1609 has a task force (subgroup?) thinking about large data distribution topics - ISO ITS folks already have an active work item in this area as well.

Cheers,

• Ira

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434 (until May 2020) 203 W Oak St Elletsville, IN 47429 phone is TBD

On Mon, Jan 6, 2020 at 11:14 AM Justin Cappos notifications@github.com wrote:

So is this something where both updates need to have already been downloaded and the system should switch to the right version? Is this something where one would keep wiping and reinstalling as you cross state lines?

On Sun, Jan 5, 2020 at 5:43 PM iramcdonald notifications@github.com wrote:

Hi,

Third use case (from IEEE 1609 WAVE/DSRC):

Current local policy updates (triggered by geolocation changes which also sometimes already trigger maps updates in current vehicles). Cross a state or national border and vehicle laws and regulations change. So do the automotive safety infrastructure authoritative servers for ITS registration and root certificates.

Cheers,

• Ira

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434 (until May 2020) 203 W Oak St Elletsville, IN 47429 phone is TBD

On Sat, Jan 4, 2020 at 3:50 PM Justin Cappos notifications@github.com wrote:

I'd like to discuss this issue in a forthcoming meeting. I'd like us to have smaller discussions over a few weeks and on this list as it seems this is more contentious and so I don't want to rush this through.

I think it might make sense to split this into 2 issues because the 2 use-cases are vastly different:

• the factory ECU is something which happens once, it's the same kind of image which Uptane normally handles
• maps update is something which happens regularly, it's not firmware-related etc.

I think those should be discussed separately as they might have different fesibility, security requirements etc.

I understand the use cases are different, but we happen to use a common mechanism in TUF to address both cases. The fact that we decided in Uptane not to support this actually surprised me a bit when I learned about it. If we decide we don't want to use this mechanism in one case or the other, then let's split it out for sure. First, I'd like to hear more a little more detail about why this mechanism doesn't work for at least one of those problems though. :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <

https://github.com/uptane/uptane-standard/issues/120?email_source=notifications&email_token=AE33UO7UX45SZXJQPEBUFT3Q4DZC7A5CNFSM4H3KITAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIDAC4Y#issuecomment-570818931

, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AE33UO5VZHMFREBIZONRFQTQ4DZC7ANCNFSM4H3KITAA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/uptane/uptane-standard/issues/120?email_source=notifications&email_token=AAGRODYYT4Y5R2TZJGR6GELQ4JPBPA5CNFSM4H3KITAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIEBPEQ#issuecomment-570955666 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAGRODZ5U4XZC36IJJ7B6IDQ4JPBPANCNFSM4H3KITAA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/120?email_source=notifications&email_token=AE33UO47FTXDMYGXNSTFVTTQ4NKFFA5CNFSM4H3KITAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIF5M7A#issuecomment-571201148, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE33UOZA5RJWYE4EYNBEZNTQ4NKFFANCNFSM4H3KITAA .

[DaveNew02]

I'd like to ensure that folks are not thinking about an "either/or" situation, where only 1) or 2) is loaded. In particular, when approaching a (e.g.) state line, it would take some time (>0) to download a change, so both of them must reside in the target ECU for some (>0) time. That places requirements on the ECU to hold multiple images. Maybe this is already assumed for FOTA (Firmware Other the Air), but FOTA is like normally assumed to not take place or at least take effect while the vehicle is barreling down the highway. If we want something to take place "on" a state line, then this would have to be while the vehicle is in motion, and seamlessly (whatever that means).

-- DaveN

[iramcdonald]

Hi Dave,

Thanks for your good observations.

ETSI, ITU-T, and ISO standards committees are now describing these border crossing use cases in ITS (Intelligent Transportation System) standards. ISO and IEEE 1609 folks are looking into scalable data distribution protocols and architectures for these large lumps of data that will have important safety considerations.

Cheers,

• Ira

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434 (until May 2020) 203 W Oak St Elletsville, IN 47429 phone is TBD

On Thu, Jan 30, 2020 at 3:36 PM Dave New notifications@github.com wrote:

I'd like to ensure that folks are not thinking about an "either/or" situation, where only 1) or 2) is loaded. In particular, when approaching a (e.g.) state line, it would take some time (>0) to download a change, so both of them must reside in the target ECU for some (>0) time. That places requirements on the ECU to hold multiple images. Maybe this is already assumed for FOTA (Firmware Other the Air), but FOTA is like normally assumed to not take place or at least take effect while the vehicle is barreling down the highway. If we want something to take place "on" a state line, then this would have to be while the vehicle is in motion, and seamlessly (whatever that means).

-- DaveN

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/120?email_source=notifications&email_token=AE33UO2ZU3TZ5OO4QX2DM7DRAM23ZA5CNFSM4H3KITAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKMPBGY#issuecomment-580448411, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE33UO3TZUYYQIJXIYYJ3T3RAM23ZANCNFSM4H3KITAA .

[cameronmott]

Use cases for consideration:

1. SCMS Certificate Revocation List The current implementation for SCMS requires a Certificate Revocation List, which needs to be distributed to all vehicles. Certain (multiple) entities need to have the authority to update the list with misbehaving certificates. The CRL could be distributed by regional DOTs to vehicles that are traveling in their region. Additionally, use cases for distribution of the CRL include propagating the CRL between vehicles without a back-haul connection.

2. Regional MAP messages Regional DOTs are currently providing information to vehicles (via a J2735 MAP message) detailing the geometry of an intersection and the real-time traffic signal phases (red/yellow/green) for that intersection. These MAP messages are applicable for any vehicle in the area, or even vehicles that may be traveling in the area in the future. The DOT would need to have a signing key with the authority to make updates.

[jhdalek55]

Thanks for the input @cameronmott. Can we perhaps get a re-statement of this issue to incorporate all the topics this thread has embraced? Or if we might be talking multiple issues here, could we perhaps separate them into different issues?

Lois

[zabbal]

I think it's better to create separate issues and link them to this one. Unless we're absolutely sure that all those distinct use-cases would be fixed using exactly the same change to the spec.

[jhdalek55]

@zabbal can you or perhaps @JustinCappos or @cameronmott either rephrase this issue or divide it as suggested above? I think a re-clarification of what we are trying to resolve might help us move forward on this.

[zabbal]

we happen to use a common mechanism in TUF to address both cases

@JustinCappos could give a reference to the TUF spec to put this into context? Also, what should be changed in Uptane to "port" it from TUF?

[jhdalek55]

On the 3/3 Standards call, we decided we needed the reference from the TUF spec before we could decide if we are dealing with one or multiple issues here. @JustinCappos can you provide this reference at your earliest convenience?

[JustinCappos]

On the 3/3 Standards call, we decided we needed the reference from the TUF spec before we could decide if we are dealing with one or multiple issues here. @JustinCappos can you provide this reference at your earliest convenience?

The mechanism is that Uptane forces there to be an ID / serial number (apologies, but I forgot the technical term we used in the spec) for every targets file from the director. TUF does not require any such thing.

One could imagine a special director-like role/key that is only used for initial metadata, location-based information, etc. which does not have this restriction. This key would obviously also be kept offline for security reasons.

[trishankatdatadog]

(apologies, but I forgot the technical term we used in the spec)

ECU identifier

[cameronmott]

Along the lines of considering options, the spec could allow for an ECU to have a universally accepted ID/serial number that would be used instead of the unique ECU identifier. This "global" ECU identifier would be used by entities that do now know what ECUs should be receiving the update, and instead would like all of the ECUs to receive and verify an update.

[JustinCappos]

When I first read this, I really liked this idea and had written a post about how this might work but in that process I think I may have found a problem. If the director key is trusted to also sign things with this special ECU ID, then this defeats the security properties we want to have. If the director key isn't trusted, then you're effectively just doing the same as this proposal by having a type of delegation that can be trusted without an ECU identifier. Since we already need to have a case to handle the ECU ID missing, I'm not sure that operationally, this is a big difference.

Does this make sense?

On Thu, Mar 12, 2020 at 4:41 PM Cameron Mott notifications@github.com wrote:

Along the lines of considering options, the spec could allow for an ECU to have a universally accepted ID/serial number that would be used instead of the unique ECU identifier. This "global" ECU identifier would be used by entities that do now know what ECUs should be receiving the update, and instead would like all of the ECUs to receive and verify an update.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/120#issuecomment-598408716, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD54SVCG5WREAMNKCZLRHFCGBANCNFSM4H3KITAA .

[zabbal]

If we get back to the ticket description, it mention 2 cases: the former assume constant, repetitive updates while the latter is "once and very early in a lifetime of ECU" kind of update.

Can we address the latter by introducing special version-related rules without breaking security properties? Smth like "this (targets?) role is trusted to sing special/missing ECU ID update only if the version == 0". What do you think?

[tkfu]

Further discussion of the location-specific, on-the-road cases should be moved to #161; we'll continue to discuss the "once and very early in a lifetime of ECU" use case here.

[zabbal]

On a related note, I'm curious about Section 5.4.4.6 - https://uptane.github.io/papers/ieee-isto-6100.1.0.0.uptane-standard.html#rfc.section.5.4.4.6

In particular Step 4: "Check that the version number of the previous Targets metadata file, if any, is less than or equal to..." - could we use "if any" bit for this issue? Or the case of unversioned Targets/Snapshot/Timestamp metadata is intended for some other (which one?) use-case?

If I interpret Section 5.2.1 correctly (am I?) than we can move from Targets-without-version to Targets-v1 but not the other way around.

Or that's simply my non-native English mixing up "Targets metadata might not exist" and "version field inside Targets metadata might not exist" cases?

[pattivacek]

To summarize some points from the call:

"Check that the version number of the previous Targets metadata file, if any, is less than or equal to..." - could we use "if any" bit for this issue? Or the case of unversioned Targets/Snapshot/Timestamp metadata is intended for some other (which one?) use-case?

1. The "if any" refers to whether their was a previous Targets metadata file. There might not be one the first time that you receive such a file. Still, your point stands that an absent version or version of zero could have a special meaning, presumably if and only if there is no previous Targets metadata file, or the previous version also lacks the version or has it set to zero.

2. We think that the solution to #161 might solve this issue as well, so that one is slightly more critical. My understanding of the location-based solution could be an option for this as well.

[iramcdonald]

Hi,

RFC 5870 defines the "geo:" URI scheme and should be used as the basis for vehicle location metadata:

https://tools.ietf.org/html/rfc5870

Cheers,

• Ira

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434

On Tue, Mar 31, 2020 at 11:02 AM Patrick Vacek notifications@github.com wrote:

To summarize some points from the call:

"Check that the version number of the previous Targets metadata file, if any, is less than or equal to..." - could we use "if any" bit for this issue? Or the case of unversioned Targets/Snapshot/Timestamp metadata is intended for some other (which one?) use-case?

1.

The "if any" refers to whether their was a previous Targets metadata file. There might not be one the first time that you receive such a file. Still, your point stands that an absent version or version of zero could have a special meaning, presumably if and only if there is no previous Targets metadata file, or the previous version also lacks the version or has it set to zero. 2.

We think that the solution to #161 https://github.com/uptane/uptane-standard/issues/161 might solve this issue as well, so that one is slightly more critical. My understanding of the location-based solution https://github.com/uptane/uptane-standard/issues/161#issuecomment-606681496 could be an option for this as well.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/120#issuecomment-606682801, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE33UO4BJY5WY4AFHUB2LZTRKIAWXANCNFSM4H3KITAA .

[jhdalek55]

In the 4/28 Standards Meeting, it was decided that this use case could be addressed with an addition to the Deployment pages, as any type of exception mentioned in the Standard could potentially lead to insecure behavior. @tkfu offered to draft text for the Deployment pages to address this issue.

[jhdalek55]

@tkfu --can you remind me if this was addressed? No worries if it hasn't. I'm just trying to assess any open issues on the Standard and Deployment pages.

Lois

[jhdalek55]

On the 7/23 Standards call, the group agreed to close this issue. Can someone with right privileges do so?