News has recently bring attention on mobile phones encryption policies, particularly through the Apple vs. FBI case. The FBI unsuccessfully tried to force the firm to decipher the phone used by a terrorist. This article will aim at making an overview of the different encryption methods used by major mobile operating systems.
Apple phones are encrypted by default since iOS 8, the current version being iOS 9 (which keeps the same encryption policy). By the control that Apple has on the hardware as much as the software of its phones, it can easily develop advanced encryption capabilities without fear of compatibility default. This control also allows the massive deployment of new updates, which explains that 79% of iPhones run with the latest version of iOS, and 16% with the second last, bringing to a total of 95% of encrypted iPhones 1.
All Apple devices with an A7 or higher processor integrate a coprocessor specialized in the management of cryptographic keys and cryptographic operations. This coprocessor, called Secure Enclave, uses its own secure boot sequence and has personalized software updates, different from the application processor ones. Its microkernel is based on a modified version of L4 and its memory is encrypted, as well as the communications it has with other system components (including the Touch ID).
The iPhone 3GS and above, the iPod Touch 3rd generation and higher and all iPads2 have an AES 256 encryption chip located on the DMA path (Direct Memory Access) between the flash storage and the main system memory 3.
Each phone or tablet is assigned a unique identification number (UID), which is a 256-bit AES key integrated to the Secure Enclave coprocessor when manufacturing the device, which cannot be read by any software or firmware: only the AES module can read it. In principle, it is neither known by Apple nor any of its subcontractors. It is also protected against physical attacks by a silicon layer. This key is always used for cryptographic operations, which is why Apple is not able to decipher one of its phones.
In fact, any encryption operation done on the phone will be made using a randomly generated key, itself encrypted with a key derived from the UID (named "key0x89b"), which means that a bruteforce attempt will have to be made directly on the device itself. Indeed, moving the storage chips will compromise possibilities of decrypting the files because of a different or nonexistent UID.
Furthermore, any encryption keys generated on the device are forged using the physical random number generator which uses an algorithm based on CTR_DRBG (Counter Mode Deterministic Random Byte Generator4, standardized by the NIST5). This RNG is present within the Secure Enclave.
When configuring the passphrase of the phone (which unlocks the mobile, this lock being optional), iOS automatically activates the "Data Protection" service. This feature enhances the security of the physical cryptographic module by encrypting some keys of this physical module with the passphrase, increasing the entropy of the keys. The passphrase can consist of 4 or 6 digits, or alphanumeric characters without limitation. This passphrase is correlated with the UID to provide more robust encryption keys.
To limit the risks of bruteforcing the passphrase, Apple has implemented some security measures, including a minimum time of 80 ms between each keystroke. There is also a time to wait between attempts, summarized in the following table:
|1 – 4||None|
Note that for devices with an A7 or higher processor, count is not canceled by restarting the device, if it is done within a specified time, which prevents bypassing the waiting time. This function is provided by the Secure Enclave.
It is also possible to activate a feature that automatically erases phone data (including encryption keys) after ten consecutive bad attempts.
Apple assures that with a passphrase consisting of 6 alphanumeric characters (uppercase and lowercase), the time required to unlock the phone by bruteforce is 5 and a half years.
A more detailed vision of the encryption architecture is available in the following guide.
However, even if data is encrypted on the phone, some of it can also be stored unencrypted on iCloud. Data stored encrypted in the cloud of Apple (such as automatic backups) are encrypted by a key whose Apple holds a copy6. Apple would like to change this method in order not to be able to provide any information whatsoever to law enforcements demanding it7.
In the case between Apple and FBI, it seems that the Israeli company Cellebrite, specialized in the extraction of mobile phone data, has helped the US government agency to recover data from the iPhone 5C belonging to a terrorist .
Since 2011, the encryption is provided by Google, the user being free to activate it. In 2014 and the release of Android 5.0, the encryption is enabled by default even if the final configuration is left to the discretion of the manufacturer. In fact, the function is often turned off for performance reasons, manufacturers contradicting the results of the tests conducted by Google that showed minimal impact on performances.
Since 2015 and the arrival of Android 6.0, encryption becomes mandatory above a certain level of material performance (encryption / decryption speed upper than 50MiB / sec8). This means that entry level phones are not affected by the measure. The SD card data may also be encrypted with the rest of the system 9.
Note that some manufacturers enhance Android security, for example Samsung Knox (for professionals) who can use a secure element in the phone and SD card.
In general, Google is not able to decipher an Android phone.
Due to the diversity of manufacturers and alternatives ROM, very few Android phones are encrypted today, less than 10% according to experts. This is not surprising given the fact that only 2.3% of devices runs on the latest version of Android yet launched in October 2015 10.
From a technical perspective, the Full Disk Encryption feature, which ensures encryption of the phone, uses dm-crypt. Encryption must be at least in 128 AES, as well as the encryption of the key itself.
The encryption process for a new phone can be summarized as follows:
The full documentation that describes the encryption process, including the one for an already configured phone, is available here.
Researchers have shown a few years ago that a cold boot attacks were possible on Android phones, allowing to recover encryption keys and the RAM content using the FROST tool11.
Bruteforcing the encryption PIN is also possible12.
With Windows Phone 8 and 8.1, the encryption of the phone is only possible through an Exchange server (internally or using a solution like Microsoft Office 365), and selecting the appropriate security policy. Encryption is offered more as a profesionnal feature, although the Exchange infrastructure does not seem to need being explicitly deployed in a professional setting to offer the possibility of encryption.
Through an Exchange service supplied by Microsoft, a spare key available to decrypt the device. If the solution is deployed internally, Microsoft has not the possibility to decipher.
In all cases, the encryption is performed by Bitlocker.
There is not much information on Windows 10 Mobile security. Encryption is possible for all users, and is deployable in an application using an enterprise MDM (mobile device management).
Windows 10 Mobile Enterprise provides flexibility in the possibilities of encryption, leaving to the administrator the choice for the encryption policy, the algorithm or the key size13. If Bitlocker is used, the encryption will be processed by default with a 128-bit AES key.
A list of all policies is available here.
In all cases, data on the SD card is not encrypted by these security systems, as it is with Android.
12 An example among others: http://cyborg.ztrela.com/android-bruteforce-encryption.php/