16

Recently, the new full-disk encryption system of Apple's iOS 8 operating system has been in the news. And soon after Apple's release, Google announced that they will also enable encryption by default in the upcoming version of their Android operating system.

My question is: From the security perspective, are the two systems similar or different (assuming you use the same password or PIN code)? Precisely how does Android's encryption work under the hood?

In more concrete terms: If I use a random 8-lowercase-letter password, which supposedly takes approx. 265 years to brute-force in the case of iOS devices, how safe am I with a similar setup on an Android phone?

For background on the approach that Apple took with iOS 8, see this document. If I understood this right, the key point seems to be that there is a special piece of tamper-proof hardware that contains a device-specific secret identifier. Supposedly, the only way to retrieve the encryption key is to feed your pin code to this piece of hardware, wait for 80ms, and see what comes out. To brute-force this, you will either have to keep entering PIN codes to this single unique piece of hardware (and each attempt takes 80ms, and you cannot parallelise this, as there is just one such chip in the world), or you will have to also brute-force the identifier (which is very long).

How does this compare to what Google (and Android phone manufacturers) are doing with Android phones?

Jukka Suomela
  • 339
  • 1
  • 2
  • 7

2 Answers2

8

Currently, Android's device encryption uses dm-crypt and indeed seems to be susceptible to the kind of brute-force attack you mention, because the PIN/password is more or less directly used to derive the key that decrypts the AES key stored in the volume header.

To protect against such brute-force attacks, the password has to be of sufficiently high entropy (just like on desktop encryption systems). Unfortunately, Android does not allow setting a different password for disk decryption and screen lock. This is only a UI limitation, though: It is easily possible to use a strong password for boot-time disk decryption, but this requires root access.

However, this might all change with Android L – nothing is publicly known right now, but there are suggestions that Android will move to a scheme that uses a "trusted" hardware part, like iOS does.

By the way, the iOS hardware key derivation you describe seems to have been replaced by something else for devices using an A7 SoC (or newer). Apple seems to perform (and rate-limit) the PIN/password verification inside the Secure Enclave, which would theoretically be even more secure. From the document you referenced:

On a device with an A7 or later A-series processor, the key operations are performed by the Secure Enclave, which also enforces a 5-second delay between repeated failed unlocking requests. This provides a governor against brute-force attacks in addition to safeguards enforced by iOS.

You will have to wait for the entire Android L souce code to be released to be sure (and even then, this might be something that will have to be implemented by the device manufacturers), but as of now, some Android devices already support hardware key stores for asymmetric keys; this mechanism seems to be based on ARMs TrustZone exection environment, and might theoretically be extended to device encryption keys, similar to Apple's Secure Enclave concept.

Community
  • 1
lxgr
  • 4,114
  • 3
  • 29
  • 37
  • 3
    It must be noted that the so called 'secure enclave' is a dedicated crypto coprocessor, while TrustZone based solutions run on the main CPU (application processor) and switch between secure and insecure 'worlds' via a CPU instruction. So at this point, iPhone+iOS 8 is more secure. Newer Qualcomm SoCs have some dedicated crypto hardware, not clear whether Android L makes any use of it though. – Nikolay Elenkov Oct 02 '14 at 07:56
  • 2
    @NikolayElenkov why would a crypto processor be less secure just because it's physically located on a CPU die, rather than packaged as a separate chip? I don't see why it should make any difference, with regards to security. – runeks Jun 26 '15 at 22:16
  • 1
    @runeks Actually, the Secure Enclave is also located inside the SoC die. The difference lies in the logical architecture, and arguably only applies to the existing implementations: Apple states that the SE uses encrypted memory; I remember reading that many TrustZone implementations do not, making them vulnerable to certain hardware attacks (e.g. a DRAM emulator). I don't see why a TrustZone implementation couldn't include a hardware key (compare http://dl.acm.org/citation.cfm?id=2541949) and use encrypted memory, though. – lxgr Jun 27 '15 at 22:41
  • 1
    Right, with Apple's solution even data going to/from the crypto chip is encrypted. SoC's used in current Android devices have a built-in crypto core, and also at least one hardware (fused) key, which is used for secure boot, and most probably for deriving other keys used in the TEE (TrustZone). Still, a lot more stuff is done in software (albeit in the SecureOS), so more vulnerable. You can find the FIPS validation documents for Qualcomm Snapdragon 810, etc. if interested. Not much more public info, unfortunately. – Nikolay Elenkov Jul 02 '15 at 03:43
0

The different encryption architectures between Android (block level encryption) and iOS (file level encryption) creates different behaviors when a file is deleted:

  • With block level encryption, when a file is deleted, the filesystem unlinks the blocks from the filesystem but does not actually destroy the data. As most Android devices use NAND flash which contains "wear-leveling" it is generally impossible to actually overwrite specific data so sensitive files can be un-deleted.
  • With file level encryption, the per file key is destroyed when the inode is unlinked causing the now unreferenced data to be effectively destroyed and hence un-deletion is not possible.
ve6yeq
  • 17
  • 1
  • Now that ext4 supports file-based encryption, it will be supported in Android (eventually). It has already been backported to the 3.10 kernel many of the current devices use, Android has some userlevel support for it (in the master branch). – Nikolay Elenkov Jul 02 '15 at 03:37
  • Android 7 is using file based encryption now so same as iOS. – Sealer_05 Sep 06 '16 at 05:03
  • If your inode structure is located in the NAND flash, it is subject to the same wear-leveling routines as any other block, meaning it is potentially recoverable. – Dmitry Grigoryev Jun 27 '17 at 12:54