Becoming The Evil Maid: Hacking Android Disk Encryption For Fun And Profit

thank you yeah um this take is going to this talk is going to be about Android and it's full disk encryption um I'll I had an introduction so there's not much I'm going to say about myself I work on security I do uh security audits mostly code audits uh nothing uh breaking into facilities and stuff like that and I also do engineering work so I have both hats on and I also have a third head which is managing other people and so on so there's a bunch I do uh and at one point I got this request from a person sorry sles are messed up I got a uh on social media I got a

message from saying hi um somebody told me about you it's a friend of ours I know that guy um can you help me uh recover data for my Android phone and I was like yeah well sure um have do you have a backup they were like yeah sure but uh it's a low-level disc dump and it's encrypted I was like okay well I have more questions but on the other hand there was this little voice in my head and say with a new toy it's something I going to be could have fun with uh so long story short I I met up with the guy uh we talked about it and he told me his phone phone is some

Samsung flagship phone at the time uh was stuck in a boot loop so he got into the bootloader created a disc tump blow level from the boot loader side and then he flashed Android 12 on there the thing was running Android 11 before and now it's running Android 12 and it's working again I was like okay um maybe yeah I can have a look at it and I can try uh maybe see if we can decrypt that so in in the sense I was thinking this is somehow like an evil mates attack right because I have physically access to the phone um and I want to recover the encrypted data that's on there but now it's just not in on the

phone itself it's in a backup file but in the end it doesn't really matter and I also have the advantage that I have the passcode which he gave me and I don't need to care about being stealth and even not noticing me so in the end I have a bit of an easier task but not really what I knew at that time was that um Android Android's dis encryption feature is is called file based encryption that's their marketing term since Android 10 um and they do basically Ed the Linux stuff for dis encryptions so they use the mcrypt they use FS script which was actually created by Google and upstreamed so in the end it's what I knew I worked with that with

that stuff almost daily so I knew that part and the easy part with this en this encryption is all you need is the key right you just need the key then you can give it to the to the colur and then it will decrypt everything for you yeah I knew that there has to be some security chip or trust Zone stuff involved because otherwise it wouldn't make sense because then it wouldn't be secure and I didn't know how Android was using that and I didn't know a lot about the details of that I I knew that maybe the passcode would come into play at some point or Biometrics yeah and I thought it was time to change that I wanted to know

more about that so the first idea was I have a backup um and he told me it's stuck in a boot loop so why not just flash the backup onto to the phone and be done with it yeah I tried that and I noticed that I couldn't Flash Android 11 I couldn't Flash Android 11 backup on a device which was now running Android 12 because Samsung flipped some bit in the lowlevel euses which told it told the the phone it wouldn't allow flashing an older version so that was downgrade prevention and the reason for that was um after I searched for it and I got a hint um the reason was a paper which which is called trust eyes in the

darkness shedding light on Samsung trust Zone uh key master design which was exactly after some after reading the paper was exactly what I would have needed because they were they found a flaw in in the trust Zone mechanism that's doing the decryption of key blobs and that's the whole thing where which brings the security to dis encryption on Android so tough luck but there was one cool thing the guys who did that they uh published their their tooling so it's on GitHub and I could look around and I saved a lot of time on reverse engineering um so I thought hey let's let's make it easy let's live off the land let's use there I have an Android

12 phone it's running I can simply root it um that worked fine um it has to somehow work I thought because during an upgrade from Android 11 to 12 the same thing would happen right so it should be able to deal with an dis that's encrypted with for Android 11 but I what what I didn't know is since he flashed Android 12 on there if something was reset and I couldn't cover those key blops that were on there and I also didn't know what Samsung changed and they do not tell anybody about it because you I got access to the GPL res sources from from Samsung but uh and also the the Google sources so the

official Upstream Android Source but I don't know any user space code which Android uh which Samsung doesn't publish so there could have been or could be something in there which I I'm missing so I did quite some research I read up on on how Android works I searched through the Upstream Android code and basically Android since Android 9 uh does this encryption in three layers there's metadata encryption which is the lowest then there's device encrypted storage and then there's credential encrypted storage metadata encryption is basically quite similar to to what we have or almost the same as the mcrypt on Linux so it simply takes um it it sits in the B uh block layer so

the file system sits on top of that and everything the file system wants to write to dis is passed through the block layer and gets encrypted and then written to disk it needs a single key um and there's some IO controls uh for setting that up for setting the key and then you're done it's called DM default key for some reason but in the end if you look at the source code it's almost the same as the encrypt then there's device encrypted storage which is this the second layer which sits on top of that um this storage is only uh they do encrypt only parts of of the partition so just some folders um and it's available right

after boot so you don't have to enter your password for that and the device will automatically uh open up uh that encryption layer and have it accessible on the device it's used for I think phone calls alarms and stuff like that it's using F escript which is as I mentioned before which is an encryption layer which is Upstream in the Linux col and it's it's sits right in the file system so the file system has to support it ec4 f2fs and U ifs and others do support it I know that stuff because I've Upstream part of that and there's simply one IO control which you can use to set the key and the rest just works if the kernel supports it

then each should and then there's the last one that's essentially crypted storage that's the first part when you need your passcode or your fingerprint or whatever it again uses FS script it's basically the same thing but it adds it factors in your passcode somehow and somehow is the interesting part and also it will use the trust zone for that so the high level boot logic after after looking at the source code is something like that um the kernel goes ahead mounts / metadata it finds a key on there it unws it using the trust Zone then it it attaches that um device maper volume using the DM default key um then it goes ahead mounts that looks up more

key blobs from there which is the de key so the device encryptor key and the C key and both are again unwed uh using the trust Zone and added to the col via the a script IO control and then you're done so all I had to do was reimplement that for the the backup file which I was attaching and that should work and there's one key part or key element which is involved there which is the trust Zone and which handles the trust Zone and that's called the Android key store the Android key store consists of multiple Parts there user space part um which is the the key master H Al um so Hardware EXT abstraction layer I

assume and there's a key master trusted application which is running in the trust zone so um on samung phones that's I think it's called tigis their trust on OS and the key master application is implemented by Samsung um it's closed s you don't uh you have to reverse engineer to really find out what he doing but in the end the paper I was reading and I was mentioning before they did a bunch of reversing there and found the buck and they also had some cool tooling and also I found the trick for them which is um their tool which they called key Buster um they were not directly talking to the user space demon but instead they used the shed Library

which this demon was was loading um to bypass all the checks the user space demon was doing because the demon was checking who is calling me who is who wants to decrypt The Blob but the shed Library didn't so I could just go ahead and use the shed Library directly and then talk to the uh Trust on side so the high level picture is something like this um you can ignore the gatekeeper parts for now but the key store and there's something called volume D so I assume volume D so w um which is the main service which does all the setup during Boot and it's it's talking to the key store which is then

talking to the key master and and I didn't draw it here but the shared Library sits in between here and it's talking to the kernel interface for the trust Zone on on the trust Zone side we have the trust applications like the key master and there's also the the kernel implementations for the file systems which I have to call the I controls to to set the keys once I got them yeah long story short I had to really dig through the their Android sourcecore to to find where which keys are loaded and when and some things were a bit different on Samsung phones but in the end I found that the metadata key is loaded from that path um

I looked there there's a bunch I could have I could Mount that from the backup directly because that partition is not encrypted at all there's a bunch of files in there and looking through the code code I I noticed I can ignore some of them like the stretching file which contains no password and when when it does that I can simply ignore that file which was the case for me so lucky um the SEC disc carable file is is some number or some random thing which you just use pipe through a a hashing algorithm and then you get something that they call app ID um which I only need to send to the key master uh to the

truston application and that should work and there's two keys or to encrypted Keys the encrypted key itself is the key I I want to get and there's the key master key blob which is basically a key encryption key so what what they do is they encrypt this encrypted key using this key in there and this key is itself is encrypted with something the trust Zer has but I didn't know what it was so what I my idea was to Simply do the usual process I give everything the trust Zone needs to the trust Zone and let it do it its thing and um hopefully I get the pl Tex key back um yeah I I did further research

and looked into the whole API and in the end it's three things I have to call on the trust onite it's a begin operation it's an update operation and a finish operation the begin operation gets this key master key blob um and some a bunch of parameters including the app ID I get an operation handle back and then with this operation handle handle I can call update operation give it my my actual key blob which I wanted to decrypt and then I simply have to I simply get the pl text key back and the Finish operation is just some cleanup um yeah then I was looking into the the actual shared library because the the keyas tool wasn't using these

calls for their stuff they could use some other apis so they didn't reverse those and then I had to reverse these uh three functions in the end um most of the parameters they they are getting I could ignore and so the the simple pseudo code of what you need to do is this you just read this SE disc carable file generate the app ID which is some has hash function but you can look that up in the Android source code uh read the two key blops and generate some input parameters I will get to that and then I can call the three functions begin update and finish with tell the uh trust Zone that I want to decrypt that key

here's the encryption key um the parameters I will get my handle and then I give it the the key blop which I want it to decrypt then I will get the pl T ke back and finish is just to not have my program cash yeah the input parameters are basically telling the the trust Zone what Cipher to use what parameters it needs to decrypt the block I have to get those right um because otherwise I will get an error from the trust Zone back which I had a bunch of times um but in the end if you get everything right then it will work and you will get a key back um and so I managed to decrypt the to

get the first key blob uh decrypted um to test that I had to attach um the device maper volume which with some minor tooling I managed to do I had to do some trial and error but um in the end it worked there's some minor difference between uh 11 and 12 with Android 12 they added some prefix to their blobs um I could just strip that and uh that worked and there were some bugs in the key Buster tool they got some constants wrong but in the end it worked out fine so yeah um yeah then the next layer was the the device encryption encryption part which I thought yeah simple again do the same thing it almost was they I

was looking for the keys again and I found three keys which is the data un encrypted key then there's the de key then the c key at first I couldn't read those directories uh until I noticed I have to first uh load that key blob then those because that folders were again encrypted with FS script so there's actually a fourth layer uh which they don't tell you about really but in the end I could load those key blobs again I get it decrypted via the trust Zone API some minor issues were were there but nothing really it's just me being silly and and not getting getting the uh API right but in the end that worked so what

I ended up with was I have basically decrypted the whole file system except the credential encrypted storage and that's where all the user data actually sits so all the user data for the user profile isn't there and that's why I want to get to but in the end I could boot the the basically I could load everything from the application I saw uh from the OS I saw logs I saw when the device was last booted I lo so basically everything from the system and everybody can do that with access to the device you don't need a lot a lot of fancy thing I basically what I needed was the device and the ability to root the

device and I also knew that uh flashing Android 12 on there didn't reset the trust zone or any state in there so it's basically always using the same key and from what I think uh it will keep using the same key so once uh you update your phone it will not change the internal key in the trust Zone and I assume it's Hardware Bound for some reason so the next challenge is um getting into the credential encrypted part which will then require the passphrase and which which will need a a little more work because there's more trust Zone stuff in there it uh involves another TruStone application the one which you saw in the picture before it's called

gatekeeper um which does verify the past phrase roughly but I'll get to that I was lucky again because before I started there was nothing really much on the topic but quite some time into I was working on that and I did that on the site uh the brilliant people at corks lab uh posted on their blog uh a very similar thing to I was doing what I was doing they were uh looking into getting the encryption Keys actually they were trying to Brute Force the pass phrase the passcode of Android phones and they were looking into how to do that using the disc encryption part and what their approach was they patched the whole boot chain to get into

um the the trust Zone and Patch the gatekeeper application patch the key master and then be able to Brute Force um the passcode and try it basically they have brilliant doc documentation on the blog post and in the end that's their picture what I was doing was that and that's still to do for the credential encrypted storage there's a bunch of of stuff with uh a a so-called synthetic passcode uh password which which is derived from the user credentials and which you need to to get the key master application really to decrypt your your keep blob so the next steps uh would then be to authenticate the gatekeeper uh authenticate the authentication toker which is what

gatekeeper is for there's a fun thing which which the qu quarl people uh noticed all you have to provide to gatekeeper is some passcode which works right so I have to give them the expected blob which is which is encrypted and I have to give them my passcode which matches that blob but I can use I hope I can use um that from the from the Android 12 installation where I have set the passcode and I do not need to use the one from the backup actually on that step I can bypass the um passcode because all they do is they they just generate a random authentication token which is not dependent on the input I gave it

this is called the output is then called application ID and with that I can go ahead and have uh the synthetic password which is again just a file on the disk which is encrypted by the trust Zone um give it to the key master application with that authentication token and then it will give me um a decryption of that applic of of that synthetic password which again have to decrypt so there's two encryptions in there uh to get the real um synthetic password out of it and with that I can derive my app ID which is now different than from what I was using until now and give it to Key Master just like I did with all the

other layers before and then I get the the actual key which I can use for fspt yeah uh now you think yeah I did that and it's done no I'm not I haven't my evil plan here is to to get into next year's session because I haven't finished that part yet I still have to um the uh reverse engineer the gatekeeper interface and then I can can do all that which I was telling you about right now but uh maybe next year um there's going to be a talk on the second part yeah in the end what I wanted to show you is um even if the device looks broken um or the the backup is encrypted

you have a good chance into getting to your data uh by simply trying to understand what how the system works how Android is using the trust Zone and with the way it it currently is and I think recent Android versions do the same thing unless you have the latest security chip variant which is a bit different different but in the end you can as long as you control the device you can get it to do what you want and that's the main danger of rooting your password and your phone will warn you about it if you use a rooted phone you should not put any data which you which is sensitive on there because you can

get it out the only thing that's stopping you is the passcode but hey who enters your passord in public right nobody does okay yeah that's it any [Applause] questions we at the first question in the audience please

by the way how did you make sure that phone you got wasn't from a criminal that was just stolen the phone that's that's the reason why I wanted to meet the person the guy in in person he was actually living close by so I told him yeah come by tell me and and show me what you have I even saw the bill which he was using so I I had some checking and also the friend he was telling me about I checked with him too so yeah I was pretty sure uh thanks for the interesting talk uh question do you think that the enclaves that MacBooks for example have or the new ones I think with Intel do

you think that any of this is actually secure or will there be also a similar way to decrypt things if you have the physical access to the device I mean the main problem in my opinion here is that um the whole decryption of the key blobs does not depend on the state of of what's running on the device right so I rooted the phone and I was still able to access the trust Zone and they it used the same keys so they did not factor into this into their decryption Logic the state of my normal word in in arm speak so I think if you manage or if if MacBooks and and other devices actually incorporate that

information um then it's a lot better and a lot safer because then you cannot decrypt uh everything unless your device is in a secure and and verified State and I think with TPM chips um that's basically the thing right you only get uh stuff out of the DPM if all the PCR values match I don't know about Mach specifically um they have this dedicated from what I know it's a dedicated uh chip on the system and but I don't know the interface I haven't looked at that very closely to be honest any more

questions then I would say let's thanks again David for his presentation thank you