Wow, this is just really basic stuff in the secure IC world that you need to monitor the supply voltage for glitch attacks [0]. The glitch they are injecting is in the 20 us range which isn't even that fast. Whatever part of the chip you want to keep secure (the SP in this case I guess) probably needs a dedicated voltage regulator, preferably an on-chip LDO w/ a droop monitor on the output. I only skimmed the paper, but it seems like there is no supply monitoring being done that would cause the SP to bail out of its hash checking.
Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
41–50 of 66 posts
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#42Earlier 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.
One potential use of SEV is to provide a secure environment to run a VM at an untrusted provider. That provider could do lots of things with funky motherboards and forced migrations without notice by their clients.
If it's an insider attack on company owner and operated hardware, there's always some reason to have a long downtime, and you can piggyback on that to attack the CPUs... Or just put it in a new system and use the migration setup.
Suggested downtimes, organic or sabotage up to attacker's timeline:
HVAC failure: have to shut down many/most/all servers to manage temperatures until HVAC techs can fix.
Automatic transfer switch failure: these things love to fail at the same time as a utility failure, and aren't always easy to bypass.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#43With 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…
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 & stolen iPhone, then those countermeasures have likely succeeded at their intended purpose. This is why threat models try to quantify the time and/or monetary value of what they're protecting.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#44Earlier 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…
[deleted]
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#45With 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.
Thanks, I was worried I had red that wrong
ducks
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#46With 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 contro…
There's a significant asymmetry in motivation and resources available to compromise hardware between Jimmy and his Xbox vs. Google and their cloud infrastructure.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#47With 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.
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.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#48Wow, this is just really basic stuff in the secure IC world that you need to monitor the supply voltage for glitch attacks [0]. The glitch they are injecting is in the 20 us range which isn't even that fast. Whatever part of the chip you want to keep secure (the SP in this case I guess) probably needs a dedicated voltage regulator, preferably an on-chip LDO w/ a droop monitor on the output. I only skimmed the paper,…
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.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#49Earlier quoted context omitted.
> 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 contro…
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 caught making an attack would get fired and/or arrested.
Re: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization
#50Wow, this is just really basic stuff in the secure IC world that you need to monitor the supply voltage for glitch attacks [0]. The glitch they are injecting is in the 20 us range which isn't even that fast. Whatever part of the chip you want to keep secure (the SP in this case I guess) probably needs a dedicated voltage regulator, preferably an on-chip LDO w/ a droop monitor on the output. I only skimmed the paper,…
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.