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

31–40 of 66 posts

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

#31

Post by nine_k »

phire wrote: post #21
floatboth wrote: post #17

Earlier quoted context omitted.

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.

Though, that means you just need one modified motherboard. Put each CPU in, extract the keys, deploy in a regular motherboard.

This still excludes wide ranges of possible rogue admin attacks.

As a minimum, it takes shutting down and powering down the physical machine, then starting it up, which would not go unnoticed in highly controlled environment where SEV makes most sense.

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

#32

Post by michaelt »

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.

> It is an interesting attack but is the above goal ever achievable? To protect against adversaries from the inside.

People have gotten very close to achieving similar goals.

For example, modern games consoles' anti-piracy measures guard against the device owner who has physical control and unlimited time. [1]

iPhone activation locks likewise prevent stolen phones from being used, even by thieves with physical control and unlimited time.

And neither of the systems rely on the clunky 'brick the device if the case is opened' methods of yesteryear.

(Of course there have also been a great many failed attempts - almost every console since the dawn of time has eventually been hacked, as have things like TPMs and TrustZone, many versions of the iPhone were rooted, etc etc)

[1] https://www.youtube.com/watch?v=quLa6kzzra0

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

#33

Post by tzs »

no_time wrote: post #5

Good. I hope this allows me to extract the fTPM keys from the hardware I own.

What benefit would you get from having the fTPM keys? I don't own any PCs with TPM or fTPM as far as I know, so am not very familiar with what having it does as far as user experience is concerned and what having the keys would do to improve that.

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

#34

Post by api »

floatboth wrote: post #16
londons_explore wrote: post #13

Earlier quoted context omitted.

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.

So this means the secure VM feature is secure up to the threat model of someone able to crack open the hardware.

Honestly that's kind of what I would have expected. Just making it almost impossible to get VM memory remotely by owning the hypervisor is pretty good and reduces your attack surface to people who can get into the data center and have electronics expertise.

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

#35

Post by dnautics »

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.

it's distinguish from bleu team administrators!

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

#36

Post by no_time »

tzs wrote: post #33
no_time wrote: post #5

Good. I hope this allows me to extract the fTPM keys from the hardware I own.

What benefit would you get from having the fTPM keys? I don't own any PCs with TPM or fTPM as far as I know, so am not very familiar with what having it does as far as user experience is concerned and what having the keys would do to improve that.

It would allow me to fake any measured boot attestation. Right now this infrastructure is only provided to companies looking to secure their network[0] but if you look at Android's SafetyNet and the trends in IT, companies may force you to only use software they approve of to use their services.

On android it's already a choice between banking apps or a device you fully control. I fear that this will include all internet connected devices in the future.

[0] https://docs.microsoft.com/en-us/windows-server/security/dev...

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

#37

Post by DSingularity »

lima wrote: post #9
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.

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

Do you mean “adversaries from the inside” could be more detailed to create reasonable limitations on access and resources as imposed by external systems (eg cameras, guards, searches) securing the machines?

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

#38

Post by dnautics »

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.

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

#39

Post by mmastrac »

no_time wrote: post #36
tzs wrote: post #33

Earlier quoted context omitted.

What benefit would you get from having the fTPM keys? I don't own any PCs with TPM or fTPM as far as I know, so am not very familiar with what having it does as far as user experience is concerned and what having the keys would do to improve that.

It would allow me to fake any measured boot attestation. Right now this infrastructure is only provided to companies looking to secure their network[0] but if you look at Android's SafetyNet and the trends in IT, companies may force you to only use software they approve of to use their services. On android it's already a choice between banking apps or a device you fully control. I fear that this will include all inte…

Oh god yes. I don't want a device where I have to choose between full services and full control (for myself). The introduction of SafetyNet really annoyed me for those reasons.

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

#40

Post by simcop2387 »

nine_k wrote: post #31
phire wrote: post #21

Earlier quoted context omitted.

Though, that means you just need one modified motherboard. Put each CPU in, extract the keys, deploy in a regular motherboard.

This still excludes wide ranges of possible rogue admin attacks. As a minimum, it takes shutting down and powering down the physical machine, then starting it up, which would not go unnoticed in highly controlled environment where SEV makes most sense.

it does mean though that a system integrator could extract the keys ahead of time, likely without any way to know this has happened. adding a way to generate a new key or otherwise rotate the key material should fix that issue though.
Post reply on HN