5 ms·
Does anyone have a ELI5 explanation?
by ddtaylor 7y ago
Does anyone have a ELI5 explanation?
- taspeotis 7y agohttps://arstechnica.com/information-technology/2019/12/scientists-pluck-crypto-keys-from-intels-sgx-by-tweaking-cpu-voltage/ https://arstechnica.com/information-technology/2019/12/scien...
- xucheng 7y agoIntel SGX is a Secure Enclave embedded in Intel CPU, which aims to provide secure and trust computation environment. For example, storing and processing cryptography secret keys, etc. It is similar to the enclave in Apple A chips used in Touch ID/Face ID. Currently, there is no wide adoption of SGX in the production environments, mainly due to the attacks like this. In this attack, the researchers found that by adjusting the voltage and clock frequencies of the CPU, they are able to generate errors inside SGX enclave and recover the secret keys inside.
- mehrdadn 7y ago> Currently, there is no wide adoption of SGX in the production environments, mainly due to the attacks like this. How long have these attacks been around? I only started hearing about them maybe like... in the past week or so? Nothing remotely close to explaining why these aren't used in production.
- saagarjha 7y agoThere are other attacks (https://arxiv.org/pdf/1802.09085.pdf https://arxiv.org/pdf/1802.09085.pdf), but I doubt they’re the major driving force behind lagging adoption.
- Legogris 7y agoIME lack of adoption is more due to lack of tooling and integration with popular languages and libraries. Also, the domains that have the most to benefit from SGX (heavily regulated ones like healthcare) tend to be very slow adopters of new technology. I guess there is definitely some level of concern for sidechannel attacks, given Intel's track record, but I don't think that's whats been holding back adoption.
- saagarjha 7y agoHow could healthcare benefit from SGX?
- Legogris 7y agoStrengthened protection for patient data.
- throwaway2048 7y agoIt also requires a very expensive license from intel, and to allow them partial control of your code via codesigning.
- thu2111 7y agoNo it doesn't. Getting a whitelisted code signing key just requires you to agree that you won't distribute malware. You pay nothing for it and Intel don't see the code you sign. Please don't make things up because they "sound right".
- dboreham 7y agoAre there non-Intel remote attestation servers now?
- thu2111 7y agoOnly Intel know what chips they've manufactured and what microcode patch levels are currently considered secure, so that wouldn't make much conceptual sense. But the new DCAP feature lets you run some of the RA infrastructure yourself, yes.
- Legogris 7y agoSGX is Intel's TEE (Trusted Execution Environment) platform, where an isolated memory address space (aka enclave) can host applications which give certain guarantees: * No outside code can gain access to any part of it - not even the host OS * Applications run precisely as executed (binaries need to be chryptographically signed) You could generate cryptographic keys inside the enclave and ensure that the private key is never seen in cleartext outside it. Let's say you're building a SaaS product to host sensitive data and expose an API. Using SGX, the remote endpoint can be ensured of the above. Root keys are signed by Intel (and recently delegated to cloud providers) - so there is some element of trust there. This attack uses power management interfaces to the hardware to induce faults in computations in the enclave, leading to data leaks. In the example above, the machine operator (or someone who gained privileged access on their machine) could abuse this to get access to sensitive data that's supposedly only inside the enclave. In any case and even in the absence of these threat vectors, SGX and similar solutions should be used as a layered security approach, not something to rely solely upon.
- josh2600 7y agoYeah, this is exactly correct. Sgx is not a silver bullet, at all. It’s a part of a security story.
- ljhsiung 7y agoIntel SGX is an enclave, or a hardware supported mechanism to store keys/do protected operations (most often implemented as essentially a co-processor). For example, if you want to run some AES operation, you would send it off into the enclave. More on faults-- A "fault attack" (I like to call them active attacks) is an attack where someone actively tampers with a device to "force" it into an "unreachable" state. An example of an "unreachable" state might be, for a single cycle, cutting off the voltage to a flip-flop to prevent a bit from being written. Contrived example, but enough to get the idea of "fault" in your head hopefully. Intel SGX is heavily advertised as being fault-resistant (although in recent years, time and time again it has shown to not be the case!). This is especially crucial because some crypto algorithms (e.g. RSA-CRT and AES in general) heavily rely on zero/minimal faults due to the nature of how these algorithms are constructed. RSA-CRT, for example, only needs a single fault in its algorithm for the private key to be compromised. CPU design today will also typically employ frequency or voltage scaling based on workload as a power saving metric-- say, if the CPU is idle. They will also make this ability software-visible, as it's quite handy for general uses as a whole. The researchers here exploit this ability to "cut the voltage" from software in the CPU to directly affect SGX as well, resulting in faults in the underlying operations. While fault attacks (especially timing ones) on SGX are nothing new, the shocker frankly is how they did the fault attack. Typically, in my experience, whenever someone says "power fault attack" you might envision someone with physical access to the chip "glitching" the clock or VCC to bypass some verification step, maybe in a lab or using a ChipWhisperer. This is obviously not the case here-- this is the first case of software power glitching I've seen (note that software clock glitching was done a few years back, but not on Intel machines I believe). I feel the need to point out that this isn't a fault (pun intended) of Intel's design-- OK maybe it is a little bit since this does fall under the SGX-type threat model, but I feel like this would more be an industry wide issue for any system with an actual hardware enclave (looking at you Apple), so Intel is unlikely alone in the blame, in the same way that speculative execution was (and still is, in my opinion!).
- anonymousDan 7y agoIt's not particularly novel to be honest. Someone already did a very similar attack a few years ago on ARM Trustzone (see a paper called "CLKSCREW: Exposing the Perils of Security- Oblivious Energy Management"). It was pretty well known that type of attack is likely possible on SGX too.