"rouge administrators" ?
Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
11–20 of 66 posts
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#12With 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 some…
> It's now beyond the ability of a rouge administrator or technician, requiring complex custom motherboards
The end of the abstract explicitly refutes this. It is claiming that a software-only solution, using keys derived with this technique, can pretend to be a suitable target to migrate a secure VM to, which then allows the rogue admin to inspect or modify anything in the VM.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#13With 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.(..)"
InstallRogueFirmware.exe. double-click.
This is about protecting a VM from people who have admin rights and hardware access outside the VM.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#14"rouge administrators" ?
I guess that physically proves they are on the red team? /j
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#15With 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.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#16Earlier quoted context omitted.
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.(..)"
InstallRogueFirmware.exe. double-click . This is about protecting a VM from people who have admin rights and hardware access outside the VM.
Voltage glitching is no double-click. It would be a huge embarrassment to AMD if just double-click defeated the secure processor's firmware authentication. This requires electrically messing with the power supply of the processor.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#17Earlier quoted context omitted.
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 some…
> It's now beyond the ability of a rouge administrator or technician, requiring complex custom motherboards The end of the abstract explicitly refutes this. It is claiming that a software-only solution, using keys derived with this technique, can pretend to be a suitable target to migrate a secure VM to, which then allows the rogue admin to inspect or modify anything in the VM.
A bit unclear from the abstract whether the keys they learned how to derive (and the secret material they're derived from) are per individual chip or for all chips ever produced. If it's the former, that means the rogue admin still needs to electrically mess with the hardware once.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#18With 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
#19Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#20With 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.
Are you sure they aren't talking about these admins ?
https://en.wikipedia.org/wiki/Wikipedia:Rouge_admin