Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles oder https://rocket.events.ccc.de/channel/subtitles oder https://chat.rc3.world/channel/subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!

Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles or https://rocket.events.ccc.de/channel/subtitles or https://chat.rc3.world/channel/subtitles .
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!




======================================================================






[Music]
[Applause]
 y thank you everyone uh super quick about me pretty much exactly the same as the intro Hardware hacker verse engineer security researcher and sometimes even a forward engineer uh as of now I'm a former undergraduate student at the University of Michigan uh and at my time there I was uh asked to be part of the sjx fail team who was looking into some real world applications that utilize sgx uh secure Enclave technology and see what we can find out about them so before we get into all that I want to take a quick uh detour and do a history lesson on DRM in movies and discs starting with CSS uh not that CSS this CSS is the content scramble system system it was introduced uh back in '96 uh developed by Matsushita who's now Panasonic and it was the primarily the DRM scheme of DVD and their main goal was to prevent just someone putting a drive a disc into a drive doing a onetoone bit copy and getting another good decryptable DVD out the other side and uh as a byproduct of that that also encourages the manufacturers of both software and the actual drives themselves to go through the official licensing processes and not just uh come up with their own Solutions so the content on the dis is encrypted with the m6 block Cipher which is a uh pretty weak uh Cipher it has a multi- keyed system though so there's a whole bunch of keys like authentication keys title Keys dis Keys player keys and something called a dis key block which stores effectively like hashes or encrypted versions of the keys you don't have actually have to understand how this works just uh keep some of these names in mind because we'll see them come up again and again and the actual Parts on the disk that are flagged as holding the copyrighted content that we want to protect are prevented by the drive itself from being read by the host until an authentication handshake is performed and there's a limited uh revocation support with the disc key block system so if someone is doing bad things and leaks Drive Keys ho
st Keys a certificate then there is a mechanism implemented by the CSS scheme to revoke that uh user so what went wrong well at the time the US uh still had export controls on strong cryptography uh over 40 bits and the m6 Cipher itself uh had some mathematical cryptographic faults but turns out that actually didn't matter because even in the late 90s your 450 megahertz penum 3 could Brute Force the key in like 18 seconds and the revocation system itself only had limited tolerance to leaks so when uh tool by the name of dcss was published in uh around the late 90s then that could effectively generate the entire keying system and the revocation uh system was rendered completely ineffective since you can't revoke everyone or your scheme doesn't work anymore and yeah by 99 it was completely broken and they've given up so that brings us to ACS or V1 which is the advanced access content system and it was the response to the breakage of CSS and they formed a new Coalition called the ACs licensing Authority and they want this to be developed in time for the release of the upcoming HD DVD and Blu-ray high definition formats the specifications are actually released publicly in uh April of 2005 which is kind of surprising for a DRM scheme and they were actually deployed to devices in 2006 and now that the xort control band was lifted you could actually use strong cryptography uh so it made a lot of use of as1 128 Shaw one the standard strong Cipher Suites and it's a very complex scheme but again we see media key blocks uh another revocation model that's significantly more robust this time uh Mutual Drive poost authentication again and something called Trader tracing which will get to in a little bit and yeah the whole scheme according to the official uh white paper looks a little bit something like this and again it's quite complex but I'll try to give an overview of just the parts you need to understand for now and again similar to CSS aacs Works in a key hierarchy the video
 content itself is encrypted with a randomly generated title key that's unique per title which is almost like a release of a movie but you might have like the same movie mastered in different times or with different regions that would count as a different title the title key is then wrapped and encrypted with the volume unique key which is generated by combining the volume ID with the media key and the volume ID is just a little uh value that's read off a special area in the dis that the drive will actually only give to you after you pass the drive host authentication process so that's how they enforce having to not only have licensed hosts but also licensed drives and the media key is derived from a processing key and this processing key should you be able to obtain it could theoretically decrypt every single physical disc that's been pressed up to the point of it being revoked and having new discs being mastered since you can't revoke something that physically exists and to actually get a processing key it must be derived by the player when you try to play a movie using its set of device keys and something called the media key block which hey that sounds pretty familiar so what is this media key Block it's the mechanism that they Implement to allow only unrevoked devices to derive a processing key using their set of device keys and these device device keys can be revoked when you issue a new mkb version so like we said this requires mastering new physical media but leaking a processing key can will permanently lock discs so oops the actual the way the actual revocation model works is also uh quite mathematically complex but it's based on something called a subset difference tree method and it was invented in 2001 and that is the official diagram that they give in the white paper which uh you might see is not that helpful we've definitely spent a lot of time staring at that trying to make heads or tails of it but you can kind of think of it like a binary tree where
 every node is a 128 bit value the left and right sub nodes can be derived from the parent node through a robust one-way function which is effectively a hash but they don't use a hash like Shaw or md5 they actually came up with a new hash called as G3 which is based on as and it does three rounds using a hardcoded seed just because they wanted to a certain parent node could have a third Center node which is uh would be denoted by a special value which instead of continuing down and making more uh more uh levels of the tree you would actually stop there and when you get that Center node that 128 bit node label is your processing key and a device key or the device key set is just the set of node labels that they give to you at very certain points in the tree and each device has a set of device keys but the whole system of devices has some overlap uh of the total possible device Keys that's computed in a way where every device has a lot of shared overlap but is guaranteed to have exactly one unique Leaf key at the very bottom of the tree that no other device in the scheme has and this is how you can actually uh Implement per device based based replication since that's actually what this uh triangle is showing that the device at the very bottom of the tree uh because it has the device key Noe at that level in white at the very bottom and you can't invert the hash there's no way to travel from the bottom of the tree back up the tree along that specific path and every single device has a unique path path from the bottom to the top so this is weird tried to make a little bit of a an easier way to visualize this so suppose we have this smaller sub tree and two devices a in uh White and B in uh purple so let's say we give a its unique device key as at the very bottom of the tree as that white circle and we give device B its own uh unique device key at the bottom of the tree in purple well if we give a these device Keys it can derive all sub Keys shaded in a yellow but notice
 again there is exists that path from its own unique white device key to the roof of the tree along which it cannot div derive any keys so similarly device B given that set of keys has its own unique path from the base of the tree to the root along which it cannot derive any nodes so if we want to revoke a device like let's say we want to revoke device B we can encrypt an entry in the mkb with its its device key which is a little bit counterintuitive but because you're encrypting the processing key with that uh that device Key Circle in red every device in the system except for device B can end up in that node now let's say we want revoke both A and B we can choose the subset difference of both systems and find the least common uh node that neither device can derive and use that to encrypt uh key and this is a a little bit more complex in in practice because ACS uses multiple subt treats for efficient non-contiguous re revocation and there's a very easy way to think about that just imagine some four-dimensional pseudo binary trees but uh Also regarding revocation discs contain revocation lists for host and drive certificates and uh in a little bit of a sneaky move they came up with a scheme where if you inserted the certificate revocation lists exist on Diss and if you insert a dis into a drive with a older version of the revocation list the drive will actually install that revocation list into its Envy Ram so if you get revoked well don't play your movie because that will revoke your drive and now you can't watch anything and there's more crypto there's a lot more details unfortunately we don't have time right now but if you interested then uh that is the actual release of the ACs uh common cryptographic elements by ACS laa and that that's the uh document that contains in depth how all this this crypto works so so this is very complex and obviously relies on on a lot of strong crypto so what could have gone wrong well on December 27th 2006 uh Forum poster by the na
