The December 2022 issue of IEEE Spectrum is here!

Close bar

It’s Surprisingly Easy to Hack the Precision Time Protocol

A simple attack can knock off a system’s timing by 48 years

3 min read
Illustration of an open lock with light beams bursting out of it.
Illustration: iStock

When it comes to synchronizing large and important networks, for instance in the energy or financial sectors, every microsecond counts. Different protocols have been designed and implemented to achieve such precision. One of the most effective approaches is called IEEE 1588-2008 or the Precision Time Protocol (PTP). But while PTP can in theory help networks synchronize their actions to within a microsecond, a team of computer scientists recently demonstrated that PTP also makes it possible—in multiple ways—to hack such a system.

In a network using PTP, one central clock, referred to as a “master” clock, is responsible for coordinating and communicating time to “slave” clocks across the network (these controversial terms were recently removed from the popular programming language Python, but continue to be used in many fields). The master clock accomplishes this by sending time-stamped data packets to the slaves. The protocol itself measures and compensates for time delays over the network.

A team of researchers from IBM and Marist College recently sought to test PTP from a cybersecurity standpoint, probing for weaknesses. They identified a remarkably simple but effective way to hack a PTP network—throwing the timing of the slave clocks off by a whopping 2,149.5 minutes after just a 37-second attack. They describe this approach, as well as several others, in a study published 23 May in IEEE Transactions on Instrumentation and Measurement.

The first form of attack that the researchers developed relies on the packets of data sent across the network that are used to establish the master-slave hierarchy. To identify a master clock, each node sends out a time-stamped ANNOUNCE data packet, and the clock with the best quality is selected to be the master. The master then multicasts its timestamp to all slave nodes via a SYNC message, which is sent to all nodes on a periodic basis.

The researchers were able to infiltrate the network by “sniffing” out the ANNOUNCE and SYNC packets of the legitimate master clock. Next, they created a rogue master clock that creates the same ANNOUNCE and SYNC messages—which then sent an onslaught of 292 such packets per second to the slave clock, overwhelming it. This is known as a denial of service attack

“This attack was very effective at generating incorrect timing values,” says Casimer DeCusatis, a research at Marist College involved in the study. “It took only 37 seconds, including time to sniff packets, for the slave timing offset and slave clock frequency to change by 30 seconds or more… The maximum offset we observed in all our testing from this type of attack was over 48 years.”

He notes that the slave was unable to recover from this kind of attack, even when the researchers left the network running for more than an hour after the attack ended. DeCusatis says, “Since many applications will be disrupted by much smaller discrepancies in timing, this attack can significantly impact the PTP network.”

What’s worrisome is that this type of attack would be fairly easy to execute. DeCusatis points out that it wasn’t necessary to know the clock ID or IP address of the slave, and it wasn’t necessary to disrupt communication between the grand master and the target slave. He says the code used to send the fake packets can easily fit on a USB key.

In a more complicated approach, the team shows it’s also possible to hack a PTP network by creating an evil twin of the master clock that can take control over the timing network.

DeCusatis says there are several ways to address these issues. One example is by constructing the master clock ID from its network ID and then creating a way in which slaves can verify the master’s network address. Another suggestion he offers involves giving a unique ID to each packet, which the slave could verify.

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
A plate of spaghetti made from code
Shira Inbar

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less