[Cryptography] Juniper & Dual_EC_DRBG
Thor Lancelot Simon
tls at rek.tjls.com
Fri Dec 25 12:30:08 EST 2015
On Fri, Dec 25, 2015 at 07:14:05AM -0500, Watson Ladd wrote:
> > 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*.
> I'm working on this, but the IKE negotiations and packet forming are
> not done by the accelerator but the CPU. That's enough to recover the
> keys. Furthermore, there are many systems involved, some very low end.
I believe even the lowest-end ScreenOS devices used (the lowest-end)
Cavium accellerators for packet encryption/decryption. Certainly if
you peel apart the smaller SSG boxes you'll find a Cavium chip in there.
I think I still can't talk about any prices anyone might have paid
for these parts, but I can say that there's a reason the CN1010 and its
even-littler siblings remained in production long after Cavium had moved
on to newer and faster things.
Discussions with some friends and former colleagues suggest that Cavium may
have had some kind of IKE support in very early IPsec microcode releases
but that later releases were ESP/AH only. I also found some notes from
when I was doing SSL stuff with these chips that make it clear that in
a number of operations, the caller in fact explicitly supplied random values
to the chip (even if Cavium's software toolkit may have earlier _obtained_
those same values from the onboard RNG and buffered them up for later use).
The operations in question would be pretty directly analogous to IKE Phase 1,
so I think all in all it does make sense that -- even with a crypto chip
in use, and whether or not it is or ever was used for IKE -- the first few
messages of the IKE exchange are where to look for the RNG state leak, and
it's a fair assumption that key material used in IKE came from the software,
not the accelerator's, RNG.
More information about the cryptography