[Cryptography] OpenSSL and random

[Tom Mitchell]

On Fri, Dec 2, 2016 at 9:26 AM, Nico Williams <nico at cryptonector.com> wrote:

> On Fri, Dec 02, 2016 at 11:24:45AM +0000, Peter Gutmann wrote:
> > Ray Dillinger <bear at sonic.net> writes:
> > >As written, it regards 128 bits as sufficient initial entropy.
> >
> > Why 128 bits?  What if it's less?  Lets say you never block, which means
> you
> > could run on, say, 32 bits of entropy early on.  Given the information
> > "somewhere on the Internet there may be a system that may be running with
> > lowered entropy in the RNG", how would an attacker exploit this?
>
> For a sufficiently-low number of bits we'd have a number of recognizable
> SSH host keys and such.  How low is that?  16 bits is too low for sure.
>


Does it make sense to look at a strategy that allows a system to boot and
connect with famous cached sites to update the system and then  replace the
keys with unknown entropy with "better keys."   Good bits  should be very
possible once the device (IOT class device) has been up for reasonable
time (define reasonable).

It may be silly to have key generation so early in the boot process.
Better to let the system initialize itself and allow the entropy pool to
fill and  then gate tools that need good keys.   For sure after fsck has
run.  The risky ssh attacks that can begin seconds after a device are real
but the attacks are distributed and the login+password+time is not
under the control of a TLA (today) and could be used as an additional
source of entropy.

Even connection attempts from the internet could trigger the lazy generation
of keys in contrast to building a key early.  Knock, Knock... I hear you
let let me get presentable.   Most real people would not answer the door
without
pulling on pants...   So a firewall rule,  block,  inspect the log to see
who knocked
and act as needed.

If a design builds a map of a set of bits and lacking a quality TRNG require
bits from here and there be collected mixed and hashed into a larger seed
for use by a PRNG.

i.e. six bits of TRN is not enough but six bits to select, reorder  and
hash local "stuff"
like a DHCP  assigned IPV4 and IPv6 tcp/ip address,  domain name, a hash
of bits from a "random" offset into a  binary system file or three, packet
return or failure
times

If I time a reboot to a reconnect cycle on a small device the result is
minutes today
so a lot of machine time exists to allow entropy to be collected.

Devices that only make outgoing connections need not keep the "first" key
generated.   A fresh key a day might keep some snooper away.

Local DHCP servers can also deliver local bits to hash and mix.
The DHCP server uptime is likely long enough that quality bits invisible
to TLAs  might be interesting  interesting for enterprises.

Local AES accelerated encryption of local bits mixed into the pile.

All of these:

Initial first boot,
IOT devices,
Portable devices with corporate data.
Portable with encrypted files.
Portable with encrypted filesystems.
Critical servers.
home routers,
local routers,

trunk routers,

Virtual machines (in many rolls).

Mail servers.
Web servers
Data servers

and more will be interacting and _any one_
might be used as the classic side door access
to gain elevate privilege and obtain access to the next.

So if the hardware+system does not deliver a quality TRN of sufficient
size quickly,  a fall through swizzle of local bits and events could
leverage a small set (6+bits perhaps) to build a much better
seed for a more responsive system PRNG.

This is a fundamental system problem as much as an OpenSSL problem.
The system is no stronger than its weakest link.
The small devices are important.



-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161203/bbae920d/attachment.html>