Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

/dev/random and virtual systems

mail-archive.com

Post reply on HN
Print view View original

31–40 of 42 posts

Re: /dev/random and virtual systems

#31

Post by jsprinkles »

tptacek wrote: post #30
jsprinkles wrote: post #27

Earlier quoted context omitted.

> VMs are bad because they make it much easier for an attacker to get a process on the same CPU as yours; nothing more, nothing less. The paper cites less than 25% of the time which is specific to EC2. With more cores on the host this attack rapidly becomes impossible as domUs rarely share cores. Which is why I asked for actual evidence of cryptographic compromise in the wild and not yet more papers. You suffer from…

To your last question: yes. To your inevitable followup question: no, I'm not going to talk to you about it. To your overarching point: if you are on a cloud platform that promises you will never share hardware with any other company – which virtually nobody is – you are still at greater risk simply being on a nanosecond-timeable switched network with your attackers. But local crypto timing attacks are far more power…

So your NDA allows you to acknowledge that a side-channel cryptographic compromise is possible but not give any details? That's a really funny NDA. I call bullshit.

Or did you violate it to tell me 'yes'?

Re: /dev/random and virtual systems

#32

Post by tptacek »

jsprinkles wrote: post #29
tptacek wrote: post #28

Earlier quoted context omitted.

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

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 experi…

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)

Re: /dev/random and virtual systems

#33

Post by tptacek »

jsprinkles wrote: post #31
tptacek wrote: post #30

Earlier quoted context omitted.

To your last question: yes. To your inevitable followup question: no, I'm not going to talk to you about it. To your overarching point: if you are on a cloud platform that promises you will never share hardware with any other company – which virtually nobody is – you are still at greater risk simply being on a nanosecond-timeable switched network with your attackers. But local crypto timing attacks are far more power…

So your NDA allows you to acknowledge that a side-channel cryptographic compromise is possible but not give any details? That's a really funny NDA. I call bullshit. Or did you violate it to tell me 'yes'?

This comment doesn't make any sense. I'm not sure you know how NDA's work.

I asked a specific question in my comment that you haven't answered yet.

Re: /dev/random and virtual systems

#34

Post by jsprinkles »

tptacek wrote: post #33
jsprinkles wrote: post #31

Earlier quoted context omitted.

So your NDA allows you to acknowledge that a side-channel cryptographic compromise is possible but not give any details? That's a really funny NDA. I call bullshit. Or did you violate it to tell me 'yes'?

This comment doesn't make any sense. I'm not sure you know how NDA's work. I asked a specific question in my comment that you haven't answered yet.

Since I have executed one with my employer yes I do.

For example if you asked me directly if such an attack was possible I cannot answer you due to my NDA even though I have personal experience with the matter. You seem really eager to answer that it is though.

All of the NDAs I have signed have never said anything like "you can't say how, but you can say that we pulled it off". In fact most of the NDAs I've signed have been along the lines of "you don't talk about Fight Club".

Can we deduce that you are willing to violate your NDA to write that you have observed such an attack or that you never executed an NDA regarding the specific attack? Yes.

Re: /dev/random and virtual systems

#35

Post by tptacek »

jsprinkles wrote: post #34
tptacek wrote: post #33

Earlier quoted context omitted.

This comment doesn't make any sense. I'm not sure you know how NDA's work. I asked a specific question in my comment that you haven't answered yet.

Since I have executed one with my employer yes I do. For example if you asked me directly if such an attack was possible I cannot answer you due to my NDA even though I have personal experience with the matter. You seem really eager to answer that it is though. All of the NDAs I have signed have never said anything like "you can't say how, but you can say that we pulled it off". In fact most of the NDAs I've signed h…

Uh huh. Unfortunately, I have spent years building up a resistance to Iocane powder.

I'd still like to know what x86 side channel research you're writing off as "theoretical".

And I'd like to know why you so stridently believe this is a nonissue.

Re: /dev/random and virtual systems

#36

Post by jsprinkles »

tptacek wrote: post #32
jsprinkles wrote: post #29

Earlier quoted context omitted.

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 experi…

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),…

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

Re: /dev/random and virtual systems

#37

Post by tptacek »

jsprinkles wrote: post #36
tptacek wrote: post #32

Earlier quoted context omitted.

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),…

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

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.

Re: /dev/random and virtual systems

#38

Post by tptacek »

AretNCarlsen wrote: post #26
tptacek wrote: post #21

Earlier quoted context omitted.

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 S…

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.

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

Re: /dev/random and virtual systems

#39

Post by eru »

nodata wrote: post #7
ScottBurson wrote: post #6

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 t…

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

But most bare-metal installations will only hang once.

Re: /dev/random and virtual systems

#40

Post by stipes »

tptacek wrote: post #20
yuhong wrote: post #13

Earlier quoted context omitted.

How about having a command to manually reseed the PRNG?

You mean like write(2)? :)

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.
Post reply on HN