Identification Security & Identification Security Blog Technology

The Tiny Difference Between iOS & Android Security Is Hardware

Android Smartphone

Business emails, private photos and important documents – users tend to store sensitive data on their smartphones creating the need for privacy and security solutions on the devices. Therefore Apple and Google protect your data with full disk encryption (FDE) on iOS and Android products.

This protection of all data stored on our phones is usually achieved by using a passcode which you need to enter to unlock the device. To the user the solutions of Apple and Google appear very similar. On both systems it is possible to set up a personal password (4 or more digits/letters or swipe patterns) which is part of a key derivation function (KDF).

However there are some differences between the two systems regarding the FDE implementation in the soft- and hardware. Security researcher Gal Beniamini lately exposed some of those differences and the resulting security issues for Android devices equipped with Qualcomm chipsets on his blog “Bits, Please!”.

The uncovered vulnerability of Android devices can be attributed to one main difference compared to iPhones: the missing secure hardware element as part of the KDF.

Why Apple’s Security Scheme Gets Even The FBI Troubled

In order to fully understand how hardware helps Apple to secure devices up to a level where even the FBI struggles to access the smartphones from the Silicon Valley company let’s assume we would want to hack one.

The first method that comes to mind is using sheer brute force attacks. This is a valid approach since most smartphone owners choose comparably weak passwords on their devices to be able to unlock them easily.

However in order to crack the user’s password in a feasible timeframe you would need to use special equipment to try different combinations as fast as possible. This is prevented by Apple using the secure hardware element. Each device is equipped with an immutable 256-bit unique key called the UID which is randomly generated and fused into the device’s hardware at the factory. The way the key is stored in the hardware prevents access via software and firmware as it can only be set as key for the AES engine. Thus even Apple could not access it once it is set.

This device specific key is used in combination with the user password to generate the encryption key used in the FDE (see graphic below for Apple’s FDE KDF).

Apple’s FDE KDF (image: Apple iOS Security White Paper | May 2016)
Apple’s FDE KDF (image: Apple iOS Security White Paper | May 2016)


For the hacker this creates a huge problem, as this means that brute force attempts need to be executed on the Apple device and can not be performed on special hardware instead. This principal allows Apple to use several defence mechanisms that make cracking the passcode nearly impossible. Introducing a 80 milliseconds delay into the key derivation extends the approx. time necessary to crack a 4-character alphanumeric password to about two weeks and makes hacking longer passwords completely unfeasible.

Additional incrementally increasingly software delays between every password guess along with the option to erase all of the information stored on the device after 10 failed password attempts make hacking the Apple devices nearly impossible (however it is possible to bypass the software protection – if you’re interested in details read Dan Guido’s post about the technical aspects of Apple v. FBI or take a look at the iOS Security Guide).

Android Security – Good But Not Good Enough

The Android FDE works in a similar fashion to Apple’s. It is based on a robust encryption scheme (using  a Linux Kernel subsystem called dm-crypt). As described in the Android Security Guide user data is protected by a randomly-chosen 128-bit master key (device encryption key, DEK) and a 128-bit randomly-chosen salt. The DEK is encrypted by a key which is derived using the user’s provided unlock credentials in an an elaborate key derivation scheme.

The encrypted DEK is stored inside the crypto footer. In order to decrypt the disk the user passcode and salt are applied in the KDF, using the resulting key to decrypt the DEK which is then used to decrypt the user data (see graphic below).

Android Disk Encryption
Android Disk Encryption (image: Gal Beniamini)

Hacks performed on the Android device are prevented with delays similar to the scheme of Apple. In order to prevent off-device brute force attacks using specialised hardware the DEK is bound to the device’s hardware. This is done using an application called KeyMaster (part of Android’s Hardware-backed Keystore).

The concept principally protects crypto keys generated by applications as the KeyMaster module runs in a Trusted Execution Environment (TEE). This environment is completely separate from the Android OS. In other words the KeyMaster module is used to generate encryption keys and to perform cryptographic operations on them without ever revealing the keys to the smartphone OS.

Keys generated by the KeyMaster are encrypted using a hardware-backed encryption key and returned to the OS. Whenever an operation is intended to be performed using the generated (encrypted) keys they need to be supplied back to the KeyMaster. The KeyMaster module decrypts the stored key, performs the operation and returns the result.

As all operations are executed without ever revealing the cryptographic keys all crypto operations must be executed by the KeyMaster on the device itself.

Sounds good so far. However, Beniamini found a way to break into the Trusted Execution Environment of Qualcomm chips called QSEE (Qualcomm Secure Execution Environment). In this environment small applications called Trustlets are executed via a dedicated secured processor. One such Trustlet is the KeyMaster application.

What does this mean for the user? By reverse-engineering the KeyMaster module it is possible to access the DEK. This in turn means that brute-force attacks could be performed off the device on specialised equipment (e.g. a server cluster). Consequently security of user data on Android phones equipped with Qualcomm chips (approx. 50% of devices) is significantly reduced.

Even though the problem has been patched by Google it is still possible to obtain the encrypted disk image (e.g. by using forensic tools) and then to downgrade it to a vulnerable version according to Beniamini.

Hardware Beats Software Security

In conclusion this means that key derivation is not hardware bound and thus access to the FDE is definitely easier to achieve than if the key could not be extracted by software.

The case above is only one popular example for security issues created through missing crypto hardware. Using a secure element could prevent the extraction of encrypted images from Android phones and thus also the hacking on off-device hardware.

As semiconductor manufactures offer more and more easy-to-use security chips it gets increasingly feasible to implement crypto hardware even for smaller companies. If you need assistance with your products and security concepts feel free to approach EBV here to get full support and access to state-of-art hardware and take a look at our Identification Website here.