Requiring "Secure Time"

[allen-cain-tm]

The standard states "ECUs MUST have a secure source of time." (Section 5.4) and further elaborates that this may be an external or internal source of time (Section 5.4).
My understanding is that this is included to prevent rollback and freeze attacks.
Separately, the Deployment Considerations states: "If the ECU’s time is set too far ahead, it will detect that the current valid metadata is expired and thus be unable to perform an update".

Taking this information into account, my concern is two-fold:

1. Unintentional DOS of an ECU with a real-time clock (RTC) since Uptane metadata will most likely be earlier than the value of RTC.
   Thus, the ECU may deem the update to be insecure and not perform the update.

2. I believe the requirement of a 'secure time' may be too prescriptive of a solution to provide protection from rollback and freeze attacks.
   For example, OEMs & ECU designers could choose to utilize both a "secure counter" and "update logic" to protect against these classes of attacks.

Proposals:

1. In Deployment Considerations account for the DOS scenario described above by rephrasing as following: "If the ECU’s time is set too far ahead, it will detect that the current valid metadata is expired and thus **may** be unable to perform an update"
2. In both the Standard and the Deployment Considerations modify the requirement for secure time in favor of a potential combination of several technologies including but not limited to: secure attestation of time, secure metadata versioning, secure counter, and update logic.

[iramcdonald]

Hi, Interesting comment. I don't follow the logic of why an ECU w/ a later time would *unintentionally* reject an earlier signature or build date. For any update on rollback protection, we should explicitly reference SAE J3101 clauses and align terms. I'm not sure that ISO 21434 has rollback protection (it should, but is probably too high-level). However, this issue has to be tagged for v2.0.0 because it would modify or reduce a SHALL in the Standard. 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 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 Tue, Jul 28, 2020 at 3:20 PM allen-cain ***@***.***> wrote: The standard states "ECUs MUST have a secure source of time." (Section 5.4) and further elaborates that this may be an external or internal source of time (Section 5.4). My understanding is that this is included to prevent rollback and freeze attacks. Separately, the Deployment Considerations states: "If the ECU’s time is set too far ahead, it will detect that the current valid metadata is expired and thus be unable to perform an update". Taking this information into account, my concern is two-fold: 1. Unintentional DOS of an ECU with a real-time clock (RTC) since Uptane metadata will *most likely* be earlier than the value of RTC. Thus, the ECU *may* deem the update to be insecure and not perform the update. 2. I believe the requirement of a 'secure time' may be too prescriptive of a solution to provide protection from rollback and freeze attacks. For example, OEMs & ECU designers could choose to utilize both a "secure counter" and "update logic" to protect against these classes of attacks. *Proposals:* 1. In Deployment Considerations account for the DOS scenario described above by rephrasing as following: "If the ECU’s time is set too far ahead, it will detect that the current valid metadata is expired and thus **may** be unable to perform an update" 2. In both the Standard and the Deployment Considerations modify the requirement for secure time in favor of a potential combination of several technologies including but not limited to: secure attestation of time, secure metadata versioning, secure counter, and update logic. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#169>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE33UO5AABY2VCLJRSYJGZLR54QI7ANCNFSM4PK23K2A> .

[trishankatdatadog]

