Problem - Kevin Tafuro

Particularly when an attacker may have local access to a machine, it can be a hopeless
task to figure out what all the possible channels are. Making things difficult is
the fact that machines behave very deterministically. This behavior means that the
only points where there is the possibility for any entropy at all is when outside inputs
are added to the system.
The next problem is that, while a trusted entropy accumulator might be able to
take some measurements of the outside data, there may be nothing stopping an
attacker from taking measurements of the exact same data. For example, suppose
that an operating system uses keyboard strokes as an entropy source. The kernel
measures the keystroke and the timestamp associated with the key press. An
attacker may not be able to measure keystrokes generated by other users, but he
should be able to add his own keystrokes, which the operating system will assume
is entropy. The attacker can also take his own timestamps, and they will be highly
correlated to the timestamps the operating system takes.
If we need to use our own entropy-gathering on a system that does its own, we trust
the operating system’s infrastructure, and we use a different infrastructure (particularly
in terms of the cryptographic design), measuring entropy that the system also
measures will generally not be a problem.
For example, suppose that you have a user interactively type data on startup so that
you can be sure there is sufficient entropy for a seed. If an attacker is a local nonprivileged
user, you can hope that the exact timings and values of key-press information
will contain some data the attacker cannot know and will need to guess. If the system’s
entropy collection system does its job properly, cryptographically postprocessing
entropy and processing it only in large chunks, there should be no practical way
to use system infrastructure as a channel of information on the internal state of your
own infrastructure. This falls apart only when the cryptography in use is broken, or
when entropy estimates are too low.
The worst-case scenario for collecting entropy is generally a headless server. On such
a machine, there is often very little trustworthy entropy coming from the environment,
because all input comes from the network, which should generally be largely
untrusted. Such systems are more likely to request entropy frequently for things like
key generation. Because there is generally little entropy available on such machines,
resource starvation attacks can be a major problem when there are frequent entropy
requests.
There are two solutions to this problem. The first is operational: get a good hardware
random number generator and use it. The second is to make sure that you do
not frequently require entropy. Instead, be willing to fall back on cryptographic
pseudo-randomness, as discussed in Recipe 11.5.
If you take the second approach, you will only need to worry about collecting
entropy at startup time, which may be feasible to do interactively. Alternatively, if
624 | Chapter 11: Random Numbers
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.