[ntp:hackers] A stop-gap authenticated time service

Greg Dowd Greg.Dowd at microsemi.com
Tue Nov 10 16:24:26 UTC 2015


If you are steering a clock using current NTP, MitM can move it.  And accuracy is application dependent so it may be premature to say that what Dave Mills' called a thermometer can accurately maintain time for days.  In theory, that's why you were running the protocol to begin with.

-----Original Message-----
From: hackers [mailto:hackers-bounces+greg.dowd=microsemi.com at lists.ntp.org] On Behalf Of Miroslav Lichvar
Sent: Tuesday, November 10, 2015 2:09 AM
To: Poul-Henning Kamp
Cc: hackers at lists.ntp.org; magnus at rubidium.se
Subject: Re: [ntp:hackers] A stop-gap authenticated time service


On Tue, Nov 10, 2015 at 07:58:05AM +0000, Poul-Henning Kamp wrote:
> The only variable left for the attacker to tamper with is the RTT 
> which I can reliably measure and thus detect said tampering.

I don't think delay added in a MITM attack can be realiably detected.
The attacker can increase the delay by a small amount and slowly, so it looks like the network is getting congested or the HTTPS server is overloaded and it needs more time to respond.

Sure, the admin could set a very tight limit on the delay, but then it will drop measurements when the network really is congested or the server is overloaded.

> If the clock was already suitably disciplined, it will take days 
> before the accumulated phase error becomes prohibitive, and that is 
> plenty of time to raise an alarm where it matters.

I think that depends on what error is acceptable. The attacker doesn't need to delay the packets much in order to throw the client's frequency off and let it drift away. The frequency error can be much larger than what it would be if the synchronization was just suddenly stopped. This is why it's important to monitor if the servers are reachable and the clock is still being updated.

Miroslav Lichvar
hackers mailing list
hackers at lists.ntp.org

More information about the hackers mailing list