Security of data and passwords when phone is lost/stolen
-
Hi,
I'm in the process of setting up a Google Nexus 5 with ubports for somebody else. And I keep wondering, what are the security implications of running ubports on a device with unlocked boot-loader?
In case the phone is lost or stolen, will any new "owner" of the device be able to access the WiFi passwords, IMAP passwords and all data, photos etc. stored on the phone by just connecting USB cable and running adb/fastboot to dump the flash?
Are passwords stored on the device encrypted with the unlock passcode?
What precautions can/should be done to secure the data on a phone running ubports?
Thanks for any insights,
cheers,Dave
-
@Dave said in Security of data and passwords when phone is lost/stolen:
In case the phone is lost or stolen, will any new "owner" of the device be able to access the WiFi passwords, IMAP passwords and all data, photos etc. stored on the phone by just connecting USB cable and running adb/fastboot to dump the flash?
Yes.
Are passwords stored on the device encrypted with the unlock passcode?
Wifi passwords are stored in plaintext in /etc/NetworkManager/system-connections
I haven't looked into how other passwords are stored (either at the system or application level), but consider that even if they are encrypted with a key itself encrypted by the lock screen password, lock screen passwords that must frequently be entered tend nearly invariably to be of low complexity (and UT's PIN can only be 4 digits, though a password can be longer).
That works okay for a system like most recent smartphones with locked bootloaders (and often tamper-resistant hardware keystores) and rate limitations on password attempts. In a system like Ubuntu Touch, however, where the data may be trivially removed from the current devices (all of which so far as I know are running unlocked bootloaders), any key stored in that data and encrypted with the typical PIN would require mere seconds (if that) to decrypt.
What precautions can/should be done to secure the data on a phone running ubports?
If you are comfortable with the command line, you can create an encrypted container which you can remount as /home/phablet after each boot and initial login to an unencrypted home. There is a thread on this forum describing the hacks to do this (search for "cryptsetup," and you will find it). Note that this method is unsupported by the UBPorts developers and may be frequently broken by updates.
It's also little more than a bandaid, being still vulnerable to cold-boot attacks, evil maid attacks, etc. Still, it raises the barrier to reaping your data from a lost or stolen phone from "anyone with a USB cable who understands fastbooting TWRP" to "someone who genuinely knows what they're doing and feels it worth their time." I use this method on the UBPorts devices on which I do anything real (i.e., with other than test data), but even then I don't put anything especially important on those devices.
I do not want to cast Ubuntu Touch in a negative light. Rather to the contrary, I have high hopes for this OS. The UBPorts developers are doing an amazing job of picking up the OS where Cannonical left off and dragging it up to current support. Missing features will be added in time. There are unfortunately however more pressing needs in the OS right now than data security, so if you need that security at the present, Ubuntu Touch is probably not ready for you yet.
Edit to add: the above talk of mounting encrypted home assumes developer mode is turned off. With developer mode on, adb stays available all the time.
-
One small suggestion - if you must access private info on your phone - the Standard Notes UT webapp allows one to add a password for loading end to end encrypted notes from the web.
Best regards,
Steve Berson -
Is there a reason the bootloader on the N5 needs to remain unlocked? On a rooted Android system apps can un/lock the boot loader, so couldn't it be relocked after installation of the OS? Maybe just use one of the many tools available to relock it from adb to close that security hole.
I know more modern phones have made this harder.
-
@Giiba said in Security of data and passwords when phone is lost/stolen:
Is there a reason the bootloader on the N5 needs to remain unlocked? On a rooted Android system apps can un/lock the boot loader, so couldn't it be relocked after installation of the OS?
Bootloader of the Nexus 5 (and OnePlus One, for that matter) is only locked for the protection of an unwary user from themselves. It may be unlocked directly from the command line (fastboot oem unlock) without any input in Android. Later Android phones must be flagged as unlockable from within developer settings in Android before the bootloader can be unlocked. (I don't believe the bootloaders of either of these devices were ever updated to require authorization from Android, but perhaps I'm mistaken. Certainly as initially shipped, no such authorization was required.)
Perhaps some existing UT devices stem from those later generations that can be effectively relocked? (I don't know, myself.) Then one runs into the problem that to relock the bootloader, one must be sure that the bootloader can handle booting an OS not signed with the manufacturer's keys. Pixels can do this, but many devices cannot.
-
@trainailleur thanks for the detailed response. I see the trouble.
Would there be a way around this, or will phones like the N5 always be with this security hole?
-
@Giiba said in Security of data and passwords when phone is lost/stolen:
Would there be a way around this, or will phones like the N5 always be with this security hole?
Older Android phones with bootloaders unlockable without authorization will always be vulnerable to having encrypted data pulled off-device for attack. EDIT: I was forgetting that unlocking forces a wipe. Thanks to @dobey for the correction.
One could however implement strong encryption with the keys stored in tamper-resistant hardware (pretty sure N5 has hardware key storage), potentially still to be unlocked on-device by a weak-ish PIN. (I sort of glossed over this in my earlier post; should have elaborated more.) That would make an off-device attack significantly harder than with the key stored in regular data partition.
Alternatively, one could use a strong password to decrypt, then a more convenient PIN or passphase for screen lock. This is what I do with the encrypted home hack on Ubuntu Touch and, for that matter, with various encrypted Linux machines. This is a big step down from the state of the art, but it works to a degree.
With an unlocked bootloader though you will always be subject to tampering (a..k.a. evil maid). (Given a sufficiently powerful maid, even a locked bootloader might not be an obstacle, but one can invade tin-foil-hat territory very quickly with that line of thinking.
) -
In addition, currently, there is no mechanism to secure access to data of the micro-sd card for the phones that (will) support it ? Isn't that right ? So after a robbery...
-
@trainailleur said in Security of data and passwords when phone is lost/stolen:
Older Android phones with bootloaders unlockable without authorization will always be vulnerable to having encrypted data pulled off-device for attack.
This is only true if the bootloader is already unlocked, or the device has a bug where unlocking the bootloader does not perform a system reset and destroy all data. Newer devices do not necessarily require "authorization" either, but just have a more complex process where you have to also set an option from within the booted Android system.
-
@dobey said in Security of data and passwords when phone is lost/stolen:
This is only true if the bootloader is already unlocked, or the device has a bug where unlocking the bootloader does not perform a system reset and destroy all data. Newer devices do not necessarily require "authorization" either, but just have a more complex process where you have to also set an option from within the booted Android system.
You're right. Completely forgot that unlocking forced a wipe. Thanks for the correction.
Newer devices do not necessarily require "authorization" either, but just have a more complex process where you have to also set an option from within the booted Android system.
Yes, that process is what I'm referring to when I say unlocking must be authorized from within the stock OS before it can be done to newer devices. (i.e., "must be flagged as unlockable from within developer settings" in the earlier post. I probably should have added the word "manually" before "flagged" to make that clear.)
