
GPS Flaw: Security Expert Says He Won't Fly April 6 - musha68k
https://www.tomsguide.com/us/gps-mini-y2k-rsa2019,news-29583.html
======
nullc
Most GPS devices made at least after 1999 implement an unwrapping algorithm
that has an epoch at some random date set by the maker in the firmware.

Essentially the firmware knows that the day is later than say, July 4th 2004
because that's when it was built. If the GPS date is less than that date, it
adds 1024 weeks repeated until its greater than the hardcoded date.

This means that the exact wrap date will depend on the receiver, though some
will wrap on April 6th

Fortunately GPS rollover doesn't normally get in the way of positioning. The
only way it would is if the 'wrong' dates triggered some other bug.

~~~
makomk
Apparently it did cause positioning issues last time around. One major problem
was that GPS receivers calculate which satellites they expect to see in the
sky based on the current time and the almanac+ephemeris data, and at the
wraparound some receivers started expecting all the satellites to be where
they would've been 1024 weeks ago and completely lost lock. I think there were
some problems caused by individual satellites wrapping their counts slightly
before the actual GPS time too. Receivers which are started up after the 6th
should be fine though.

~~~
gsich
Wrong almanac means a somewhat longer time for first fix.

------
olliej
Ok so just to be clear this isn’t the first time a gps time rollover has
occurred. The only real difference between this time and last time is that god
technology is widely deployed at the consumer level.

As for the risk to flights:

* this has happened before, and I don’t recall any plane accidents then

* I assume pilots would notice if they’re suddenly substantially off course - it’s not a gradual drifting change, it’s a big kachunk change if software isn’t handling it correctly.

* there are many other (non-gps) signals including radio that are used to track where an aircraft is.

If anything I’d be more concerned about drivers getting lost in their cars

~~~
dsl
> this has happened before, and I don’t recall any plane accidents then

