
Technical feasibility of decrypting https by replacing the computer's PRNG - lucb1e
http://crypto.stackexchange.com/questions/9210/technical-feasibility-of-decrypting-https-by-replacing-the-computers-prng/9212
======
tptacek
Once again, if you believe this is a real issue, you're logically enjoined
from using practically any hardware cryptography, including the AES
instructions or any HSM.

Moreover, if you're serious about having a problem with rdrand, you really
can't be doing crypto on the x86 platform (putting you between a rock and a
hard place, owing to that HSM injunction) --- that's because you don't
actually know what the microarchitecture of the x86 platform is. It's far more
complicated than the instruction set, or even what's documented in the PRM.

Aciicmez was able to recover keys from an Intel branch target buffer (the
branch prediction cache). Did you know what the BTB was before I wrote this?
Well, the BTB is public knowledge. How many microarchitectural features are
there on the platform that aren't public knowledge? _Probably lots_. Not being
a tinfoil hat type, I tend not to believe that any of these are malicious. But
if you think rdrand is a plot by the NSA, you _are_ a tinfoil hat type, and so
let me help you be consistent: you need to stop using AWS right now, and stop
using x86 platforms to run your encryption code. The NSA can pay $50 to get a
VM on the same AWS box as runs your VMs, and then use local side channels to
siphon out your secrets.

(Actually, so can the Slovak Mafia, which is a reason to be leery of doing any
crypto on AWS.)

If you can't tell, I think this whole kerfluffle about Linux using rdrand is
pretty silly.

~~~
sweis
I inadvertently spawned this discussion by pointing out that many open source
security projects like Linux, OpenSSL, GnuTLS, libgcrypt, dm-crypt, etc. all
depend on closed-source crypto implementations [1]. This was followed by one
of the Linux guys saying he quit the project over RdRand [2].

Everyone seems to be missing the point: RdRand is the least of your worries.
If you can't trust the CPU, you can't trust it to multiply correctly, much
less perform crypto.

If a CPU maker or OEM wanted to be evil, they wouldn't even need to bother
backdooring the hardware. SMM or microcode updates would be much easier to
compromise.

