[Cryptography] In search of random numbers

[Tom Mitchell]

On Fri, Oct 24, 2014 at 5:18 AM, Alexandre Anzala-Yamajako <
anzalaya at gmail.com> wrote:

> Recent research has shown that numerous devices (headless servers for
> example) generate their long lived cryptographic keys upon their first
> start.
>

But in this case there is a file system and it is clear that
extra effort is needed to generate entropy.  Long lived keys
would be known to be fragile and in need of replacement
if the extra effort is missing.

In that case there is no "last time" that can be reliably trusted.
> Unless I misunderstood your point I don't clearly see the engineering
> option.
>

The lack of persistent storage is the issue.  A refrigerator
or other device that generates a fresh set of keys each time
it powers up needs hardware engineering.  A factory process could be
engineered
that would insert a trustable entropy seed in such a device as part of
testing.
Network MAC addresses are factory programmed and if the device
containing a MAC address had room such a seed could be used
once and combined with site specific local data time, temperature, arp,
broadcast ping, DHCP, bootp ...  input so the long lived keys can start
live on improved footing.   Other hardware could have a one time latch
that gates read access to a seed and after reading the seed device
once at boot time  it would be unavailable.  Future entropy seeding could
look at it and also for a filesystem cookie combine them and move on.

The first start is a challenge but engineering can improve it. Cost
reductions can make it more difficult.

Site process can connect to new headless servers quickly and insert
trusted entropy, regenerate keys and more before allowing a server
to connect to anything except a single trusted host.   But this
requires engineering at the site.  Best practice analysis and models can
remove a lot of mis-steps.


-- 
  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/20141024/96c60be3/attachment.html>