I like to draw parallels with the '90s and all of the Pentium bugs. These events really really lit a fire under Intel's ass to get their crap working. Cue decades worth of research and $$$ into formal verif, EDA tooling, and perhaps most importantly, organizational ownership.

Software models, where many security paradigms have been explored decently, don't map too well or don't have a great solution, like fuzzing or linters. So it's kinda hard to provide various security guarantees if you don't have tooling to verify them. Plus, the tools that do exist require domain expertise from the engineer, so the thought to look for some MMIO exploit will never occur to a cache designer.

This kinda turned into a ramble, but ultimately, while I agree I wish Intel would do better, I can't fully fault them since I feel like the whole industry is ill-equipped to provide these security guarantees. Spectre has started some efforts, but it's slow to pickup, which is why it's rather patchwork-y still. Frankly, it kinda feels like the only thing that'll kick asses into gear is some lawsuits, F00F and FDIV style.

P.S. A couple questions--

1) Would you happen to have the "EGX" framework you wrote in Appendix A? That seems massively useful.

2) Can I just screenshot the rubber duck NFT? :)

The Secret Network is also attempting to force users to execute code which they cannot inspect or modify in order to implement the core component that sets their bullshit crypto block chain aside from Ethereum, for example. They're not selling some novel software. They're selling Ethereum running in SGX to keep you from copying NFTs or inspecting the content of smart contracts. Furthermore, anyone running this or other SGX software should be ashamed of themselves for allowing these thieves to pretend they're doing anything other than taking advantage of a poorly implemented scheme to deprive you of your control over your property.

Few people seem to recall the blowback Intel got over their Pentium III chips containing a unique processor ID, and how they went as far as having the ID disabled by default in every BIOS to keep people from mass migrating to AMD. The same thing should happen with these trash SGX implementations, and the most embarrassing thing is that Intel plans to launch software defined silicon, making users pay for CPU features while shipping the exact same chip to everyone. One of the main features they want to ship to eveyone and sell to suckers is SGX itself. You can see this here: https://www.tomshardware.com/news/intel-officially-introduce...

Frankly, everyone should be ashamed for using Intel hardware when AMD chips do not abuse the user with these schemes and generally allow much more freedom. Intel makes people pay for frequency unlocked chips, pay for features shipped with the chip, and even pay to have code they do not control run on their system. If this isn't an absolute embarrassment to anyone purchasing CPUs, it's a poor reflection on them and their obvious stupidity and contempt for their own freedom.

AS IT SHOULD BE. UHD Blu-Rays are not cheap [1]. If I am going to buy one, I damn sure should able to play it using whatever program I want. Its quite sad how many people have just accepted this reality without a fight. If you buy an apple (the fruit), does the grocery store get to choose what knife you use to cut it, or what plate you use to serve it?

1. https://bestbuy.com/site/dvd-blu-ray-movies-tv/4k-ultra-hd-b...

Like:

Technology Preview for secure value recovery

<https://signal.org/blog/secure-value-recovery/>

Technology preview: Private contact discovery for Signal

<https://signal.org/blog/private-contact-discovery/>

https://www.usenix.org/conference/usenixsecurity17/technical...

IMO, this is the most damning of the attacks. It uses voltage and CPU frequency overrides to flip a bit a the right time during an AES operation, leaking the AES key.

Although clkscrew was remotely exploitable (!!!) via malicious android apps, I don't see a path forward to mitigate these issues, especially when physical attacks are feasible.

IBM had a piece of AES key management hardware that would wipe keys if it changed temperature, saw voltage fluctuations, etc. It was also dipped in layers of epoxy surrounded by grounded wire mesh (with secret signals, etc for the layers) so it could kill itself if cut into (or before a low temperature bath would freeze the transistors), and also to act as a Faraday cage (to keep stuff in and out).

Good luck walking down this path with cell phones or power-slurping commodity cloud hardware! Even with all that, an attacker could likely irradiate it until the right bits flipped.

In many ways that is why the idea behind the bluray AACS system is briliant (as much as i detest DRM). Its based on the idea of instead of a master key, give each client a different key, which can be revoked (at least for new bluray disks) so that a breach can be mitigated.

PowerDVD is a bit irrelevant though. PowerDVD no longer supports UHD BD playback after 10th gen Intel, IIRC, because Intel dumped SGX on consumer platforms. Not that it matters anyway - the pirates had the idea to keep their stolen decryption key and generate the disc-specific decryption keys themselves and post them online. These disc-unique keys are then retrieved and used by a modded drive to decrypt the disc, without revealing what the stolen drive key is (so that AACS LA can't revoke it). Thus the AACS LA is in a stalemate, where they could revoke the pirate key, but don't know which one the pirates are using, and so can't fix this problem without revoking all keys which is simply impractical. This won't change though, don't worry, because storing keys in a TEE of some kind is mandatory for the 4K Blu-ray spec. (This happy accident for pirates also happened because 4K Blu-ray is mostly readable by standard Blu-ray-only BDXL drives made years before the standard, which doesn't seem to have been intentional.)

A TEE wasn't mandatory for the original Blu-ray because... well... it was 2005... and so now there are no shortage of stolen Blu-ray player keys floating around and it's impractical to keep revoking keys for them to be stolen again, possibly from the same flawed hardware. (You can't tell me that securing every Blu-ray player since 2005 perfectly, and having no keys stolen, without a TEE, is possible. Especially not when it takes up to 90 days for discs revoking a key to roll out.)

EDIT: OK, this is insane, hilarious, and finally shows how AACS2's inner functions may have been smashed so quickly:

"Unlike for AACS 1.0, AACS-LA (the consortium which maintains AACS standards) decided to not publish any publicly-available specifications for AACS2 and typically mandates that any AACS code is obfuscated and/or encrypted in some form [...] Finally, we further analyzed the contents of CLTA_SW.dll. Remarkably, we discovered that CLTA_SW.dll contains nearly identical code, strings, and cryptographic constants as the CLTE.dll enclave. In particular, CLTA_SW.dll contained the code for the AACS2 algorithm, without any protection. The latter is significant, as it directly violates AACS-LA’s requirement to not publish AACS algorithms without obfuscation and/or encryption. We thus reaffirm our hypothesis from Section 6.1, that CLTA_SW.dll is an internal debugging module that should not have been shipped."

Well, no s***. If you ship decrypted DLLs with all the code for the DRM except the decryption key, and then allow your software to provision enclaves on out of date, known insecure devices for storing the key, what did they expect would happen... (well, obviously, they didn't realize they were doing that, but it's just so pathetic... On the upside, AACS LA might have a pretty good idea on which key they've been using now! ;) )

> Every validator on Secret Network runs their code inside a TEE so no one—not even the nodes operating on the network—can access the information being decrypted and processed.

How could one possibly verify that a secure enclave is being used?

Sure you have to play each movie in full in real time (although maybe you could get around this by spoofing the clock on the playing device somehow?), but you still only need a few people setting up a little movie ripping farm to get retail quality lossless video of everything regardless of how much money anyone puts into DRM nonsense.

The analogue hole makes all of this effort entirely pointless. All reasonably popular non interactive media is going to be available on pirate sites within hours of release no matter what you do, all this does is make life harder for legitimate consumers.