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

Fault Injection Attacks Against AMD's Secure Encrypted Virtualization

arxiv.org

Post reply on HN
Print view View original

61–66 of 66 posts

Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization

#61

Post by baybal2 »

evancox100 wrote: post #43
baybal2 wrote: post #4

Earlier quoted context omitted.

> It is an interesting attack but is the above goal ever achievable? To protect against adversaries from the inside. No, safe execution of untrusted code is impossible by the very definition, not without undoing 40 years of IC design practices. It's an almost physical limitation which makes it very hard to compute something without some electromagnetic leakage from/to the die. Take a look on secure CPUs for credit ca…

What is a TEM shop? Curious about this topic, the threat model for some chips in the secure payments space assumes a secret value much higher than $10k for something like a root encryption key that blows open the payment processing security of multiple cards. Also, just because something is physically possible, doesn't mean that the barriers to doing so are irrelevant. If it costs you $10k to unbrick a locked & stole…

Tunneling electron microscope

A single facility for TEM comes with $10,00,000+ pricetag, and usually they amount to few dozens per a developed country, in use in places like universities, and research institutes.

China has probably more of them than the rest of the world combined.

Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization

#62

Post by Taek »

monocasa wrote: post #59
michaelt wrote: post #49

Earlier quoted context omitted.

Yes, someone with an xbox hack has tens of millions of potential customers who can save $60 a game, with complete physical access to the hardware and no chance of getting fired or arrested. Whereas someone with a Google cloud infrastructure hardware fault injection attack has only a tiny number of spy agencies or rogue admins as potential customers, the servers are all locked up in data centres, and anyone who got ca…

Jimmy is only willing to spend less than he'd spend in the cost of games. Even with a large amount of Jimmys there might not be market without getting the cost of an individual attack low enough. On the other hand, there for sure is a market for cloud based attacks, and nation states that can apply a stick to go along with the carrot of millions of dollars in "consulting fees".

Especially as we move more key infrastructure into the cloud. If people start trusting these sorts of remote systems with things like financial data, the payoff of a clandestine compromise could be hundreds of billions of dollars.

Doubly true when you consider the history of Google working with the USG.

Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization

#63

Post by smcl »

creamytaco wrote: post #11

"rouge administrators" ?

One of the more commonly misspelled words. In this case it's just a little easily fixable typo in an article online, but I've seen a few businesses where people wanted "rogue" and had "rouge" instead which is kinda mindblowing. When you've registered a business, setup branding and signage etc all the while repeatedly messing up the same word each step of the way. Boy, that's embarrassing.

Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization

#64

Post by jlawer »

From a skim through the article, it seems to require soldering onto the power line between the voltage regulator and the processor to trigger the voltage drop. I don't believe the VR circuitry could be caused to glitch in the desired way by software / easily accessible physical components (i.e. plugging into USB).

Someone might be able to develop a method of causing this to occur by targeting a draw elsewhere, but this will likely by motherboard specific (or even entire platform specific).

It definitely means that SEV isn't going to save you if your vendors conspire against you, but unless your dealing with a determined state level actor, I doubt there is much risk to most of us. Internal actors (rogue staff) are likely to compromise in a simpler way.

However this is great research, I imagine in CPU designs that are being planned now, there will be some work to ensure the Secure processor is protected, likely by making the processor fault when SP input voltage drops. Alternatively they might be able to move some power regulation onto the processor package providing buffering against voltage manipulation.

Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization

#65

Post by new_realist »

swiley wrote: post #25
lima wrote: post #9

Earlier quoted context omitted.

> It is an interesting attack but is the above goal ever achievable? To protect against adversaries from the inside. Achievable in any circumstances? No. Within a well-defined threat model, definitely.

Except that the threat model the crippled SEV defends against is the same one the SU command does, making it irrelevant.

No. SEV is supposed to protect from root.

Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization

#66

Post by MayeulC »

baybal2 wrote: post #60
MayeulC wrote: post #8

Earlier quoted context omitted.

>> It is an interesting attack but is the above goal ever achievable? To protect against adversaries from the inside. > No, safe execution of untrusted code is impossible by the very definition I think this is more about data processing while hiding the data from whoever operates the hardware. Homomorphic encryption could be a partial answer to that.

> Homomorphic encryption Explain please to me how homomorphic encryption will protect someone from basic laws of physics.

I hate your condescending tone, especially since you are clueless about that and don't seem to be able to perform a simple search

https://en.wikipedia.org/wiki/Homomorphic_encryption

The idea is to use a special encryption scheme (and associated operations). If I take 50 numbers and multiply them by two before asking you to add them, I'll just have to divide the result by two to get the correct answer, and you won't see the data nor the result. Of course, actual schemes are more complex than that.

https://arstechnica.com/gadgets/2020/07/ibm-completes-succes...

Post reply on HN