[1]
[https://mailman.stanford.edu/pipermail/liberationtech/2013-J...](https://mailman.stanford.edu/pipermail/liberationtech/2013-July/009946.html)

[2]
[https://mailman.stanford.edu/pipermail/liberationtech/2013-J...](https://mailman.stanford.edu/pipermail/liberationtech/2013-July/009969.html)

~~~
ig1
It's about verifiability, you can verify if a CPU is multiplying incorrectly,
there's no way of verifying if the random source is generating randomness
correctly.

~~~
tptacek
You can verify that your CPU is multiply correctly _at one moment in time._

~~~
ig1
Yes, but active attacks where a third-party can switch on-and-off features on
your CPU are obviously vastly different from a passive attack such as a
compromised random number source.

The RNG attack suggested can pass verifiability while at the exact same time
introduce a backdoor and thus constantly be on.

------
fragmede
The 'answer' is light on technical details, however.

Given a 'random' number generator which always outputs the number 4, how can
you attack ARIA, DES, 3DES, ARCFOUR, AES, Camellia, RC2, IDEA, SEED. That
should be easy enough to show.

Now take a random number generator that _seems_ random when N values are
graphed, when N is small.

How do you exploit that?

How about when N is large? How about when N is _huge_ and you've got
researchers writing programs looking for predictability?

------
wazoox
Reminds me of this friend working at the DST (french counter-intelligence
service) explaining how all the crypto hardware coming from Bull, Thales and
other French companies need to be backdoored to get its proper government
qualification. Furthermore, the French government happily provides this
hardware for a very attractive price to "their friends", like Romanian,
Lebanese, etc. security services.

------
acqq
No, you _shouldn 't_ be worried about RdRand particularly, not more than about
any other function, as long as you use it properly. If you don't use it
yourself, others already did the right thing for you, so you don't have to
worry: The present discussion here on HN showed that it _is_ used properly on
Linux. It's not the _only_ source and there's a seed used separately:

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

~~~
nightcracker
It's still used directly in Linux:
[https://mailman.stanford.edu/pipermail/liberationtech/2013-J...](https://mailman.stanford.edu/pipermail/liberationtech/2013-July/009969.html)
Furthermore, if RdRand is insecure but not recognized as such it's a potential
risk due to people building supposedly secure software using the instruction.

~~~
acqq
Address space randomization is not something you should worry about unless the
attacker is already on your machine, that is, it's irrelevant for passive
attacks.

------
e3pi
The Advanced Encryption Standard (AES)

"...is a specification for the encryption of electronic data established by
the U.S. National Institute of Standards and Technology (NIST) in 2001.[3] It
is based on the Rijndael cipher[4] developed by two Belgian cryptographers,
Joan Daemen and Vincent Rijmen, who submitted a proposal which was evaluated
by the NIST during the AES selection process.[5]

AES has been adopted by the U.S. government and is now used worldwide. It
supersedes the Data Encryption Standard (DES),[6] which was published in 1977.
The algorithm described by AES is a symmetric-key algorithm, meaning the same
key is used for both encrypting and decrypting the data.

AES is available in many different encryption packages, and is the first
publicly accessible and open cipher approved by the National Security Agency
(NSA) for top secret information when used in an NSA approved cryptographic
module (see Security of AES, below)..."

[http://en.wikipedia.org/wiki/Advanced_Encryption_Standard](http://en.wikipedia.org/wiki/Advanced_Encryption_Standard)

RdRand (also RDRAND)

"...is an instruction for returning random numbers from an on-chip random
number generator.[1] RdRand is available in Ivy Bridge processors[note 1] and
is part of the Intel 64 and IA-32 instruction set architectures.

Intel Secure Key, formerly known as Bull Mountain, is Intel's code name for
both the RdRand instruction and the underlying random number generator (RNG)
hardware implementation.[1] Intel calls their RNG a "digital random number
generator". The generator uses an on-processor entropy source, which passes
the randomly generated bits to an AES (in CBC-MAC mode) conditioner to distill
the entropy into non-deterministic random numbers. A deterministic random-bit
generator is seeded by the output from the conditioner, providing
cryptographically secure random numbers to applications requesting them via
the RdRand instruction..."

[http://en.wikipedia.org/wiki/RDRAND](http://en.wikipedia.org/wiki/RDRAND)

------
Nrsolis
For many years, I've been considering purchasing one of these:

[http://www.entropykey.co.uk/](http://www.entropykey.co.uk/)

I honestly don't know why we're using anything other than provable randomness
using discrete entropy sources in this day and age.

IIRC, even the Raspberry Pi has an entropy generator on-board. I haven't
verified this though.

~~~
exceptione
From the website

    
    
        Please note that there is a very long waiting period for 
        Entropy Keys at the moment.
    

Likely more people got this idea.

~~~
Nrsolis
Not exactly:

On Tue, Jul 02, 2013 at 08:11:13AM -0500, Robert Lee wrote: > This is
unfortunate. I do hope they are not going out of business.

We've gone through a major crisis, but are still here... just. To say any more
in public at this stage might be unwise from a legal standpoint.

We currently have no manufacturing capability for ekeys but are working
towards getting things up and running again. There's no timescale on that yet,
I'm afraid.

\-- Paul Martin <pm at simtec.co.uk> Simtec Electronics
[http://www.simtec.co.uk/](http://www.simtec.co.uk/)

------
nos4A2
I am just curious, why can't there be an online service which does Random
Number Generation, that should free up this dependency right? I understand
there would be trust issues etc, but I am sure well defined contracts and code
transparency coupled with open hardware can solve that?

~~~
olalonde
1) It would be slow.

2) The trust issue would be even greater and it would introduce a single point
of failure.

3) Online RNGs do actually exist. [http://Random.org](http://Random.org) for
example.

------
DanBC
{snipped}

EDIT: Thanks to lub1be for pointing out my error!!

~~~
lucb1e
You mean Thomas[1]? That's not Thomas Pornin[2].

[1] [http://crypto.stackexchange.com/questions/9210/technical-
fea...](http://crypto.stackexchange.com/questions/9210/technical-feasibility-
of-decrypting-https-by-replacing-the-computers-prng#comment17368_9212)

[2] [http://crypto.stackexchange.com/users/28/thomas-
pornin](http://crypto.stackexchange.com/users/28/thomas-pornin)

Edit: Guys there is no need to downvote him for making a simple mistake. I
actually also assumed that at first before remembering that Thomas Pornin uses
his full name as display name.

------
bangbang
Wouldn't a easier path for decrypting SSL be to go directly to Cert providers
and hit them with a NSL?

~~~
DenisM
Cert provider does not have the secret key, so the only thing you can do is
get a new cert and and then do man-in-the-middle. It's doable for an
individual target, but not doable for a massive dragnet.

If a compromised RNG can be used to decrypt data, it might be useful for
wholesale decryption of all encrypted traffic on the web.

------
thomasjames
If this actually yields anything, could it mean the wider proliferation of HW
random number generators?

------
jokoon
Aren't there ways to not use this rdrand thing ?

~~~
hannibal5
Yes there are and it would not hurt to use RdRand as part of the mix in
entropy pool.

The current flood of posts comes from the fact that Linux allows RdRand to
bypass the entropy pool.

------
cmccabe
Guess what: none of this matters, because RdRand is only one source of entropy
among many. For example, another source is the timing of TCP packets coming
into the machine. The NSA can't predict that; nobody can. It's the butterfly
effect in action.

RdRand is kind of the "crocodiles in the sewer" of HN. A tall tale that
somehow keeps getting passed around. Guys, they're just generating random bits
from thermal noise, that's it! There's a million other more effective
backdoors they could insert into the motherboard, CPU, or firmware.