me of a musle x64 made this legendary post uh releasing backup HD DVD so this tool was the first uh tool that claimed to decrypt ACS protected titles now they didn't provide any keys or information on how Keys could be obtained but that Ki started a search with people trying to find any existing keys in the wild and the first place they turned was the software players power DVD and wind DVD and this wasn't some crazy complex reverse engineering effort no they dumped the ram while the you put a movie in you dump the RAM and you just take what comes out and start searching for anything that might look like a key and well that worked and soon a volume unique key was found which allowed them to decrypt one dis but finally on February 11th 2007 they found an actual processing key and as we said that allows pretty much all existing tows to be decrypted and this is the uh depending on how you look at it the infamous 09 F9 key and a few days later the actual device key sets were found also in the ram of when dvd8 and ACS confirmed the legitimacy of the revoke keys of the leaked keys and obviously revoked them but this started an interesting cat and mouse game because power DVD and wind DVD need to now issue software updates so that all their other users still can watch their movies but the Pirates can dump and release the keys faster than acsa can revoke
[Applause]
 them also in a little bit of an ironic twist uh one of the largest uh contributors to the ACs La group was Sony and around this time uh at a C3 talk actually the PS3 rot key was figured out and considering that one of its selling points was that as a Blu-ray player the PS3 firmware updates also became a source of ACS
