It's no secret that every time Intel tries to add a Trusted Execution Environment like TrustZone, they somehow manage to screw up. For better or worse, "successful" TEE implementations on other platforms are why we don't have Google Pay or (for many services) 4K streaming on PC. (If everybody was falling apart like SGX, companies may have had to lighten up.)<p>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 <i>could</i> revoke the pirate key, but don't know which one the pirates are using, and so can't fix this problem without revoking <i>all</i> 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.)<p>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.)<p>EDIT: OK, this is insane, hilarious, and finally shows how AACS2's inner functions may have been smashed so quickly:<p>"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."<p>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! ;) )