Turning the clock back won't help defeat HTTPS if the root certificate store doesn't contain obsolete certs. The root certs will become invalid before their validity dates.
There is a clock attack which can brick many GPS receivers. GPS time uses a "week number", which is only 10 bits. Every 1024 weeks, GPS time wraps around. The first rollover was on 1999-08-15, and the next rollover is 2019-05-06. So standalone GPS receivers (not phones; they're "assisted GPS" and have to talk to a server) store a value indicating which rollover period they are currently in.
Sending phony signals to a GPS receiver which gradually advance the time can, for some units, convince it to advance the rollover period number in nonvolatile memory. On some devices, no way to reset it at all. Once this has happened, the ephemeris data won't be used properly, and it can't produce valid location data.
OpenNTPD has implemented a clever mitigation to this problem. It relies on trusting various key sites such as Google. You put one or more lines like this into your configuration file:
constraints from "https://www.google.com/search?q=openntpd"
As the man page puts it:
ntpd(8) can be configured to query the `Date'
from trusted HTTPS servers via TLS. This time
information is not used for precision but
acts as an authenticated constraint, thereby
reducing the impact of unauthenticated NTP
`Man-In-The-Middle' attacks. Received NTP
packets with time information falling outside
of a range near the constraint will be
discarded and such NTP servers will be
marked as invalid.
Of course, the devil is in the details. IIRC at the moment this check is only made when NTPD starts up, and not periodically during operation. But the general idea is probably quite solid.
The problem with this solution is that it's very expensive. Imagine couple hundreds of millions of computers making a TLS connection every few minutes.
For NTP there is Autokey (RFC 5906), which allows authentication of the servers with public-key crypto. It has various problems, one of them is that it's insecure.
The NTP working group is currently preparing a Network Time Security specification and its implementation in NTP, which is supposed to replace Autokey.
Not mentioned in the paper's implications section, so I'll ask, is there also a significant "bootstrapping" class of attacks on services where special access is granted to the earliest created account? Eg. Wordpress-like systems without a hardcoded admin username, and an installation process that asks the 'first' client to set the administrator credentials.
6 comments
[ 3.7 ms ] story [ 22.8 ms ] threadThere is a clock attack which can brick many GPS receivers. GPS time uses a "week number", which is only 10 bits. Every 1024 weeks, GPS time wraps around. The first rollover was on 1999-08-15, and the next rollover is 2019-05-06. So standalone GPS receivers (not phones; they're "assisted GPS" and have to talk to a server) store a value indicating which rollover period they are currently in.
Sending phony signals to a GPS receiver which gradually advance the time can, for some units, convince it to advance the rollover period number in nonvolatile memory. On some devices, no way to reset it at all. Once this has happened, the ephemeris data won't be used properly, and it can't produce valid location data.
For NTP there is Autokey (RFC 5906), which allows authentication of the servers with public-key crypto. It has various problems, one of them is that it's insecure.
The NTP working group is currently preparing a Network Time Security specification and its implementation in NTP, which is supposed to replace Autokey.
https://datatracker.ietf.org/wg/ntp/documents/
OS updates could increase this hardcoded date, and the user could still override it if they wanted.