[Applause]
 keys so let's look at some aftermath the acla issued a statement uh that effectively boils down to it's not our fault that your software left decrypto keys in Ram and it's not actually a compromise of the ACs scheme or algorithm itself and that is true but the keys are still being dumped and published to this day and they can't revoke them fast enough so they effectively had to give up and acsa decided to go back to the drawing board for the upcoming uh Ultra HD 4K Blu-ray uh format that was coming out and that finally brings us to ACS V2 so this is developed uh with the release of the Ultra HD 4K Blu-ray format launched in 2008 the specifications are now under NDA they decide they no longer want to tell people how it works and of course it requires purchasing uh new hardware players or uh dis drives here on PC and interestingly PC playback requires windows on Intel 7th gen CPUs are newer so why is that well acsv 2 uses Intel sgx technology to guard its secrets so if you are on Linux or AMD or arm or anything that is not officially supported windows on sgx uh supporting Intel 7th gen plus platforms sorry your movies will not work so this is where we get involved uh tax on sjx had largely been an academic or theoretic thing up to this point and we want to find some consumer facing usages of sgx tech in the wild and break him and the most prolific use that we found was acsv 2 and what they do is that they hide the DRM code and all the keys and secrets inside this sgx trusted Enclave which has prevented uh any analysis or compromises up to this point effectively and it was implemented by CyberLink also in power DVD starting with a version 17 so uh let's do the obvious thing buy a copy and reverse it but before we can uh dive into pyate itself uh want to take a quick detour and talk about sgx technology since it's something that a lot of people might have heard of at some point but it's not a very U it's not a very commonly used protocol so what is Intel sgx stands for
 software guard extensions and it's an set of processor extensions developed by Intel that enables a hardware back trusted execution enclave and you can kind of think of it like an inverse of the VM threat model it's actually designed to protect sensitive and code sensitive code and data from higher privilege threats on your machine so if you have your code running an enclave it's not only protected from the kernel the hypervisor even bios smm or management engine and even physical attacks on the machine because any memory leaving the core is uh transparently encrypted on the fly so sgx is also quite complicated but I'll try my best to give a brief but sufficient overview so how does this work well you write C++ code as normal uh but you can Mark The Trusted parts of the enclave uh as being trusted and to be put into sgx and the sgx aware compiler tool chain will lift those functions out and put them in the enclave and then do all the transparent uh Edge routines and uh call a gate functionality for you so for an enclave to work it must be signed by its author and you can use a self-signed certificate for local debugging but for any production enclaves you must obtain an Intel sign certificate and once you have all this you effectively have a fairly normal shared object or dll that you can distribute along with the rest of your application binaries so how does it actually work though well enclaves are launched with some special new instructions that Intel implemented we have EC create which will actually create the enclave and set up its address Bas uh and some other stuff like e uh e extend which computes a Shaw 256 over all the Enclave contents and Pages um init which will actually verify that the certificate used to sign the Enclave is valid and you're not trying to do something like launch an enclave in production mode with a self-signed certificate and EG key is a quite interesting one which will derive and return a cryptographic key that you request uh based o
n a couple different types that you can choose from and because it's Intel it's a micro code but it's uh even worse it's something called zuo code which is almost like micro code but it's actually like x86 64 code that they're calling in from myo code but it's not really x86 64 it's like a pseudo x864 it's uh very cursed and Intel does not provide a ton of information on how it works but we can only speculate so once you have an enclave now what well The Enclave API it consists of e- calls and O calls an eall just transfers your control into an enclave and an O call will transfer your control back out of an enclave interesting to note is that there are no CIS calls Intel did not want a theoretical sgx malware to be deployed that can do all of its dirty work inside the enclave and prevent analysis so because we have no CIS calls how can data be securely passed back and forth well that brings us to sgx ceiling secure data has to be sealed before leaving the enclave and this sealed blob can be written to disc nonv memory passed around whatever you want and then later has to be unsealed to recover the data in the enclave and to do this uh there's a special leaf for E get key called seal key which will do some micro code magic derive the seal key and return it to you and then you can just throw that into as GCM and do your crypto the ceiling key is derived from one of two measurements uh there's a measurement called Mr signer which binds the ceiling key to the Enclave uh any Enclave signed by the same author certificate and there's Mr Enclave which binds the uh seal key to only that an instance of that exact Enclave since it hashes the code in data sections so let's take a look at Power DVD uh we got a copy of power DVD 20 Ultra uh which was the newest at the time and opening installing it and opening it up we see there's like almost 900 megabytes thousands of files hundreds of folders is just a mess uh and the actual application is just a wrapper so we have to follow th
e rabbit hole down on the flow from uh trying to launch the application to actually playing a movie and because it's a uh media player software they take a lot of steps along the way to make sure you can't debug it you can't inspect you can't analyze it well eventually we find that power DVD movie. exe is the uh application that actually handles coordinating media playback and figuring out what types of codecs files decoders to load for a given media uh and it's uh in the case of Ultra HD Blu-ray it loads the acb2 related modules when it detects that you put a UHD disc in the drive so once it uh detects that you're trying to play back an acsv to protected title it loads a couple of new dlls that are responsible for actually doing the decryption so we have clta uh which uh stands for CyberLink trusted agent and it contains the implementation for the high level implementation for all of the AC csv2 stuff and it's uh protected by the theida Packer and opos Gator which is effect the best in the business uh for for uh binary protection packing offc code protection they have every trick in the book you know anti- debug VM detection control flow obic flattening so it's a pain to look at there's a we find another deal next to it CLT ASW which not really sure what it does but it's okay because it's not used CKD now this is the first Enclave we encounter stands for CyberLink key downloader and this is The Enclave that actually performs the remot adastation to securely provision the keys into the into your machine and clte which is the trusted Enclave which is also an enclave uh but this is The Enclave that actually handles the the operations of acb2 the decryption decrypting the movie files and passing them to like an htcp compliant sync and this is interesting because it's protected with something called Intel sgx PCL so what is PCL well uh if you think back to clta well I was able to strip the theida protections from clta and de offis gate for reverse engineering along with
 uh getting it patched to allow us to uh run it under a debugger but CLT dll is protected by PCL so uh PCL is interesting because it encrypts the code and data sections on disk uh to prevent stat analysis and it wraps them with this little loader stuff program that loads a sealed AES key from disk decrypts it in place inside The Enclave to protect it from Dynamic analysis and this PCL key is also not shipped with the software but provisioned securely alongside the acsv 2 keys so if you were able to somehow break the scheme and get the PCL key then it doesn't really matter because you would have already broken enough to obtain the ACs keys anyway and effectively this gives you a black box aable code blob that runs on your machine there's no way you can't see what it looks like statically you can't see what it's doing dynamically it's just a mystery black box that's in charge of doing all the DRM so what actually happens when we play a movie well we start with power DVD movie and when it detects that we're trying to play an ACS V2 protected title it'll try to go and check your system for sgx support and if there's no sgx supported then obviously we fail and if it is supported we load the clta trusted agent which will then handle the remaining ACS operations first thing we'll do is check for a file on your disc called CLD show X2 and this is the actual seal blob that is stored on disk that will contain all the keys now if it exists we can go and load CLT directly but if not we'll actually have to download the keys into the platform so then we load CKD which will go and talk to the CyberLink key server to securely provision the keys and if something happens and it fails and we can't get keys again we must fail since there's there's nothing else we can do at this point without keys if it does work we download the keys decrypt them and seal them and write them to this file and then again transfer control to clte that uh upon starting first runs the PCL wrapper stub which 
