[Ach] Recomendation on haveged in Bettercrypto chapter 3.3.3

[Aaron Zauner]

Hi,

Ralf Schlatterbeck wrote:
> On Wed, Apr 29, 2015 at 05:31:44PM +0200, Aaron Zauner wrote:
>>> The main worries of RNG seeding are for small embedded devices and for
>>> VMs -- in particular during startup when not much entropy is available.
>>> For VMs recent KVM seem to have mechanisms of seeding the RNG of the
>>> guest from the host machine. This is not yet in stable releases of major
>>> distros, though (checked for Debian). Some of the entropy gathering
>>> techniques of haveged work also inside a VM (because they rely on timing
>>> of events of the real hardware). This implies that you need good timers
>>> inside the VM.
>> https://lists.debian.org/debian-boot/2013/01/msg00225.html
> 
> But embedded devices have no filesystem :-(
> Good for VMs, though.
> 
>>> For small embedded devices the problem is IMO still mainly unsolved but
>>> running haveged there *seems* to improve things (although some of the
>>> mechanisms of haveged only work on bigger CPUs).
>> Exactly. For most embedded devices haveged doesn't really give you
>> anything because haveged is architecture dependent. So sticking with
>> what the kernel gives you is probably a better idea.
> 
> I think it makes a difference. But measuring this would be cool.
> 
>>> As far as I understand the kernel entropy mixing code, if something
>>> feeds the kernel entropy pool (and default install of haveged is used in
>>> that mode) I don't think it can somehow "dilute" the entropy pool -- if
>>> it doesn't feed entropy into the pool (in the worst case constant data)
>>> the kernel entropy pool won't be worse than without this non-random
>>> source.
>> That's my understanding as well. But I don't see how haveged does
>> improve the entropy pool in any way. The kernel has excellent entropy
>> sources and the algorithms for mixing are constantly reviewed and
>> updated if need be.
> 
> Not for embedded devices, see Ps and Qs paper.
> 
> [...]
>> Some software still reads from /dev/random unfortunately. Do you have
>> further references w.r.t. embedded entropy sources? Not sure but using
>> kernel interrupts seems quite generic.
> 
> AFAIR in Ps and Qs paper, haven't looked at it for some months though.
> And I'm not up to date with kernel developments in this area.
> 
> Note that embedded devices don't have many interrupt sources to begin
> with. And I think to remember from Ps&Qs paper that network interrupts
> were deemed attacker-influenceable at some point -- which is the *only*
> interrupt source of many embedded routers.
> 
>>> In addition there was -- at the time of the Ps & Qs paper -- some
>>> brokenness in OpenSSL entropy code in that OpenSSL seeded its RNG
>>> early-on *once* and later only if enough entropy was consumed from the
>>> internal OpenSSL pool. This means that a daemon relying on entropy (e.g. SSH)
>>> would have seeded the OpenSSL internal RNG once from /dev/urandom when
>>> there was almost no entropy in the system (at the start of the daemon).
>>> One of the results were guessable nonces for DSL algos (making the
>>> secret key recoverable) *even after days of running the system* (where
>>> enough entropy would have been available but OpenSSL didn't use it).
>>> I don't know if this is fixed in recent OpenSSL.
>> I think this has been fixed.
>>
>> https://github.com/openssl/openssl/commit/8a99cb29d1f0013243a532bccc1dc70ed678eebe
> 
> Um, no. This might improve things if the RNG fails (but if you have
> known plaintext and you can predict the RNG you still can crack the
> DSA key). I'm looking for the Seeding algos on the RNG generator
> of OpenSSL, this should be fixed at the root...
> 
> I remember this from the paper:
> - OpenSSL has its own internal RNG pool from which RNG numbers are
>   computed
> - This pool is seeded once on startup from the Linux RNG (with urandom)
> - The pool is re-seeded only after enough (hopefully random) bits have
>   been consumed
> - If seeded from a repeatable Linux RNG value it will produce the same
>   sequence of "random" numbers everytime
> 
> On embedded devices which were up for *months* this led to repeatable
> sequences of DSA nonces for *different* devices randomly probed on the
> net. The SSH daemon had been started with no entropy and the OpenSSL RNG
> had kepts its (predictable) state over months.
> 
>>> Has someone done measurements on this?
>>> I'd like to see experiments with some OpenWRT devices with current
>>> OpenSSL code check for, e.g., DSL nonces generated with and without
>>> haveged...
>>> Has someone recently looked into OpenSSL RNG code?
>> No idea. But that's a problem quite different from the kernel source, right?
> 
> It means repeating the stuff done in the Ps and Qs paper with
> more modern kernels -- and comparing with running additional entropy
> gathering tools like haveged. To have an opinion on haveged backed by
> facts (and I'm not accusing of having no facts I don't have any either :-)
> 

Ok. I'm going to answer to this mail as a whole: BetterCrypto does not
really take embedded devices into account. With embedded devices
there're far more pressing problems than haveged. Some embedded devices
won't use proper TLS, some do not negotiate modern ciphers. Most will
use TLS-PSK instead of DH. AES support is a problem in the embedded
world. GCM has problems on architectures that do not support AESNI
instructions, deployed ECDSA implementations have problems. The list
goes on forever.

This is a very real problem -- but not a problem that should be handled
by our project. We cater to sysadmins, not embedded developers, and I do
not think we have the proper knowledge in here to care for embedded.
This is something embedded people need to figure out, and I'm hoping
they pay their crypto consultants well.

OpenWRT et al: well, these devices do usually have some form of
non-volatile storage, so pre-seeding is not an issues.

Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20150429/37435683/attachment.sig>