[Cryptography] In search of random numbers

ianG iang at iang.org
Sun Oct 26 05:45:50 EDT 2014


On 25/10/2014 20:16 pm, Bear wrote:
> 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."


Actually this is hard.  To do it properly requires the measurement of
entropy.  This is a mess.  It's a hard problem to get right.  Sure there
are some people who think they've got the handle on it, but they aren't
enough for this task.  Hence, some who are pragmatic would say, no,
never block.  Just do the best you can, supply what you've got and take
on the knocks.  Sucks if you want your light switch to have an SSH key...

What might be easier is a simple 1st order approximation such as
counting the number of light switch hits (and using the difference as
entropy).  In the manual you can have a line that says "SSH key will not
be generated until lightswitch hit 10 times..."


> 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?


That part I agree with, but the challenge is in getting the IoT people
to do it.

> If the code on the ROM is discovered to be flawed or someone 
> finds an attack surface, it's product recall time.

You only get product recall when it is likely to kill the user.  Bad as
the randomness issue appears to us, I'm not sure we're there yet.


> 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. 


Huh?  Light switches require an electrician.  Problem part is sub $1,
install is o($100).  A whitegoods replacement part is a callout fee,
even the lightbulbs in a fridge will challenge some people.



iang


More information about the cryptography mailing list