Re: Successful remote AES key extraction

From: Vernon Schryver (vjs_at_calcite.rhyolite.com)
Date: 04/23/05 

Date: Sat, 23 Apr 2005 09:52:49 -0600 (MDT)

In article <slrnd6jr94.206n.usenet@stoneport.math.uic.edu>,
D. J. Bernstein <djb@cr.yp.to> wrote:

>> Or to move from academic handwaving toward the real world, if it is so
>> easy to detect 0.1 microsecond signals on say 25% of 8 million attempted
>> probes by naively discarding the outliers, why is it so much fun to try
>> to make NTP discipline clocks to within microseconds?
>
>You are, once again, fundamentally confused.
>
>An NTP client is trying to produce an accurate measurement of the time
>of day---the time since midnight, for example---from a relatively small
>number of packets. This has no relevance to the problem of producing an
>accurate measurement of a _small_ time interval from _many_ packets.

Perhaps there is some confusion between NTP and the protocols on ports
13 and 37. Never mind that NTP is not strictly a client-server but
almost a peer-to-peer protocol. An NTP peer does need to know the
time of day claimed by its peers, but the substance of the system is
measuriing the differences in the rate at which its local clock ticks
and the rates at which the remote peers tick as precisely as possible
so that the rate of the local clock can be adjusted. When a local
application needs to know the time, it checks the local clock instead
of chattering over the network. The point of NTP is to make the local
clock keep good time by measuring microseconds or less of clock skew.

The main sources of errors for those measuresments of clock ticking
rates are the same as the signal and the noise in an AES timing attack,
hiccups in either host including interrupts and stalling for memory
(e.g. cache delays) and variations in network delays. The basic NTP
transaction consists of
   - local system notes the time and sends a packet to the peer.
   - peer answers as quickly as possible with its own time
   - local system receives answer and notes the local time.
The purpose of those transations is to measure the difference between
the local clock and the remote clock that has accumulated since the
previous transaction. When NTP is clicking at microsecond synchronization,
those measurement are of microseconds or less, albeit multiplied by
delays among transactions.

On idle networks, NTP readily disciplines local ticks to peers very
closely. On the wild Internet, it's a whole lot more fun, which is
why NTP implementations have fancy math filtering that is a lot more
sophisticated than just discarding outliers.

Those transactions are repeated continually at a tiny rate compared
to an AES timing attack. The reported AES attacks ran at about 3000
packets/sec or 10 Mbit/sec, but over the real Internet to a target
that won't invoke DoS defenses and stop answering entirely, you only
hope for 100 Kbit/sec or 30 pps for more than seconds. (Never mind
how you reach 30 pps when each probably requires a round trip for a
TCP 3-way handshake.) 30 pps also seems like an optimistic rate outside
the targets own network for a passive attack. The eventual NTP rate
is about 1 packet every 90 seconds or 0.03% of 30 pps.

>> Or if packet delays are so well behaved, why is VoIP, which needs
>> merely 10s of milliseconds instead of micorseconds, so interesting to
>> implement and still so much different from the classical notion of
>> "toll quality"?
>
>Another laughably ignorant analogy.
>
>VoIP needs _constant_ service. When VoIP users bump into the occasional
>half-second network overload, they're justifiably annoyed. When an
>attacker bumps into the occasional half-second network overload, he
>simply waits and tries again.

VoIP users also retry when too many of their packets are lost or delayed
too much. Details of error recovery protocols matter a lot less than
the frequency at which those network overloads occur. What matters
more is that VoIP requires de-jitter buffering not for network overloads
but because network delays vary a lot. A VoIP implemenation must not
have too much buffering because it is better to have a drop-out than
go into satellite phone mode with 0.5 second delays. Perhaps the
problem of variations in network delays in real networks are more
visible to those who have worked on Internet video conferencing systems.

I notice a lack of response to evidence showing that typical Internet
links are not practically idle.

Perhaps it is time to tally unaddressed issues:

  - whether delays round trips would be required for active attacking
     because each probe might need a new TCP connection.

  - how many additional packets a passive attack needs compared to the
     2 million required for an active attack.

  - how close an attacker must be to the target to see enough traffic
     mount a passive attack

  - whether an active attack could be mounted over the Internet and
     collect sufficient data before ordinary DoS defenses stopped it.

  - whether typical Internet paths are mostly idle, and so whether
     variations in network delays make either active or passive attacks
     practical over the Internet as opposed to from within the target's
     own network.

Vernon Schryver vjs@rhyolite.com

Relevant Pages

  • Re: Getting NTP to correct only the clock skew
    ... to synchronize B's clock to the source of your CBR data. ... at least the maximum network latency, the packets out of B will have the ... that ignores that the NTP algorithm is a phase ...
    (comp.protocols.time.ntp)
  • Re: API for step time server notification
    ... Mind you if ntpd is stepping after having been running for a few hours, ... many network measurements are very badly affected by time ... ntp sources for a while (I set up the step threshold to 1s on the ntp ... You might also want to let the clock freewheel (ie do not use ntp to ...
    (comp.protocols.time.ntp)
  • Re: broadcast client
    ... synchronizing with the same ntp server. ... ntp displined clock. ... completely undisciplined local clock configured to be the NTP reference clock. ... It's not running from a refclock, but over a network and Dave Mills assumes that when running over a network one needs minpoll 6 maxpoll 10. ...
    (comp.protocols.time.ntp)
  • Re: SNTP with 1ms of precision?
    ... My question is about Time Accuracy of NTP/SNTP protocol. ... network with 50 hostsusing only swithes, ... ntp relies on the outgoing and ingoing times are the same. ... The internal clock in my devicesstarts with the crystal ...
    (comp.protocols.time.ntp)
  • Re: Successful remote AES key extraction
    ... No, the start of the epoch has nothing to do with the accuracy of NTP, ... The primary result of NTP is a clock that ticks at the right frequency. ... - how many additional packets a passive attack needs compared to the ... million required for an active attack. ...
    (sci.crypt)