[Cryptography] In search of random numbers
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
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
More information about the cryptography