[onerng talk] install & access

[Paul Campbell]

On Wed, 29 Oct 2014 12:34:59 ianG wrote:
> 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!

actually 600 - otherwise a non-root actor could attack by draining the  
device's entropy pool

to be fair the kernel entropy pool /dev/random is susceptible to the same 
issue, but that's really a SEP

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

it's more that you can see the noise signal going into the chip, what you 
can't see is where it decides the bits are (where it samples) 

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

yes I agree

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

if it were all 0s I could create a compressed (RLL for example) image that 
could easily be embedded in another bogus set of firmware

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

I am going to publish the full image as well as the padding binary (so one can 
recreate the image, part of making it all open)

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

I'm using gpg to sign it with a 4k bit key  I just set the default hash to:

	personal-digest-preferences SHA512 SHA384 SHA256

which should hold it for a year or so. 

Adding a nonce will have to wait - I'm not sure that helps, since it's not 
going to be secret (needs to all be open if it's distributed)

	Paul