Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
1–10 of 66 posts
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#2With 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.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#3With 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.
My understanding is that this is part of the threat model of TEEs (Trusted Execution Environment). Whether or not this will ever be achievable is a different story.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#4With 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.
> 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 cards. They have layer, upon layers of anti-tampering, anti-extraction measures, and yet TEM shops in China do firmware/secret extraction from them for $10k-$20k
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#5Good. I hope this allows me to extract the fTPM keys from the hardware I own.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#6With 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.
> 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 very hard to perform a physical process while making it impossible to observe it. Similarly it is very difficult to have some object with permanent physical properties that you (the chip) can measure yourself, but no one else can, like a cloud of electrons trapped on an island, or a metal connection between two places.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#7With 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.
It's not plug-and-play. It still needs a custom firmware:
"(...)The presented methods allow us to deploy a custom SEV firmware on the AMD-SP, which enables an adversary to decrypt a VM's memory.(..)"
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#8With 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.
> 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.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#9With 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.
> 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.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#10With 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.
Well, that's the explicit goal of SEV.
That the CPU should be able to cryptographically prove that a VM has been setup without any interference from an inside attacker who controls the hardware.
At the very least, SEV massively raises the barrier to such attacks. It's now beyond the ability of a rogue administrator or technician, requiring complex custom motherboards. But a well-funded inside attacker can target something with high enough value.