13

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.

Improve this question

2 Answers 2

Reset to default
10

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.

Improve this answer
12
  • @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.
    – eldarerathis
    Feb 18, 2016 at 3:33
  • 1
    @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
    Feb 18, 2016 at 4:44
  • 1
    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)?
    – Bob
    Feb 18, 2016 at 4:46
  • 1
    @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
    Feb 18, 2016 at 15:08
  • 1
    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.
    – eldarerathis
    Feb 18, 2016 at 15:09
-1

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.

Improve this answer
2
  • Are you aware of the limitation of screen lock PIN length? Consider rebooting your answer accordingly
    – beeshyams
    Feb 24, 2016 at 9:37
  • Yeah, 16 characters is the limitation if you check the source code.
    – Firelord ♦
    Feb 24, 2016 at 9:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .