LWN: Comments on "SGX: when 20 patch versions aren't enough"

SGX: when 20 patch versions aren't enough

immibis — Fri, 26 Jul 2019 03:13:18 +0000

That measure would be part of a defense-in-depth scenario for an embedded system for example. Not something you need to be concerned about coming to your desktop.

SGX: when 20 patch versions aren't enough

farnz — Sun, 28 Apr 2019 13:27:30 +0000

Your Intel FSE should be able to help you out :-(. There doesn't appear to be a generally available public key for SGX; those are things you get under NDA.

SGX: when 20 patch versions aren't enough

ballombe — Sun, 28 Apr 2019 10:09:28 +0000

How do you get the public key ?

SGX: when 20 patch versions aren't enough

smurf — Fri, 26 Apr 2019 13:45:31 +0000

Presumably the enclave isn't running in a vacuum but requires external data to process, which you can send to it by way of attestation-based encryption. Your debugger can't get an attest and thus doesn't have the key to decrypt the data.

SGX: when 20 patch versions aren't enough

nix — Fri, 26 Apr 2019 13:12:13 +0000

Ah, this was their post-attack fix: I didn't know one had been released yet, let alone that it was part of the same thing that included opening up enclave signing so it's actually useful to anyone other than very large corporations that can get their DRM malware signed by Intel.

I'm not sure if this works on existing SGX-supporting processors with a microcode update, or only on new ones: the link to a list of supported processors in the page you link to is empty for me. (If it does work only on new ones, the omens are rather bad: if every attack means you have to buy new hardware to be able to use SGX securely again, it will be a *long* time before this becomes useful to the general public.)

SGX: when 20 patch versions aren't enough

LtWorf — Fri, 26 Apr 2019 10:36:50 +0000

But I could also run the same code twice, inside the enclave and with a debugger, thus learning what it's doing. Or am I missing something?

SGX: when 20 patch versions aren't enough

excors — Fri, 26 Apr 2019 01:54:49 +0000

It doesn't sign just the nonce, it signs the nonce plus an identifier of the application running in the enclave, plus (I think) parts of a key exchange protocol. Those exchanged keys will get wiped whenever the application is replaced. The user can communicate using those keys, with a guarantee that those keys are known only by a single instance of their real application running in a real enclave, so they're communicating securely with their remotely-hosted application.

The only thing a MITM can do is redirect the request to another real enclave running the user's real application (because that's the only way to get a valid signature), then observe the encrypted traffic to that application (they can't decrypt it because the enclave is designed to keep those keys secret even when the attacker has physical access). And that's not really an attack, that's just free secure hosting for the user.

SGX: when 20 patch versions aren't enough

rgmoore — Fri, 26 Apr 2019 00:56:16 +0000

It seems as if there ought to be a way to deal with this through something like a MITM attack. It would work something like:

Malicious admin sets up a real enclave with software that can have a nonce signed by the hardware key.
Malicious admin creates a system to make fake enclaves for their users.
User creates a fake enclave and asks the hardware to sign a nonce.
Malicious admin intercepts the nonce, sends it to his own enclave to have it signed, and returns the signed nonce to the fake enclave.
User believes his nonce being signed is proof that the system hasn't been compromised

I will admit I'm not a security professional, but what is the mechanism for preventing something like this?

SGX: when 20 patch versions aren't enough

luto — Thu, 25 Apr 2019 21:01:21 +0000

Indeed. That entire mechanism is all software and a decent fraction of it runs in the cloud. The mechanism I'm talking about is newer and a bit closer to the raw hardware mechanism. It's described here:

https://software.intel.com/en-us/blogs/2018/12/09/an-upda...

SGX: when 20 patch versions aren't enough

farnz — Thu, 25 Apr 2019 20:52:31 +0000

The bit you're missing is the hardware root of trust; I can get Intel's on-chip private key to sign a nonce that I then use to verify that it's my code running inside SGX. The kernel does not have that private key, so cannot generate the signature you need to get the code to execute.

SGX: when 20 patch versions aren't enough

nix — Thu, 25 Apr 2019 20:42:09 +0000

The keys are per-CPU, but there is a pseudonymous attestation mode which uses keys shared by large numbers of CPUs. At least some of those keys have (allegedly?) been extracted through side-channel attacks (see e.g. FORESHADOW).

SGX: when 20 patch versions aren't enough

ju3Ceemi — Thu, 25 Apr 2019 19:45:32 +0000

"That means offering the enclave feature is a plausible promise that the kernel isn't hostile, which is something you might want an assurance of if you're running on a system that you don't completely control."

As a naive person, I would think one can simply emulate the whole sgx stuff
If I own the kernel space, I can do whatever I want, even let you think you actually used sgx, while in fact, you did nothing

This whole "feature" is, to me, a huge conceptual non-sense

SGX: when 20 patch versions aren't enough

luto — Thu, 25 Apr 2019 00:16:09 +0000

Nope, the keys are per-CPU. Side channel leaks can break SGX, but so far they haven’t even come close to leaking the real key. And Intel has a way to prevent CPUs with out of date microcode from passing the attestation check.

What I don’t quite understand is how Intel
is handling L1TF. As I understand it, even microcode can’t work around it if Hyperthreading is on.

(With the newer, easier, and vastly simpler attestation mechanism, there is no privacy whatsoever.)

SGX: when 20 patch versions aren't enough

mm7323 — Wed, 24 Apr 2019 20:16:56 +0000

It could be as simple as some bit of hardware that does the encryption and decryption for the enclave page access follows von Neumann architecture and so makes no distinction between code and data and it all ends up encrypted. Just a guess though.

SGX: when 20 patch versions aren't enough

nix — Wed, 24 Apr 2019 19:36:21 +0000

In order to retain anonymity, these keys are shared by millions of machines at once... and then side-channel attacks made it possible to leak those keys. Oops!

SGX seems to me like a nearly impossible thing to get right. Intel's CPU architecture is just too complex to be side-channel free, which means you cannot expect things running on the main CPU, encrypted or not, to be exfiltration-proof, in either direction.

SGX: when 20 patch versions aren't enough

excors — Wed, 24 Apr 2019 19:00:23 +0000

If I understand correctly, that's what the remote attestation is for. The secure chip could generate a message like "I'm running a binary with hash X, and I've generated a key pair with public key Y and shared the private key with X", then sign that message using a per-chip private key that's stored securely inside the chip and is signed by the chip's manufacturer. A hostile kernel can't fake that message because it doesn't have the keys. The user can verify all the signatures, then encrypt their data with Y, send it to the cloud server, and it can only be decrypted by the secure chip that's definitely running X.

The user has to trust the manufacturer of the secure chip to implement everything properly, to not leak the private keys, etc. But they don't have to trust the cloud provider at all, or any of the other chips in the server, so it's a significant improvement.

SGX: when 20 patch versions aren't enough

sfeam — Wed, 24 Apr 2019 18:19:14 +0000

I don't understand why this scheme would be trusted by, say, a user reluctant to send sensitive data to a cloud server. Wouldn't a truly hostile kernel want to pretend it was providing a secure enclave, but then peek at the contents anyway? How can code running inside the enclave know for sure that the 'protections' are being honored by the host kernel?

SGX: when 20 patch versions aren't enough

rgmoore — Wed, 24 Apr 2019 18:04:15 +0000

I can't wrap my head around the whole principle of the thing, why would a hostile kernel even allow you to create an enclave and how could anyone think to trust a hostile kernel?

The point isn't that the kernel is hostile to the person who owns the computer, but that it might be hostile to the process running in the enclave. The classic example that everyone loves to point out is DRM, where the whole point of using DRM is to prevent the owner of the system from being able to access the data. In that case, the DRM process has to consider the OS to be at least potentially hostile.

A less worrying case is cloud computing. Some people might be reluctant to rely on cloud computing if they're worried that the cloud provider- or another customer who's using the same physical device- might be able to access their secret data. Having a mechanism that lets cloud users send all their information to the cloud encrypted, process it in a secure enclave that even the OS can't spy on, and send it home encrypted would be a really nice way of allaying that fear.

IOW, it's true that a hostile kernel would probably disable the enclave feature. That means offering the enclave feature is a plausible promise that the kernel isn't hostile, which is something you might want an assurance of if you're running on a system that you don't completely control.

SGX: when 20 patch versions aren't enough

mageta — Wed, 24 Apr 2019 17:58:49 +0000

If we talk about DRM or the like, virtually any kernel is "hostile", and they might still wanna load the binary, because it is the gateway to stuff you bought/rented. It is enough for the code/data in the enclave to be encrypted - via remote attestation of the initial image and then dynamic load of further load/data via a remote site (might be encrypted), the "hostile" kernel can not influence or even know what is done in the enclave.

SGX: when 20 patch versions aren't enough

luto — Wed, 24 Apr 2019 17:01:57 +0000

The code is open for inspection, or at least the initial code is. SGX only provides confidentiality after the enclave starts running.

SGX: when 20 patch versions aren't enough

flussence — Wed, 24 Apr 2019 16:57:23 +0000

It's encrypted because it's *designed* first and foremost to run malware - specifically corporate DRM.

SGX: when 20 patch versions aren't enough

XTerminator — Wed, 24 Apr 2019 14:55:36 +0000

I can't wrap my head around the whole principle of the thing, why would a hostile kernel even allow you to create an enclave and how could anyone think to trust a hostile kernel? The data you load into the enclave is accessible to the hostile kernel. Only the copy of the data inside the enclave is encrypted.

SGX: when 20 patch versions aren't enough

quotemstr — Wed, 24 Apr 2019 14:43:53 +0000

I've never liked measures that try to limit PROT_EXEC to signed code. What's the point? Executing processor instructions isn't the only way to write code! Whatever machine code can do, I can write a little interpreted to do. PROT_EXEC restrictions prevent nothing! As far as I'm concerned, banning PROT_EXEC is useless security theater that makes computers slower for no reason. (I'm okay with W^X so long as a W->X transition is possible.)

SGX: when 20 patch versions aren't enough

smurf — Wed, 24 Apr 2019 14:34:45 +0000

Define "data". Constant data are stored in code pages. Like a hardcoded encryption key (those can't always be avoided). Game over if anybody can read that.

SGX: when 20 patch versions aren't enough

mageta — Wed, 24 Apr 2019 13:29:35 +0000

As far as I know - in reference to this paper: https://arxiv.org/abs/1902.03256 (pretty nice paper, shows that SGX enclaves can in fact do more than information retrieval: "WithSGX-ROP, we bypassed ASLR, stack canaries, and address sanitizer, to run ROPgadgets in the host context enabling practical enclave malware.") - the prime exploiter of SGX at this points are DRM systems, or systems that try to protect intellectual property in general. For me it is obvious why these users are interested to do away with any access what so ever, in order to limit the amount of reverse engineering the user can do on them.

In regards to the thought that the images are only signed, not encrypted: there is some thoughts on how attackers/drm-providers might load code into an enclave at run-time: http://theinvisiblethings.blogspot.com/2013/09/thoughts-o.... This way you can not inspect the code at all, even if you can inspect the original image/blob.

SGX: when 20 patch versions aren't enough

grawity — Wed, 24 Apr 2019 09:45:47 +0000

Um, but that was already the question: why is the entire enclave encrypted, as opposed to just the "data" pages being encrypted. "It's encrypted because it's encrypted" doesn't quite answer it. (The article notes that encryption is done at enclave startup time – the original code blob is merely signed, but not encrypted yet.)

Not that it would help much, if at all. You'd quickly find malware putting a bytecode interpreter in the "code" part, and all the interesting stuff being stored as "data".

SGX: when 20 patch versions aren't enough

smurf — Wed, 24 Apr 2019 06:39:55 +0000

The whole enclave is encrypted. There's no way to read the bytes in there, code or data doesn't matter.

SGX: when 20 patch versions aren't enough

amarao — Wed, 24 Apr 2019 01:01:26 +0000

I can understand why there is a need for enclave data concealment, but I can't understand why a code should not be open for inspection? Make it read-only, and half concern are gone.