
Juniper: Recording Some Twitter Conversations - tptacek
https://www.imperialviolet.org/2015/12/19/juniper.html
======
tptacek
Stop and consider for a second how crazy this page is:

[https://kb.juniper.net/InfoCenter/index?page=content&id=KB28...](https://kb.juniper.net/InfoCenter/index?page=content&id=KB28205&pmv=print&actp=LIST)

Dual_EC is a PKRNG. PKRNGs are a kind of crypto random number generator
(CSPRNG). All the crypto keys in modern cryptosystems come from CSPRNGS.

PKRNGs are special because they embed a public key in the generator. Anyone
who holds the corresponding private key can "decrypt" the output of the RNG
and recover the generator's "state"; once they have that, they can fast-
forward and rewind through it to find all the other numbers (read: crypto
keys) it can generate.

Juniper is here saying that they recognize the problem of Dual_EC --- it's a
PKRNG, and the USG may hold its private key.

 _So instead, they generated their own private keys and embedded them in the
CSPRNGs of the VPNs they sold to customers_.

WAT?

But see also this thread:

[https://news.ycombinator.com/item?id=10764359](https://news.ycombinator.com/item?id=10764359)

~~~
mcintyre1994
Just out of interest, is there any legitimate use of a PKRNG or is it just a
backdoor enabler?

~~~
LukaAl
Not totally an expert but the explanation of what a PKRNG is overly
simplified. The problem with Dual EC is not that it is a PKRNG, but that some
design choice made allowed for allegedly planting a backdoor for agencies with
enough computing power.

Basically one of the problem you are trying to solve with a CSPRNG is how you
avoid to disclose the generator state with the random numbers. Obviously once
the state is known it is easy to replay the sequence.

Since we don't like to reinvent the wheel overtime, a solution is leveraging
known properties of hashing and encryption algorithms. The idea behind a PKRNG
is to use a fairly simple state evolution function but then to encrypt the
output with a known public key. Since a property of public key encryption is
that you can't know the message if you don't know the private key, the state
is safe for everybody except the owner of the key. If you then truncate the
encrypted message and you choose the public key without computing the private
key you get a very strong CSPRNG. To be more clear:

\- There are procedure to generate a public key without generating the private
key (but you should trust the person who generated the numbers).

\- The encrypted message is truncated, so even if you still have the private
key, you should guess the missing bit of the message to decode the state.

The problem with Dual EC is that the resulting encrypted message is not
truncated enough (it is enough to protect against a casual attacker, not an
organization with massive computing power like an intelligence agency). Plus
doubt were casted on the procedure used to generate the public key, given that
you were forced to use the one in the standard and not your own if you want to
get certified.

~~~
tptacek
There's no reason to use a public key transform to generate random bits other
than to leverage the fact that the tranform is trapdoored with a private key.
They are otherwise cost-prohibitive.

If you can point to a "good" PKRNG that sees any use, that would be an
interesting way to rebut my argument.

------
unchocked
Is this going to become the primary case study on why back doors are a bad
idea?

If so, it's important to get a quality layman's explanation out fast, and this
is the framework of a great one.

~~~
andreyf
No. It will not. Backdoors are fine as long as they are NOBUS and the master
key remains safe. Notice, for example, how every major corporation has a
"backdoor" in all their employee's hard drive encryption schemes, except they
call them "data recovery options".

~~~
gh02t
The assumption of the master key remaining safe is the problem though. If e.g.
the government forced a known back door in encryption systems, that master key
then becomes the single juciest, most delicious target of every cyber criminal
and foreign intelligence agency in the world. It's hard to be able to keep
something like that secure while making it accessible enough to actually use
for its intended purpose.

~~~
andreyf
We have ways of keeping keys like that secure. For example, the master
recovery keys used for HD encryption on NSA / Google / Lockheed laptops. Those
are all pretty valuable, and yet they've been kept secure.

I don't think legislating away single-user encryption is a good idea, but not
because backdoors are inherently bad.

~~~
gh02t
It's possible under ideal circumstances, but it's an uphill battle in the real
world. The examples you gave are small potatoes compared to how frequently a
master key for criminal cases would be needed and dramatically lower risk. If
the NSA leaked their hard drive encryption keys hundreds of people would
probably die. Bad yes, but if the master key to (virtually) all encryption
schemes in the country is leaked many people would end up getting killed _and_
it would be an economic disaster. Not to mention the potential for limitless
privacy abuse, whether in the name of a righteous cause or not.

I'm sure they could work out some sort of subkey scheme and key splitting (via
e.g. Shamir's scheme) to lower the possibility of compromise and reduce damage
if a subkey was leaked, but the possibility won't be zero. And with that big
of a target the number of people trying to acquire the keys means the chance
of the keys eventually being leaked is pretty good.

------
mooneater
I would love to know what the commits in the source code look like for these.
Author, message, date.

How did they bypass the review process? Was the process socially engineered,
or was the repo hacked directly?

What will the new process be to ensure this doesn't happen again?

This has implications for the process at most companies.

~~~
discardorama
We would all love to see how it went down. But I'd bet good money that Juniper
will not reveal what happened.

Sometimes I wonder how difficult is it for $TLA to send their employees off
into the world (on their payroll), as sleeper coders, to be activated whenever
a small piece of code needs to be inserted in the right place. You don't even
need too many; just a handful would be sufficient.

~~~
johnchristopher
But are sleepers agents reliable enough ? Considering they would be living in
peace in a modern and comfortable country, wouldn't they hesitate to act when
activated?

~~~
zrth
Sleeper agents should be reliable enough, considered that they (the in the
long past "recruited") want to have their family and loved ones safe -- it
would really be a pity if some stupid accident happened to any of them on
their way home... Sounds morbid, yes, but rest assured, with enough
"motivation" financial options and "moral flexibility" you can always motivate
others, to do as demanded.

~~~
johnchristopher
Ah, (you're) right. My game on these matters isn't top-notch.

------
e12e
So, if we assume this is indeed a backdoored Dual_EC PKRNG - how are those
typically initialized? Are we looking at something equivalent to the Debian
ssh/ssl bug, where we have some millions of "known bad keys", or is it more
likely each case is different (ie some knowledge of the state is needed for a
useful attack)?

Does anyone have a pointer to a proof-of-concept "evil" (or "escrow-enabled")
system based around such an RNG?

~~~
hannob
It's not like the Debian bug, because that would be something everyone can
detect and exploit. The interesting case with of this backdoor is that it can
only be abused by the person who has the secret points used to generate the
parameters.

There's been quite some research about the exploitability of this
construction: [http://dualec.org/](http://dualec.org/)
[https://projectbullrun.org/dual-ec/](https://projectbullrun.org/dual-ec/)

------
mythrowawayaway
If you recall, Juniper was a part of the China backed Auroa attacks
([http://www.marketwatch.com/story/juniper-networks-
investigat...](http://www.marketwatch.com/story/juniper-networks-
investigating-cyber-attacks-2010-01-15)), which was in 2010.

Once the backdoor administration password is posted publicly, we can try to
use it against older versions of ScreenOS code to do a process of elimination
to find out how long ago it was added.

------
lukeh
Not the most serious issue but, how come they're encoding these constants as
ASCII strings?

~~~
tptacek
Usually it's because you only have to read them once, and you're uncertain
about the most compatible way to encode bignums. You're often generating
parameters on one system or in one language, but then using them in another.

ASCII is slow but everyone interprets it the same way.

~~~
lukeh
Meh, sounds lazy to me!

~~~
tptacek
It's lazy, but it's the good kind of lazy.

------
cant_kant
No Such Agency...