will unseal the PCL key from this blob crypt the actual contents of the real clte enclave and then that will finally talk to the Blu-ray Drive uh htcp and do the movie Playback but there was something interesting we noticed when we ran this on a machine that I had corrupted so bad that the sjx run time just didn't work that well the sgx support check failed and it didn't exactly fail well what it it happened is that it loaded CLT ASW instead did something and then failed so it turns out that ctaw doesn't just fail like this it fails like this so what is ctw well let's load into Ida and well what do we see uhoh no theida no encryption debug logging strings and a lot of them this is pretty much a nearly complete implementation of the acb2
[Applause]
 algorithm so we have no idea why or how this got here and we're pretty sure it shouldn't be here we hypothesized that it's a software only implementation before uh they put it through the sgx compiler to lift out the trusted Parts into enclaves and they must have accidentally left in their production build and uh makes me think back to this statement I don't think this is compliant with the uh robustness rules set forth in the ACs license agreement but I could be wrong but this is really funny and cool but even with the PCL protections rendered effectively useless by ctsw were actually no closer to getting aacs Keys the clta CD show X2 file is not shipped as part of the software but has to be securely provisioned into your system later through an online connection from their server and is only then sealed to disk and that's the job of the CKD Enclave so you might think we can just talk to the server and download a pre-sealed blob of keys but you actually can't do that well why so to figure that out we got look a little bit deeper into sgx ceiling well all sgx keys returned from E get key are derived from one of two master keys there's something called the root provisioning key and the root sealing key these uh keys are burned into euses during manufacturing and the rpk is generated by Intel on a secure uh HSM it's tracked in the database and is linkable to CPUs but the root seal key is uh randomly generated on the CPU itself at production time and is not known to Intel so what does this actually mean for ceiling well the uh sgx ceiling keys are derived from the root ceiling key as it uh sounds but this means that the same uh Enclave meaning it has the same Mr and Mr Enclave measurements on a different CPU will derive a different sealing Key from eget Key because we'll have a different rsk so this means that the sealed blobs only work locally on your machine and cannot be shared between physical CPUs this is actually seems like a feature right because data can't be 
