Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/3034 Thanks!
[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 host 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 name 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 on 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 the 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 this 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 derived
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 them 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 congratulations 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
also 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