[onerng talk] install & access

[ianG]

On 29/10/2014 18:26 pm, Paul Campbell wrote:
> 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


Aha, my assumptions are falling like skittles.

I guess you're assuming the rngd will copy the entropy into /dev/random
and that it, done & dusted.  This is good, it matches my Rule #1 of RNGs
better than I'm doing.

In my use case, the user-server will be sucking directly off the stick,
as it has its own mixer.  Breaking my own rule...

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


Right, falls in with the whole root issue.

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


Right.  And the hopping...

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


not sure how that works?  Oh, you're talking about compressing the
entire thing, then uncompressing it internally.  Got it.

Isn't the entire package signed?  I'm assuming here that any flashing
will require the new package to be signed by a key bedded into to the
non-flashable code?


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


Ah, SHA512 will be good for a few more months, yep :)

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


Sure, I'm probably over-engineering at this stage.



iang