Re: Successful remote AES key extraction
From: Vernon Schryver (vjs_at_calcite.rhyolite.com)
Date: Sat, 23 Apr 2005 09:52:49 -0600 (MDT)
In article <email@example.com>,
D. J. Bernstein <firstname.lastname@example.org> 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
Vernon Schryver email@example.com