Slashdot Mirror
Researchers Warn Computer Clocks Can Be Easily Scrambled Via NTP Flaws (networkworld.com)
alphadogg writes: Researchers at Boston University said this week that they've found flaws in the Network Time Protocol (NTP), a 30-year-old Internet protocol whose security shortcomings could undermine encrypted communications and even jam up bitcoin transactions. The importance of NTP was highlighted in a 2012 incident in which two servers run by the U.S. Navy rolled back their clocks 12 years, deciding it was the year 2000. Computers that checked in with the Navy's servers and adjusted their clocks accordingly had a variety of problems with their phones systems, routers and authentication systems.
There is at least one alternative out there, and reason to use it.
That would work if the attackee uses only the attacker's server.
That's not how NTP is supposed to be used: It is designed to pull
time from multiple sources, weigh their accuracy/trustworthyness
over a longer time window against each other (with rather sophisticated
algorithms), and use the best ones as the time source to follow.
I usually go for 5-6 independent sources (with independent stratum0 masters!):
some national labs' PPS; GPS; etc. - this doesn't make an attack impossible,
but it mitigates the "the master time source is wrong" problem. This has
happend by accident before, so even without considering active attacks, it's
just the sensible thing to do.
OpenNTP uses a pool of HTTPS servers to do basic sanity checks against the NTP time. It does a kind of simple NTP using TLS, then uses NTP against your time servers. If the NTP time is too far off from the TLS time, it rejects it. Pretty much all of the practical security of NTPSEC without all of the accuracy reducing overhead.
There is at least one alternative out there
Whoever proposed tlsdate as an alternative to NTP has no idea how either NTP or tlsdate work. What moving to tlsdate is doing is replacing a well-designed clock-synchronisation protocol talking to precise time servers with an opportunistic gimme-whatver-time-you've-got mechanism that returns a one-off estimate of an approximate time on a web server, assuming the server doesn't just set the time field to random bytes as many do. They're totally different things.
If you're really worried about this, run your own stratum 1 clock and serve NTP off that. If you're worried about the cost of a dedicated NTP server, build it yourself using any number of instructions on the Internet, e.g. these ones.
Many devices such as tablets and cell phones contain GPS, another hard to spoof time source. Multi factor authentication checking NTP, Cell tower time, and GPS would make a very robust system that could detect tampering. On an IMSI catcher, Time wrong, GPS time difference would catch it. NTP spoof, Cell and GPS mismatch would catch it. Local area GPS spoof, Cell and NTP would catch it. Targeting a mobile device with 3 factor time authentication + internal clock for 4 factor would be very hard to spoof undetected.
If you want to roll your own, GPS receiver modules for RC drones are under $20 online. Adding GPS to your NTP corporate servers is not difficult. You can protect your network with a little hardware and software.
The truth shall set you free!
The mentioned TLSdate isn't a NTP replacement.
It openly admits is roughly only good for a <1-5 second accuracy. That's crap. A typical NTP setup can easily maintain ~10-15 millisecond accuracy using public stratum 2 or 3 NTP servers from the Internet.
Sure, tlsdate is a simple, secure rdate replacement, and while many people without precise timing requirements it is good enough, it is simply not suitable for a huge range of applications that are time sensitive, or are timing / synchronization critical.