Thank you very much for this feedback!

Re: 1 - I re-read the relevant SDM sections, and saw that there is no requirement that the new upgrade version exceeds the current microcode version. Thank you very much for pointing that out! The next published revision will have the fix.

Do you have any public references for 3 and 4? That looks like it'd help make the case that SGX rests on very complex and unstable foundations.

SGX serves a good purpose, at least in theory. Many people, myself included, wanted it to turn out to be good. So, I don't think many Intel folks objected to it.

Instead, I think that a bunch of MBAs showed up and decided SGX is security, security is an enterprise thing, so SGX must be pay-to-play. For whatever it's worth, I think the SGX designers did a pretty good job of separating the objectionable parts from the rest of the design.

For example, the EPID homebrew crypto is all in software, so Intel can change the algorithm without hardware mods or microcode updates.

Also, the way they set up the Launch Enclave gives Intel time until the very last minute to not be a douche. They still have the option to release a permissive Launch Enclave that only includes the checks needed to keep attestation secure.

The SGX design that doesn't come from MBAs is quite clean, given that it addresses the multi-layered crap pile that is X86. There are some cool tricks in there.

Intel presented on SGX at Real World crypto.

If the functionality works as is being described here, I feel they deceived the audience, both in their presentations and in 1:1 discussions.

This is especially unfortunate, since I know for a fact their actions have influenced purchasing decisions.

Do you happen to know if the Launch Enclave has the debug flag set? If so, you can't use it to launch production enclaves.

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.

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...

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.

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.

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.

Perhaps it means they're trying to be thorough?

A Xeon implementation would have to secure the QPI links between the CPU chips. These run at significantly higher speeds than DRAM, so the current MEE design would likely not be able to keep up. Also, a Xeon implementation would have to somehow have the chips mutually authenticate each other.

That being said, I wouldn't be surprised if Intel was trying to see if they can get away with the licensing bs in desktops before committing resources to tackling the challenges that I mentioned above.

I'm terrible at writing. I am trying to say that SGX cannot restore things from the SSA, and it has to use some protected area. To the best of my knowledge, they're using the non-architectural area of the TCS, which is protected from any sort of write.