[Cryptography] Random numbers only once

[Watson Ladd]

On Tue, Feb 4, 2014 at 6:35 PM, Jim Gettys <jg at freedesktop.org> wrote:
>
>
>
> On Tue, Feb 4, 2014 at 7:59 PM, Watson Ladd <watsonbladd at gmail.com> wrote:
>>
>>
>>
>> But that only justifies blocking exactly once after boot.
>>
>
> But this is just where the fun begins...
>
> This begs the question: blocking for how long?  Under what circumstances?
>
> This is what sparked me to call Ted T'so last summer to get cycles spent on
> /dev/random in Linux.  We all owe him a debt for picking up that code again
> and working with architecture maintainers to fix it.
>
> At the time, we were running a full Bind 9 implementation in CeroWrt (we've
> gone back to using dnsmasq since).  You can think of CeroWrt as a bleeding
> edge build of OpenWrt for network crazed people to work in to fix
> bufferbloat and other things that annoy us.  Lots of features beyond
> OpenWrt, but also you'll bleed more.  Mesh networking; test tools, real
> routing rather than bridging...  yadda yadda.
>
> We wanted DNSsec to actually work as intended to put an end to arguments
> that we can't get it all the way to the end user who just picks up the DNS
> server from his home router.  It was easier to prove to the IETF homenet
> working group that doing it was feasible than spend time arguing about
> whether it was feasible.  These days, Comcast (and now Google) actually have
> good DNSsec in production.
>
> Worked great (wonderful full validation on my browser! Nice Green indication
> on my browser if the web site implemented DNSsec) except the following
> couple cases:
>
> 1) If you had a fresh installation of CeroWrt and plugged it in, it would
> never come up.  Why, might the educated reader ask?

Why not provision the fresh install with entropy on the machine
flashing the image?

>
> No entropy at all: most of the peripherals you normally think you can get
> entropy from don't exist on these devices, and the MIPS architecture port
> (most home routers are MIPS CPU's today), was completely broken at the time
> to use the last resort of only scraping things from the system clock.

There weren't two different oscillators? No radio which could tune to
an empty band?
No DRAM amplifiers which could be fooled into reading a high entropy state?

>
> So you would wait forever; blocking even once is not acceptable.
>
> There are a bunch of hack arounds, but given this summer's events, I decided
> it had to get fixed "right". Ted T'so, of course, wizard that he is, has now
> mostly or entirely drained that swamp.   Thanks Ted.
>
> Bind and CeroWrt hung forever because on initial installation, the first
> thing CeroWrt tried to do was to generate its certificates so that it could
> do DNSsec validation, and would refuse to answer any queries at all.
> Dunno at what rate we now get entropy on this hardware to generate the
> certs; at least I now think eventually we'd get enough to sign the certs,
> but it still might take a long time.

Wait, why does DNSSEC validation require entropy?
I'm still not sure how running with low entropy fixes this, except
for a funny definition of fixed.

>
> The problems in embedded are similar to the problems of virtualized
> machines, except you have no host you might also be able to get some entropy
> from.
>
> If you don't most embedded developers will just hack and disable any
> security features that might be in the code.  Various penetrations have
> already exploited this fact.
>
> But our security related fun was not over.
>
> 2) Time....
>
> On a home router or most embedded devices, you have no TOY (time of year)
> clock.  Nor will you ever have a TOY clock due to both cost (a battery + 1
> chip typically), and the fact that the batteries eventually die.  Don't ask
> for something you'll never get....  So don't ask...
>
> Again, Bind wouldn't let us run until the time is set to within an hour
> (this is a requirement of DNSsec).  And since we need to do a DNS resolution
> to even try find a time server on the internet  which might not even be
> running or connected (hardwiring IP addresses is anti-social), we'd either
> have to hack Bind, or try to get the time some other way, and your ISP might
> not even be running or your router plugged in.
>
> So if the time of day had never been set on the home router since the last
> power cycle, you lost and CeroWrt would not run.
>
> This doesn't even begin to worry about men in the middle who might mess with
> time to attack or DOS you...
>
> Three morals of this true story:
>
> 1) scrounge as much possible entropy from wherever you can find it; even
> then we can't trust any single entropy source including HWRNG's.  Get over
> it....  The enemy of the good is the perfect.
>
> 2) there is no easy way to *bootstrap* getting time *securely* in today's
> Internet, and we depend on time in various crypto systems, short of a TOY
> clock and battery and human intervention.  Easily fixable, needs fixing.

DNSSEC for pool.ntp.org?
Do we need to make an authenticated NTP, or would a signed clock
protocol work fine for this?
I've thought on and off about this problem, but it is tough given the
latency requirements for NTP,
and the fact that server state in a UDP protocol can have interesting effects.

>
> 3) making robust global scaleable secure distributed systems (not just
> operating systems) is really, really hard :-(.
>                                       - Jim
>
> P.S. I'm new to this list and have avoided security and crypto in the past:
> my mistake, but have a number of friends on this list who are expert.
>
> PPS.  Please don't fall down the "is DNSsec worth having" rat hole.
>
>
>
>
>
>
>
>
>
>
>
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin