By malexdev

2016-02-17 22:57:01 8 Comments

Apple recently made waves within the tech community by refusing to comply with law enforcement in regards to accessing encrypted user data. Their statement was that they do not have the technical ability to decrypt this data.

As an Android user, is there any similar possibility (preferably built in to the OS instead of third party) that I can use to achieve similar protection from even Google and my device manufacturer? I know there is the "Full Device Encryption" in my settings, but does this prevent Google etc. from accessing it?

For reference, my device runs Android Lollipop and is a OnePlus Two. If other versions like Marshmallow would allow me to do this that's fine.


@Andrew Brown 2016-02-24 09:22:03

Full device encryption will protect your device if you use a key too long to brute force, even when the attackers are able to use brute force techniques -- assuming there are ways to allow them to do this. Snowden says 64 characters is long enough for truly unbreakable encryption. So complete security is attainable - if you don't mind typing in a 64 character passphrase every time you wake the phone.

@beeshyams 2016-02-24 09:37:02

Are you aware of the limitation of screen lock PIN length? Consider rebooting your answer accordingly

@Firelord 2016-02-24 09:38:55

Yeah, 16 characters is the limitation if you check the source code.

@eldarerathis 2016-02-18 01:30:44

Google has no idea what the encryption key for your device is. The entire process takes place on your device and the key is never transmitted anywhere. The key itself is also not stored in plaintext on your device:

Storing the encrypted key

The encrypted key is stored in the crypto metadata. Hardware backing is implemented by using Trusted Execution Environment’s (TEE) signing capability. Previously, we encrypted the master key with a key generated by applying scrypt to the user's password and the stored salt. In order to make the key resilient against off-box attacks, we extend this algorithm by signing the resultant key with a stored TEE key. The resultant signature is then turned into an appropriate length key by one more application of scrypt. This key is then used to encrypt and decrypt the master key.

So even if someone had a copy of your encrypted master key, they could not decrypt it without the TEE key from your device's SoC.

Therefore, outside of a flaw in the implementation, full device encryption will prevent anyone from accessing your data unless they know/obtain your password OR can guess your password (e.g via brute-forcing it or some kind of social engineering techniques). On devices that lack the necessary hardware-backing, FDE will attempt to encrypt the key using a software-only method.

@eldarerathis 2016-02-18 03:33:55

@beeshyams It's a feature of the processor. ARM's implementation is called "TrustZone", but other architectures also provide similar mechanisms. The idea is that you can generate a device key, store it in a place only accessible to the TEE, then never reveal it to the outside world. When you need to encrypt/decrypt something, you ask code running in the TEE to do it for you, so the key remains secure. Wikipedia has a decent(-ish) article.

@Bob 2016-02-18 04:03:53

How well does this protect against brute-force attacks via modified firmware? Does it prevent firmware updates without decryption? Apparently that's the current potential attack vector for iOS (prior to iPhone 6). Would be good to have that answered for Android too. Keeping a device-local TEE key is all well and good, but it's weakened if attackers have the ability to load/boot a vulnerable version of firmware.

@beeshyams 2016-02-18 04:27:19

@eldarerathis: Thanks. IMO it requires more understanding. Drafting a bounty question. You may like to answer, provided it does not get shot down :)

@eldarerathis 2016-02-18 04:39:40

@Bob The encrypted data itself couldn't be decrypted by a ROM update alone. You would still need the key (I'm not sure if that was what you meant by your second question?). As for flashing a weakened ROM, as long as the device's bootloader is locked it would be basically the same as the iOS situation - only OEM signed updates will install. Also, unlocking the bootloader to try to flash an unsigned image would wipe the device.

@Bob 2016-02-18 04:44:52

@eldarerathis What I've heard is that iPhone 6 and newer are safe from even OEM updates, as the password verification (including the timed delay/lockout) are implemented entirely in hardware. What I'm asking is whether Android does something similar, or if it's purely a software lockout - which can of course be bypassed by a firmware update. I'm also asking if there exists any Android-based phones with bootloaders that refuse updates without the user-specified passcode being entered - which would make bypassing software lockout periods easier.

@Bob 2016-02-18 04:46:50

Yet another way of rephrasing is whether there is a way to require that decryption (w/ user password) occurs before updates are allowed. In other words, are (OEM, signed) updates installable by without the decryption key (without a compulsory wipe of user data)?

@eldarerathis 2016-02-18 15:08:45

@Bob To my knowledge, Android does not require the decryption password to perform the update process, because it only encrypts the /userdata partition, not the partitions that the update would actually be modifying (/system and /boot, generally). It's pretty much in the same boat as the iPhone 5 (and lower).

@eldarerathis 2016-02-18 15:09:32

I would add, I'm not sure if the general delay per attempt is something that can be "disabled" by an update, or if Android scales it artificially. Android uses scrypt rounds during the key generation process, so it would need to be used when decrypting the key as well, and scrypt is designed specifically to be difficult to speed up, as a mitigation against brute-forcing. That much would remain consistent. A lockout after X number of failed attempts (or a scaled lockout, if one exists) would be implemented in software, though, AFAIK.

@Bob 2016-02-19 02:30:18

Thanks. Also, relevant: apparently on iOS it might be possible to update the "Secure Enclave" firmware without knowing the passcode and without losing the keys. Assuming that's true, at the end of the day the same vulnerability (to OEM-signed updates) applies to both Android and iOS. Perhaps Android is more secure by virtue of allowing longer passwords, though that depends on the user and would be quite inconvenient.

@Andrew Brown 2016-02-24 09:18:08

Bob, I suspect that "implemented in hardware" is misleading. What actually happens is that these protections are implemented in firmware, and that firmware can be updated. The alternative would be that there was no way to fix bugs in it, such as the "Error 53" problem in iPhones. Bruce Schneier refers to this as a "security hole" but arguably that's stretching the definition of "security hole" too far. Obviously the firmware can only be updated if you possess the OEMs keys. We know those keys leaked for the Stuxnet worm (as Schneier points out) and they might for Apple or Google products too.

@user4951 2016-03-06 00:04:40

will rooting the device allows anyone without the OEM keys update the firmware?

@eldarerathis 2016-03-07 02:34:07

@JimThio Probably, but only if you had access to the system or ADB while booted. Otherwise you'd have no way to actually make use of the root permissions. Alternatively, a custom recovery would allow you to update the firmware.

Related Questions

Sponsored Content

1 Answered Questions

[SOLVED] How does rooting affect full disk encryption (Oneplus 3T)?

1 Answered Questions

[SOLVED] Security of Android cryptography in versions < 5.0 against government agencies

  • 2014-11-11 14:04:44
  • usr-local-ΕΨΗΕΛΩΝ
  • 116 View
  • 1 Score
  • 1 Answer
  • Tags:   security encryption

1 Answered Questions

[SOLVED] Android 4.1.2 Full Device Encryption

1 Answered Questions

How do I keep my email and passwords secure without full-device encryption?

2 Answered Questions

[SOLVED] Does Android's Full Filesystem Encryption also Encrypt the SDcard?

1 Answered Questions

Sponsored Content