So while our Microsoft Exchange Server has always been a tad pissy with my Android phone, my employer has reconfigured it recently to up the ante: it’s now fully come out and said to my phone “Look: encryption or GTFO“.
I was a bit taken aback by this level of militancy. It’s not like the phone even belonged to them… this was my personal phone, which – so that I don’t look a complete nincompoop by missing reminders for meetings or important emails – I allow to sync to Exchange at all. Said sync’ing has been iffy at best and sometimes I still look like a ninny… but I’ve gotten by so far.
But looked at from an employer’s point of view, all this BYOD-aligned personal phone use is just a great big yawning security hole.
Or is it?
As is generally understood by anyone who takes even a moment to think about it, security is an illusion. All you can really do is inch up the barriers to entry so that the baddies have more clambering to do before they can get at the goodies. And of course, as the hurdles go up for the baddies, they go up for you too. In the case of encrypting a phone, not only do you now have to lock/unlock your phone with a PIN (OK most people already do that), but now your phone is going to be anywere from slightly to very noticeably slower.
Most of us have PINs to our phones. But we should be aware that there are tools to bypass (or at least not require) your cutesy little pin entirely, with devices such as the one in the picture for this post (swiped from cellebrite, a company that manages to be fascinating, legitimate and disconcerting all at once). And that’s the scenario in which some sufficiently powerful entity (police, national defence, whatever) wants the low-down on you. You’ll notice in the picture that the phone’s owner is absent from the picture: the device has probably been swiped from them, temporarily or permanently. You’ll also notice that this might not be such a bad thing altogether, for consider a slightly more thuggish approach:
you: “Hey – that’s my phone give it back!”
thug: “Oh yeah? What you gonna do about it?”
you (feeling smug):”well…. well you won’t be able to use it anyway cos you don’t know the pin! Hah!”
thug: (reaching for a crowbar): “you mean I don’t know what the pin is… yet.“
In both cases your pin will not have protected anything on the phone and in at least one case you got a kneecapping for having a pin at all.
The reason I’m focusing on the (very mild) uselessness of PINs in actual data security instances is that the encryption made possible on Android phones actually uses your PIN as a seed. This is when I got suspicious and did some serious googling. What good is it if everything’s based off your PIN, and – as discussed above – your PIN isn’t really much of a barrier for entry? Well I learned that it’s not quite as literal as that:
Take your Android secured-ness with a pinch of salt
So, your pin will itself be encrypted and stored in separate block on the phone. (hacker/thug/government agent: “whatever, I have way more processing power at my disposal than your puny phone and I can decrypt that PIN fairly easily. Especially if its a feeble 4-digit pin… which, let’s face it, it WILL be”). Then, your PIN is used to ‘salt‘ the encryption algorithms.
But then I also learned that if you’re, for example, an Android developer and you put your phone in debugging mode, or (and root your phone? not sure on this part), none o’ the above PIN/encrypt/salting shenanigans even matters. You can still get into the phone. I quote from comment #4 on the this Android issues thread:
This would make android development cumbersome. The debugging port has to stay on when the screen is locked for ADB to maintain a connection to the device, for things like shell access, logcat etc.
In a corporate/enterprise environment USB Debugging should be explicitly disabled for end-users. Having USB debugging enabled on the phone is the same as having no unlock code (and should be treated the same). ‘USB debugging’ gives you privileged access to the device, that’s why it’s a ‘debugging’ feature.
I didn’t get past the first screen in the encryption process that asks for your PIN (cos I had all the above questions)… but I hope that later on it forces you to switch debugging off otherwise the whole thing becomes an exercise in mootness. I guess I’ll find out when I re-attempt. If I re-attempt. Sigh…