

/dev/random and virtual systems - bobds
http://www.mail-archive.com/cryptography@metzdowd.com/msg11533.html

======
tptacek
There are even bigger concerns with crypto on virtualized hardware: side
channels. We probably don't even know all the microarchitectural pathways that
crypto code can leave footprints on, let alone how to deploy efficient
general-purpose crypto code to obscure those footprints.

~~~
JonnieCache
Could you elaborate on this? My _interesting stuff_ detector is going crazy
but I'm kinda out of my depth as to what exactly you're talking about. Are you
referring to information leakage from the guest to the host operating system
that might allow the host to sniff the inner workings of crypto algorithms
running on the guest? Or perhaps guests sniffing other guests through timing
attacks and suchlike?

~~~
tptacek
Here's a fine starting point:

<http://eprint.iacr.org/2006/351>

~~~
JoachimSchipper
For the benefit of everyone in a hurry: those attacks are very real. If you're
running on AWS, assume that the NSA [EDIT: or anyone with deep pockets, or
plenty of time on his hands] can break any crypto algorithm you use.

You are still secure from script kiddies, of course, and you've done a fairly
good job if this is the easiest way to hack you.

~~~
tptacek
This isn't NSA-hard stuff; it's $500,000-contract hard.

~~~
jsprinkles
So what you're saying is that your fee for side-channeling the private keys
from a neighboring domU or dom0 without root dom0 access is $500,000? How long
to deliver?

~~~
tptacek
That is not what I'm saying, as you well know.

~~~
jsprinkles
Then who if not Matasano can perform such an attack for $500,000?

Let's say I'm in the market and this particular web site annoys me and it is
hosted on EC2. I want to compromise that web site's crypto from a neighboring
domU and my budget is $500,000.

You are saying I can contract with someone at that rate and it will get done?
How long does _that_ security company take to deliver? With your breadth of
security experience and your claim that it's a $500,000-contract job surely
you must know who will write that contract otherwise you wouldn't have said
such a thing, right?

~~~
tptacek
I didn't pull that number out of the air; I gave it a good 30 seconds of
thought.

I arrived at it by:

* modding our bill rate up to that of a contractor who specializes in hardware crypto (we do not, but I know the bill rates of several people who do),

* guessing the amount of time it would take me to implement e.g. Aciicmez (something I can do reasonably because we did BTB timing for virtualized rootkit detection), and

* breaking it up into hours x bill rate.

If you can name 3 people who specialize in adversarial hardware crypto
review†, then you know there are _at least_ another 3 who will do grey-area
projects of similar sophistication (say, for a company's competitor).

Can _you_ name 3 hardware crypto testing specialist firms? I know there are
other people on HN who can. Are you one of them?

† _(I can: 83f633acea3a6ca594ea85ae552445369058ded1)_

~~~
jsprinkles
Hilarious to watch you fight for HN all over the place then throw it all out
the window when someone questions you.

~~~
tptacek
I don't even know what this means.

I asked more specific questions in my comment; you aren't answering them. The
only important question: why are you so strident about x86 side channels being
a non-issue?

Because I'd watch chip vendors not even figure out how to secure MSIs under
their IOMMUs and question whether just-plain-old- software security was a
reasonable expectation under virtualization. You on the other hand seem to
think it's so solid that the microarchitecture doesn't cache crypto artifacts.

------
ScottBurson
In a previous job I worked for a company whose product needed some entropy on
startup. It originally read from /dev/random. But then one of our customers
reported that the product was hanging on startup, just after installation. It
turned out that they had installed it into a freshly built VM (not a cloned
one, I guess) and the read from /dev/random was waiting to accumulate enough
entropy to return. (We changed it to use /dev/urandom instead, which is not
entirely satisfactory, but at least prevents hanging in this situation.)

While this is not exactly the scenario the OP is describing, it's another
thing that can go wrong with /dev/random and VMs.

~~~
nodata
But that's not a problem with /dev/random and VMs, that's a problem
everywhere.

~~~
eru
But most bare-metal installations will only hang once.

------
justincormack
Most servers have little source of decent entropy. Virtualisation makes this
worse. Intel has dropped the motherboard RNG support in their chipsets. The
suggestion in the thread to use a few cheap VIA boxes which have CPU RNG is
one idea. There are cheap USB rngs too like <http://www.entropykey.co.uk/>.

------
stipes
I did some research work last semester on crypto inside VMs. One of our
initial readings was Yilek's work on attacking VM crypto through VM snapshots
<http://cseweb.ucsd.edu/~syilek/ndss2010.html>

~~~
tptacek
That's an interesting trick but not really representative of the problem.
Reusing an RNG's entropy pool wholesale after restarting a snapshot is a
mistake, not a design flaw.

~~~
stipes
Part of the problem is the conflict of transparency and security here. Fixing
the wholesale reuse of RNG state would most likely require modifying the guest
so that it is aware of being restarted from a snapshot so it can react
appropriately.

However, that might have consequences on what restoring from a snapshot means
conceptually.

~~~
yuhong
How about having a command to manually reseed the PRNG?

~~~
tptacek
You mean like write(2)? :)

~~~
stipes
Yes, in general write to /dev/random with the write permissions is how entropy
gathering daemons and the like work. It gets added the input and mixed in.
However, that doesn't fix the issue of how a snapshot restore works on most
hypervisors. Adding an RNG refresh as part of the restore process could be
possible, but definitely not trivial, and it could have other consequences if
not carefully implemented.

------
AretNCarlsen
I put up a poll on the subject:

<http://news.ycombinator.com/item?id=2597256>

~~~
JoachimSchipper
Why do you feel a poll is useful?

~~~
AretNCarlsen
I'm coming from a background in massively parallel computing and financial
services, both of which are heavy on security. Nonetheless, and even though I
have been running cryptographically active instances on Amazon and Rackspace
for a long time, I had honestly never thought about the RNG source on VMs.

That is my own failure, of course. I wonder, though, whether everyone else
knew about the VM RNG issue, or if only I had missed the memo. If the majority
of poll respondents have never thought about the problem at all, perhaps I
should start an awareness campaign on wikis and forums.

~~~
tptacek
You did not miss the memo. Crypto on virtualized cloud platforms isn't
trustworthy. But it's a grade of untrustworthy several steps higher than
"exploitable SQL injection", so people don't think about it, talk about it, or
take it seriously.

The poll, though, is unnecessary and I flagged it.

Meanwhile, you brought up:

 _Robert Brown's dieharder:_
<http://www.phy.duke.edu/~rgb/General/dieharder.php>

_NIST Statistical Test Suite:_
<http://csrc.nist.gov/groups/ST/toolkit/rng/index.html>

_Fourmilab's ENT:_ <http://www.fourmilab.ch/random/>

You noted that people could run these on their CSPRNGs to check randomness.
No, they can't. These are all useful tools indeed; pentesters use them to
check cookies and crypto tokens. But they can only tell you whether bits are
correlated. It is very easy for an uncorrelated stream of bits to be terribly
insecure: they simply have to be seeded from the same source.

It is not a good idea to suggest people test their RNGs with things like
"ent". In "ent", Ruby's insecure rand() can appear competitive with
/dev/random.

There's also the obvious confounding issue with testing an entropy pool by
depleting it.

~~~
AretNCarlsen
Hence the caveat: "and hope/trust that the entropy you observe is unique, not
copied to any other instances".

I suppose it would take a centralized web service to detect correlated
unrandomness between servers. I am not personally willing to implement such a
service right now.

~~~
tptacek
Even if entropy isn't shared, you can't really test a CSPRNG by feeding it
through "ent".

