Clock synchronization systems are vulnerable to a number of security failures that are exceptionally difficult to address. TimeKeeper has a growing portfolio of security protections to provide a defense in depth at wire speed. The defense in depth approach to security involves multiple levels of protection that support each other to complicate the task of an attacker. For example, TimeKeeper’s instrumentation of GPS signal strength and powerful interference detection software in Skymap combines with TimeKeeper source check technology to detect and defeat jamming and spoofing. Several other subsystems also add protection. A recently added component implements the NTP standard packet authentication technology while preserving TimeKeeper’s unique ability to synchronize to submicrosecond accuracy levels using either NTP or IEEE 1588 PTP.
Encrypting time synchronization packets is obvious but neither a panacea nor simple to do without sacrificing performance. And a security system that caused performance problems in a synchronization system would essentially be self defeating – possibly throwing the time calculation off even without an attacker’s assistance. NTPv3 specification RFC-1305 addresses one problem by putting cryptographic identifiers in time packets. Secret keys are distributed by any one of a number of secure methods and then the receiver uses its keys to compute a checksum on a time packet which it can then compare to the identifier in the packet. If they match, the packet should come from an authorized source.
TimeKeeper makes it simple and straightforward – here’s how it works:
- Create a set of keys to be used by the clients and the server to validate the NTP exchange. (The tools for this are included with TimeKeeper Grandmasters.)
- Put these keys in place on the client and server. Generally any particular client may only use a subset of the keys the server knows about.
- On the server, enable the keys by telling TimeKeeper which ones are enabled. This is done in the TimeKeeper GUI, like this:
4. Then, on the client, also tell TimeKeeper which key to use. Here we’re using key #5 on the client, which corresponds with key #5 above on the server:
5. Apply the changes and restart TimeKeeper.
Now, when the TimeKeeper server gets a request, it can use these keys to validate the client data wasn’t tampered with in-flight between the client and the server. When the client gets its time from the server, it also knows that the packet is intact from the server and wasn’t modified by some actor in the middle.
Significant engineering time was invested in making sure that, on TimeKeeper, this security mechanism did not impose either a cost in accuracy or come with a high level of processing overhead. The addition of the checksum does require CPU time on the server and the client, but TimeKeeper optimizations keep this time to a minimum. The overhead is not detectable until a TimeKeeper server is serving many tens of thousands of requests per second. On the accuracy side, there’s little to no loss when using TimeKeeper’s high speed implementation of the protocol. Sub-microsecond accuracy with NTP is possible, just like before – parity with PTP. The only difference is that there is an additional level of assurance that the packet exchanges weren’t modified, intentionally or not.
NTP authentication can also be rolled out in stages. Authentication can be enabled on the server and with zero changes on clients. If a client asks for time without authentication, TimeKeeper provides a response without authentication. Clients, TimeKeeper or otherwise, can enable the feature as needed and as IT staff has time to update them, making sure the impact to the network is minimal and on IT team schedule.
Not everyone is concerned with authentication, but it’s slowly becoming a requirement for many of our customers. So we’ve worked to make the process of adding authentication as easy as possible – if you’ve got any questions, let us know at [email protected].
