[onerng talk] install & access

Paul Campbell paul at taniwha.com
Tue Oct 28 18:25:09 GMT 2014


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

> 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

> 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

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) 

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

> 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

	Paul




More information about the Discuss mailing list