How Stuff Gets eXposed
sgx.fail
sgx.fail
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.
AMD has their own analog to Intel's Management Engine. Maybe they don't have SGX or something like it, but AMD is no saint either.
In theory, SGX can be used for good: see Signal's use to avoid seeing users' contact lists. Granted, their scheme is pretty broken given how broken SGX is (and probably for other reasons), but I think the idea behind it is good. Of course, we can't force companies not to use technology in anti-user ways, and I assume Intel built SGX with the PowerDVD-type use cases in mind.
"Ashamed" is a weird word, not sure why I'd be "ashamed" for choosing an Intel-based laptop that meets my needs, when nothing with an AMD CPU did. Maybe the Framework folks will eventually build an AMD-based mainboard, and if they do, I'll consider it, but for now I have what I have, and I don't particularly feel... anything... about it, let alone shame.
Ultimately we have limited choices in the market, and we have to make compromises. I'm fine running an Intel chip (which doesn't even have SGX, as they don't ship SGX in non-server SKUs anymore), and don't run anything that uses SGX... not sure there's anything written for desktop Linux that I'd use that even tries to use it anyway.
In another post downthread you acknowledge that AMD has their own trusted execution engine (which they don't ship... but neither does Intel, at least in consumer hardware), so for some reason you seem to love AMD and hate Intel when they essentially do the same things.
You also list a bunch of bad stuff Intel has done -- and yes, agreed, they were bad -- but I'm sure AMD has done just as much similar bad stuff. And if not, I'm sure it's not because they're saints, but because they hadn't had the clout of a dominant-enough market position (like Intel has had) that would allow them to get away with things like that. I have no doubt they would have done similar things if they found themselves in similar circumstances. ::shrug::
Either way, this whole "Intel vs. AMD" thing is not really a hill I care do die on... much more important stuff going on in my life.
It works on slightly different layer (virtualisation, not process), but the threat model and capabilities are pretty much the same.
This is already a pretty common practice IIRC, it's just that the features are usually disabled at the hardware level.
- Intel wanted to lock users to RamBus RDRAM which was incompatible with AMD chips and a patented technology which AMD would not be able to use.
- Intel shipped the aforemtioned CPU identifier. Intel did the management engine first.
- Intel locks its chips from frequency tuning so they can charge more for overclocking.
- Intel locks the amount of RAM that is addressable by their chips arbitrarily rather than basing it on hardware support in order to squeeze more money out of you.
- Intel and NVIDIA locked their GPU linking technology (SLI) while AMD allows Crossfire to run on both Intel and AMD processors.
These are just the ones I remember off the top of my head. Not all of them may be current, but it's obvious that Intel has no problem extorting money from their customers in a million ways where AMD doesn't play this disgusting game.
As far as I can tell, AMD does currently ship a trusted execution environment supporting remote attestation, namely SEV. However, it’s only supported on server-class processors, so it’s unlikely to be used for DRM.
Are you sure about that? Ten years ago or so I had an ASUS motherboard for AMD processors that explicitly supported SLI.
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...
But seriously... I agree. I get that DRM is meant to prevent "casual copying," but right now, that's just called "Downloading from 1337x." Unfortunately, I think that the only lesson movie studios are going to learn from this... is that they should phase out physical media and use Widevine and FairPlay hardware-assisted streaming DRM for everything. Which, to be fair, has been quite more resilient than AACS... but not pirate-proof...
I think the ultimate lesson is that movie studios will never cave on DRM or Copyright. In which case, in an ideal world, we'd repeal DMCA 1201 making breaking DRM legal for private use, and we'd cut copyright to 28 years in length (the original length, and also solving the video game preservation problem). From there, we could just have a trademark protection which states that distributing expired-copyright material in its original state gets a fair-use exception to trademark use, but modifications do not, solving that issue. [I.e. If I distributed Original Super Mario Bros. without changes, it wouldn't offend Nintendo's copyright - but if I changed it, I would have to call it something else and couldn't use "Mario" as a character.]
its pretty widely available how to get around this now. I have my own implementation actually. I wont say its "easy", but it is doable. And you can get quite a lot even with just an L3 CDM. Also at least one public Widevine proxy is now available, as well as a content key database.
> Also at least one public Widevine proxy is now available, as well as a content key database.
Public? Can you share some info?
I dont think you (and the public in general) realize that several sites offer 1080p, even with L3.
Is all of this DRM actually stopping pirates? No. Is it harming your paying customers? Yes. Not always, but often enough that it discourages people from buying the media.
Like:
Technology Preview for secure value recovery
<https://signal.org/blog/secure-value-recovery/>
Technology preview: Private contact discovery for Signal
At least solutions like Matrix give you the choice where your metadata is stored, and have never had a requirement for PII like phone numbers to worry about in the first place.
I will not deny you have made valid criticisms of the matrix protocol, but Signal has some very broken design choices as well. One of these is much easier to fix by motivated technical end users than the other.
At least in matrix a user choice of client codebase and binary can control which server they trust, and if they wish to automatically encrypt to new unverified room participants or not depending on their threat model. Technical users have total control over their rooms and the UX will improve for less technical users.
Also it is possible for someone to run the server daemon in a remotely attestable system like a Nitro enclave allowing it to prove to users what administrative features are enabled on a given server. This is something I am building foundations for right now.
Unlike Signal, any organization is free to run their own matrix servers with server-pinned channels adjusted for different threat models while still having access to the wider network. You get to choose the server that can decide your room membership, including choosing a server that does not grant a central administrator any significant trust.
If forced to pick between two flawed protocols, I will choose an open network controlled by democracy that gives individual users total freedom to make it better over a dictatorship for the long run.
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.
Sure, DRM has been a huge pain for lots of people, and I don't want to think of the billions of dollars wasted on it that could have gone to more productive things... but ultimately people will find ways around DRM, technical and legal measures be damned.
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! ;) )
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.
> 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?
Obviously this assumes attacker can't extract TLS private key from the enclave. Nominally this is a central promise of SGX, but if you have some attack which allows you to read enclave's memory anyway, all of this falls apart. TFA discussess several attacks to this effect.
[1] SGX' threat model says CPU silicon is too complicated to extract this key even if you have physical access.
You can't get valid quote outside the enclave, because CPU doesn't provide the instruction to sign the quote outside the enclave, and you can't calculate it youself, because you don't know CPU's private key.