On 16-11-2012 19:57, Jeffrey Walton wrote:
Hi Jacob,
On Fri, Nov 16, 2012 at 1:22 PM, Jakob Bohm <jb-open...@wisemo.com> wrote:
On 11/16/2012 3:36 AM, Jeffrey Walton wrote:
...
Headless servers, entropy starvation, and rollbacks are a concern in
modern environments. OpenSSL and other entropy gathers, such as EDG,
don't account for the later. Its best to take the bull by the horns
and do it yourself. At minimum, you need to call RAND_add() with
entropy external to /dev/{u}rand.
Would you care to elaborate on the following points:
1. What do you mean by "rollback"
Virtual Machine rollback attacks.
And how would an attacker rollback the victims VM?, an attacker with that
level of control is already presumably able to access the VMs data,
storage and execution state directly.
2. What RNG/PRNG are you referring to as "EDG"
EDG is Entropy Gatering Daemon. I was talking to John Steven about it
over the summer (John is CTO of Cigital, OWASP member, and part of the
project). EDG does not take measure to mitigate rollback attacks.
Ah, I thought that was called "EGD"
3. What exactly makes /dev/{u,}random in current (not ancient) Linux
kernelsinsecure given an appropriate supply of entropy?
Note that the two papers you site on the Linux kernel PRNG are:
I. A 6 year old document, presumably not applicable to the code in
currentkernel versions.
I don't believe this is correct. For example, the Linux generator
still lacks forward secrecy.
Do you mean "lack forward secrecy" as in past random bits can be predicted
from later random bits (very bad) or "lack forward secrecy" as in internal
PRNG state may reveal bits output in the recent past (less of a concern for
most real attacks).
II. A document about the consequences of using any PRNG without
sufficient entropy input, with the Linux kernel PRNG as a common
example. This would presumably be irrelevant if feeding the kernel
plenty of external entropy e.g. by getting it from a hardware RNG
hooked up to a trusted server (under your own control of course).
The "trusted server" is a problem. First some background.
The Linux kernel folks *disabled* feeding data into the generator
based on interrupts because the attacker may control it. For example,
the arrival of a network packet. There's a real problem of starvation,
especially in headless servers and mobile devices. The problem was
highlighted (again) in a recent paper: "Mining Your Ps and Qs:
Detection of Widespread Weak Keys in Network Devices,"
https://factorable.net/paper.html. See Section 5 where the analysis
occurs and 5.1, "Weak entropy and the Linux RNG".
What I said, the consequences of entropy starvation and ignoring the
starvation.
If I go to https://www.wisemo.com, I initiated that connection so its
not under control of an attacker). The exchange contains some random
(but public) data - namely, Wisemo's public key. A passive attacker on
the public internet may be able to observe the exchange. So we can
improve entropy in the generator at the cost of leaking information
about state input.
And what if (hypothetically speaking) I had doctored that public key
to negatively affect the entropy of some well known PRNG when used
with some well known hedging software (I haven't, but you have to
take my word for it).
If the server is within my logical security boundary (for example, my
LAN/MAN segment), the attacker probably cannot observe the exchange.
In this case, I can improve entropy in the generator without the side
effect of leaking information about state input.
Of cause, I recommend having it within the data center, as the amount
of entropy requested by a server is likely to be a valuable side
channel.
Later, when the
machine goes out on the internet, its quality of random numbers will
be improved.
Only if your PRNG is secure against a partially known/chosen entropy
attack, not all are. For instance the PRNG entropy management code
might batch up enough raw entropy for a full PRNG state and then
discard the past state to improve long term forward secrecy, this
would be a great strategy with trusted secret entropy sources, but
fatal if fed large amounts of attacker-known/chosen entropy, as it
would make the state completely known.
You should join us over at the cryptography mailing list
(http://lists.randombit.net/mailman/listinfo/cryptography).
e.g. by getting it from a hardware RNG
I personally use an Entropy Key when I need to ensure I have
sufficient bits to generate a long term key
(http://www.entropykey.co.uk). I carry it with me in my laptop bag.
I personally try not to let the world know precisely what brand and
version of countermeasures I use, just in case of a 0-day.
I know of a number of medium and large size enterprises that don't use
hardware, and rely on the software generator provided by the OS. Those
enterprises include financial institutions in New York.
This is a true story. I'm a security architect, and this got pushed to
the team for risk acceptance. One financial institution was having
problems with entropy depletion in a virtual environment. The
appliance was apparently running out, and could not push sufficient
entropy to its hosts (it was blocking in calls to /dev/random, if I
recall correctly). The vendor stated we should delete /dev/random and
then link it to /dev/urandom (or vice versa), so the generator would
not block.
Yeah, typical incompetent support, and or management forcing the
engineers to provide a quick fix even if only a slower fix is possible.
Happens all the time to safety measures much more important than this.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
