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

51–60 of 66 posts

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

#51

Post by mindslight »

titzer wrote: post #50
mindslight wrote: post #48

Earlier quoted context omitted.

I'd like to imagine that the engineers tasked with developing these systems are aware of management's evil endgame, and leave in whatever obvious bugs they can to slow down the loss of computational freedom. The spec for the next version will include an on chip regulator, and they'll have to sabotage it a different way.

Uh, this is completely unethical behavior from an engineer. In no way, shape, or form is the insertion of a deliberate, hidden flaw that breaks the intended security properties of a system an acceptable form of protest.

It wouldn't be a "protest". Rather, it would be directly preserving individual human autonomy against emergent entities. Would you also consider it "unethical" for a farm animal to break out of its pen?

The true ethics violation here is creating devices to be "sold" while retaining control over their new supposed owner. Unfortunately, the digital/software engineer's main recourse to ethical violations is to quit, and someone else will just take their place. As the digital honeymoon wears off and we become keenly aware of communications technology's authoritarian potential, I hope there is a different type of resistance forming within all of these systems of control.

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

#52

Post by dnautics »

theevilsharpie wrote: post #47
dnautics wrote: post #38

Earlier quoted context omitted.

does anyone actually use SEV in cloud environments? My impression was that its lineage (my understanding it's basically AMD's intel-SGX) is to enable DRM for stuff like netflix. I know for a time there was a lot of talk about using SGX in the cloud, but I was under the impression that the trust in SGX has been eroded over time to the point where no one thinks it's a good idea.

SEV is completely different from SGX, and doesn't (currently, to my knowledge) have an equivalent on Intel chips that are currently on the market. Google Cloud's confidential compute feature makes use of SEV under the covers.

thanks for clearing that up!

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

#53

Post by benlivengood »

dnautics wrote: post #38
spdy wrote: post #2

With our findings, we prove that SEV cannot adequately protect confidential data in cloud environments from insider attackers, such as rouge administrators, on currently available CPUs. --- It is an interesting attack but is the above goal ever achievable? To protect against adversaries from the inside.

does anyone actually use SEV in cloud environments? My impression was that its lineage (my understanding it's basically AMD's intel-SGX) is to enable DRM for stuff like netflix. I know for a time there was a lot of talk about using SGX in the cloud, but I was under the impression that the trust in SGX has been eroded over time to the point where no one thinks it's a good idea.

I've only spun up a SEV instance for the novelty but am considering using it for things like hashicorp vault where performance isn't critical but extra privacy assurance is nice.

Fundamentally, though, system security hasn't caught up with the promise of SEV. It's far more likely that a VM will be compromised by 0-day attacks than insiders at the cloud companies. But if you really need to run a secure kernel on someone else's machine then SEV is the way of the future. This includes using SEV on-premises against hardware attacks. I've wanted hardware RAM encryption for a decade or two to avoid coldboot attacks and similar hardware vulnerabilities.

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

#54

Post by [deleted] »

JustFinishedBSG wrote: post #15
spdy wrote: post #2

With our findings, we prove that SEV cannot adequately protect confidential data in cloud environments from insider attackers, such as rouge administrators, on currently available CPUs. --- It is an interesting attack but is the above goal ever achievable? To protect against adversaries from the inside.

> rouge administrators It's not important but come on, if your field is cyber security at least make sure rogue is spelled correctly.

[deleted]

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

#55

Post by doubled112 »

swiley wrote: post #29
throwaway420y wrote: post #20

Earlier quoted context omitted.

Are you sure they aren't talking about these admins ? https://en.wikipedia.org/wiki/Wikipedia:Rouge_admin

One day, when I'm retired or homeless, I'd love to pull apart and try to understand the weird cultures of wikipedians.

If you're retired AND homeless, will you do the same, or will you have bigger problems?

Just trying to figure out where you've drawn the line.

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

#56

Post by landr0id »

spdy wrote: post #2

With our findings, we prove that SEV cannot adequately protect confidential data in cloud environments from insider attackers, such as rouge administrators, on currently available CPUs. --- It is an interesting attack but is the above goal ever achievable? To protect against adversaries from the inside.

While its goals are a bit different from confidential computing, people saying "no" here have apparently never heard of the Xbox One. More generally, securing a device against its physical owner is notoriously difficult. Tony Chen gave a talk about how the Xbox One was secured against physical attack: https://www.youtube.com/watch?v=U7VwtOrwceo

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

#57

Post by wmf »

theevilsharpie wrote: post #47
dnautics wrote: post #38

Earlier quoted context omitted.

does anyone actually use SEV in cloud environments? My impression was that its lineage (my understanding it's basically AMD's intel-SGX) is to enable DRM for stuff like netflix. I know for a time there was a lot of talk about using SGX in the cloud, but I was under the impression that the trust in SGX has been eroded over time to the point where no one thinks it's a good idea.

SEV is completely different from SGX, and doesn't (currently, to my knowledge) have an equivalent on Intel chips that are currently on the market. Google Cloud's confidential compute feature makes use of SEV under the covers.

Specifically, I think SEV is lacking attestation that would be needed for DRM.

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

#58

Post by monocasa »

landr0id wrote: post #56
spdy wrote: post #2

With our findings, we prove that SEV cannot adequately protect confidential data in cloud environments from insider attackers, such as rouge administrators, on currently available CPUs. --- It is an interesting attack but is the above goal ever achievable? To protect against adversaries from the inside.

While its goals are a bit different from confidential computing, people saying "no" here have apparently never heard of the Xbox One. More generally, securing a device against its physical owner is notoriously difficult. Tony Chen gave a talk about how the Xbox One was secured against physical attack: https://www.youtube.com/watch?v=U7VwtOrwceo

Chen makes it very clear that their threat model only includes attacks costing less than the attach rate of the system (about $600). He doesn't consider it an achievable goal in the general case.

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

#59

Post by monocasa »

michaelt wrote: post #49
steelframe wrote: post #46

Earlier quoted context omitted.

There's a significant asymmetry in motivation and resources available to compromise hardware between Jimmy and his Xbox vs. Google and their cloud infrastructure.

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".

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

#60

Post by baybal2 »

MayeulC wrote: post #8
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…

>> 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.

Post reply on HN