ADSB (the "non-gps" radio signals you mention) broadcasts the planes
location... sourced from GPS. Because of deployment requirements there are
tons of sub-$2000 ADSB out boxes on the market now that didn't exist in 1999,
and hardware wise they are a race to the bottom. (Edit: I also just realized
the software could have been written by someone who wasn't alive in 1999).

I don't think anything is going to happen. But I also don't like saying
nothing is going to happen, because that is when you get a complex failure.

~~~
7952
I think the parent meant radio beacons on the ground. These give an angle or
distance to a known location.

ADSB does broadcast the planes location. But this is only used in a very
limited fashion. ATC use radar as the main source of information.

~~~
dsl
ADSB is how planes see each other without relying on ATC, and feeds collision
avoidance systems. The FAA instructs pilots to believe these systems over ATC
because it updates faster than radar.

In a very hypothetical worst case scenario, a malfunctioning ADSB transmitter
could suddenly put itself right in the path of a large commercial aircraft,
forcing it to make dangerous maneuvers to avoid a collision.

~~~
sho
TCAS[1] doesn't rely on GPS though, it builds a picture of the airspace around
it through triangulation and radar-style ranging - I believe it only relies on
altitude to be reported by the other aircraft, which is generally very
accurate.

I suppose anything is possible, but I've never heard of it actually getting
plane positions wrong due to sensor malfunctions. Far more likely is pilots
not following, or improperly following, its warnings. It's not capable of
assuming control over the plane, as far as I know...

[1]
[https://en.wikipedia.org/wiki/Traffic_collision_avoidance_sy...](https://en.wikipedia.org/wiki/Traffic_collision_avoidance_system)

------
Zombiethrowaway
Not GPS related, but the day I am really worried about is January 19th 2038
3:14:07AM... Unix time will roll over if stored in a signed four byte integer
field.

~~~
SAI_Peregrinus
Or slightly later the use of a 2-digit year in x509 certificates. The standard
assumes that dates with year <50 are 20xx, and >=50 are 19xx. It doesn't help
that this is one of the best designed, most understandable, and well-thought-
out parts of the x509 standard.

------
cheesedoodle
What he is pertaining to is WNRO, the 10-bit binary counter representing the
GPS Week Number, a key piece of the date and time information. Every 19.7
years this week number counter reaches its limit and rolls back to zero. [0]

[0] [https://www.trimble.com/wnro/](https://www.trimble.com/wnro/)

------
bronco21016
In the US at least I’m not aware of a single certified aircraft that relies on
GPS as the primary and only means of navigation. Even brand new Airbus
320/321s and Boeing 737-700/800/900s have INS installed and is considered
primary. GPS and radio based navigation add correction and cross checking to
the INS derived position. GPS is necessary for RNP but RNP procedures are not
yet widespread enough to cause major disruption to the national airspace
system.

As we move closer and closer to primarily an RNP system a GPS outage may
become more disruptive but for at least several more decades the
infrastructure and equipment to navigate using INS and radio based means such
as VORs will provide a proven and safe backup.

------
yuchi
> So that this doesn't happen again any time soon, GPS devices made in the
> past decade use 13 bits for the week counter, yielding a total of 8,192
> weeks or 157 years. Those devices will not have to restart time until 2137,
> by which time our descendants will have created a whole new set of
> technological problems.

I love the snarky final sarcasm.

------
Arbalest
For the majority of us, probably the only thing that will happen is some power
outages in some areas. Charge some portable batteries and buy some bottled
water (mains pumps maybe?). It won't be a problem for more than about a day.

~~~
jimktrains2
I think you commented on the wrong article? Why would gps-derived date issues
cause problems with electrical generation and distribution?

~~~
snowwindwaves
Gps timestamped electrical measurements are sent over fiber optic cables
between substations on either end of transmission lines to make sure current
in is the same as current out, roughly. Also for measuring and controlling
power flows.

[https://www.smartgrid.gov/recovery_act/program_impacts/appli...](https://www.smartgrid.gov/recovery_act/program_impacts/applications_synchrophasor_technology.html)

~~~
jimktrains2
Interesting! Thanks for the link.

------
wildylion
He probably won't fly April 5, or April 7, either.

------
jlgaddis
> _Universal Time Code (UTC)_

Uh, Coordinated Universal Time [0]?

I can't be the only one who, upon seeing little things like this, immediately
has doubts about the accuracy of everything else in the article.

[0]:
[https://en.wikipedia.org/wiki/Coordinated_Universal_Time](https://en.wikipedia.org/wiki/Coordinated_Universal_Time)

~~~
sho
Apropos: [https://en.wikipedia.org/wiki/Gell-
Mann_amnesia_effect](https://en.wikipedia.org/wiki/Gell-Mann_amnesia_effect)

~~~
dingaling
That keeps getting quoted but with no evidence that it exists on a large
scale.

If I read a $NEWS_SOURCE article and they get something wildly incorrect I
don't just proceed to the next article, I close the tab / newspaper.

~~~
TeMPOraL
> _If I read a $NEWS_SOURCE article and they get something wildly incorrect I
> don 't just proceed to the next article, I close the tab / newspaper._

Then couple hours or days later you get an article on a different topic from
the same $NEWS_SOURCE, and you read it like gospel.

What changed over past decades is the way we consume news - it's "unbundled"
now; much like we consume movies per-title and not per-channel, we consume
news per-story, not per-newspaper. But this didn't improve news quality.

Gell-Mann amnesia exists at scale, it's one of the most trivial things to
verify - you just need to talk with people. With your family, friends, or with
folks on any social media site / on-line bulletin board. You'll see countless
of examples of people who suffer from this amnesia, who can't perform the most
obvious generalization from observation - to conclude that, since for any
topic they know anything about every news article is utter bullshit, and since
their friends report the same observations for their domains, the news on the
topics they're not experts on must be bullshit too.

------
cylinder
Can someone sensible with expertise comment on this please?

~~~
elfchief
Sure, gps geek and time-nut here.

The rollover problem is a hard one to fix, because there's no reasonable way
for a GPS (at least one using LNAV (legacy) signals -- pretty much all of
them, though I don't know what modern passenger jets use) to know which GPS
"epoch" they're in. If you don't know what epoch you're in, you don't know
what the date is.

Some GPSs solve this by recording the week number of their firmware build, and
if the signals they get indicate the week number is less than that, they
assume they're in the next epoch and update accordingly. Still means you run
out of time, but you get a full ~19 years of life first (and then fail at some
random GPS week). Some use fuses to record when an epoch has passed. Some use
out of band information. Some store the current epoch in flash or battery-
backed RAM. Some just never address the problem.

Thing is, though -- the only effect this has, is that it makes the GPS return
the wrong date. That's it. The week rollover has _no_ effect on navigation
unless there's some significant bugs in the unit, or something external to the
GPS relies on the date being output and doesn't deal well with the date
suddenly going back in time. That's it.

I'd be kinda shocked if airplanes were just jam-syncing the clocks of their
nav computers to the output of a GPS, and then had those nav systems be
dependent on that time. But then again, I work in the tech industry, and I've
seen the kinda code that goes into most products, so maybe I _wouldn 't_ be
that shocked.

(I also can't imagine that GPS units used in aircraft aren't directly tested
for their behavior during the week rollover. It's a well known and understood
problem, and even if some random GPS manufacturer drops the ball, stuff that
goes into aircraft has to go through certification for a reason...)

~~~
nyc111
> gps geek and time-nut here.

This is off topic, but since you describe yourself as "gps geek" I thought I
ask. Is it possible to gain access to the actual operational code where GPS
operators correct for General Relativity? I'm not disputing GR, I just want to
find out if this is a myth or true. Thanks.

~~~
elfchief
If you want this straight from the spec, grab a copy of IS-GPS-200J (it's
free, just google it), look at section 3.3.1.1, which talks about the carrier
frequencies of the various signals. From that:

"The carrier frequencies for the L1 and L2 signals shall be coherently derived
from a common frequency source within the SV. The nominal frequency of this
source -- as it appears to an observer on the ground -- is 10.23 MHz. The SV
carrier frequency and clock rates -- as they would appear to an observer
located in the SV -- are offset to compensate for relativistic effects. The
clock rates are offset by (delta f)/f = -4.4647E-10, equivalent to a change in
the P-code chipping rate of 10.23 MHz offset by (delta)f = -4.5674E-3 Hz. This
is equal to 10.2299999954326 MHz. The nominal carrier frequencies (f0) shall
be 1575.42 MHz, and 1227.6 MHz for L1 and L2, respectively."

In this context, "SV" is "Space Vehicle", a.k.a. a GPS satellite.

You also have to make a relativistic adjustment in the user segment (aka "your
GPS"). You can see an example of doing this correction in open-source software
GPS receivers, for example [https://github.com/jks-
prv/Beagle_SDR_GPS/blob/de895035e93ba...](https://github.com/jks-
prv/Beagle_SDR_GPS/blob/de895035e93ba1b1b5b8f58df4149c32a4cdbfde/gps/ephemeris.cpp#L188)
. This adjustment is documented in the above spec, in section 20.3.3.3.3.1
(which you'll see is almost verbatim copied into the the code linked above)

~~~
nyc111
Great! Thanks. I'll study these.