SE sealed and exfiltrated by this hypothetical sgx malware since that sealed blob will be useless once it's removed from the CPU that generated it uh trusted data can still be processed locally into nonvolatile storage but that still raises the question that how can we uh provision the secure data Into The Enclave in the first place so to do that uh there's a mechanism Intel came up with called adastation so sgx provides two mechanisms for enclaves to prove their security there's local adastation on your machine which is just a mutual authentication between two enclaves uh and this could theoretically still be emulated locally if you uh implement the eget key derivation yourself and just return junk but deterministic keys but remote add station is a little bit more interesting since this authentication is between an enclave and a remote server and it allows the remote server to Pro uh provide The Enclave with secrets and this actually cannot be emulated by Design and this should solve a secure provisioning problem so before we get to remote adastation uh we got to look at remote local adastation and uh there's a I apologize there's still some more terminology but trying to keep it as light as possible so there's something called a report that is a just a data structure containing the measurements from The Enclave to be verified like Mr Enclave Mr siner and there's also some additional Security State info in there uh this can also include optional user data like if you want to put some Diffy Helman parameters in there for your own future use and the interesting part of a report is that it is signed with a CMAC signature but using not the uh report key of The Enclave that generates it but the report key of The Enclave that verifies it and to do this uh there's of course another instruction called e report and this will populate the report struct with measurements from The Enclave that called it and it can actually derive the verifying enclaves report key and sign the 
CAC so it doesn't actually give you the report key from the other Enclave it will in one instruction remember populate the report struct derive the key compute the as CMAC and then give that back to you so let's do a quick walk through just how this works because this is a little bit confusing say we have two applications A and B and we'll call a the prover and B the verifier although as you'll see they prove and verify each other anyway first step is that Enclave B has to send over its Mr Enclave measurement a which will then create a report struct using this e-report instruction and the provided Mr Enclave so the instruction will generate this report derive the CMAC key and uh calculate the signature you can then send the report from Enclave A to B now to verify this report all B has to do is simply call EG get key with uh the report key type to get its own report key and then it's a simple as CMAC and once that's verified we just do this process in reverse and you may note that uh Mr Enclave is not EX change again since we can just uh obtain A's Mr Enclave from the report that we just verified do the same process in backwards send it back to a it'll do the exact same verification call EG key for its report key compute and verify CMAC and then we're all good we're both running in inside sgx or an emulator so to do this remotely there's something called a quote which is just a special type of report that has been locally signed in a remotely verifiable way these quotes can be either fully Anonymous or pseudonymous or linkable which just means that uh the verifying server can detect if two quotes came from the same CPU to do this Intel implements something called an architectural Enclave which are a set of special enclaves authored by Intel that they delegate they delegate tasks to on your machine and because they're signed by Intel's certificate they are afforded some special privileges by the micro code uh mainly they get access to a couple new EG key types and th
is is on your machine as part of the sgx runtime services and it's actually open source you can check it on GitHub but only the Linux version though and we're on windows so that was a little bit annoying but that was a fairly simple reverse engineering task now I I mentioned uh verifying and remote verification and certificates but we want to do this in a privacy PR preserving way so Intel has a scheme called epid which is an asymmetric group signature scheme uh based on daa uh that groups processors into groups based roughly on processor type it's actually not fully known exactly how it works but you can for the sake of this uh talk you can imagine that a CPU that let's say SE 7th gen I9 i7 I don't think they had I9 a 7th gen i7 is in a group of all other sth gen i7s so you have these large groups and each CPU in a group holds its own private signing key the public key holder uh which is Intel can only verify if a signature is valid and what group produced it but not the actual individual member of that group these are of course revocable and there's three mechanisms Intel gives you to revoke uh there's the group revocation list if they have to revoke an entire group a private key revocation list which if someone leaks their epid private Keys then they will simply be put on this revocation list and a little bit more interestingly the cigarette uh cigarl or signature evocation list which is a list of Bas name signature pairs produced by a known bad member of this group so if intel knows that you were able to obtain your own private keys and sign things but even if intel can't figure out which private key you have they can say that this pair of uh data and signatures produced by a bad member and must be revoked now the actual provisioning the actual architectural enclaves themselves we have The provisioning Enclave which will interact with Intel server to do the protocol to actually join into this epid group scheme and it proves its authenticity to Intel using keys d
erived from the rpk fuses and that's the mechanism that prevents emulation since there's no way uh other than a uh something like a management engine level exploit where uh code could otherwise access rpk fuses and these uh keys are only accessible through enclaves that are signed with the special inert and the actual process is again more complicated crypto so that's out of this scope for this talk but the result is that you have this unique epid private key blob that is then sealed to disk after you pass provisioning uh with this provisioning seal key the more interesting Enclave is the quoting Enclave this is what actually signs these reports into quotes and since it's also signed by Intel it also can derive the same psk and unseal the epid private key blob from your disc to actually make a quote we'll first ver do a local adastation to verify that the requestor is in fact an enclave and that also uh has the side effect of having a verifiable report already given to the QE and then the QE will unseal the epid private key sign the report into a quote and then uh of course encrypt with the uh Intel RSA public key so that no one else can verify these quotes except Intel and that's verifi verifiable by Intel there's also something called the sigma protocol which is just an enhanced version of uh elliptic Cur Diffy Helman key exchange that has some additional authentication on there uh with cmax to prevent any man thee middle attacks but the important part is that this is what actually guards the remote attestation messages going between the enclave and the server itself from someone trying to man the middle it and since it's just Json over HTTP hopefully s uh we want to prevent people from man the middling it and the other feature of Sigma that's of note is that it allows you to derive some additional ephemeral session keys that you can then later on use after you pass at a station to encrypt the secrets in a way that both the server and The Enclave can uh access the
m and then that's how you actually download them into the Enclave so okay that was a lot let's look at how this actually works in practice we have our local platform running CyberLink and we have the Intel PSW architectural Enclave runtime and then on on the right we have the in the Intel server and the CyberLink server that we'll be talking to so before we do anything with Blu-rays we need to uh join this epid scheme if we haven't already and provision ourselves so The provisioning Enclave can do this provisioning protocol to do this join scheme and if that passes we're left with this epid private key blob on disk so later on we're trying to watch a movie and we uh realize that hey we don't have the secret keys yet in the CLD show X2 and we need to download them so clta will fire up the key downloader Enclave which will then initiate the remote adastation process first thing we do for message one we get our group ID we generate our uh Diffy Helman curve points and uh you can also include some user data and interestingly CyberLink includes some things like your serial number your CD key additional parameters of how you registered it and some stuff from your platform so they uh are able to actually Trace back a specific license of power DVD to a remote adastation uh request that's then sent to their server which will store the parameters from the elliptic curve and prepare message to to do that it will send its uh service provider id and group ID to the Intel adastation service it's kind of like its API key which will then validate that um the requester and obtain the revocation list list for the group ID that's sent back to CyberLink uh it'll generate its own uh curve points and then derive the uh session Mac key and then compute a CMAC over this as part of the authentication scheme so that you can't man the middle it that's sent back to The Enclave which can now start to generate a quote so like we said we first do a local ad station with the quoting Enclave which 
will verify a report and start the process to make to turn that report into a quote it'll unseal the private key blob produce a quote from the report re and you can think of it like resaling it and putting it back we then have encrypt the quote with the Intel uh attestation service RSA key give that back to CKD who will just forward it onto CyberLink who has to then verify it by again forwarding it onto Intel they can uh finally decrypt this quote and verify since they have the epid group uh public Keys once that's verified it'll uh tell that to CyberLink who then checks a couple things they check is the quote actually authentic like does it have a valid signature they also check the Mr signer and Mr Enclave uh measurements contained in the quote since we want to make sure that you're not trying to do remote at at a station with just a completely different Enclave uh are there any ing attributes enabled like debug since we want to make sure uh debuggable Enclave is not trying to connect and download keys and they don't check if the secure um the TCB which is um effectively encodes security patch levels they don't check if that's up to date uh but we'll get back to why once that passes we can finally do the last step of this process encrypt the AAC key blobs and the PCL key send that to The Enclave who can now encrypted with another with the same ephemeral session key and then finally seal that to disk so okay that was a lot let's attack this so uh we're going to attack this based on the uh methods of frog and toad so what are side channels a side Channel attack is some attack that leverages extra information that you can obtain from Target that is not necessarily a flaw in the algorithm itself but a leak of information that is inherent to the actual implementation you might have actually heard of some side types of side channel taxs uh like power analysis timing analysis electromagnetic leaks um but a lot of these happen on more embedded platforms like you might see
 on microcontrollers or um simpler CPUs is something like Intel sgx vulnerable to side channels well turns out yes a few of them yeah this is a uh a list of some of the possible attacks we can choose for extracting data out of uh Intel sgx or just uh Intel CPUs as as a whole but before we can go into the details uh just a quick primer on how these cache based side channels work uh using something called Prime and probe with Prime and probe we have a victim thread and attacker thread running on a physical core with some cach and some much slower Ram somewhere outside of the core first thing we need to do allocate a cach size buffer and RAM we then Prime the cache to uh set it to a known state with and remove the junk uh that's unpredictable based on what was running before by accessing all the elements to fill it with the buffer contents we then sit there and wait for the victim to do something that accesses RAM and when it accesses Ram uh it'll leave an imprint in the cache now we can't read the cache directly but we can probe the cache by measuring the access time and since the ram is much slower than the core accessing an element in the uh in our buffer that is no longer cached which is the the blue square we'll have to go and uh defer to Ram which is much slower and we can measure the difference in the access time so the uh this is then extend to uh tack called meltdown which uses uh these cache side channels to exploit another Hardware vulnerability in Intel processors that just lets an attacker completely bypass all memory protections on a CPU uh you can dump kernel memory from user land in three lines of code effectively and it's a speculative execution class vulnerability what's happening under the hood is that if you do a faulty load of data that you don't have access to it'll crash with an access viation that you would expect but interestingly uh that data actually exists in the context of the speculative window before that crash is actually happens so the 
