3 ms·
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
by phire 5y ago
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.
- londons_explore 5y ago> 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.
- floatboth 5y agoA 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.
- phire 5y agoThough, that means you just need one modified motherboard. Put each CPU in, extract the keys, deploy in a regular motherboard.
- nine_k 5y agoThis 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.
- simcop2387 5y agoit 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.
- toast0 5y agoOne 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.
- nieve 5y agoThe part about "without requiring physical access to the target host" would seem to imply that they only need access to a machine on their end for some attacks.