search

uptane / uptane-standard

standard for Uptane
https://uptane.github.io
Other
37 stars 31 forks source link

Requiring "Secure Time" #169

Closed allen-cain-tm closed 1 year ago

allen-cain-tm commented 4 years ago

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 commented 4 years ago

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 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/blueroofmusichttp://sites.google.com/site/highnorthinc http://sites.google.com/site/highnorthincmailto: 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 notifications@github.com 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 https://github.com/uptane/uptane-standard/issues/169, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE33UO5AABY2VCLJRSYJGZLR54QI7ANCNFSM4PK23K2A .

trishankatdatadog commented 4 years ago

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 commented 4 years ago

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

Irrespective of the signatures over metadata, the signature(s) on ECU firmware binaries could have used out-of-date or revoked keys.

Cheers,

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/blueroofmusichttp://sites.google.com/site/highnorthinc http://sites.google.com/site/highnorthincmailto: 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 < notifications@github.com> 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 https://github.com/uptane/uptane-standard/issues/169#issuecomment-682988805, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE33UO5QHZ4QBUC7SBJKYSDSC7U4BANCNFSM4PK23K2A .

trishankatdatadog commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 https://github.com/uptane/uptane-standard/issues/169#issuecomment-888672673, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGROD5JJMZVETTCI4LI3NLT2CDKZANCNFSM4PK23K2A .

jhdalek55 commented 3 years ago

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

jhdalek55 commented 3 years ago

@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 commented 3 years ago

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

jhdalek55 commented 3 years ago

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 commented 2 years ago

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

jhdalek55 commented 2 years ago

@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 commented 2 years ago

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

"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."

"ECUs MUST have a secure source of time. An OEM/Uptane implementer MAY use any external source of time that is demonstrably secure."

"5. OPTIONAL: Send latest time to Secondaries (Section 5.4.2.5)"

"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 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."

"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)."

"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 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/blueroofmusichttp://sites.google.com/site/highnorthinc http://sites.google.com/site/highnorthincmailto: @. @.>(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 https://github.com/uptane/uptane-standard/issues/169#issuecomment-985965007, 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 commented 2 years ago

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

jhdalek55 commented 2 years ago

Issue also address in Deployment PR #124

jhdalek55 commented 2 years ago

Can someone change the milestone here to Future?

jhdalek55 commented 2 years ago

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

jhdalek55 commented 2 years ago

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

jhdalek55 commented 1 year ago

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.