[Cryptography] Juniper & Dual_EC_DRBG

dj at deadhat.com dj at deadhat.com
Fri Dec 25 03:01:52 EST 2015


> On Thu, Dec 24, 2015 at 04:21:45AM +0000, Jacob Appelbaum wrote:
>> On 12/23/15, Thor Lancelot Simon <tls at rek.tjls.com> wrote:
>>
>> > So I am just not sure what would have been generated by the system RNG
>> > nor how to leak it: the accellerator should be generating all the
>> random
>> > fields of all the messages and stamping them in for you, and certainly
>> > it should be generating the actual session keys.
>> >
>> > So what's being generated by the system RNG and how is it being
>> leaked?
>>
>> I think you're on the right path here. It makes sense from what we've
>> published about their VPN decrypt capabilities. I think that anywhere
>> there is Cavium, we'll find a "SIGINT enabled" VPN.
>
> I think you're on the wrong path here: why would anyone bother to
> subvert the system RNG if the crypto accellerator were already subverted?
>
> What I'm asking is *how subverting the system RNG* led to loss of
> confidentiality for VPN sessions, *given that the system appears to
> use an accelerator which has its own RNG and stamps that RNG's output
> into packets*.
>
> Thor

I know nothing about the Juniper system, but I know a thing or two about
how RNGs are used in real systems. An RNG in an offload accelerator
generating per packet random numbers is typically going to be fast.
Therefore someone implementing the accelerator will have considered the
options and dismissed the Dual-EC-DRBG on performance grounds, without
ever having to visit the other issues. For hardware performance, the
CTR-DRBG is one for which you can make very fast implementations.

But there's usually a layer of software somewhere doing session
establishment with public key stuff and this would use whatever RNG is
available from the system it is running on. Typically the OS or RdRand or
an RNG hanging off a bus in an ASIC or some combination thereof.

Subverting either the accelerator RNG or the system RNG would do the job I
presume, albeit with a different attack methodology required for each.




More information about the cryptography mailing list