data should be lost when the crash is uh retired and the windows rewound destroying the um the data but it turns out it can uh be leaked in the meantime with cach based side channels so to extend this sgx we use an attack called foreshadow which is just uh melt down with some extra virtual memory tricks uh to extend it to reading data out of sgx but we have this foreshadow leak but what do we actually leak even if uh PCL was the not undermined by CyberLink themselves attacking The Enclave is uh unnecessarily slow and hard we could attack CKD but that requires a copy of power DV DVD and windows to be installed on every machine uh we have to uh run the tack on and we also didn't want to deal with the windows virtual memory management um much easier would be the quoting Enclave since well it has access to the epid private key and we'd only need to leak the 128 bits of the secret seal key and it's exactly what we
[Applause]
 did so what do we do now that we have these epid private keys well first attack we can do is Implement a rogue quoting Enclave the U IOD shim program that sits between the cyberink enclaves and the real Intel enclaves that intercept the whole adastation flow from CKD and instead of loading the real Intel quoting Enclave it will call my evil quoting Enclave instead unlike Intel's quoting enclaves mine will sign anything and it allows me to patch CKD normally you couldn't do that since you'd have to resign it with your certificate and that would change Mr signer Mr Enclave it would have debug mode enabled but because my evil quoting Enclave will sign anything uh well and also we don't care about local ad station I can just patch the quote values for Mr signer and Mr Enclave before signing to what they should be sign them with the extracted epid private key and you make an enclave that's remotely indistinguishable from the original thing now what can we do with this well sgx uses Rd ran to generate the cryptographically secure uh curve points when they're doing the elliptic curve handshake it's supposed to look like this you can see it reading uh Rd Rand values and that's what it's going to use to generate the GX gy curve points well mine looks like this I call it sonye
