[onerng talk] install & access

[ianG]

On 28/10/2014 18:25 pm, Paul Campbell wrote:
> On Tue, 28 Oct 2014 12:34:29 ianG wrote:
>> Just musing here, as a potential attack, could I attack another reader
>> by opening tty and writing cmdX to it?  The other reader will then get
>> the code dump which is known data.  My attacker could even do it
>> continuously :)
> 
> yes you could - you'd have to be root to do it and if you're already root you 
> can subvert anything


Aha.  You're saying the mode is 644.  OK got it.  Doh!

>> So another attack would be to sneak in and put an interfering RF thing
>> close by, then switch it across to raw RF, cmd7.  Although it would have
>> to be a pretty fierce source given that you're only sampling the last
>> bit, but hey, that's how these games are played.
> 
> that's harder (you don't know what my sampling clock is) - but again you'd 
> have to be root

Right.  And then you can replace the device.

>> Or another attack is to switch it to cmd4,5.  What happens then?  Does a
>> reader receive anything?  Does it block?
> 
> it blocks once the entropy pool drains


hmmm ok.  Perhaps write up a FAQ of software engineering quirks /
vulnerabilities at this point:

1.  Root can write to the device, configure it to be less reliable and
even replace the device file with a false one that looks reasonable but
is spiked.
2.  Root should only try and configure the device when there are no
other readers or writers.
3.  Another reader could suck all the available product and cause your
reader to be be blocked.
4.  On VMs, ... tbd.


> all these attacks require someone to have root to access the device (we 
> explicitly make it root only accessible in the plug in script) - it's not 
> something I've spent much time on I figure if your attacker already has root 
> they can do what they want (change the kernel, replace rngd, change my install 
> scripts etc etc) 


Sure, let's get the part built :)

But now that I'm thinking about it, and now we're well advanced on the
hardware engineering perhaps we can just identify those weaknesses for
the software engineering benefit.  People are going to hit up against
these issues, and be surprised if not forewarned.


>>>> Same question for the verification command.
>>>
>>> basically the same - the verification stream has a framing header with a
>>> count and a version followed by a memory image




>> In cmdX, 'size in bytes' refers to the signed firmware image?  'actual
>> code size' refers to the code firmware image within?
> 
> it's the firmware image, the signature is of both the firmware and the following 
> random data (ie the entire flash contents all 256k)
> 
>> Is it actually a good idea to pad with random data?  In light of above
>> attack, might be a better idea to pad with the opposite.
> 
> remember the contents of the firmware are not secret - the firmware is about 3% 
> of the flash size (< 8k), what I'm trying to guard against is a board which has 
> had a bad firmware image loaded (perhaps it was intercepted in the mail) - I 
> could easily create a 'bad' image and embed in it a copy of the good image and 
> serve it up when presented with cmdX - by creating an image that is (I hope) 
> not compressible (well it has to be a little because it has 8k of non-random 
> code - but hopefully one can't get enough space back to embed a USB stack, 
> decompressor, etc)


Sorry, I'll try and make myself clearer.  I agree that the padding is a
great idea.  What I was commenting on was the choice of padding.

Using random data to do the padding isn't quite right because it isn't
cryptographically useful.  The padding is known to anyone who sees it,
so it can't be considered to be a random input.  In this sense, I would
suggest the padding be all zeros.

There's also a potential attack on the hash of the signature that would
be assisted immeasurably (*) by a large random pad, because it would
give space to change that random data to something else, and not have it
noticed.  In this sense if the padding is all zeros, then it can't so
easily be attacked without being noticed.

E.g., if you were to use a SHA1-RSA signature, I'd say you were running
too close to the edge because we expect SHA1 to fall to that sort attack
in the next decade.  Should have fallen already... Obviously it gets
harder with say SHA256 over 160 but this way to attack things has
variations...

Also, to assist these matters, it would be good if there was a a big
random nonce at the very start of the packet.

(These are minor critiques.  I'd suggest you look at them in the next
revision, not now.)


(*) well, actually it is measurable, it is 2^N where N is the number of
bits.

>> You're 'ent' table, would it be helpful to add a row showing perfect
>> results?  Being 8, 127.5, 10-90, etc...
> 
> good point
> 
>> (I note with amusement that the 'ent' results measure of entropy goes up
>> with the whitener.  Add more whitener ;)
> 
> yes sad isn't it - and it's the simplest whitener - says poor things about ent 
> more than anything I guess


Just another random dichotomy in the entropy game.  No entropy tester
can detect that a recursive SHA1 over 0 has no entropy.

iang