Intel's SGX cloud-server security defeated by $30 chip, electrical shenanigans Boffins at the University of Birmingham in the UK have developed yet another way to compromise the confidentiality of Intel's Software Guard Extensions (SGX) secure enclaves, supposed "safe rooms" for sensitive computation. Over the past few years, the security of SGX, a set of security-oriented instructions used to set up so- …
See also this recent article: Kernel support for processor undervolting at Linux Weekly News.
"Intel mitigated the vulnerability by removing the ability to reduce processor voltage, via microcode and BIOS updates."
The problem with fixing something via a BIOS update is that these aren't offered via the usual OS update mechanism, so often never get updated as they have to be done manually.
At least on most security-conscious Linux distributions, microcode updates are applied early in the boot process; usually they're prepended to the initial ramdisk image (initrd.img) or equivalent and installed by the kernel, or earlier by GRUB with an additional "initrd /boot/microcode.cpio".
Debian and derivatives have packages intel-microcode and amd-microcode.
Your task as a system admnistrator is to make machines as much safe and secure as possibile. If you believe that only OS updates will do you will find your wrong because often firmware updates - BIOS included fix other issues an OS can't, including security ones.
Many enterprise system now have IPMI management that allows to install most firmware updates in a very automated way. Anyway microcode updates made by BIOS or the OS are the same, those in the BIOS are applied earlier in the boot process.
AAFAIK microcode updates aren't persistent. They need to be uploaded to the CPU every time the system boots. BIOS/UEFI have a chance to upload them well before they hand off the system to the OS boot loader. Moreover if you run an OS for which microcode updates aren't available you'll need to rely on the BIOS uploading them.
I was looking at the SGX architecture and was amazed at its capabilities. And I had serious doubts about the ability of the architecture to be resistant to all the attacks we see.
By doing more than some key protection, protected crypto, secure boot, Intel was pushing its own boundaries. Sometimes, especially in security, being small and simple is better.
from the article :-
Over the past few years, the security of SGX, a set of security-oriented instructions used to set up so-called secure enclaves, has been assailed repeatedly by infosec types.
always been the way, make something, say it is SECURE, or worse, UNBREAKABLE, sit back and watch it crumble
gotta say, kind of impressed by the work done to actually manage this, I suppose the upside is that we get some new research, and possibly a step closer to truly SECURE ?
> some new research, and possibly a step closer to truly SECURE
I'm sorry but that's never going to happen.
What we've got here is the classic "sword vs. shield" contest, where each one gets incremental improvements to counter the other one's improvements till they eventually become totally pointless.
Anybody claiming he managed to create something totally secure is either criminally naive or a scam artist. The best you can ever hope to achieve is "secure enough", where "enough" means "if you don't look at it too closely".
I can securely store data for you. Guaranteed security - nobody will ever be able to read it. Including you, unfortunately; provide it in hardcopy and I'll burn it and compost the ashes.
All joking aside, you're right. If one person can retrieve the data, there will always be the possibility that someone else can. The concept of SGI is nice, but isn't foolproof and never will be.
Never mind the Evil Maid. Physical access isn't insurmountable.
1) Your OWN PC, at home, you can circumvent CPU based DRM of streaming stuff. Or maybe something remote uses the same key?
2) State actors, bribery by criminals etc gets data centre physical access.
So Game Over for all SGX based DRM or Security.
Yeah, that sort of last century thinking isn't what the marketing departments at aws and azure and GCP and whatever oracle's cloud is called etc.
The whole point of sgx (and Amazon's nitro enclaves- I think thats the only one on offer so far. Apart from enarx, which isn't really ready) is that you _can_ put your secure stuff in someone else's data centre. For Intel to be saying that hardware attacks aren't part of the threat model is like those car emergency braking systems that got confused by being near metal.
[blockquote]"The results in this paper, together with the manufacturer’s decision to not mitigate this type of attack, prompt us to reconsider whether the widely believed enclaved execution promise of outsourcing sensitive computations to an untrusted, remote platform is still viable."[/blockquote]
Yeah, but you know that it's going to be done anyway. When Ruby is used for back-end code to handle "secure" data in the cloud, then never mind what special bonuses an Intel SGX could possibly bring.
> opening the case and tampering of internal hardware to compromise SGX is out of scope for SGX threat model
That is correct.
> The boffins conclude that, in light of their findings, relying on third-parties and secure enclaves to protect computational secrets may be unwise.
And so is that.
In other words, a state of security must always be referenced to a specific threat model, i.e., secure against *what* exactly? Intel have defined their threat model and this attack falls outside its scope, so it doesn't say anything about the security of their system.
And the research team know this and point out that there are other things to consider in the process of defining and maintaining your own threat model to protect against the specific threats that you know or expect that you might encounter (and can afford to protect against).
This needs to be understood.
Intel have a threat model. That doesn't mean it is correct, complete, consistent, or even appropriate. Attacks are constantly evolving and Intel seem to be hiding behind their threat model rather than being proactive, engaging with these researchers, and asking what new threats look like and how it is possible to mitigate against them.
It is possible to defend against these attacks, the problem is that it costs money.
And a degree of throwing it away and doing it properly.
If SGX is proven to be smashed, does this mean we can drop the requirement for UHD playback limiting PC users being able to watch 4k discs they legally own on a pc other than one with an Intel CPU made in the last five years (especially given AMD's are rather fashionable at the moment).
Speaking as someone who's desktop is AMD, spare desktop is AMD, HTPC is intel (but a NUC that's older than Skylake) and neither laptop in the house supports it too. Only my NAS with it's little i3 that I built last year can actually playback the UHD's I have (thank god the drive's USB so I could actually test it in all these machines).
It absolutely stinks from a customer perspective. I can't watch the discs I legally own unless I'm huddled under the stairs with my NAS box but I could easily go online and download a myriad of rips of these discs.
That said, out of the two I own I only bought one. Alien I won in a competition and Die Hard is so full of noise from the transfer on the anniversary steel tin I bought that my old DVD looks better anyway. But, as a massively film nerd with a 4k projector, I would buy more of these things if I could bloody well play them.
No - I suspect the opposite is true. If the content providers can't trust general purpose processors to provide adequate security, they may prevent it working via an update and go back to dedicated appliances.
Having said that, SGX and similar cover a large range of security requirements from content protection to disk encryption to memory encryption and beyond.
While these flaws exist, they exist in a world where other protections are in-place such as physical security and the value of data varies. For content protection, they release a new format thats secure for a few more years and drive another upgrade cycle and everyone purchases Star Wars for the 26th time. For cloud security, its likely good enough for most people (put a tick against encryption at rest in our compliance spreadsheet) and for the really paranoid (with or without reason) they use alternative key sources such as hardware keys in key servers in a physically secure location that you own/control all access to.
The real question is whether other non-Intel/AMD secure enclaves are just as vulnerable. I suspect the answer is yes given sufficient effort.
The entire point of SGX is to isolate the data and code running inside an enclave from code and data outside of it. Its main purpose is to ensure that secrets in a VM is kept out of reach from someone having control of the VMM, the threat model really doesn't include physical access.
I'm kind of curious if they had code running in the enclave too, or if they just stuck a key in there? I'd imagine that the more you have, and the more that changes, in an enclave the harder it'll be to get a key. These types of attacks aren't really my gig though, so I'm just guessing.
I can’t see how SGX and other non-Intel/AMD secure enclaves can ever be totally secure from someone that has complete access to the hardware. The secure enclave is a black box. But with complete access to the hardware around it you are able to observe/measure everything that happens outside it and control what goes into it. It will always be possible to model what happens inside.
I was at IBM during the STI collaboration that created the Cell microprocessor. This design won all three of the big gaming consoles for that cycle. A major concern was that online transactions were to be supported (for the first time?), along with the notorious concerns of proprietary systems. So, one of these "secure enclaves" was part of the design. Fairly late in the process, the lawyers were looking over the situation, and got panicky, "We are calling this 'secure'? What if someone breaks it? We could be sued!" So--we started referring to it as "isolated". As reported in these pages, the "isolation" was broken in less than a year.
"Secure Enclave"---are you sure?
was a microcode and BIOS update, which has to be installed by the hardware owner? The very people that this architecture is designed to protect against?
"This attack is quite relevant because it is often claimed that SGX can defend against malicious insiders/cloud providers," namely, the people "trusted" to apply the patch to prevent this kind of thing. Hmm.
Really seems like the only viable option is to own the hardware and have intrusion monitoring devices. The cloud seems to have acid rain these days...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