[Applause]
 so now that we know the uh Diffy Helman secret a uh and the servers gbx gby points it's trivial to compute the ephemeral session key uh and once we have the session key that's what's actually encrypting the ACs keys in the Json so let's look at the message for that we get well it should be Json but it's not it's just a random blob and it turns out doing some more reverse engineering there's an eall 5 in CKD uh that for whatever Eason has some hard-coded AES wrapper around it but uh luckily for us the keys and IV are hard-coded in CKD and also CLT ASW for good measure so applying that we can finally decrypt the message 4 into valid Json like we expected and this now contains four Keys ACS two device Keys the um there's another scheme called Blu-ray bd+ which um is an something completely different and is not used here the keys are there but they're blank so we can just effectively ignore those and the uh PCL key that we talked about since we have the session key trivially computable we can just decrypt them from these uh b64 blobs and that gets us an entire set of 253 acb2 device keys and the PCL key
[Applause]
 let's try something else this is a good proof of concept but this again still requires sgx on this platform it requires power DVD it requires Windows since we're still running the actual power DVD software enclaves we're just messing with the quotes but since we have the EP epid private key uh we can just emulate remote ad a station its entirety so that's what I did I implemented CKD functionality the quoting onclave functionality and all of the epid crypto in Python so if you can run python congratulations uh you're now an authentic Intel sgx secure
[Applause]
 Enclave have a demo so this is uh as you may notice is running on a Raspberry Pi which does in fact support Python and I don't think I need to convince you does not in fact support uh Intel sgx technology but we have our private keys so let's run the implementation so we'll do a few things generate a curve points send that off to the server they'll reply we now derive the ephemeral session Keys magic of a quote send that off that'll then be sent to Intel who will verify it and say Yep looks good and then once we get that we got our message 4 decrypted with all the keys that we uh know how to get and that gets us a nice blob of ACS Keys um Blu-ray BD plus2 keys that don't exist and and our PCL key for good
[Applause]
 measure oops so okay now we have all this uh we have the keys we have the PCL key we have the enclaves decrypted uh let's take a look inside well reversing it the real CLT reveals that it's actually pretty much the exact same thing as acv1 just uh slightly updated with some new crypto uh ciphers and a couple very similar just new mkb entries instead of sha one they use sha 256 that's nice instead of their uh custom 190 bit ECC curve they have a standard Prime 256 all the all the AES based hashes still remain and they have the exact same subset uh difference tree system for revocation just with obviously new device keys but something interesting is that software players no longer share one common key like had back in the day where wind DVD had its one key that all the users shared because um of a uh the linkable epid quotes uh Power DV can actually issue a unique set of EP of ACS keys for a given epid signature and that allows uh that allows uh not only uh ACS to figure out who leaked stuff they can revoke just you and leave all the other users unharmed without them also having to update everything there's also uh I should mention acsv 2.1 which is practically an always online DRM scheme that was has never been implemented so there's no real way to investigate how it works and also uh with acsb 2.1 there is something interesting they do where they actually encode bits of your key set that can uniquely identify you and your CPU into which chunks of video it decrypts so you can think of it like a water marking scheme but it's a lot more interesting since you might think okay well what if I just point my phone at the screen that won't survive re-encoding so what they came up with is a scheme where you can instead of just doing invisible watermarks we just do visible watermarks imagine two scenes rendered where in one scene there's you know something happens with a character but in another scene the exact same thing happens but there's a little glimmer in their eye cong
