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.
> 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.
> 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.
> 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".
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.
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. Later, when the
machine goes out on the internet, its quality of random numbers will
be improved.
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 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.
Jeff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
