Time Synchronization Security Chaudhry Tanmay Agenda Time - PowerPoint PPT Presentation

Lehrstuhl Netzarchitekturen und Netzdienste Institut für Informatik Technische Universität München Time Synchronization Security Chaudhry Tanmay

Agenda  Time Synchronization Protocols?  Security Concerns  Network Time Protocol  Security • Autokey • Network Time Security  Conclusion 2 TIME SYNCHRONIZATION SECURITY

Time Synchronization Protocols  Purpose : Synchronize computer clocks over a network  Different protocols, but usual operation includes:  'Server' – Has correct time  'Client' – Wants correct time.  Communication between the two entities to synchronize client's clock  Two most widely deployed protocols:  Network Time Protocol  Precision Time Protocol  Security Concerns? 3 TIME SYNCHRONIZATION SECURITY

Network Time Protocol  Most widespread  Accuracy  1ms on LAN  ~10-100ms on public Internet  Architecture – Hierarchical  Multiple levels of 'Servers'  Closer to the Top = More accurate  Higher node serves lower nodes  Peer connections also possible 4 TIME SYNCHRONIZATION SECURITY

NTP – Synchronization Algorithm  Client 'requests' the server for time and calculates two components based on the 'response'  Round Trip Time(δ ) and Offset(θ)  'Offset' is basically difference between the two clocks  Client adjusts it's own clock to minimize 'offset'  All calculation is based on time- stamps of the packets  δ = (t3 - t0) – (t2 – t1)  θ = ((t1 – t0) + (t2 – t3))/2 5 TIME SYNCHRONIZATION SECURITY

Security Concerns  What can happen if a time Attack False Time Degradation synchronization protocol is attacked?  Impacts: Manipulation + -  False Time • Server not authentic, sends Spoofing + - incorrect time on purpose. • Packet manipulated by Delay/ + + attackers during transport. Replay  Degradation of Service • 'Flood' of requests Crypt. - + • Server takes too long to Performance respond. Degraded time Attacks keeping ...  Numerous attacks possible, leading to at least one of the above 6 TIME SYNCHRONIZATION SECURITY

NTP – Security  Consider the two same problems as above:  Fake 'Server': • Sends falsified time-stamps – Protocol Breaks !  Packets Manipulated: • Alter Time-Stamps • Capture and Delay/Replay packets – Protocol Breaks  Security Mechanisms  Autokey  Network Time Security 7 TIME SYNCHRONIZATION SECURITY

Security Requirements  Aim is to prevent 'False Time' and 'Service Degradation'  Security Mechanism must:  Prevent false time – How? • Successfully authenticate 'Server' • Protection against packet manipulation (including delay/replay)  Prevent Degradation of Service – How? • No recurrent computationally intensive tasks!  Most times, balance required between the two. 8 TIME SYNCHRONIZATION SECURITY

Autokey  Available as an Extension to NTP  Major Components:  Message Digests - Packet Integrity  Digital Signatures + Certificates – Identity  Session Key – 'Autokey' to encrypt • Autokey = IPv4 Source Address + Destination Address + KeyId + Cookie – KeyID = Client Specific – Cookie = Random Bits based on Server Seed  In theory, should take care of both server authentication and packet manipulation protection. 9 TIME SYNCHRONIZATION SECURITY

Autokey Vulnerabilities  Server Seed – 32 bits  Request Cookie and brute force the server seed  Similarly, Cookie – 32 bits  Only secret component  Open to Brute Force  Client Authentication based on IP Address  Masquerade/Spoofing breaks this 10 TIME SYNCHRONIZATION SECURITY

Network Time Security  Started out as Autokey v2, aiming to fix it's short comings  Same philosophy with certain differences:  Use X.509 certificates for Identity Authentication  'Cookie' still present but, • Cookie = MSB_128 (HMAC(ServerSeed, H(Certificate Client)) • 128 bits, fixes problem of Brute Force attacks • Includes client certificate, can't request cookie for others by masquerading IP  Also aims to be available for PTP (not yet though) 11 TIME SYNCHRONIZATION SECURITY

NTS – Vulnerabilities  Fixes Autokey's vulnerabilities successfully, but still new. No thorough analysis yet.  Other Issues:  Initial Verification of Certificates  Delay Attacks  Distributed Denial of Service?  Recommendations for these issues as well, but not part of protocol yet. 12 TIME SYNCHRONIZATION SECURITY

NTP Conclusion Autokey Network Time Security Not considered secure So far cryptographically secure. Cryptographically. However no thorough analysis exists. Minimal impact on performance. Uses stronger encryption, but stateless server means it must be repeated, potentially performance degrading. Easy extension to NTP Backward compatible and does not effect operation if not implemented on either side. Only NTP Will be available for PTP as well 13 TIME SYNCHRONIZATION SECURITY