Sorry, I'm a bit confused. Just because an ECU clock is ahead of the "real" current time, doesn't mean it would reject earlier signatures (doesn't matter when it was signed), only what is now considered "expired" metadata, no?

[iramcdonald]

Hi Trishank, But the "expired" metadata is determined by the signature on the metadata, right? The idea of a DoS attack on an individual ECU by corrupting its own RTC seems vanishingly unlikely to me. Distribution of current time in vehicles is OEM-specific, but there are usually only one or two trusted ECUs in a whole vehicle for time source. Rationale implementations *never* trust GPS time. For signature and key lifetime validation, Google Roughtime works fine (and is widely adopted - it's now in a new Internet-Draft to become an IETF standard). Irrespective of the signatures over metadata, the signature(s) on ECU firmware binaries could have used out-of-date or revoked keys. 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 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 Fri, Aug 28, 2020 at 1:49 PM Trishank Karthik Kuppusamy < ***@***.***> wrote: Sorry, I'm a bit confused. Just because an ECU clock is ahead of the "real" current time, doesn't mean it would reject earlier signatures (doesn't matter when it was signed), only what is now considered "expired" metadata, no? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#169 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE33UO5QHZ4QBUC7SBJKYSDSC7U4BANCNFSM4PK23K2A> .

[trishankatdatadog]

But the "expired" metadata is determined by the signature on the metadata, right? The idea of a DoS attack on an individual ECU by corrupting its own RTC seems vanishingly unlikely to me. Distribution of current time in vehicles is OEM-specific, but there are usually only one or two trusted ECUs in a whole vehicle for time source. Rationale implementations never trust GPS time. For signature and key lifetime validation, Google Roughtime works fine (and is widely adopted - it's now in a new Internet-Draft to become an IETF standard). Irrespective of the signatures over metadata, the signature(s) on ECU firmware binaries could have used out-of-date or revoked keys.

Agreed. There may be an escape hatch for ignoring the signed expiration time, if need be, and I don't think this is even a possibility in the standard right now. Definitely a 2.0.0 thing if it ever happens.

[jhdalek55]

In the 12/8 Standards meeting this was flagged as a 2.0.0 issue, though again its likely it might get held for a later version.

[jhdalek55]

Here was the discussion of this issues from the 7/6 meeting:

This touches on architecture issues that Uptane is not designed to resolve. In section 5.4.2.5, the Standard currently includes a “conditional” requirement: “Unless the Secondary ECU has its own way of verifying the time or does not have the capacity to verify a time message, the Primary is CONDITIONALLY REQUIRED to send the time to each ECU. The Secondary will verify the time message, then overwrite its current time with the received time.” The “unless” statement raises some red flags as it seems to be pointing to a vulnerability.

The suggestion was to leave what is described in the Standard and add something to the Deployment Best Practices. This could include some text about monotonic counters, a tamper-resistant type of primitive embedded in a device whose value, once incremented, cannot be reverted back to a previous value. Such a device can help prevent replay attacks, as it can not be tricked into using an older value (i.e. an older time).

@allen-cain-tm offered to draft a pull request on this topic.

[JustinCappos]

Another option is just always to require the primary to send the time. Then we would need to deal with the issue of the times not matching, though (which I think we should already comment on in the Deployment Best Practices).

…

On Thu, Jul 29, 2021 at 6:56 AM Lois Anne DeLong ***@***.***> wrote: Here was the discussion of this issues from the 7/6 meeting: This touches on architecture issues that Uptane is not designed to resolve. In section 5.4.2.5, the Standard currently includes a “conditional” requirement: “Unless the Secondary ECU has its own way of verifying the time or does not have the capacity to verify a time message, the Primary is CONDITIONALLY REQUIRED to send the time to each ECU. The Secondary will verify the time message, then overwrite its current time with the received time.” The “unless” statement raises some red flags as it seems to be pointing to a vulnerability. The suggestion was to leave what is described in the Standard and add something to the Deployment Best Practices. This could include some text about monotonic counters, a tamper-resistant type of primitive embedded in a device whose value, once incremented, cannot be reverted back to a previous value. Such a device can help prevent replay attacks, as it can not be tricked into using an older value (i.e. an older time). @allen-cain-tm <https://github.com/allen-cain-tm> offered to draft a pull request on this topic. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#169 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD5JJMZVETTCI4LI3NLT2CDKZANCNFSM4PK23K2A> .

[jhdalek55]

Can someone start a PR on the Deployment pages that addresses this issue?

[jhdalek55]

@trishankatdatadog...is this the issue Datadog wants to pursue, as per our discussion at the 8/31 meeting? If so, could you or someone from your group open up a PR on the Deployment pages addressing this?

[jhdalek55]

We will discuss this issue in response to Datadog's interest in this topic at our meeting on September 28.

[jhdalek55]

This issue keeps coming up in our meetings (including another discussion at our most recent meeting) but no one has submitted a PR. If we cannot get some text in place to deliberate on within the next few weeks, I think we need to push this back to 3.0.0 or some intervening version.

[jhdalek55]

At the 11/23 meeting,@iramcdonald agreed to provide text to be used in a PR addressing this issue.

[jhdalek55]

@iramcdonald will you be able to provide at least a rough version of text for this? All that is needed is the important points to be made. I will draft the PR, but you have the best handle on the issue.

[iramcdonald]

Hi Lois and Uptane folks, With my apologies for text in the Standard or Deployment Best Practices which may already have changed since v1.2.0 - I get lost rooting through GitHub and totally lost reading Markdown (one of my least favorite markup languages). So I'm looking at the published v1.2.0 text of these two documents. OK - here are some rough ideas for text: 1) Uptane Standard * Section 5.4 currently says: "An Uptane-compliant ECU SHALL be able to download and verify image metadata and image binaries before installing a new image and MUST have a secure way of verifying the current time, or a sufficiently recent attestation of the time." - KEEP this excellent requirement as is in v2.0.0. "ECUs MUST have a secure source of time. An OEM/Uptane implementer MAY use any external source of time that is demonstrably secure." - KEEP this excellent requirement as is in v2.0.0. * Section 5.4.2 currently says: "5. OPTIONAL: Send latest time to Secondaries (Section 5.4.2.5)" - REMOVE the "OPTIONAL" (per Justin's good comment earlier in this thread) and make this mandatory. * Section 5.4.2.5 currently says: "Unless the Secondary ECU has its own way of verifying the time or does not have the capacity to verify a time message, the Primary is CONDITIONALLY REQUIRED to send the time to each ECU. The Secondary will verify the time message, then overwrite its current time with the received time." - REVISE to strengthen as follows: "The Primary SHALL send the time to each ECU. The Secondary SHALL verify the time message, and then overwrite its current time with the received time." 2) Deployment Best Practices Section "Secure source of time" currently says: "If an ECU does not have a secure clock, we recommend the use of a Time Server for time attestations. The following subsection describes how a Time Server can be used in an Uptane implementation." - REVISE to strengthen as follows: "If a Primary ECU does not have a secure clock, then that Primary ECU SHALL use a Time Server or other secure external means to acquire accurate time. If a Secondary ECU does not have a secure clock, then that ECU SHALL use the time messages from its Primary ECU to acquire accurate time.. The following subsection describes how Time Servers can be used in an Uptane implementation. Section "Time server" currently says: "As the name suggests, a Time Server is a dedicated server that is responsible for providing a secure source of current time to ECUs that would not otherwise have access to this information. It informs ECUs in a cryptographically secure way through signed records and an exchange of tokens. The Time Server receives a list of tokens from vehicles, and returns back a list of signed records containing every token from the originally received list and at least one instance of the current time. If the Time Server is used, it is CONDITIONALLY REQUIRED to conform to the following requirements: • When the Time Server receives a sequence of tokens from a vehicle, it will provide one or more signed responses, containing the time along with these tokens. It MAY produce either one signed time attestation containing the current time and all tokens, or multiple time attestations each containing the current time and one or more tokens. All tokens should be included in the response. • The Time Server will expose a public interface for communicating with Primaries. This communication MAY occur over FTP, FTPS, SFTP, HTTP, HTTPS, or any other transport control the implementer may choose. • The Time Server’s key is rotated in the same manner as other roles’ keys by listing the new key in the Director’s Root metadata. It is also listed in the custom field of the Director repository’s Targets metadata (for partial verification Secondaries)." - REPLACE entirely. This section advocates the unwise use of an Uptane-unique external Time Server - NOT an acceptable practice in the current public Internet. The Uptane Standard text on Uptane Time Server (and the role) should be REMOVED entirely. Also, insecure transport protocols (specifically FTP, SFTP (FTP over SSH - obsolete), and HTTP) must NEVER be mentioned or allowed in Uptane implementations. ONLY TLS/1.3 (or for legacy reasons, TLS/1.2) should ever be mentioned as valid Uptane transport protocols. MQTT and others without the wrapper of TLS should NEVER be mentioned or allowed in Uptane implementations. "The IETF Network Time Protocol v4 (NTPv4, RFC 5905, https://datatracker.ietf.org/doc/rfc5905) with IETF Network Time Security for the Network Time Protocol (NTS for NTP, RFC 8915, https://datatracker.ietf.org/doc/html/rfc8915) SHOULD be used by an ECU to acquire accurate time. If IETF NTPv4 (or higher version) is used, then that ECU SHALL conform to IETF Network Time Protocol Best Current Practices (BCP 223 / RFC 8633, https://datatracker.ietf.org/doc/rfc8633/). If IETF NTPv4 (or higher version) is used, then that ECUSHALL discard any received NTP mode 6 and mode 7 packets to prevent the famous 2013 DDOS attack caused by from an old (1989) NTP implementation bug described in http://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho and https://us-cert.cisa.gov/ncas/alerts/TA14-013A. The work-in-progress IETF Roughtime protocol ( https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime/) and the IETF Roughtime Ecosystem ( https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime-ecosystem/) MAY be used by an ECU to acquire sufficiently accurate time to verify certificates (i.e., expiration) and signatures (i.e., freshness). Note that these are a revision and enhancement of the original Google Roughtime ( https://roughtime.googlesource.com/roughtime). See also the Cloudflare implementation (https://github.com/cloudflare/roughtime). The US Global Positioning System (GPS), originally Navstar GPS, SHOULD NOT be used as a secure time source by any Uptane ECU, because spoofing attacks against the unsecured, civilian GPS signals are common, as described in https://www.euractiv.com/section/defence-and-security/news/russia-responsible-for-massive-satellite-system-spoofing-study-finds/ and https://rin.org.uk/blogpost/1706945/332376/What-is-spoofing-and-how-to-ensure-GPS-security ." 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, Dec 3, 2021 at 11:26 PM Lois Anne DeLong ***@***.***> wrote: @iramcdonald <https://github.com/iramcdonald> will you be able to provide at least a rough version of text for this? All that is needed is the important points to be made. I will draft the PR, but you have the best handle on the issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#169 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE33UO7GM7CUKL2CDE6YNMDUPGJ77ANCNFSM4PK23K2A> . 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]

Thanks, Ira. I will happily integrate these suggested changes tomorrow.

[jhdalek55]

Issue also address in Deployment PR #124

[jhdalek55]

Can someone change the milestone here to Future?

[jhdalek55]

We have addressed the immediate issue here, but I think a rewrite to clarify the remaining question is called for.

[jhdalek55]

It's been almost 10 months since this was discussed. Can all or part of this question be addressed?

[jhdalek55]

The immediate question here has been resolved, so this issue will be resolved. In the future when IETF NTP v5 is published, we should update the text about secure time.