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

TIME SYNCHRONIZATION SECURITY

2

Agenda

 Time Synchronization Protocols?  Security Concerns  Network Time Protocol

• Security
• Autokey
• Network Time Security
• Conclusion

TIME SYNCHRONIZATION SECURITY

3

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?

TIME SYNCHRONIZATION SECURITY

4

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

TIME SYNCHRONIZATION SECURITY

5

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

TIME SYNCHRONIZATION SECURITY

6

Security Concerns

 What can happen if a time

synchronization protocol is attacked?

 Impacts:

• False Time
• Server not authentic, sends

incorrect time on purpose.

• Packet manipulated by

attackers during transport.

• Degradation of Service
• 'Flood' of requests
• Server takes too long to
• respond. Degraded time

keeping

 Numerous attacks possible,

leading to at least one of the above

Attack False Time Degradation Manipulation +

• Spoofing

+

• Delay/

Replay + + Crypt. Performance Attacks

• +

...

TIME SYNCHRONIZATION SECURITY

7

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

TIME SYNCHRONIZATION SECURITY

8

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.

TIME SYNCHRONIZATION SECURITY

9

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.

TIME SYNCHRONIZATION SECURITY

10

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

TIME SYNCHRONIZATION SECURITY

11

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)

TIME SYNCHRONIZATION SECURITY

12

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.

TIME SYNCHRONIZATION SECURITY

13

NTP Conclusion

Autokey Network Time Security Not considered secure Cryptographically. So far cryptographically secure. 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