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/1084 Thanks!
[Music]
one of the major pitfalls in any
security solution is usability and one
way to deal with that the market decided
is self- encrypting devices you might
have come across them it's usually
external drives that do all the crypto
stuff for you but what do you do if
these devices are broken and have weak
crypto well it gets even worse if you
have a operating system like Microsoft
Windows and it detects you're using such
a device bit Locker for instance will
automatically use that device instead
possibly stronger software crypto here
to tell us more about that is Carlos
Meer
all right thanks so um who is this guy
well I'm a PhD student at rbout
University in NAA um my focus is on like
cryptographic stuff in the wild so
basically breaking stuff that's uh Black
Box um uh you might know me for uh
cryptographic attacks on Myra classic
like the the the patched one um and some
uh algorithms in uh for generating
passwords in Wi-Fi routers and this year
uh about self- encrypting drives if uh
if my research appeals to you then uh
you can hire me as a consultant at U
midnight blue Labs if you want
to um and first I'll start off with a
few acknowledgements um like I can't
thank Philip ging enough for his
research on the Samsung 840 Evo like it
really contributed to mine so uh thanks
if you want to get involved with this
reverse engineering uh stuff you should
it's uh it's awesome it's amazing
so um yeah cliche what's a self-
encrypting Drive um so um traditional
encryption is like you have a plain text
you have an algorithm and a key and
combined you get some Cipher text that
you that that means nothing to you and
can only be decrypted if you have the
same key and that ends up in a storage
device now uh there's also the hardware
style which uh basically integrates
everything into a single device so both
the encryption and you should you just
basically give the drive the data and
the key and it will do everything for
you and that sounds convenient but there
there are caveats that's that's probably
why why you think I'm here so um
basically these things encrypt
everything and they always encrypt
everything so even if you don't set a
password the moment that you set a
password basically uses that password to
encrypt the key so the encryption is
then instant so you don't have to
reencrypt
everything
um so um basically if you look up the
spec sheets of these things um these
aren't like magical chips they're just
arm cores and there's another um so
there's firmware it's basically software
if you if you dip these enough and
there's um if you look at a PCB then you
might wonder what these these these pins
are and they're actually JTAG so you can
actually debug these things and there's
another example of one so um yeah that's
where the the fun starts so um well
these these self- encrypting drives
haven't been like theoretically proven
but they've been democratically proven
in the sense that um yeah there's
there's all this marketing fluff around
it and well basically the the takeaway
note is um software encryption is uh way
inferior to Hardware encryption there's
uh even Studies released about it um
it's all it's great so um even bit
Locker trusts these things but if fault
if your drive actually uh advertises
support for this so um I kind of wonder
what like what are the actual security
guarantees of these things well um just
taking theoretical approach we're going
to dive into the practice later um so
there's three attacker models uh and
we're just going to play the attacker
model game so item machine is on and the
attacker has physical access to a power
on machine um this is very bad when
you're using software encryption uh
either the machine is off and there is
no awareness of the the victim that the
attacker has actually physically
physical access to the machine and or
the victim is actually aware that there
is that there has been physical access
to the machine so then you should that
you then you should consider the device
tainted and therefore you shouldn't
enter a password into it anymore so you
you're just going to assume that from
the from the physical encounter onward
there is no you won't get anything from
the victim anymore so no password
secrets whatsoever so let's focus on the
first one first so um software
encryption keeps a secret key in Ram it
needed it needs that to operate so uh
that has inherent weaknesses so you can
extract that key from Ram uh with a cold
boot attack for example I won't go into
this uh in too much detail but basically
you uh load a custom OS and then uh
basically you extract it from its
previous uh previous state or you could
do dma attack for example through
Thunder through Thunderbolt or firewire
and that kind of stuff and so Hardware
encryption is supposedly immune but so
actually the key is Captain Ram uh and
that is in order to support uh standby
mode so if you if you put your PC in
standby mode it turns off all the
peripheral devices and therefore when
you resume it again the drive needs to
be unlocked again and you don't have to
enter a password so guess where that
password came from so it's actually kept
in Ram all the
time um and also a key is kept in
storage controller because it needs to
use it for encryption and a storage
controller is not a secure device by any
standard so there's actually in on many
of them as we saw in the previous slide
there's debugging interfaces on them so
you can just use that and take the key
out uh and given that the after area has
physical access you can basically just
hot plug the device so um in this
scenario um self- encrypting drives are
definitely not Superior to software
encryption um so we take a look at the
second attacker model so the machines
off and the and the the the victim
hasn't uh noticed that there has been a
physical encounter then that's what we
call the evil mate attack so basically
you're in you're out and your laptop is
in in a hotel room and the and the evil
mate comes there and install some back
door functionality so basically you
install the back door functionality you
wait for the victim to enter a secret
key and then you exate the data or the
key or whatever you want and so this can
be Hardware key logger um there's not
really meaningful defense this can be
back door in the boot loader well you
can actually defend against this uh with
TPMS or um or secure boot but when a
hardware encryption enters the game it
doesn't change anything so it's still
equivalent it's not
Superior and then we end up at our last
uh scenario it's uh when the when the
when the thing is powered off or when
you lose it or when your device gets
stolen then and the ad tracker has
physical access to it then um software
encryption actually provides proper
security given that the implementation
is sound and if you use open source
software uh which is audited by
independent experts you have a you have
a pretty safe bet that your data is
secure um or if you use a proprietary
software uh with some implementation
details that are public and
independently audited then you prob fine
as well or you can just live on the edge
and use a black box uh implementation
and hope for the best I mean I wouldn't
prefer it but it's your choice and you
have that choice for Hardware encryption
you just you only have that choice so
and it's moreover it's extremely hard to
audit and there's even additional
pitfalls in the implementation uh that
apply only to Hardware encryption and
not to software so basically the
takeaway messages security guarantees
are equivalent at best and probably
worse so U with that I'll guide you
through some standards for self-
encrypting drives so uh there's actually
two widely used standards so it's ATA
security feature set and TC opal ATA
security feature set is actually
something it's just designed for Access
Control um and so it it actually
predated the self- encrypting Drive era
and then manufacturers decided to
basically take that and use it for uh
use the incoming password as a key for
encrypting the stuff
um and tcd opal is actually designed for
for us for usage in self encrypting
drives so let's take a look at the first
well before we do that suppose that you
had to implement this yourself like it
will probably look something like this
so you get a incoming user suppli
password and some key hash which you use
uh combined with the password and ass
salt and then you get a hash result and
you compare that to some hash output and
if that matches you take another key
hash with another salt with the same p
password and that will be your
key at least this is how I would
probably implement this so so far this
is easy um so now if we go back to ATA
standard um as I said it's it's predated
the the S era um so encryption is not
mentioned anywhere at all um and there's
two types of password user master and
both are user setable actually uh but
the master pass would is set in during
the manufacturing process so so there's
some setting it's called the master pass
word capability bit and it's either high
or maximum and so high means both user
and master password have access to the
drive's contents and Max means only the
user can unlock the drive but the master
may actually erase the drive so I didn't
come up with these terms but High
doesn't seem that high security to me um
so bottom line you should either always
change the master password or set this
thing to Max uh or face
consequences so um so this is how I
would likely implement this so you have
two of these data structures and
basically you have the same thing for
checking the password so you have an
incoming key uh incoming user password
and you uh you put that through key hash
with assault and then you get a hash
result and you check whether the hash
whether the incoming password was valid
and if so then you use uh another assult
to generate a key which then decrypts an
entry in this data structure uh which
then decrypts another entry in this data
structure and the reason for it is that
if you want to erase the drive then you
don't need both
passwords so TC Opel it's uh it's uh
like more modern they say and so it's
actually a def facto standard for these
kind of things um there so there's a
notion of multiple
partitions um which you called locking
ranges and there's a notion of multiple
passwords which they call credentials
and a single credential has the ability
to unlock multiple ranges and a single
range can be unlocked by multiple
credentials and so in databas terms this
is many to many so this is something
that has to be supported if you
implement this so any password any range
and many to many so imagine that you had
to implement this like it it shouldn't
come as a surprise that that people make
mistakes with this and oh by the way you
also need to be able to scramble single
range independ dep of all the others and
also not knowing all the passwords that
unlock
it so this is fully trusted by bit
Locker bit Locker doesn't use the ATA
standard it only uses
this so well there's a couple of typical
pitfalls in these in the implementation
of these things so uh Pitfall number one
and um yeah this is like the the the
stupidest so you have an incoming
password coming from the host PC and
everything that ends up in the in the
dries flash chips gets encrypted with
some key so and in the middle there's a
black box that basically um that
basically uh links one to another but
you don't know how that works and you
don't even know whether these things are
related at all so if not then then
basically all the secrets that you need
in order to access the data are already
stored in the drive so this
happens and uh so Pitfall number two is
uh suppose that you naively implement
this scheme then you probably take a
single key in order to access all to in
order to encrypt all the data and then
use different passwords to encrypt that
key so this means uh the weakest
password will allow access to everything
it's it's you can you can uh you can
lock that down in software but it's not
cryptographically
enforced and so if statements which you
can basically do away with if you modify
the
firmware so in in in this case even bit
Locker leaves a single range un uh
unprotected where the partition table is
stored so if you would use this scheme
then you would basically need no
password because that range has to be
able to be to become
decrypted so in this case um yeah
everything's
compromised so uh obviously there's
there's this Randomness problem because
there's no way to directly influence
these Keys you need to somehow make them
trigger a regeneration of them and so
you don't know how how the randomness is
is obtained and so yeah these things in
embedded devices tend to be uh badly
implemented um and there's the wear
leveling issue uh which is kind of
interesting so uh multiple rights to the
same logical sector uh trigger rides to
different physical sectors that's
basically in order to to make sure that
that the flash chip doesn't wear down
too too too quickly so um you have you
have finite number of uh right and erase
Cycles a single block can actually
handle and in order to you want to
spread that out as much as you can over
the entire chip in order to make to make
the service life as long as possible so
therefore there's this algorithm in
between that Maps uh logical sectors to
physical sectors and if you write two
successive times to the same physical
sectors chances are that they end up to
the same logical sector chances are that
that they end up in different physical
sectors so the old data is still there
if you overwrite the original so if you
get the drive from the factory
then obviously the key is in there but
it's stored unprotected and suppose that
you you then set a password and then you
overwrite the original key with an
encrypted variant it's
oversimplification but this Bas that's a
basic idea but if you if there's wear
leveling then the original data may
still be there and therefore all you
need to in order to encrypt all the data
is also still there so yeah that's
basically what I just said um Pitfall
number five and this this is the final
one um there's this Dev sleep mode and
um this basically means going to some
power saving state so host PC sends a de
sleep signal to the storage controller
and the storage controller basically
there's no there there's no specified
way in order how it is uh that defines
how this uh power saving is to be
achieved so it can be it can be achieved
anyway so dor controller may decide to
dump its Ram into nonvolatile storage
and then turn off its Ram so
it may do that it's not specified so in
that case uh secret Keys may also end up
in non-volatile storage and it's crucial
that these things are erased on
resumption or um or not being used not
being stored in nonvolatile storage at
all so yeah there's a couple of
scenarios where we looked at this and
finally there's a general implementation
issues that also apply to software that
still apply in Hardware so stuff like
mode of operations um this probably
rings a bell uh side channels key
derivation Etc that's all still there so
what's our methodology so a general
approach it's it's actually it's pretty
ad hoc the stuff that we did and um
there's that I mean you you can't really
fit it into a single model but we tried
to make it as generic as possible so of
like there's a this three-step program
um obtaining a firmware image uh gaining
lowlevel control over the device so
actually that means debugging it or
getting codee execution or and then
analyze the firmware and see if if you
can find some uh some crypto
implementation
false uh um yeah so obtaining a firmware
image um that like that that seems easy
download it but that can be harder than
it seems because there's there's usually
obfuscation applied so you need some
vendor tool from the from the
manufacturer that uses SSL so you need
to strip that and then um then br
probably there's another layer of crypto
appli just for alisation just to piss
you off and so this is an example of the
Samsung magician which uses some some
AES key that's hardcoded and but it's
not in in the body of the of the of the
executable so you need to reverse that
and it's
annoying um and the image itself may
also be encrypted and if the decryption
is performed on the unit itself then
there's that's a dead end because you
don't have the keys if it's done on the
host PC then obviously you can perform
the decryption yourself
um so in that case you'd have to pull
the firmware from Ram to JTAG for
example um but that's not it's not a
given that that's available so um yeah
let's let's let's take a deeper look
into that so J allows you to control the
device um like completely so so you can
uh held the CPU set registers read and
right to the address space basically you
control the whole thing and some models
have a the plain in plain sight so for
example this one uh it's a 14
standardized pin layout others need some
figuring out so we use this board called
the jtagulator for it just basically
brute forces the pin
layout and if it's not there it can be
turned off in many for many of these
controllers uh then you need some code
execution uh to be achieved so how do
you do that well some vendors have
undocumented commands that allow this um
some have vulnerabilities in their
firmware but like it's kind of a chicken
and egg problem because if you don't
have a firmware image then you can't
find these obviously um some have some
code stored in memory chips like the
firmware image itself stored in some
memory tip that you may modify with
external
equipment and or like if you want to go
really hardcore you can bypass
cryptographic signature checks with
fault injection for
example um so now um yeah this is
analyzing the firmware is basically
looking at how it's implemented that's
more of an art and a science but I'll
give you a couple of uh couple of uh
hints that that you you probably want to
uh want to take away so first if you
have the image you want to figure out
its section information so you want to
see uh what what pages are mapped where
in the actual uh address space so you
take that from the image header
sometimes it's obvious sometimes you
need a little bit of reverse
engineering um then load the image into
this assembler we use ID Pro for this
and then figure out what the firmware
does now it seems it's it's easier said
than done so um like one of the things
that you probably want to look at is
finding the ha dispatch table um so
basically it's a table of structures
that has at least an OP code and a
function pointer uh that that contains
the implementation of that command and
so basically that I I haven't seen any
manufacturer that doesn't do it this way
so if you find that table then you can
actually look up in the ATA standard
what every of one of these function
implements and that's really convenient
so if you want to go Target it and you
want to see what what a kind what kind
of implementation is used for a certain
command then go hunt for that table and
yeah you'll probably find it in a a
couple of
days so yeah look through function with
interesting op codes like these can be
vendor specific those those tend to be
really
interesting so without further Ado I
will um I will uh go into the case
studies so the first one is the crucial
mx1 100 it has some Marvel control
roller there's no documentation
whatsoever um so we use reverse
engineering for all of it um it has a
dual core yeah basically arm controller
it's some proprietary design I believe
and of course it has a hardware crypto
Cod processor in order to uh cope with
the bandwidth of of ATA because this
thing obviously isn't powerful enough
although it's quite powerful it's like
in the range of a Raspberry
Pi so firmware images they come as
bootable ISO images so you can just um
yeah you can just take the firmware
image out and it's plain text
everything's there uh they're
cryptographically signed though so you
can just modify it and then flash it but
it has a jte debugger so you can if you
want you can still flash it by uh by by
breaking the signature
checks so the findings on these drives
is uh well the incoming ATA password if
you're using ATA in order to encrypt
your data um it's basically hashed
compared to some other hash and then not
used further on anywhere so basically
that's it remove the check and then
access the data that's enough that's
that's sufficient in order to break the
encryption if you're using ATA Security
on this drive um now with TCG opal you
probably expect better but nah then
again so same story everything is the
same um there's some interesting vendor
commands so but you need to unlock them
first so you need like this this this
quer key command set some LBA to some
magic Val
and use this feature code and this ATA
op code and then all of a sudden the the
unlock the the the vender commands are
unlocked and you can use different
commands so one of them is to read uh a
page in SPI or erase or write it to it
and the SPI flash actually contains like
the serial number some diagnostic stuff
but also the bootloader so you can
actually get code execution with this
from the host PC which is interesting if
you're developing malware for example uh
but even they thought this was kind of
like inefficient so they also included a
arbitrary
right so so summarizing the above um
it's great you'll
see so the the mx200 is the basically
the successor to this thing um the J
deck pins have moved so it's kind of
annoying to solder on them now so um
yeah that that's that's basically the
challenge that you get uh but everything
else is the same so same vulnerabilities
same everything same vendor commands
everything so yeah great uh the mx300
though they really up their game so they
move to to a different kind of memory
which is not really relevant in security
but I I thought I uh I i' tell you
anyway uh new controller um and they
turned off the JTAG um and they also
completely Rewritten the security code
so uh oh yeah by the way the vendor
commands are still in there but now you
don't need this magic uh you can't use
this magic unlock command anymore they
use cryptographic signatures and
obviously we don't have the key because
it's asymmetric too bad and there's some
buffer of flows and none of them are
exploitable though at least I couldn't
exploit them so how do we how do we get
code execution on this thing because we
need that in order to well it makes
researching this thing easier and so you
wanted you want code execution in order
to exploit some crypto bugs so for that
we looked at the boot process so on the
left you see a ROM which is embedded
into the controller which then loads
some code from The spbi Flash and
basically that loads the firmware from
nand so um yeah this this like if you
want to take off the nand and modify the
firmware in N that's really annoying
like there's it's a BGA chip like over
100 pins uh um so how about we look at
the SBI flash um because that's only
eight pins and the pins are Exposed on
the
outside and it's located there on the
board so that's what we did we connected
a reader to this thing so um some wires
going on and convenient header um so
first what you do is connect an SBI
reader device and make a backup
obviously of this thing then craft some
code that removes the signature checks
from the firmware so once the firmware
is loaded and but not not yet jumped to
then you patch it that's that's some
some code that you inject into the SBI
flash so yeah that and then flash this
modified stage two of the boot process
and then the drive will accept arbitrary
firmwares with invalid signatures so
then you take a firmware image and add
some features like arbitrary read write
and execute and then you flash it as if
you would flash your normal firmware
update to send it through some ATA
command um so I'll do that later
actually I'll demonstrate that so on
with the key derivation scheme so we
reverse engineered all of it um
basically there is now binding between
the actual password and the actual key
that's being used eventually for
encrypting your data but and that's a
big butt um basically this incoming
password is used to encrypt one key and
every password basically yields that
same key and that key is then used to
decrypt uh some range key so basically
if you have that key which they refer to
um as the RDS key then you have actually
access to everything everything else is
just if
statements so um yeah this is prevented
by the firmware but it's not actually
cryptographically enforced but you still
need a single password in order to
access all the ranges and all the keys
for all the all the unprotected ranges
are actually stored in plain text so
they don't get you don't get the the RDS
key from them so this could work um at
least like you need a single password
which like in it let's be honest like
that's the only reasonable uh scenario
that you're going to use this in you're
not going to use multiple passwords
multiple ranges so um but we still found
a way around it so consider the password
protection function so they call it
protect password and from the name you
probably think this thing just generates
a
but it does more than that it actually
uh the output actually contains the RDS
key encrypted with your password so you
shouldn't really be throwing around the
output of this
thing so actually we looked at um so we
injected some code into the firmware uh
on some uh on some within some functions
and we changed the behavior such that it
just does the original behavior and also
just um puts it's uh puts the fact that
it's been called into a log file so with
its parameters so what you get from that
is this fancy log file and it basically
it says protect password and the
password is a zero buffer and the flag
for storing the RDS key is yes please
store the RDS key in some slot number in
some table and then that entry gets
copied to a lot of other slots So
eventually this RDS key encrypted with a
zero buffer ends up in all of these
slots except for 15 which is overwritten
later and the decryption key is a zerob
buffer so as an attack strategy you
would flash this modified firmware image
then craft some code that recovers the
rdsk key from slot one basically
decrypting it with a zero buffer execute
that code on the device and then you
have the RDS key but you're still not
there yet because there's still some
some Access Control in the way so you
need to remove that so there's a
password verification function that
basically checks a hash that you have to
nullify and then unlock any desired
range with an arbitrary password so now
I'm going to demo this let's spray to
the demo
card um
so yeah
sorry
so let me see oh yeah this one see flash
R yeah so it detected my flash so it's
actually it's actually on the desk here
could could someone please the change
the camera maybe yeah so um this is my
USB uh SPI reader device and this is the
crucial
mx300 and it's actually connected and
there's this board in between and it's
it's a FY jator but it's just there to
supply
voltage sorry so
um so yeah uh I created a cheat sheet uh
though so basically what I'm going to do
now is generate this uh I already made a
backup of this thing obviously so I'm
just going
to uh
make okay so yeah this is my make file
that does everything and it patches the
firmware and now basically the firmware
uh so the SBI flash image is patched now
so I have this
this thing here and I'm going to flash
it so I'm going to look it up in my
cheat
sheet okay so now it's flashing so that
will take a while in the me I'll show
you video of the stuff that I did
earlier so um this is basically this B
the bit Locker setup phase so um the
drive is connected to the PC for the
first time and it detects it and let's
create an empty part ation
table new volume NTFS everything
default and then we enable bit Locker
so spoiler alert the password is hdf
hdf as you can see there's no dialogue
asking you to to would you like Hardware
encryption whatsoever it's just just
uses it um and now Drive encryption is
enabled
okay let's see if the flashing is
finished verifying
flesh
for
yeah okay so that's probably this this
is not within the range that I uh that I
actually modified so it's okay just some
some
glitch so um now I will remove
this and remove the
reader and plug this
in
okay
so oh wow my colel
panicked
so while the laptop's rebooting I'll be
the metaphorical uh chicken to be
butchered to appraise the
gods who here had demo crash on
stage hands
[Applause]
[Music]
up of those uh was it
Hardware yeah was it
software
ooh well how's it going ready
yes
[Music]
um can I get a picture
maybe to pull it off
ah there we are great
[Music]
great so um okay now that the thebi is
flashed it should now accept arbitary
firmware images so I'm going to make an
arbitrary F
image and it's over there and and now
I'm going to flash that so this is the
command for flashing it HD par yes I
know what I'm doing please destroy my
drive oh great doesn't
work SDC oh
okay
done
okay so
now okay so now uh I'm going
to compile some code uh recover RDS key
oh it's already there and then I'm going
to use my tool Tinker in order to uh to
write that into RAM of the
drive so oh by the way uh let's read out
the RDS key
uh oh wow oh wait
SDC
so this thing is zero uh so it's not
loaded um so then use Tinker to write
this code into the address space then
SDC
yeah all right
successful okay and now run it
invoke jump
successful and now read it out again oh
I can use
this the rdsk is there okay
[Applause]
[Music]
so cryptographically we won um now
though we have to unlock the drive so um
I'm going to use this just make a four
byte zero Z byte file and then upload
that to the
drive DC okay and now I should be able
to unlock this thing with any
password no no oh you're
right
there we
go
[Applause]
[Music]
[Applause]
[Music]
W
okay
that went sort of okayish so um they
claim this is the best in-class hardware
encryption um yeah I'll I'll leave that
up to you whether that's true um so
there's uh there's also they also
obviously implement the at security
feature set and they it by default it
has an empty master password so um you
need to change that or set the master
password capability set to Max as i' as
you know so uh for the mx300 it's
insufficient because if you have this
custom firmware you you can basically
set that variable in Ram to zero and
then downgrade to high and unlock it
with an empty
string so um I'm not going to demo that
though um so on with the Samsung A40 Evo
it's actually the first Samsung drive
that supports the TCG Opel standard it's
a three core cortex 3 400 MHz pretty
powerful um firmware updates are pushed
through magician or bootable ISO image
and it's cryptographically signed and it
has a j Deb so this is their scheme um
so bear with me so on the left you have
a password coming from the user and
actually they take some salt in some uh
table which is the credential table so
there's in total there's 14 credentials
you can Define 14 credentials and it
takes a password takes the first salt
and then uh puts that through key hash
and then you get a hash in know and you
verify that hash and if it's if it
matches then you take the second salt
with the key and you get a key and that
key is used to decrypt an entry in a
table that tables uh 14 * 9 entries wide
so for every 14 credentials uh it has an
entry for all the nine ranges that are
possible and it takes that one entry and
uses it to decrypt that entry entry
entry and with that you get another key
which is then used to to decrypt these
list an entry in this encrypted disc
encryption key tables so this is how you
properly imp Implement opal so they
actually use a
64k uh blob in order to store all of
this data and then you get all of the
the proper cryptographically uh uh
enforced properties so congrats to
Samsung they did it um on the ATA
security feature set though um the D
only depends on the password in Max mode
so if you use high mode there's no
cryptographic binding there there the
password and the key is not related at
all so you can just um remove the the
password check and uh and do whatever
you
want um so uh this 64k bit uh blob is
stored somewhere and that's actually
stored in uh wear leveled memory so you
can just scan through through the nand
and find an earlier copy of it if you're
lucky there's a plain text key in there
and you can use that to unlock the drive
and we actually did this in practice
although it's pretty unlikely that
you're going to find this but if you
find it then you're there and it affects
obviously both both opal and TG opal uh
and ATA security because it's in the
same data structure so on with the 850
uh it's a success 340 of course and it
uses a newo controller and different
obfuscation routines but that's
obfuscation it's all done it's all
undone on the host PC uh but this one
supports de sleep and that that made it
interesting because we wanted to take a
look at death sleep as well and 840
didn't have that um everything is pretty
different um they did quite they made
quite some changes except for the crypto
implementation that's built on the same
implementation so uh it's basically all
of the same uh except for the wear
leveling issue they uh they fix that
so now uh the T3 portable it's a it's a
portable drive based on the 850 it's
actually the exact same thing it's just
with a USB SATA converter in front of it
with a T3 specific firmware that you can
download but you can pull it from JTAG
so it has a proprietary security command
set so no ATA and no Opel proprietary
stuff and as 256 is a big part of its
marketing and so there's this
configuration tool that they ship um it
actually supports Android I think it's
kind of cool if it if it properly
secured your your data uh this thing is
actually the implementation of these
these secure these proprietary commands
are actually based on their ATA security
implementation with the the master
password capability set to high so no
cryptographic binding whatsoever you
just can you can just remove the the
password check so yeah I'm hopefully
going to demo this as well so virtual
box
um
okay
so um it says security enabled so um
yeah if I go into here as far as I know
this yeah this thing
connected yeah it's not
there so if I do this
yes then security set to enabled so if I
now want to disable security I'm just
going to go for an arbitrary password
and that's incorrect okay so far so good
let's try something
um oh
wait of course I have a cheat
sheet
uh there we go so this
address uh wait open
OCD
okay JTAG is connected so and I should
be able to
do this hang
on okay so these are the
cores
can now help the CPU dump registers all
of that it's amazing okay so let's put a
breakpoint at this address so to
Hardware
resume okay so now if I enter an
arbitrary password it will stumble upon
that
breakpoint
and
wait so I will now remove that that
Jack and I'll see remove the break point
and then resume and there we go security
[Applause]
[Music]
disabled continue
so yeah that
works okay so
uh apparently this thing is uh tough to
crack so um some uh some very uh
impressive um shock resistant exterior
this thing has and of course Hardware as
256 encryption so um yeah I hope the
exterior does a better
job um
so on with the T5 it's basically a T3
with um yeah actually with a different
converter so rather than USB 3.1 gen one
it supports gen two but actually the
hardware behind it is pretty similar so
it's equally vulnerable they just
switched off the jtec so it's just
harder to
exploit so same thing uh conclusion so
most of these self- encrypting drives uh
have some severe weaknesses uh best case
scenario it's going going to be it's
going to be equivalent to software not
better and worst case it's uh it's all
down the drain so uh on a further note
TCG opal is uh terrible so so it's act
it's really over engineered um they um
uh they had all of these kinds of
features that nobody uses and security
goals are not clear like what what's the
benefit and uh there's no reference
implementation of this thing and
implementation is not even part of its
liance test whatsoever so yeah there's
structural changes
needed so with that um if you have any
questions I'm happy to take
[Applause]
[Music]
them okay we have microphones in the
hall here please line up behind the
microphones if you have any questions
and keep your question to one sentence
and for all of you to spare you that
thank you very much for this excellent
talk uh and we'll start with our signal
Angel referring um questions from the
internet I hope your is
fine so do I are there SAR issues um
mx500 and latest crucial drives one can
buy today uh the m 500 in particular I
didn't take a look at it because
actually uh the mx100 200 and 300 um
they they use some Marvel controller and
the mx500 it's from a different
manufacturer and it's not even based on
arm and so it's really annoying for me
to reverse and so therefore I left it at
that microphone number two
please hi great talk can I ask you if
that uh uh Hardware encryption can be
disabled for bit loock Lo ER and what if
I don't use bit Locker use another
software or another operating system
does it use Hardware encryption um so
with bit loock so the question was can I
disable the the the bit Locker
encryption delegating it to the drive uh
and how how is it this thing uh what
what's happening with other operating
systems so bit Locker can be you can
actually tell bit Locker not to use this
you can change some group policy setting
um there's an advisory set up by
Microsoft uh that tells you how to do
this and with other operating systems
they basically don't do this so um so if
you use like Linux or Mac OSX file Vault
it doesn't matter so um particularly
with bit Locker um yeah they basically
bit Locker is the only thing that does
it except if you use a tool that
advertises like hey uh we using the
hardware
crypto microphone number four please
what about the newer Samsung versions
like 960 and 860 I haven't taken a look
at it um so actually I've I've taken a
look at the 950 and it's pretty similar
to the 850 uh the point is um so they
didn't screw up opal they screwed up ATA
security and with the 950 that the the
950 is an nvme drive right so uh but
they still support ATA security and
nobody in their right mind would use
that but they support it and you can
actually use it um so but I I don't
think it's it's actually really
interesting to to look at all of these
Samsung drives like we're trying to make
a scientific approach here so we're
taking a couple of samples we don't want
to uh take too much of these convenient
samples like okay this is probably
similar to that and therefore it's just
another driver that we can add to our
collection uh we want to make it a bit
more um more broad so we want to make
the the sample that we have um as
accurate as
possible microphone number one one
please how how hard would it be to
implement the security on self
encrypting drives correctly and uh is it
reasonable that that could be done in an
open-source uh development model um I
mean there are efforts for open source
firmware on these drives uh but they
didn't get far as of yet um so yeah I
mean you probably want that and but then
if I made like like um why would you
want self- encrypting drives like
they're not in any way better just use
software encryption it's fine and like
even for performance you have these AES
instructions that everyone has now so
for performance it's it's negligible so
um yeah you can you can do it this
properly uh Samsung did this with opal
as far as I know because like I I'm I'm
not a wizard I don't know everything um
so yeah um you probably could implement
me this correctly but um even if you did
then it doesn't give you any
benefit microphone number two please
thanks for your research um what about
your communication with vendors did you
do responsible disclosure yes uh in
April we actually uh gathered together
with Samsung and so we set up a meeting
and we actually demonstrated all of this
stuff and then uh so they they were
really kind to us um so uh and also we
we contacted crucial for this uh it's
just that um yeah basically they
responded uh obviously they weren't
happy with what we found but we they
were very happy the way we reported it
so um yeah Ian I don't know what what
can I say it's uh it's a responsible
disclosure thanks number four please I
thanks for a great talk my question
would be did you happen to take a look
at mvme drives and if yes uh did things
improve on that front
um so as I said before uh we did take a
look at the 950 so that's a Samsung nvme
drive and it's basically the same thing
just with an added nvme sawce so the
core of the implementation of everything
is the same just the interface has
changed so um but we didn't include it
in our final research report because uh
that's that's basically um we're not
trying to Cherry piig drives that are
likely vulnerable whatsoever so number
one please um how common our firmer
updates for the class of devices are
they distributed by Windows updates or
similar measures or are they only
available if you install them manually
um so for for Samsung uh you have this
uh tool called magician that checks for
firmware updates uh definitely not
through Windows update though so um yeah
I I think I think like it depends on
your manufacturer uh but all of them do
offer some some kind of centralized uh
distribution platform for firmware
images but if you don't run Windows then
you're basically on your own you have to
download them from the
website number two please hi um on most
ssds there is a function to completely
wipe the drive by removing the key have
you looked into this case um and have
you tried to recover the data after
wiping the drive uh well not not deeply
enough I'd say uh well of course we did
look at uh at some of these
implementations like is the key actually
written with random data and where does
that data come from so yeah yeah we did
that uh but like like for example if
there's wear leveling you can probably
still uh get the key out but then again
all the tables like probably the the the
FTL so the the the physical The Logical
uh mapping tables probably destroyed and
you get all that kind of stuff so it
will be really hard to recover data from
this thing even if you had the key
again microphone to
please yeah um thanks for your clear yet
um a kind of radical statement about uh
self encrypting drives um I'm wondering
working in an uh Research Institute
where uh I find more and more people
going uh to use or or demand uh these um
self encrypting drives for as they say
practical reasons of data protection
when working in the field and now I have
learned just now that um It software
encryption is um Superior um what do you
recommend uh in a practical uh usage
scenario for the three ecosystems um
Apple Linux Windows uh as a software uh
solution that is definitely Superior to
self encrypting drives I'd say
veracrypt okay thank you are there any
more
[Applause]
questions no more questions from the
internet oh we have one question for at
microphone number
two uh yeah thanks for your research uh
you said you actually disclosed these
problems to the vendors did they
actually fix it um so um actually
Samsung Rel released a statement and
basically saying if you're using an
internal drive and you're dependent on
the on the hardware encryption please
switch to software which
is I think it's kind of radical because
I think as far as I I have seen the Opel
implementation is solid um for crucial
they basically uh told everyone yeah we
released firmware updates um I haven't
looked into the mx300 firmware update
but for the mx100 and 200 they basically
just switch off the jtec and remove some
vendor commands that allow for the
arbitrary right and uh and also
obviously not make it able to downgrade
but if you find some alternative means
to get code execution on this thing
you're back on in the same uh
boat I think we're all out of time thank
you very much Oscar
[Applause]
[Music]
Meer
[Music]
oh