Trjtdtk

The NPR new item and audio podcast The Global Positioning System Resets talks about a 19 year cycling of something in the GPS system, but it's not clear what it is.

Every 19 years, the Global Positioning System resets a measure of time built into its program. The latest rollover is Saturday and NPR's Scott Simon asks cybersecurity expert Frank Cilluffo about it.

It's Y2K for GPS. The Global Positioning System was designed with a limit for the number of weeks it could count. Every 19 years, the program reaches that limit and the count resets. That happens tonight. What might happen tonight? Frank Cilluffo is director of the McCrary Institute for Critical Infrastructure Protection and Cyber Systems. He joins us now from the campus of Auburn University. Thanks so much for being with us.

1. What is it exactly that cycles or "rolls over" every 19 years?


2. Is it in any way analogous to y2k?


3. Is there any cybersecurity issue associated with the rollover more subtle than GPS simply not working for some users? For example, is there some hacking potential associated with this moment?

The field in the protocol that specifies the week number is a 10-bit value. In most computers, when an (unsigned) integer exceeds its maximum value, it wraps around to zero. This is roughly similar to Y2K, though is more like the upcoming year 2038 problem (but with weeks instead of seconds). This 10-bit value will wrap around, and the GPS system will hold the same time value as it held back in 1999.

Yes, this can cause some security issues. Many people use GPS signals as a way to tell time instead of its traditional use with geolocation. Accurate time is extremely important for security, such as for verifying that a certificate is valid and has not expired. If an operating system exclusively uses GPS to calibrate its internal clock, this rollover could, if handled improperly in firmware, result in certificate validation errors or even the failure to check for security updates. See also How important is local time for security?.

@forest’s answer is correct. But what makes the rollover slightly more problematic is that many GPS receiver manufacturers have accounted for it by pre-programming an internal “pivot date” in the firmware. That is, if a receiver was manufactured/programmed in, say, 2015, then there is internal logic that says “if the date appears to be prior to 2015, it’s obviously nonsense so add 1024 to the apparent week number”. This means the receiver will roll over, just some time in the future, 1024 weeks after the pivot date.

There’s a good explanation here.

This means that most receivers will roll over at different times making it hard to plan for. The date, unless known by the manufacturer, needs to be tested for (using a GPS simulator you need to go way in the future, then in the past, until you can narrow down the actual date).

Location based receivers (car sat navs for example) should continue to function (although their date may be wrong unless fixed in firmware). However, the prevalence of NTP, PTP and other time-of-day protocols in the finance, power, telecom and many other industries, the source of which is almost always traceable back to GPS, makes this a potential headache.

Side note: Some equipment I’m aware of actually rolled over earlier than the 6th April 2019 date, back in 2018. I’m aware of at least one large-ish telecoms provider experiencing a major outage because they hadn’t accounted for it. Their switches all started receiving a time way in the past which caused them to crash.

Further side note: New GPS satellites (i.e. those launched since around 2014 or so) also broadcast a 13-bit week number value. Any receivers designed to utilise them won't roll over for 8191 weeks, or 157 years.

Other answers explain the WNRO problem as an overflow/high order truncation/rollover problem.

This is correct.

It is a security issue because services may be impacted. Not all security issues are about data loss. Business continuity is strangely important to people as well.

This type of thing has been going on in the digital world for a while now.
Windows 95, 98 and possibly NT 3.51 would crash on millis rollover after 49.7 days.

The real time clock in many early PC motherboards could only cope with an 8 year range, (3 bits) putting a ceiling on the date (1987 for many 8086's).

Enough has been written about Y2K and tm_year from time.h (which did not rollover but got fat). I recall too we had a post Y2K issue with packed decimal (COMP-3) date arithmetic in point of sale systems world wide.

The important thing is that it is foreseeable, so it should be dealt with by software, almanac data, and appliances that depend upon it.