This is a true story.
Yesterday my phone crashed, and it wouldn’t reboot. Actually it would do nothing but reboot, over and over, with a seemingly different error message every time. I tried all of the tricks available to a technically handy person, and nothing worked—I couldn’t get it out of the crash-reboot cycle.
So I need to send my phone in for service. The problem is: the phone is full of my data, and I don’t want a random service guy to get his hands on that data. Nor do I want a random service guy to be able to resume whatever logged-in sessions I had on apps and sites when the phone started crashing.
What I want is to have the data on my phone encrypted. Strongly encrypted. Without a backdoor, because the service guy has no need to see my data and no right to get it. I would have wiped the phone’s memory before sending it in for service, but that would have required the phone to stay functional long enough to wipe itself.
What I don’t want is for the service guy to have access to a “secure golden key” that gives him access to my data.
That is a really good tip especially to those fresh to the
blogosphere. Brief but very precise info… Thank you for
sharing this one. A must read article!
Hi! I’ve been reading your website for some time now and finally got the courage to go
ahead and give you a shout out from Atascocita Texas!
Just wanted to mention keep up the good job!
I think there is another solution. Separate encryption for the System and User areas. Wherever I have data I own, I want it encrypted with my own user key. Wherever there is system data (that is the same data for everyone, like system programs on a new phone, they should be encrypted by a joint system-user key. (different user key). If I send the phoe for repair, I provide the technician with my part of the joint system-user key for that phone. That way he can restore, replace, reformat, whatever the system without touching my personal data. j
excellent post, very informative. I wonder why the opposite experts of this sector don’t notice this.
You should proceed your writing. I am confident, you’ve a great readers’ base already!
Two ways to avoid this quandary that don’t require trust in software that is already known to be malfunctioning:
1. Don’t store any data on your phone that you wouldn’t mind published.
2. Consider the phone expendable and forget about repairing it, warranty or not. If it breaks, trash it. Get a new device and restore your data.
I do not attempt warranty exchanges on hard drives that have crashed. I write off the expense and move on. If I get too many failures from the same vendor then I put them on my “unacceptable vendors list”.
Why trust technical or institutional solutions unnecessarily?
Something about this post has been bothering me since I read it, but I’m not sure I can articulate it properly. Let me try.
It’s to do with the phrase “random service guy”.
Your problem has two roots: your sensitivity about personal material on your phone, and your lack of trust in the person who will have access to it. We often face these problems in other parts of our lives when we are faced with exposing something we would rather not to a person we do not know. Medical examinations and visits from the plumber come to mind. Usually the way to solve this is to construct an atmosphere of professional distance or of interpersonal trust. Until he retired a few months ago I had the same plumber for 20 years and I got to feel more comfortable with him in the house looking down our toilets and fixing our sinks. In the case of medicine, when we get undressed in a decidedly non-intimate setting, we hope we can trust the professional distance that the doctor or technician is trained to express.
To worry about “some random service guy” accepts a different model of labour — even though it is skilled labour (if that matters). It takes for granted that you have no personal relationship with the technician, which is probably true because they are operating in an impersonal, corporate environment. It also takes for granted that there are no professional standards that you can trust. So in this atmosphere of trust, you look for a technical solution that will let service guy do his or her job without the temptation of poking through your stuff. It’s a technical solution that serves only to cover up what seems to me the more important problem – that we must rely on people or institutions we do not trust.
The other aspect of this is that “some random service guy” is not a compliment. In fact, it sounds a bit dismissive of this person’s skills and professionalism. It sounds, to use a cliche, entitled. Maybe that’s not what you meant, but that’s how it came across to me.
Perhaps a better solution would be to demand of our phone companies that they run a professional operation that can provide you with some commitment about how they treat your personal stuff. Software companies can do this. Where I work our tech support division sometimes have to take customer databases that contain confidential information: there are all kinds of practices, company rules, and regulations around this (which I’m sure you know as well as I do) in order to prove assurance, and it does work. Plus, the tech support people are not “some random guy”, they are — for the moment — professionals who have inculcated a professional ethos.
Not sure that spells out what I mean, but I do think that this is a case for an institutional solution rather than an encryption solution. So long as we designate important personal tasks to anonymous people we don’t have respect for, and who are not treated as respected professionals in their own place of work, we will be vulnerable.
I have been using Qubes OS and it’s 2.0 incarnation seems really polished. (pun) It encrypts all but /boot partition.
But re phone just use a removeable memory card and remove it before sending to the shop. A little late for you now, but it does seem that often the simple hardware solution is safer and easier than something implemented in software.
Pretty much the same situation comes up when you RMA a failing hard drive in a desktop or server. That’s why I have cryptsetup in between LVM and the RAID stuff. (And it’s also a big part of why I don’t use ZFS-on-Linux yet — crypto isn’t an _optional_ feature!)
I use ZFS on Linux, over dmcrypt. Works fine.
The downside of the twin design flaws of most new phones. 1) You can’t remove the battery to ‘really’ turn it off. 2) There is no removable memory card, so you couldn’t have put alll or most of your important/interesting data on a removable medium.
I recently activated the device encryption on my phone (Nexus 4, running Android). When you boot the phone, you have to enter a key before it will continue the boot process.
I would be fascinated to see what happened if I was in a similar scenario – if the failure was occurring before the point at which I’m prompted for a password, it’s possible that a technician could repair the phone without it being a big deal. But if the failure didn’t occur until the password was input, then it seems I’d basically be in the same boat as you are now – I’d have to hand over my decryption key, and thus provide access to everything on my device.
Nexus devices also have a “Recovery mode” that you might be able to get to, which allows for device wiping outside of the phone OS: https://support.google.com/nexus/answer/4596836?hl=en . It’s possible your phone has a similar feature and maybe you could get to that point of the boot up to at least clear your data off…?
If the phone is under warranty, and you have a physical shop/distributor you can go to, I’d try going there with a (complicated) confidentiality agreement ready to sign, and a few copies, requesting them to let that one sign by everybody who might have the ability to access your data, and ask them about every clause in their contractual agreement for repairs that covers responsibility and safety measures towards your personal data. Usually contracts say they aren’t responsible for loss of data, but they say nothing about unauthorized access (when I last read them)/infosec.
This won’t guarantee you an exchange of phone (although it would be less hassle for them to give you a new one, then to get legal on your information-security-requirements), but it will make for an interesting case study for us to read?
Ed,
(Not addressing the encryption question, but if you still are having problems, you can try this.)
My iPhone did that after I upgraded to iOS 8. I solved it by booting it in rescue mode and connecting it to iTunes, which loaded a factory firmware to it. I then did reset and erased all data and restored it from iCloud. That took a few hours, but it worked, and I got my phone back. Turns out I had a rougue app that did not play nicely with iOS 8. I deleted the app and have not had the problem again since then.
Thanks for the tip. Unfortunately the phone is beyond such interventions. It usually fails to get even to rescue mode, and when it does get there it seems unable to accept any USB-based intervention.