How Stuff Gets eXposed
sgx.failI know its fun and popular to trash on SGX (and Intel specifically) but one thing I feel is that, in the hardware world, we don't really have the tooling infrastructure nor methodologies to provide a lot of the guarantees we make for security features that we might for "normal" features, say, coherence protocols or exception handling.
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? :)
Good. This concept of continually restricting the owner of a processor from controlling the code that executes on his machine is a futile attempt at providing "products" which are nothing more than theft. The only reason this is a requirement for POWERDVD is because they insist on treating people like thieves and locking down the ability to watch high quality movies behind a wall that keeps the user from seeing and controlling code executed on their device.
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.
> everyone should be ashamed for using Intel hardware when AMD chips do not abuse the user
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.
You say we can't force companies to not use tech in anti user ways, but then you'll give them your money becuase you can't find a laptop with an AMD chip. And I assume you just haven't shopped for a laptop long enough or you'd find one that matches your needs without Intel taking a dump on your chest while pretending to care about anything more than your money.
You seem to be... weirdly emotional about this issue, so I doubt we're going to see eye-to-eye here.
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.
AMD has SEV: https://en.wikipedia.org/wiki/Zen_(first_generation)#Enhance...
It works on slightly different layer (virtualisation, not process), but the threat model and capabilities are pretty much the same.
> making users pay for CPU features while shipping the exact same chip to everyone
This is already a pretty common practice IIRC, it's just that the features are usually disabled at the hardware level.
Buy one CPU get another free? Sounds like a win to me. Hell, it even runs itself!
AMD has the PSP too.
The PSP is not the same as SGX. That's more like the management engine, and while I agree that both Intel and AMD are shipping that antiuser "feautue" and that AMD had its own implementation of a trusted execution environment like SGX, the current AMD chips do not ship with it. AMD is not perfect, but it's sad that people can choose one or the other and still prefer to hand Intel their money when Intel goes out of their way to take advantage of their users.
- 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.
> AMD had its own implementation of a trusted execution environment like SGX, the current AMD chips do not ship with it.
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.
But AMD is fully on-board of the Microsoft Pluton platform, while even Intel is not. So again, the only difference was that AMD didn't have the means for these types of schemes. Now they do and they are also growing in the enterprise/datacenter market, so they will inevitably build more and more of this.
> Intel and NVIDIA locked their GPU linking technology (SLI)
Are you sure about that? Ten years ago or so I had an ASUS motherboard for AMD processors that explicitly supported SLI.
- Intel disables ECC Ram support for their consumer CPUs, AMD does not
> The extraction of these keys would then allow anyone to play UHD Blu-Rays outside of Intel SGX.
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...
No, but if you buy proprietary razors, they will sure as heck try to make sure you only use their blades. ;)
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.]
> Widevine
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.
Sure, but without the keys that someone extracted from devices there is no way to "get around this". L3 CDM from browsers is easy to extract as its just sitting in .dll/.so file behind AES whitebox but they downgraded it to content with low quality on most streaming platforms.
> Also at least one public Widevine proxy is now available, as well as a content key database.
Public? Can you share some info?
There are quite a few platforms that still offer e.g.1080p with L3, which I'm still looking for a replacement source for. The NHK uses it for time-limited content, such as interviews with manga authors which I've ripped for people to fansub. There's much more out there than just Netflix, Disney Amazon et al.
contact me on Discord - check my bio
I'm specifically talking about Widevine L1 in this case, which protects 1080p and 4K streams - not Widevine L3 which will always be vulnerable to some form of software-related attack. My remarks were mainly about how Widevine L1 has been shown to be much more protective in general against broadly-distributed attacks than AACS 1 and 2, even if pirates have secret workarounds.
> 1080p
I dont think you (and the public in general) realize that several sites offer 1080p, even with L3.
The other issue is that if they go all the way and lock it down it quickly becomes the situation where people have to pirate the media they just bought if they want to watch it. Then they see how much better the pirates treat them and they are discouraged from buying the actual media.
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.
SGX, the technology which Signal Messenger built a lot of their secure? stuff upon.
Like:
Technology Preview for secure value recovery
<https://signal.org/blog/secure-value-recovery/>
Technology preview: Private contact discovery for Signal
No. Virtually everything Signal has proposed to use SGX for, competing secure messengers simply store in plaintext databases already. Further, the fundamental security model of Signal is about what you don't send to Signal in the first place.
Yes. Signal should have taken your last sentence to heart and not implemented contact discovery. The feature actually compromises privacy even when used as intended, because anyone can see whether anyone else uses Signal (and, if you check regularly, when they started using it, which can be revealing). The fact that the feature requires sending your entire contact list to Signal's servers (using a broken encryption mechanism) is just another reason not to do it. To add insult on top of injury, Signal doesn't even notify the user it's uploading their contact list, instead using an actively misleading description when it asks for contacts permission ("See contact names and photos in your chats").
It's such a silly hill to die on, too. SGX keeps breaking, their push for it remains annoying, and it's not even that great of a feature. Why are they so ardent about it?
But SGX is almost no better than plain text, especially when centralized.
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.
Matrix, the secure messenger where all messages are group messages, and servers control the group membership?
Meanwhile Signal has a single stranglehold on the supply chain for client binaries that hold all decryption keys.
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.
fwiw https://github.com/matrix-org/matrix-spec-proposals/blob/fay... is the ongoing work to solve the problem of server-controlled group membership. unfortunately it’s not a trivial problem in a decentralised network (which is why we punted it so far), but it’s starting to shape up.
They mention volt2pwn, but kind of gloss over it. It is probably a variant of clkscrew for intel:
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.
I think the moral of the story is: there will always be bugs. Any application that will catastrophically fail if even a single user experiences a single security relavent bug is doomed to failure.
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.
Indeed, and that's why DRM has always been doomed from the start. It's the classic "you have to be perfect 100% of the time, but your attacker only has to get lucky once" situation.
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.
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.)
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! ;) )
Even if all of this stuff was perfectly secure end to end all someone would need to do would be to pick some arbitrary TV or monitor model and make publically available board schematics for something that hooked up after whatever point the TV hardware finally decrypts the video stream to send to the screen.
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.
These attacks on SGX are some of the most advanced attacks on any TEE ever. The crappy ARM smartphone vendor TEEs regularly fall apart from mere C bounds issues.
You're making an apple-to-oranges comparison between TEEs and SGX. The attacks on SGX here are on the processor/model of SGX itself. Buffer overflows are bugs in the applets that run inside the TEE. SGX applications can and do have similar bugs. Here's a random paper I found, there are many more: https://arxiv.org/pdf/2110.06657.pdf
Distinction without a difference, as far as the secrets are concerned. It means your claim "this is why you can't watch 4k on desktop" is dead and done.
TEE isn't implemented by smartphone vendors but implemented by SoC vendors, isn't it? You mean MediaTek is crappy?
Yes but also see my sibling comment.
Quoth one of the pages of the Secret Network <https://scrt.network/about/about-secret-network/>:
> 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?
You do attestation. CPU has it's own private key [1] and signs a message saying what was the initial state of the enclave. Enclave can plug "user data" into this message, which almost always is a signature over a public key for TLS private key which was generated inside the enclave. Enclave presents it to the other side of encrypted connection (i.e. you). You verify the CPU's signature so the encrypted channel established between you and owner of said private key necessarily happened between you and enclave. QED.
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.
Thanks. How can the network tell that it is definitely communicating with a secure enclave, and not some kind of emulator? [1] suggests that keys and signatures from Intel are burnt into CPUs, which would work. All in all it's certainly an odd thing to put trust in.
Yes, the keys are kept in CPU itself. AFAIK Intel doesn't disclose the exact mechanism (blown fuses, EPROM or something entirely different).
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.