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/2087 Thanks!
[Music]
[Laughter]
[Music]
[Laughter]
[Music]
hello and welcome to the R3 s stage on
the rc3 on of a uh great
um online conference and hopefully the
last one so today we are going to speak
about we're going to hear a talk about
military grade uh as uh
1224 bit encryption um from svon and boy
but before we go there I want to to
share with you some uh some information
uh first of all this talk will be in
English and it will be translated to
German
sorry uh tonight there will be a
lightning round um uh of talks five
minutes each um and we still are looking
for submissions for that please refer to
the uh to the blog post um to the
relevant blog post and if you submit
please please please include your event
phone number um so that we can reach you
and we can get in contact with you uh
furthermore there is the um um Herald
News show where we we are looking for
submissions to keep people up to date
for of uh what's happening and uh for
that of course we need to know what is
happening so if you want to share
something with us please feel free to
share it at C3 uh uh C3 uh news. show
and of course um there there will be a
Q&A afterwards uh on um uh and you can
submit questions on various platforms
either being uh hack in on in the
channel
r3s or uh on the mastertoons and
twitters of this world um with the
hashtag r3s or R uh rc3 r3s and so on
and so forth um I'm sure you will find a
way to contact
us last but not least I have to unlock
my phone um uh last but not least uh
about the speakers um syvan does crypto
for a living who wouldn't like to do
that um and he also likes to spend his
time doing crypto uh Hardware attacks
and security research in general General
and also somehow he likes playing ctfs
that doesn't fit the profile at all and
then there is boy uh who is also a
security researcher in his own right and
does this also as a as a job um and of
course he likes cryptography hacking and
salsa dancing what what else so and with
that um give it up for S and
boy
hello thank you for joining us to um our
presentation so I'm silv I will present
you what brings me U to Brit force uh
as124 military grade encryption and what
does it mean and then uh bo will uh
explain how he patched some uh problem I
I discover during my
research so this project started during
a forensic project one of my colleague
received a USB key containing a volt
encrypted with SanDisk secure access
software uh he he asked me if it's
possible to bre force uh the password of
the Vault so I started my my research
about that uh finally meanwhile he found
the the password um Hare basically
written on a post it so it could have
been uh end of the
story but uh while I was researching
about this software I discover that it
is distributed by default on any SanDisk
uh storage product you buy as a simple
binary so you execute it once you
configure your Vault uh and then when
you launch uh the VT the the software it
will ask you your your password you
enter it and if it is correct it let you
access to your file you can import file
export them display them so um nothing
really new new as a volt
solution but I figure out that in the uh
preferences you can uh choose the
encryption method so by default it is
set to as 128 bit but if you buy the
premium version uh you can go up to
as124 uh bits so I was a bit surprised
and it started to interest me um because
uh as you may know as is not
standardized for key larger than 256 bit
so I was interested to know how
as124 was implemented in this
solution uh so I dig a bit deeper and I
figure out that uh this solution is uh
developed by a company called ENC
security and on their website they have
a really strong security claims the they
say that they use ultimate encryption
using 1,000 24bit as Keys military grade
so then I was even more interested to
dig deeper uh to see how this solution
work and especially because each time I
see military grade I always think about
this tweet by crypto dictionary and it
always tell me okay now uh you have to
look inside the the solution to discover
how it is implemented
it uh joke apart this is a inter
interesting software to analyze as I
said it's um developed by ENC security
and it is a general solution it seems it
is used by Lexar Sony and Western
Digital uh by default in various storage
product and uh even though it's uh it
seems to be widely uh distributed it's
it was not yet supported by ashcat nor
John the reaper for password Brute Force
so from a forensic point of view it it
was interested for interesting for us to
have a solution to Brute Force this kind
of Vault if in the future we receive uh
again um this volt and also of course I
wanted to know if I'm able to bre Force
as124 so I started my my reverse um it
turns out that the solution is a p32 bit
binary uh of about 10
megabyte um it is packed with upix so I
was able to unpack it with P Explorer uh
it run perfectly there are no further
debug protection so I could debug it uh
put break p and so on it was it is
written in C++ compiled with visual
studio so it was a bit uh painful to to
reverse C++ but I use gidra and uh Tools
in gidra to to have it uh decompiled
properly and I use as well uh rather to
for some uh further
disassembler and the solution use QT for
um graphic user interface and open SSL
for the cryptographic
implementation the first difficulty I
got was um when you execute the binary
uh at another place than the storage you
have a error message saying that this
application runs only on uh um the
storage of the brand for example here it
is um the Sony solution so for sand disk
it was okay I got a USB key but for Sony
I I I had no uh SSD so I started uh
searching this string in the binary I
figure out that it was just after a
branch so I blindly patch this Branch
this um instruction g& to GE like
cracking in the '90s and then the binary
uh executed it um properly without any
uh um further check so I was able to to
debug it uh from any place I wanted so
it was quite convenient and it remind me
good um good memory about
cracking then another uh feature I use
uh massively for this project was G
function ID so since I knew that uh uh
op SSL and QT were used uh in this
solution I created signature from um the
compiled version of the library for the
same architecture and then it could
detect the signature in my binary so as
soon as uh it is detected in gidra it
add the command uh just before the
function and it helps you a lot for uh
for reversing I could avoid the function
related to the GUI
and I could dig a bit deeper in the
crypto function so that was really
convenient for and it help really helped
me to be uh faster for the for the
reverse then I started to see how the
the the binary behave so I run process
Monitor and I enter um a wrong passroad
and I figure out that uh only one file
in the preference folder is uh open
during the the process the it is file
system. that and then the file is read
and if the password is wrong it is
closed and then a sound is um is played
so I knew that my password uh is compare
I mean the derivation of my password is
compared to something uh in this
file um if we step back a bit uh here
and we go to to the general problem we
are trying to reverse a password hashing
algorithm so basically we want to derive
a key from a user password and then we
will use this key um to encrypt data
usually when we do that we use a unique
and random salt to avoid an attacker to
to to do a dictionary or rainbow table
attack we have a parameter which is
called the iteration number which help
us to adapt the work Factor so to slow
down uh the the bread force and today
the recommended algorithm are pbkdf2 uh
which stand for password based key
derivation function to we have bon
hashing which is recommended by n
passord guidelines we have escript and
more recently we got argon 2 which is a
un the winner of the passroad hashing
competition so if you are interested by
this uh topic of passr ashing I would
strongly suggest you to go uh and check
the literature about the pass hashing
competition it's really really
interesting for this project I was
interested by pbkdf2 so the construction
is quite simple we input uh the Sal
concatenated with the constant one to a
hashm function and the user password is
used as a key for this function
and then we iterate uh c times this
hashm function so here C is the
iteration
number we saw all the intermediate
result and at the end we obtain the key
the first problem here is that okay but
what if we want a key larger than the
hashm uh output for example what what is
it possible to have a 1,24 bit key if we
have only 16 byte of output from the
hashm and in fact this was the first
problem of pbk df1 the the first version
of this
algorithm and this was solved in pbkdf2
by just considering that the key output
it here is the first key and then we run
this algorithm a second time with the
constant two which is concatenated with
the salt and we obtain a second key and
we can repeat this uh process again and
again again and at the end when we have
generated enough um key BTE we
concatenate all of them and we obtain
the the final key for example if we want
a 1,24 bit key and we have only 16 byte
of output we do eight iteration of the
of the process and we obtain the the
final key so this is
fine uh here but what what is inside the
binary I I reversed it and in fact
uh I discover that the number of
iteration is Art coded and then we have
a loop with um arh function inside it so
I reverse this main Loop and I figure
out that uh the construction for the key
derivation function is really close to
uh pbk df2 except that the hash function
I mean the function use is not a hashm
but md5 a hash function and the
password is Hash uh a first time and
then input it to um uh md5 again again
1,000 times and the the key is outputed
the same way another difference is that
the salt and the constant are hared uh a
first time by md5 and S to the to the
result so it was close to pbkdf2 but
with some uh
differences
the first thing I I struggled was okay
uh I I could figure out the algorithm
but I couldn't find from where the salt
came from but I found a string which was
hardcoded in the code which looks random
but it is always the same because it is
in the code and it turns out that this
um string is a Sal of my key derivation
function so it was random but obviously
it was not a unque per
user uh and yeah it's uh it's really not
a good practice I mean it brings uh some
possible
attack because uh you you can have
dictionary or rainbow table attack for a
user and in fact I check for other
version for other vendors and it turns
out that the same um value is used for
all the vendors so your dictionary
attack can work for a sunny user and a
salt user exactly the same way which was
the first um vulnerability I discovered
here in this
solution another uh less important uh uh
problem is the iteration number for it
1,00 iteration was a recommended number
of iteration when pbkdf2 was out but now
for example OAS recommend um
310,000 iteration or more for pbkdf2
using ashmac sh
256 so this number of iteration should
be uh higher or should be updatable in
for this
solution but there is uh another um
bigger problem here and it's really a
construction problem if you look in the
blue part of uh I I I put it here on
this
algorithm you you can see that it does
not depend uh of the salt and the
constant so uh we can precompute this
part this uh 1,000 times uh md5 and then
we can reuse this uh precomputed value
to compute uh the second key and the
work Factor really disappear because we
we don't have to we we have to compute
just one time the iterations and reuse
them for all the key we have um
generated so it's really a design
problem so and here we can see that um
between a and 128bit key compared to 1,
and 24bit key it's it's simply a
operation and in addition uh we can
reuse this precomputation to have a
dictionary uh attack a precomputed
attack um for even if the salt is
randomly generated on unique per user
because we can precompute our dictionary
and just uh Sor this value to to the um
MD the hash of the salt and the constant
so we can see here that even if it's
close to uh pbkdf2 it doesn't reach the
same level of security and there is a
design problem
here so that was the uh key derivation
function now let's see how the key
verification uh works so to verify that
the password of a user is correct uh
after we have generated uh Keys we will
read the file system do do as I
explained before and we will decrypt uh
the value St um in this file and if a
word is uh a clear I mean a clear text
word equals D2 C3 B4 A1 then the
software consid the password to be
correct uh the first thing I I needed to
to know is okay but what is the
encryption algorithm uh used to crypt
the file system.
do and this part of uh the code was not
identified by gidra ID gidra function ID
and it was using a lot of SSC
instruction which has really hard to to
reverse and even the decompilation was
uh not helping much but I knew that it
uses uh op SSL so I started to read uh
some parts I mean to search in the
source code of open SSL and I found a b
script which generate uh SS instruction
to implement as exactly in the same
order as the instruction I got in my
disassembly so then I could figure out
that as uh was used for the
decryption and in fact it turns out it
was as in counter mode so for as
128 it was um as in counter mode which
was simple so then I thought okay for as
256 uh it must be uh as on 256 Block in
C mode but in fact it was not it was two
iteration of as1 128 but the nons uh was
s with the second key generated by the
key derivation function and then the
the the key stream is s again with the
cipher text to to obtain the plain text
so then it was not difficult to figure
out how
as512 and
as124 worked it was simply the same but
with four iteration for uh as512 and
eight iteration for
as124 and always with uh the keys
generated by the key reflection function
s with the nons and we can remark here
that only uh the first eight bytes uh of
the key were s with the nons the counter
was was left untouched uh before the
encryption so here the difference
between as1 128 and as on 1024 modes uh
was only the number of as uh encryption
and in addition only half of the
generated key bits were used because
even though we generated one uh 1,24
bits only half of them work so with the
nons anyway at the end the level of
security cannot be higher than the the
the level of security of the user
password if it has a a low entropy then
the security cannot be higher than this
entropy nevertheless the nons were um
randomly generated with open SSL with
run by its function so it was uh it was
really fine with this uh with with those
knowns so at this um at this state of
the project I got everything I needed to
implement uh a brute force uh in JN Z
rer so I created a python script to
extract the encrypted data the nones and
everything I needed to to breath Force
The Vault um I figure out that you can
have false positives uh after uh uh
about two to the 32
uh candidates because you are testing
your uh your password uh against um just
a 32-bit word however for SanDisk and
Sony you have the version uh right after
this magic run so it helps you to um to
to to sort the false positive so uh my
my implementation is available on my gab
and it will be soon integrated in the
main uh
uh John theer repository so now
everybody is able to uh to bre force
as124 and I encourage you to to test my
implementation and and tell me what what
you
think so now let's see how it uh Works
in practice so if you um execute John on
your the hash you obtain with my my
script it will uh Brute Force the
password here it found um the password
because it was in my password list
uh it it founded after 2 second of
execution and John the repper was able
to test about 7,000 pass per
second if we compare uh um this to
pbkdf2 using 3 10,000 iteration we can
see that John will uh figure out the
password used uh because it's in the I
use exactly the same list but it will uh
find it after 2 minutes which is quite
longer and J is able to test only um 30
pass rad per second which is really
really slower and it shows how um the
algorithm and the number of iteration
influence the the result
here so that was it for the key
derivation uh function and pass Ro
tracking the only thing missing for for
the reverse was how the file encryption
worked and in fact after the password is
verified there is a file containing uh
all the file encryption key which is
decrypted with the generated keys and
then those uh key are used to encrypt
the files uh individually so this is a
standard solution and quite good because
if the user uh changed the his password
you don't have to reencrypt all the
vault which is really uh slow but just
this file and the file encryption keys
will uh will stay untouch and will stay
the
same uh and one thing missing was okay
but what is the file encryption
algorithm so at the beginning I thought
well it is the same as the one used to
verify the the user password and for
as1 um 28 mode uh it is indeed exactly
the same it is the as 128 CTR
mode but then when I executed my script
to test for as 256 mode I was surprised
that it was not working properly so I
reversed a bit the file encryption more
and I could find that in fact there
there were a small modification the uh
second key the second file encryption
key is now fully with the nons and the
counter the 16 by uh bytes of this key
is s before the encryption and then it
is used uh uh to generate a second key
stream and S with the the first output
to obtain the pl Tex so I corrected my
did my script but then again for as512
it was not working the same way as for
the um key verification so I reversed
again and I figure out that for
as512 only two iteration of as1
128 were used but only with the last um
uh file encryption key so I was a bit
surprised it was uh really interest
interesting to me and it was the same
for
as124 uh except that we use the last the
eight uh uh file encryption key so now I
got everything I needed for the file
encryption I could reverse the uh the
file format so uh in encrypted file we
have first uh the IV in clear the nons
then we have a version number we have a
parameter telling uh which algorithm we
are using here four stands for
as124 and then we have um the file name
l in clear then encrypted with the
algorithm I described before we have the
file name we have zeros and at offset
ox2 200 we have uh the the pl text in
clear uh the second problem I discovered
here was that it is a c like design even
if there is several um iteration it is
uh almost the same as a c uh mode of
operation and you can have file
malleability meaning that if someone is
able to uh modify your file then it will
be decrypted exactly with the same
modification and it won't be detected by
this solution so that was a a problem if
for example you store your vault in the
cloud or if someone has access to your
Vault again nones were randomly
generated with open SSL so there are no
problem not the problem of nonre use it
was perfectly fine but since there is
only two iteration of as uh we got only
a maximum uh of 256 bit of security
level
um and in fact if we go a bit deeper uh
so what what if we got only the the
encrypted file we can I mean
theoretically Brute Force 128 bits uh
for the first file encryption key and
then we have to Brute Force the last
file encryption key which is s with the
IV because we don't know it so we have
indeed a security level up to 256
bit but if we do a bit of cryptography
here and we assume that we have two PL
text block uh equal to zero and we have
their corresponding Cipher Tex C1 and
C2 then we can write um the equations
for the the encryption and we know that
C1 equals as used with the first file
encryption key of the first IV so with
uh AES of the first IV S with the last
file encryption key and here the plan
text is not in the equation because we
have make the hypothesis it is zero and
we can write the same for the second um
uh Cipher text then if we rearrange the
equation and we s them together we
obtain this last equation which depends
only on the first file encryption key
and not on the um last encryption key
because it canell out and we meaning
that we can test this uh left part of
the equation with the first for all the
possible uh uh file encryption key and
test if it equals to iv1 C with iv2
which are known because uh they're uh in
clear in the in the file and as soon as
this equation is satisfied we we know
that we have uh guessed the correct key
so it gives a theoretical reduction of
128 bit uh of
security this is theoretical it it
assumes that we we got a a zero Block in
uh in our in our file encrypted but in
fact if you remember well uh it turns
out that we know from where the file
name end encrypted and then we know that
we have zero until Ox 200 uh offset so
we can use this information to have zero
BL block and in fact we can I mean this
reduction this security reduction apply
for this
solution so as soon as I got my result
um I contact I contacted uh Ang security
uh in May this year so the acknowledge
uh of the vulnerabilities so the key
derivation function problem and the file
Mal malleability problem then the
vulnerabilities were disclosed to Sony
uh Western Digital and
uh I got a meeting with ENC security uh
to um to agree on the on the deadline
and also to handle the the disclosure to
the to the vendors then I received uh
two CV one for the key derivation
function and one for the file
malleability and then in September it
turned out that uh this key derivation
function is used in other Western
Digital applications uh so we extended
the deadline to the 22nd of
December so that was uh all the finding
I found uh for this solution and now I
will let B present um his
part yes thank you
s so um I'm now going to hold this
presentation from the view of ENC
security so uh I'm going to tell our
side of the story The interesting events
that that happened the challenges that
we faced choices that we made and I
guess for this audience always
interesting how we actually came to the
designs that were uh that we made for
for fixing those
issues um a slight bit of background
here so the company actually was founded
in
2009 and we have millions of people
using the software and part of that is
because we have OEM versions so what
happened is that we managed to uh sell
the product on USB devices USB storage
devices so for example that would be
soundis which is still our biggest
customer uh and they're actually
nowadays part of Western
Digital uh Sony was also a customer of
ours and they sold it with an SSD that
they uh that they sold uh and Lexar also
sold USB sticks with our product and
in this whole um vulnerability
disclosure process only Western Digital
and Sony actually replied to uh our uh
our contacts uh our attempts at contact
uh and Lexar never really answered to
us but I have to remind you that both
Sony and Lexa are actually not
technically not customers of our anymore
of of us anymore um so the timeline from
our point of view um I'm now going to
shift the perspective a bit to my point
of view because I actually uh got
involved with ENC only in March and
April of
2001 and that was because the company
wanted to have an internal security
assessment so I did a small security
assessment I did not all the fancy stuff
that San did with uh with gidra and
decompiling and and debugging
Etc uh what I did was some basically
some simple tests that I could do uh
including looking at files with hex
editors and and modifying them and
actually I found some similar things I
also asked just questions to the team so
how do you do the key derivation well we
use md5 with a th rounds for pbkdf2 okay
so one of my findings is obviously
that's not
enough so I gave them my report in April
uh and then my assignment was done I'm a
private contractor so you know I was
just hired for a small
assignment and then uh San disclosed his
findings um ENC did acknowledge the
vulnerability but didn't do much more
with it at that time not yet and then
San disclosed his solubilities to our
businesses to business or OEM customers
so they started asking
questions um yeah and then ENC started
to investigate the
issues we then spent from June to
November uh upscaling our team doing
discussions internally with our
customers doing a new design
implementation and testing uh and as you
can imagine because I had been involved
a few months before on uh the cryptog
cryptographic assessment um I was also
asked to uh to help the company out with
this so that's what I did and in the end
we actually managed to uh publish a new
version which fixes the kdf
issue um and what we still have on the
road map is addressing the cipher text
malleability and the cipher strength
issues so one of the first things that
happened uh and when I was contacted uh
you know then my my manager said Okay so
we've got this vulnerability report from
a guy who I don't know and is this real
is this anything at all um and he was
afraid it was because you know some of
the same vulnerabilities were actually
conf confirmed in his report but yeah so
I just Googled San like okay looks legit
he has done some stuff the report was
actually very well written and and
honestly if this would have been a paid
assignment uh the report would have been
paid for so that's that's really good
work and well maybe even uh a bit too
much for uh for something that's
basically for free uh the report is also
specific to our product so it's not some
some random uh report which says you
have vulnerabilities uh just in hopes to
get a cve mention or to get a bug bounty
we don't have a bug Bounty program but
you know these sort of things happen at
times um I also notice that the
terminology and the the evidence
presented really indicated that the
author knows cryptography so yeah it was
real sorry guys we really have to do
something about it which was already
planned but um not at the speed that
that we now had to do
stuff um yeah and that sounds easy right
because just choosing a new kdf new key
derivation
function it's not rocket science this
problem has been solved before basically
uh and also the malleability issue well
you use authenticated encryption and and
it's fixed but anything is easy if you
don't have to do it yourself really so
let's take a look at uh what
happened well someone set us up the bomb
and it was
so um so the company at the time was and
the product was in maintenance mode
which meant that we didn't have that
many resources to work with so we first
had to get more people to upscale our
team we also had to figure out okay so
so what are we going to do how are we
going to fix it how bad are these issues
and can we prioritize stuff uh we had to
make a design and we also had to work
more closely with our OEM customers than
we did before like I said u w digital
was still an active customer of ours but
this thing required more attention from
them uh and that c certainly they they
also wanted to uh look at the the
proposed resolutions that we uh wanted
to implement ment they wanted to make
sure that it was actually fixed so we
had to work more closely with them than
before and everything had to be done
fast okay that's all very nice um but uh
yeah so upscaling we need more people we
need more
hands where are we going to get them
from
because there is so much demand for Tech
skills and also crypto skills it it's
really hard to find uh this thing also
happened during summer holidays and many
people are just not reachable at the
time or not don't react as quickly uh
and in fact myself I also went on
holiday and you know it it was planned
it was booked we were going on
holiday uh yeah and we had to do
everything in short notice so we did get
some extra people but most of them were
part-time uh and that really doesn't
help if you want to fix things
quickly the next thing that we did was
obviously the triage part um so we
looked at the key derivation function
and what the actual risk to the users is
and obviously that depends a bit on the
use cases but with the the findings from
s uh about key deration
function that was pretty clear it is a
big risk for users so uh we really
wanted to get that fixed first and we
also expected that it's only a limited
effort to do so
then the other issue that was found the
malleability issue that was initially
reported well that may not be so easy to
actually
abuse there's of course the theoretical
uh approach which is uh actually not a
meability issue uh but um yeah so you
you can modify files certainly uh but
it's hard to do a specific targeted
change in the files
um I'm going to actually explain a bit
more about this in in the later slide so
let's let's keep it at up um and we also
expect this to take much more effort so
what we decided on was a staged approach
first we wanted to fix the key
derivation function and then we wanted
to fix the
rest so we had to choose a new key
derivation function and there were a few
considerations that uh that were
important for us uh of course there was
compatibility because we have an
existing product and we want users to be
able to still open those faults because
if they can't open the faults we have a
problem with our help
desk uh also they may never want to buy
the product again um performance is an
issue I mean sure people want security
but they also want
performance and uh many of these users
they are
not perhaps the most technically skilled
people so for them is usually
performance is more
important then obviously there's also
security because different kdf have
different security properties and then
there was implementation time and effort
for us to to actually Implement that
stuff so those are the main
considerations
now Fire
Works
um yeah so the different options that we
consider
where argon 2 balloon hashing escript
pbkdf2
uh and then there's the question how
many iterations are we going to
do
so um the first three options here they
have an interesting property in the
sense that they are memory hardened they
take a lot of memory to compute and that
helps against uh attex using gpus or
dedicated uh cracking devices with A6 or
fbga
a and pbkdf2 with uh even with h Max sh
256 that can be parallelized much better
than the other three
algorithms however uh looking from an
implementation point of view pbkdf2 was
a lot easier for us because we use open
a cell and that's already included and
the other options are not and you can
try to build it from the components that
open C gives you but it takes more time
you actually have to f verify it because
one of the things that really really
went wrong in this uh in the software is
that um someone tried to implement
pbkdf2 in its own his own implementation
but it's actually something that looks
like pbkdf2 but is
not so we wanted to avoid that and then
there was also some discussion
internally about um the more proven
Solutions because pbkdf2 has been around
for quite some time but the others are
much
newer and then there's the question how
many iterations because our products
actually run on older platforms but also
newer platforms but also mobile
platforms so we were afraid that um if
we would do too many iterations then we
would actually um yeah have people they
would have to wait so long for opening
their fault uh that it would uh they
would not like it or they would call the
help desk and things like that so
um yeah therefore we actually decided to
in the end to use pbkdf2 but only with
100,000 iterations and not a factor
three more as recommended by
oasp so then we actually faced some
challenges implementing this
stuff we had limited team capacity and
on top of that we actually did the team
was formed
pretty quickly um but we still had to
get to know each other and some of us
had to get to know the
environment um and many of us were
part-time so we also had to know like
okay so when are people available and
when not we had to get into a common
Rhythm that actually
works um so the ENC team was like I said
was mostly part-time members but we also
uh worked closely with the testing team
from Western Digital and those people
are actually in India so we had
different time zones we also had to
discuss some of the things with people
from the United
States so more time zone stuff then we
had holidays of
festivities uh as before we started out
during the summer so there were summer
holidays and even in covid times uh
there were still options to go on
holiday even though the options were
limited but they were there uh and then
there were some more festivities for
example in India there is a festival
called the Val and that's a really
important Festival there uh I guess it's
a lot of fun um but people took a whole
week off because that that's what they
do over there uh and then uh a few weeks
later there was Thanksgiving in the US
which also meant that people were less
available then we got people getting
sick two people from our team uh got
covid uh one actually was was really
offline for like two full weeks straight
and then had to recover a bit the other
one uh had less trouble with it but
still um we also needed time to prepare
statements for public release web pages
and everything things that take
sometimes more time than you'd expect
them
to we had to fight scope creep because
there are more bugs in our software
probably doesn't surprise you but it's
software so it has bugs uh and if you
find them you the first thing you want
to do is like fix it but if you're under
a tight
deadline sometimes you have to enter the
discussion like do we really have to fix
this now or can we fix this
later um then we also ran into some some
issues where uh Apple decided to make
some updates to Mech OS which actually
broke our code so that's all very nice
that we were going to build a new
release but we also had to fix this
because otherwise users would not be
able to actually use
it um W in digital uses mobile
applications uh and the Play Store came
out with new requirements we had to use
SDK 30 um that didn't really work nicely
uh on the first
try we also had limited testing
capability um I'll show a bit more about
that later um but part of the issue was
that we couldn't test we ASC Security
could not test the mobile apps because
we didn't have the code we didn't have
an environment to test it on because
those were actually developed by W
digital um at the same time we we
provided an API which was actually uh
used by them so if there are issues in
the API
library then you know we have to look at
it but if it's the application they have
to look at it and also our API works
both on Android and on iOS and
underlying file system access calls
those are slightly different um so our
our API was sandwiched between an
application layer and a file system
layer so that doesn't always make things
easier to to
debug um yeah and we had many many
different operating system product
combinations to
test so I'm going to try and show that a
bit
so the product is called Data fault and
there is data fault version six uh
there's a new iteration called dataa
version seven and that's a slightly
different codebase mostly different user
interface uh but data 6 is also the
basis for for dataa light which is the
Sony version secure access which is the
old western digital version and private
access which is the new western digital
version and it's also the basis for
theault API
and this fa API is used for three
different mobile
applications so if you look at upgrade
paths and these are only upgrade paths
for desktop
versions because the software runs on
Windows and on Mac and it has to run on
different versions of Windows and
different versions of of Mac OS right we
want the older versions of the software
to be upgradeable to newer and
intermediate versions and and we also
want all products to be able to upgrade
to our paid version because that's a
source of
income so that's a lot of different
upgrade paths to test and it's not just
an upgrade from software to software to
software but also from the file format
to a file format that may be
different then we also had some
limitations on actually using the
software because we actually have
limitations in those free versions on
what kind of devices they can run the
full version can run on your hard disk
or any USB stick it doesn't matter but
uh the old version of secure access uh
the old version from from W digital or
SanDisk only runs on SanDisk USB
sticks then there's private access which
runs on sandis USB sticks but also
something called the the expand charger
app or I expand
charger um and this is a device that can
actually uh wirelessly charge your phone
and perform a backup at the same
time so there's an an app for on your
phone to actually do this to do the
backup and it's called the I expand
charger app and obviously this thing
only works on uh if if you got like one
of those iand
Chargers um similarly on the Sony side
data default light only runs when you
connect it uh to a Sony
SSD so that's all very nice this one I
could easily buy this one uh my manager
gave me one and this one I couldn't buy
anymore the Sony device but you know I
was hacking it like the
20s I also used to do hacking uh like in
the 90s or maybe even in the in the 80s
with with old computer games on my MSX
um but the thing is that I while of
course I could patch binaries to uh to
run on any device uh that's not actually
the situation that that we want to test
because for us the uh the limitation is
a functional
requirement uh we also can just make
debug builds that run on any device
there's a simple option for that in the
build
script um so what I did is I bought
myself an an orange spy
uh and I ran Aran on it and I just
installed I made a script that can just
load the GM storage uh kernel module and
presented it with a a fake vendor and
product ID and that way I can have an
iand drive or an iand charger or a Sony
SSD it looks like
this all right
so as before um we had some challenges
to face and while you might think that
fixing the key derivation function is
easy it turns out it is not always so
easy uh so we could not meet the
deadline and fortunately San was uh uh
allowing us to extend the deadline uh
because he didn't want to increase the
risk for users because what would be the
point um so finally the new version went
live on to December
um and that's the part of the key
derivation function and then we had
another thing to fix which is the cyhex
malleability
so what we use is AES in counter mode
and like s said we actually do if we if
we have more than AES 128 we do multiple
rounds of the counter mode but
effectively that is basically the same
as if if you know anything thing about
counter mode you you make a key stream
which you exor on top of your plain text
which basically means that you make a
more complicated key stream which you
know which is just two layers but
effectively it's the same thing so
what's the issue here with uh with Cy
text
malleability so if this is the plain
text and this oh
sorry if this is the plain text this
thing above here is the word test all
lowercase
and then you have a key stream and you
exer that on top of it then you get this
Cipher
text now what you see is because it's
xer you know if it's just two zeros it
becomes zero if there's one of the two
bits is one then it becomes a one and if
both bits are one it becomes a zero
again okay but what if I know something
about the data in uh something about the
plain text and I wanna change it for
example this I know this is test if I
want to make this uh lowercase t a
capital T I can do that by changing this
bit but now trying to select it but it
doesn't work in presentation mode sorry
um if I change this bit to zero then it
becomes a cap capital T and I can do
that by changing this bit to
one because I just have to flip the bit
and in in Cipher text and it flips the
bit in plain
text
now that's that's fine for some
applications but you can do even worse
if you for example have a a an
executable stored in this file and an
attacker knows what executable it is so
the exact attacker knows exactly bit by
bit what what is in the file they can
just replace that file by something else
of the same
size or smaller because you can just
chop off the end you can't make it
bigger because you don't have the key
stream but in that case you know you
could replace an executable by a piece
of
malware
so it's not always easy to abuse this
but if you can the result is double plus
ungood let's
say um so the proven solution to this is
just use some sort of message
authentication code and there are
several options to do this you can use a
cipher mode that is authenticated like a
counter mode with GMAC or you can use
hmac there are other constructs as
well
um but yeah that that sounds nice
because it solves your problem
completely because now it's
authenticated if someone screws around
with any of the bits in here the the the
Mac will not uh match and you have have
detected that someone changed
it however ever there are two ways of
using a
vault we have copy in copy out mode
which is what you saw in some of the
screenshots from s and that's where you
copy a file into the fault or copy a
file out of the fault and you can do
with drag or drop where you can use
buttons and with that mode you always
read or write the entire
file and then there is a mounting which
makes theault available as part of your
file system
either on a drive letter or uh as a
folder in your I think your
favorites um this this feature is only
available on the full paid product only
but that introduces some interesting
side effects in this
context
because suppose you have a file it
contains all of your Cipher text right
because it's the encrypted file and
there is a Mac summary storeage we would
probably store it in the header in this
case now
suppose um you open the file then you
first have to do a full verification of
that file if that's a long file that's
going to take some time if you change
something in the file doesn't matter if
it's small or
large you have to recalculate the Mac
for the entire file for each right now
suppose you would open um you open uh uh
a bunch of of movie files so you have
like
256 gigabytes of
movies um in
4k uh and in those movie files is
usually included an an icon so that you
can just display the the thumbnail which
is all well and good but now if you open
that fault and your your viewer wants to
show that icon it will open that file
but that file will be have to be checked
out completely from A to Z right that's
an expensive operation so opening that
that fault in your in your Explorer
window might take like
minutes that that would be annoying and
if you would uh if you would have some
sort of application that changes only a
few bytes in in your file you would have
to spend a lot of time recalculating
that Mac every single
change so that's not you know from a
performance point of view it's it's not
desirable so an obvious solution would
be to like turn a file into blocks and
then perform a back on each block and
then it's uh more
manageable because if you only need to
read the first block well then you only
need to you know check this out oh
actually you also need to check all the
other Macs with to make sure that the
entire file is correct because otherwise
people might might you know change
something around here you don't know
that the entire file has been messed
with um this this setup actually gives
you lower and much more predictable
latency which is good it gives you
higher performance for small reason
rights which is good but it will give
you additional performance overhead for
full region right because now you need
to do this for this this Mac calculation
for every block and you also need to
either maintain a Merkle tree or you
need to like combine all those Max check
that not it will give you more Onis
overhead because now you've got more max
stored uh that's usually in the order of
like uh 12 and half percent to like a
few percent depending on the Block size
that you
choose it gives you a lot more
complexity more error cases more Corner
cases so it's much more complicated and
uh it doesn't really fit into into our
current design so it will be a lot of
work so yeah what else are there
Alternatives and yes there
are what you could do is use an
encryption mode that is much more
resistant to M malleability attacks and
that could be for example CBC mode or
XTS XTS is a good example because it's
really hard to mess with things I mean
you can
certainly break some part of the file
that's really easy if you have right
access but then again you can just
destroy the entire file you know that's
if you can write you're
doomed uh CBC mode is is has more
options more opportunity formability
because you can flip individual bits uh
and then you get a penalty of the I
believe the next block will be
completely garbled so it has more
limitations than counter mode but there
are still some
options um you can also use large block
cers or All or Nothing transforms these
things actually also help against people
detecting where you changed things in
the file that's also
good um those are mitigations they're
not a full solution because it's still
not authenticated encryption but it's a
mitigation it really reduces the
risk um and we can actually combine this
with uh authenticated encryption of
headers because the headers are
obviously the most important metadata
that you have they're small so this is
quite doable to actually uh perform
authentic
encryption
on and that's actually what we intend to
do to fix theability issue we intend to
implement XTS with authentication of
headers um yeah so one last thing when I
started out on my initial assignment for
ENC I think I had the same reaction to
a124 as San
did what
this thing does not
exist um and I had some some discussion
with this about this with uh with the
people from ENC who have been around for
a bit longer and it turns out that uh
the product has been sold to many
different countries and some of them are
uh not part of the vasar agreement so
there were export restrictions against
them and uh fortunately it's not
restricted to uh 40 or 48 bit export
restrict
that's something from the 90s um but
they can only use AES
128 sure not
like you know people can't just use open
source software but
whatever I don't consider that highly
effective but that was a regulation and
if you're a company you can get fine for
breaking it so um but marketing really
wants to offer something stronger
because people feel like okay there's
128 yeah yeah but can we can we make it
stronger like we want military grade and
actually people outside the crypto
industry
they I think they have a more positive
view on military grade encryption than
than us um so what was decided okay
let's do multiple rounds of a
128 uh and then call it uh to 56 51
12,24 because people understand bigger
numbers you can't say we do eight rounds
okay and then of course what I'm not
saying here but on this was not on the
sheet but apparently we do not do eight
rounds except for only the the initial
key wrapping of the file encryption key
so that's certainly an issue but that's
uh yeah so I wanted to explain why on
Earth this decision was ever made
because anyone who knows their stuff on
cryptography they look at AES 1024 and
they say okay these people don't know
what they're talking about um and it's
Mar
marketing yeah so I'm giving the floor
back to
San yeah thank you so as we we've seen
during the presentation and to sum up um
yeah the level of security is uh really
difficult to assess for a full solution
it depend many things um the algorithm
used um the work factors number of
iteration you you perform your algorithm
and at the end of of course the the size
of the keys uh used so this project was
uh really nice in term of collaboration
with ENC security uh uh to me and they
they handled the problems um in a in a I
mean in the way they could and they
always I mean I had a lot of meetings
with them and we we we collaborate a lot
on this uh and the findings I I I got
which is not always the case and I'm
really happy that uh by could uh share
the the presentation because for our
point of view we we always have the
attacker point of view are often the
attacker point of view in our community
and it's nice to see all the constraints
uh which happen when in fact behind
people have to patch what we have found
and it's interesting to understand um
their problem at the
end so this is it for us um if you have
uh further question we'll be happy to
answer during the Q&A session or you can
you can contact us uh on Twitter GitHub
or by
EMA thank you very much I want to add
that we also enjoyed the cooperation
with
s that's uh it was it was very pleasant
to to work with you and we were happy
that you uh you spent the time for us to
do so because basically you don't have
to so thank you very
much thank
you
okay thank you very much it was uh a
really interesting talk although I do
have to admit I'm not that deep into
cryptography as you two are um but uh
thanks a lot and I heard that the that
the interest was very high um so
congratulations for that um reminder for
everybody at home uh if you want to
submit questions feel free to do so uh
on uh Twitter or uh on Twitter masteron
or uh in the RC um with a hash r3s on
the on in the feiw or in the channel r3s
uh in RC so we have some questions
already um first and foremost before I
forget it because I don't have it noted
down uh from people here on premise how
much of a pain in the in the back was it
to uh
to uh discover this and and get it and
get everything
working uh no it was I mean it was um
I'm not used to Windows reverse so it
was interesting to me to to get back to
that it was not that painful except for
the encryption part where I had to look
to open SSL source code I mean to match
this part but otherwise it was quite
quite okay there were no debug
protection and and so on so it was quite
um and and function ID was working quite
uh quite good okay thank you very much
um so let's go the first question from
the audience um uh are the signs that
this solution for uh 1,24 bits is
broadly used or only found
here so um it is used by by many people
mostly by people using SanDisk USB
sticks um but yeah that I can't give you
actual numbers but it's a a fair amount
of
people so so it's it's uh the setup is
only you've only seen it with with uh
with exactly the the set of devices you
described it's not broadly used in terms
of uh uh of uh it's not an industry
standard as you would say
it's not an industry standard no
certainly not okay uh what we can see is
the um update request because the
software has a built-in update function
and we can see the request to the update
server to see if there's a new version
available and that also reports the
version numbers that are uh actually
used by the software so that there we
can see we can make an estimate of how
many people are using it thank you very
much yeah um then um furthermore um
would a tech illiterate end user ever
want to use this type of security
products as opposed to just using
well-known software that or or um the
built in dis encryption in the operating
system it's so it's a bit different than
than full dis encryption it's a file
encryption and it's the solution is
quite simple it's by default on the disk
and it's quite simple to use so yeah if
you don't know a lot I mean if you don't
know um a lot on on this kind of
software then you you will use it and
it's quite simple um no I I I do have to
interpret the the the question but I'm
not sure um whether that's the that's
the uh
intended what they intended to say but
how I would see it is would you
recommend a a um end user to to use this
to to protect the
the uh their assets or would you rather
recommend look do software encryption
and leave this thing leave this thing
aside so
um the examples that uh that the um the
the that we got in the question are
basically all block device encryption
and that's not always working for all
scenarios so if you need file encryption
you will need to use something else and
there are actually also other
Alternatives available even open source
ones um what I think is really
interesting about especially the
combination with our software with
SanDisk is that you can actually use it
on the iPhone as well because um using
USB sticks on the iPhone is not a given
they have to make something special to
actually make it work as a vendor uh and
this software of uh SanDisk actually
includes an encryption option okay so I
like that yeah sure thanks um uh did you
have a look at uh DM [ __ ] with DM
Integrity for doing file
encryption I do see that also as a yeah
please take it if you if you want to
answer that so no we don't did not look
at that um well not in the sense that we
we we cannot use DM and uh uh we cannot
use a device mapper stuff from Linux
because this is software for Windows and
for Macos yeah um and it's file
encryption and not block encryption sure
yeah that's that's what I thought that's
so um and then um how did the make
migration for uh of existing uh Vault
work for the end
user so it's
um it's actually relatively simple as
soon as you start a new version uh and
you open the fault it will tell you that
the fault has been upgraded that's it
you have to open it you have to specify
the password and then it will upgrade it
for you which means that the key
encryption key will be re-encrypted and
we will now also write the uh the the
what is it um the salt because the
previous version had a static salt as a
sare uh correctly uh concluded
M uh so we need to write AA for every
Vault and that's what we do MH uh and
then and obviously then you need to
reencrypt the key encryption key okay
thanks and um for now the last question
um what do you think about using ECC in
military grade
cryptography I I've never heard about
ECC military grade encryption but I
would I would be happy to to know and to
look at it it would be really fun okay
thank thank you very much um okay so far
I don't see any new questions Let me
refresh my part uh no um so um thank you
very much for your uh for your talk it
was uh really interesting and as again
the the the interest from the community
was there so um thanks thanks a lot and
I just have a one remark um sure
the my my uh contribution to J rer was
merged recently to the main repo so now
you just need to update your your J the
rer repository you don't need to use
mine anymore okay cool so John the
repper has been updated from the talk um
um we have one one last question I do
think we have time for that um have you
considered data format compatibility
with existing file-based encryption
schemes such as ank
FS no we haven't okay no thanks so and
with that I will um hand you over to our
backstage crew so to
[Music]
say