[148020] in cryptography@c2.net mail archive
Re: [Cryptography] /dev/random is not robust
daemon@ATHENA.MIT.EDU (Alan Braggins)
Tue Nov 5 12:25:06 2013
X-Original-To: cryptography@metzdowd.com
Date: Tue, 05 Nov 2013 10:13:41 +0000
From: Alan Braggins <alan.braggins@gmail.com>
To: John Kelsey <crypto.jmk@gmail.com>
In-Reply-To: <B73B9CCA-9532-4DA0-AAFE-16641204C7C6@gmail.com>
Cc: Phillip Hallam-Baker <hallam@gmail.com>,
Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 04/11/13 17:39, John Kelsey wrote:
> On Nov 3, 2013, at 5:27 PM, Alan Braggins <alan.braggins@gmail.com> wrote:
>> On 24 October 2013 16:16, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> ... [I hope I got the attribution right]
>>> If I was asked three months ago my position would be 'generate the keys on
>>> the device that is going to use them and they never leave unless it is a
>>> really constrained device like a credit card.'
>>>
>>> I have completely changed my mind on this. I now think public keys should be
>>> generated in device adapted for that purpose and migrated out using some
>>> form of secure protocol that ensures only the intended device can use them.
>>
>> Given that we're assuming the device can't reliably generate a secure key pair,
>> and assuming that it doesn't already have a secret specific to the device, what
>> protocols would be suitable for doing that?
>
> Yep, this is an unfixable problem.
That was my initial reaction, but I was hoping there was something I'd
missed.
It doesn't mean the approach is useless though. Even if you have a weak
session key (based on, say, clock time, a serial number, and a "secret"
shared by all devices of this class, input to a KDF), an attacker can
find the key, but not trivially, and they have to use it to attack
perhaps just one message where the long term private key is provisioned.
That's in some ways better than generating a weak long term
private key. (But maybe worse if it gives you a false sense of
security.)
> Now, if there is local traffic I can't intercept, your program can feed that into its RNG.
[...]
>> (And if we can ask a device to generate keys and securely migrate them to us,
>> we can ask it to generate some random seed material that isn't visible to an
>> attacker, which solves the problem of local generation.)
>
> Yep. It seems like getting random secure starting seeds into devices would be a huge win here. Then they can combine that with whatever information they have locally, and initialize their RNG, and then generate their keypair.
On the other hand, having one device with well-audited RNG with real
physical randomness, and well-audited key generation, provisioning lots
of products whose PRNGs you aren't too sure of even when seeded with
that un-intercepted local traffic, might have some value.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
