Hacker News Reader

Comment by ctz | Hacker News Reader

The SDK documentation does, almost, tell you:

  > The signing tool supports a single-step signing process, which requires
  > the access to the signing key pair on the local build system. However,
  > there is a requirement that any white-listed enclave signing key must
  > be managed in a hardware security module. Thus, the ISV’s test private
  > key stored in the build platform will not be white-listed and enclaves
  > signed with this key can only be launched in debug or prerelease mode.

And, indeed, launching an enclave without debug mode set fails with 'SGX_ERROR_SERVICE_INVALID_PRIVILEGE' error.

A debuggable SGX enclave enables read-a-word and write-a-word primitives, so loses its confidentiality and integrity.

View on HN

Intel has shown a disturbing willingness to add unproven revenue generating functionality to the trusted computed base like require an Intel signature on SGX software or giving Intel DMA access to everything.

I think there would be quite a bit of controversy as with Edward Snowden if someone leaked that key somehow. That someone would be considered a hero by many, and also a traitor by others.

Alternatively, someone leaks an SGX exploit that bypasses it all, and we wonder whether it was a mistake like so many other vulnerabilities, or if someone deliberately put it there because they didn't believe in Intel having that amount of control... "I wish for the insecurity that brings us freedom."

It'd make no difference, as the keys in question are replaceable via microcode updates and the microcode version is included in the remote attestations.

SGX doesn't really give Intel "control" in the sense of taking away existing freedoms. It's a new feature. You can always elect not to use it, or not to use software that uses it.

You can always elect not to use it, or not to use software that uses it.

That's always the excuse given for every new invasive user-hostile feature. The problem is when the majority of new applications and websites require it. You can always elect not to use a computer either, but I think such a position would be untenable even for a "extreme Stallmanist".

It gives Intel control over developers. In general, a computer will execute what you ask it to. SGX will not let you run production enclaves without Intel's permission. This is like Verified Boot, except there's no credible security benefit to be gained from it.

It is a bit of a bait-and-switch since no other CPU feature works this way and Intel never mentioned this "feature" in all their years of disclosures about SGX.

Isn't that how most extensions work? And microcode has been around for at least a decade now.

I know of no other CPU feature that requires authorization from Intel.

TXT requires an ACM, which is essentially a small signed BIOS subset. At least ACMs are freely downloadable from Intel, and they don't look into what you'd like to run under TXT.

https://software.intel.com/en-us/articles/intel-trusted-exec...

Sadly, leaking the key is not the answer. You'd give independent developers the freedom to use SGX, but at the same you'd make SGX worthless.

Details: if the key used to sign architectural enclaves (like the Launch Enclave) would leak, this would completely break SGX. Anyone with the key could create their own Quoting Enclave and the guarantees behind software attestation would go down the drain.

You're assuming that SGX is only useful in conjunction with attestation.

I want to use SGX to protect cryptographic keys. Attestation is mostly unnecessary.

For normal computing, as long as you control the machines and can bootstrap trust yourself, you don't need Intel's attestation mechanism at all. You do, however, need to ability to launch an enclave.

But enclaves are worthless without attestation.

If the OS is evil and you don't do attestation, it can emulate SGX and run your code in a simulated enclave environment where EGETKEY returns keys that the OS knows about.

If the OS is not evil, you can use process isolation to generate and protect the keys.

This is a pretty black-and-white view of things. A security technology does not need to solve all problems simultaneously to be of use. (But, you do need to do thorough analysis and be cognisant of the risks.)

Ignoring the cloud computing aspect of SGX, no amount of attestation can recover from your-OS-is-compromised-from-day-one scenario. The attestation is only as good as its verifier.

Interesting question: should Linux enable non-debug enclaves at all as long as this policy remains in place?

I expect this to play out like the W3C EME standard. Software attestation separates debug from non-debug enclaves, so your kernel will need to load production enclaves for you to watch Netflix. If Mozilla/Firefox caved, so will Linux.

That'd be a ridiculous sort of circular-DRM move that helps nobody, so, no.

One of the primary use cases for this technology is cloud computing. Amazon, Google, etc are all quite capable of patching such checks out of the kernel if they want to use SGX. All it'd do is annoy a few engineers at these companies. Likewise, for deployments on the client, it's really only the Microsoft and Apple kernel devs that matter given the Linux communities tiny desktop market share, and I don't see why they would do that.

So there's absolutely no reason not to implement DRM, ever, because it doesn't help anybody? Abstaining from implementing a feature you don't agree with, especially from an open source program licensed under the GPL, is certainly a worthwhile move. It at the very least communicates that you don't agree with the feature, and forces others to think about the issue deeper to e.g. apply a patch to use it. SGX is the anti-thesis of the GPL and what Stallman has been warning about for years: software that you are physically incapable of debugging, reading, or modifying. And that's scary.

Of course, it's silly if you think the kernel won't accept a patch for SGX on moral grounds. It already has several modules for DRM technologies, along with binary blobs for drivers. But it's nice to think about.

Why is it nice to think about? It'd be a move as pointless and self-destructive as GCC refusing to implement a usable IR because of Stallman's belief that it'd hurt free software. End result: LLVM is now replacing GCC as the de-facto compiler toolchain of choice.

SGX is an optional feature. It doesn't magically run software against your will and it is not "immoral". Ascribing moral positions to CPU features seems ridiculous to me, sort of like describing a pickaxe as "immoral". If you don't want to use it, then don't execute software that includes SGX instructions. If you do want to use it, then all Linux getting in your way will do is convince you that maybe you should be using a different kernel whilst you wait for Intel's own driver to compile and install.

This stance ignores what happens when people are complacent over the long term. If we make it easy to run SGX instructions, that will encourage its use by developers, which leads to more closed source dependence.

There's some support in Intel's Management Engine for DRM, called Intel Insider (the successor of PAVP). One of the SGX papers mentions plans for hooking up SGX enclaves with PAVP.

Based on public docs, you can't do DRM decoding in an enclave. But you can execute some complex logic to validate a user's license and decide whether you want to release the encryption key to the ME or GPU.

Reply on news.ycombinator.com