[Cryptography] In search of random numbers

Bear bear at sonic.net
Sat Oct 25 15:16:43 EDT 2014


On Sat, 2014-10-25 at 00:40 +0200, Hanno Böck wrote:
> Am Fri, 24 Oct 2014 11:02:51 -0700
> schrieb Bear <bear at sonic.net>:
> 
> > On Fri, 2014-10-24 at 06:46 +0200, Stephan Neuhaus wrote:
> > > On 2014-10-24 02:09, Tom Mitchell wrote:
> > > > What "early" needs are there for entropy?
> > > 
> > > Most SSH keys are generated on first-time boot.
> > 
> > This is dumb.  
> > 
> > This is bad design.
> 
> Do you have a smart alternative? What should these devices do? Pre-load
> them with a key? (I don't particularly like that idea) Tell users they
> need to generate a key on their Desktop for their new Internet of Things
> light switch?

In response to your immediate question: since four of the 
most popular current extensions to a light switch are a timer, 
a light sensor, a motion sensor and a microphone, it can just 
damn well pause the boot until it reads enough off the sensors 
to be ready to go.  The install manual *is* allowed to say "It 
will function as a simple light switch until the flashing blue 
LED turns off after about one minute; after that, the extended 
functions are ready to use."

But more to the point, why does a light switch need a full 
Von Neumann architecture so complex that new code can ever 
run on it?

Give it a ROM of executable code that's loaded at the factory 
and cannot be rewritten under any circumstances, some kilobytes 
of non-volatile configuration which comes with "reasonable" 
defaults and is mounted on a dedicated memory bus that can 
never be the target of an instruction fetch, and some volatile 
memory also on the dedicated memory bus, and what valuable 
light-switchy task could it NOT do that a viable attack surface 
COULD?

If the code on the ROM is discovered to be flawed or someone 
finds an attack surface, it's product recall time. We're not 
talking about something terribly expensive that people can't 
replace here, nor about something so large it can't be mailed 
back and forth cheaply to get repaired or replaced. 

Seriously, justify this "Internet of Things That Can Be Targets".

"Things" are things people don't use as general-purpose computers, 
so while they need writable configuration memory, that writable 
memory doesn't need to be executable. "Things" don't need to be
reprogrammable as such for any reason relevant to the end user. 

If we're talking ubiquitous, we're talking simple and replaceable 
and cheap.  If we're talking simple and replaceable and cheap, 
we can get much better security by making the executable memory
completely non-rewritable than we can by any application of
cryptography. 

Bear




More information about the cryptography mailing list