ratulations you just encoded one bit if you do that enough times you have a Trader tracing scheme that can reveal from just a video file and a very rough video file at that enough uh key bits to see who is leaking their um who is leaking their content so uh we're as going to have a second demo since I patched since it's so similar I could just patch the VLC Li ACS plugin with the new uh types used in V2 and run it on an rpi4 to play a movie and you can do that just by putting our keys that we downloaded into the standard keydb config format uh unfortunately my drive decided to die a couple hours ago I know I'm really sad too cuz I have all the I have all these movies that we used to test with that I've never watched more than 5 Seconds of the intro with so I guess I'll have to wait a little bit later but to make it up to you I have two more special gifts that have never been uh never before been seen in the wild we have uh proof of of a authentic V2 media key and proof of an authentic V2 processing key which again could render the entire system of uh UHD discs completely
[Applause]
 cryptal so real quick let's talk about some uh possible mitigation strategies you may remember that uh the CyberLink server does not verify if the platform requesting attestation is uh actually fully up to date because even though is will try to help them out and say that hey you're out of date if there's known vulnerabilities in that CPU well could they just choose to only trust up-to-date platforms well maybe but it's not that simple see unlike sjx used in Enterprise applications these platforms are owned by users and users are not famous for being quick to update their biosis and micro code but what if we just force them to well uh some other members of the sjx off fail team scraped bios updates from six major vendors azero HP MSI gigabyte um Lenovo and Dell should be in there yeah and among those we found 173,000 micro code updates with about 5,300 related to sgx vulnerabilities that could undermine out a station but the medium patch time for some of these um vulnerabilities range from anywhere from like 25 days to 125 days with a median of that around 52 and well this is difficult to detect from just scraping bioses since their formats are so non-standardized and uh not really easy to unpack but we theorize that a lot of these older products just might never receive a patch at all so in effect acsa gets to choose between having some insecure users or no users at all and uh to this end we say farewell to sgx on consumer platforms since Intel is killing it on 11th gen
[Applause]
 after a laundry list of vulnerabilities that undermine sgx security they decided it's just not worth it trying to support it for Consumer platforms and starting from 11th gen it's gone and yeah thank
[Applause]
 you so some takeaways once again we are at back at the same uh cat and mouse game where ACS keys can be dumped theoretically faster than being revoked cuz as long as I can buy or someone can buy uh $10 vulnerable I3 7100 on eBay versus who knows how much it costs to remaster every single disc uh you know being made well that's an imbalance that's an asymmetric amount of effort time and money and also technical mitigation is not really a solution if it destroys the service uh acla sure could choose to only trust uh fully up-to-date platforms but what is what remains then from all your potential users that are still buying physical media UHD discs has the whole scheme invest in Windows invest in Intel and also have fully patched platforms then this also proves that side channel taxs are not just something theoretical in academic papers and labs this can be practically exploited in the Wild on end user devices quite very simply and also please verify that you're not shipping your internal debuck Tools in production and finally like we said uh with Intel sgx being removed from uh PL newest 11th gen plus platforms well people upgrading uh their CPUs that still want to watch their uh Blu-ray collection uh that will be left as an exercise for the reader so special thanks to the entire sgx fail team uh Bader who uh from Purdue who worked very closely with me with reverse engineering decrypting movies figuring out the triangles Stefan for from Michigan who is a wizard at Intel uh wizard at Intel caching uh side channels Daniel genin who was my adviser for uh the team at Michigan who's now Georgia Tech Christina Garmin uh crypto expert uh at Purdue who also helped us understand the four-dimensional triangles and the rest of the team working on some other parts of the sgx fail paper which you can uh read at you know just type in your browser sgx fail there's some other interesting stuff we do in there like breaking uh secret network uh crypto cryptocurrency I should say and a
lso uh Dennis are you yeah for uh being the absolute hero that tried to get the last demo to work by taking the train to Media Mark to get a replacement drive that didn't work thank you and thank you
[Applause]
 thank you Adam uh I will we might get one question through uh signal Angel what do you mind uh yeah doesn't the DVD industry tries to backpedal on the CSS Bridge with weak sectors and other methods to deter ripping did the Blu-ray disc industry ever tried similar yes so um can everyone hear the question so so the question was uh with CSS when the compromises were published the manufacturers tried some other mechanisms like weak sectors and some other things to try to patch up what they had left did blu-ray try anything similar with uh Blu-ray or acv1 they did there's like other forms of DRM that can be stacked on top of ACS uh that was the aforementioned bd+ that's like a it's implemented in Java with Blu-ray that has tries to do some more DRM that was not implemented here since this has not been broken yet and um there's also something called cavia or cavia another type of DRM so yes you can stack different drms on top of ACS they did do that with V1 but since V2 has not yet really been broken they have not done that thanks a lot Adam um please give him a you round of applause for this very very interesting talk
[Music]
 la