Apple has a cryptochip which, beside managing the encryption keys, tunnels authentication and provides throttling of failed attempts, as well as the ability to trigger a device wipe after several failed attempts to authenticate. This allows for a reasonable security using a 4 digits PIN.

I did not find any information about the existence of such a hardware mechanism in Android-based devices. The closest could be the TEE (Trusted Execution Environment)

The TEE is a secure area of the main processor in a smart phone (or any connected device). It ensures that sensitive data is stored, processed and protected in an isolated, trusted environment

My understanding is that this is essentially an implementation of a TPM, which only secures the encryption keys, and specifically does not handle the authentication itself.

In that case, how does Android ensure that the throttling of failed authentication attempts is not by-passed during an offline attack?


  • decryption of a bare disk extracted from the device is not possible (the key generated by the TEE is robust)
  • decryption of a disk in the device with the help of the TEE must be protected against - via throttling or wipe after a given number of attempts.

A description of the implementation of the latter is what I am looking for.

Note: I am aware that there are security bugs which help to bypass a security setup. This happens everywhere and on every device and is hopefully fixed with patches. This is not the subject of my question - I am specifically interested in hardware mechanisms designed to protect against seemingly insecure authentication mechanisms (which a 4 digits PIN, in the absence of these systems, would be an example of).

EDIT: also see this answer about TEE itself (as a complement to the question above)

  • Did you mean during an ONline attack (after asking about offline attacks in your previous question)? Commented Jan 1, 2016 at 21:00
  • And BTW the literal answer is “N/A”, because you're comparing apples and citruses. Different Android devices have different TEEs or none at all. Commented Jan 1, 2016 at 21:02
  • @Gilles: I do no understand 'N/A' (Not Applicable). What is not applicable? Android devices (as you mention) may differ in how TEE is implemented but I do not know which mechanism (and its hardware implementation) handles throttling during an offline attack.
    – WoJ
    Commented Jan 1, 2016 at 21:08
  • Uh? By definition, an offline attack isn't subject to throttling. An offline attack is carried out against data (copied off-device), not against a system (running on the device). Commented Jan 1, 2016 at 21:54
  • @Gilles: On a iPhone you get an encrypted disk which is encrypted with a strong key, even if you only use a PIN. a "pure offline" attack (= trying to break the key) is not feasible, you have to go though a "offline-online attack" (=proceed though the crypto chip). This crypto chip ensures throttling which makes a PIN a good protection (otherwise you would just have at most 10k tries, which would be trivial to do). I am trying to understand how the mechanism is implemented on Android devices.
    – WoJ
    Commented Jan 1, 2016 at 22:05

2 Answers 2


how does Android ensure that the throttling of failed authentication attempts is not by-passed during an offline attack?

Android KeyStores can be hardware or software based previous to android N, which has made hardware KeyStore a MUST in the CTS.

EDIT: In the below I am using the term online attack as something with the property

Online entities can perform additional security checks to make a protocol more safe. For example, an online entity can regulate the number and speed of login attempts (from another SO q)

...rather than being conducted over a remote network. Maybe I am not using it in the common way but to me the interesting property about online attacks is that there is a layer between the attacker and the data being attacked which is not under the attackers control. Whether this layer is a remote webserver or some local hardware does not make much difference in this case, as both can perform rate-limiting, unless the physical chip is attacked / inspected, which would be a completely different class of attack.

This SO answer actually has a definition closer to the one I am using

An online attack tries automated routines providing input to a legitimate system. They are not looking to create an exploit in functionality, but to abuse expected functionality.

An offline attack attempts to emulate the encryption/hashing and requires a known output of that process (i.e., you don't attack the system, you already have the hashed/encrypted password)

If hardware based, private keys should be extractable from the KeyStore without a sophisticated physical attack (maybe an electron microscope or some black box vuln exposed by the TEE/TPM. This is an online attack. You would hope the TEE/TPM implements throttling.

EDIT: I just tested the nexus 6p KeyStore impl and no throttling takes place for general Cipher operations (was seeing if a padding oracle was exposed for RSA). I have not tested KeyStore rate-limiting for the main unlock however.

If software based then with root, the KeyStore blob can be lifted and potentially bruteforced. This is an offline attack and no throttling can take place.

In answer to your question, it cant ensure throttling of an offline attack, by its very nature.

  • it cant ensure throttling of an offline attack, by its very nature. - you mean by the nature of the attack or the implementation? Because you can throttle an offline attack if you require a chip on the way (which hold the keys and manages the throttling) - this is how it is done on the iPhone.
    – WoJ
    Commented May 27, 2016 at 14:10
  • Have edited the above answer - we are using the terms online and offline in a semantically different way
    – Dori
    Commented May 28, 2016 at 10:02
  • Thanks. The thing is that there is no online attack on a phone per se: there is no service which exposes the authentication (as opposed to, following the link you mentioned, a web application). The case is always the worst one: you have the phone and have access to everything inside, included the drive. This drive is encrypted. The question is whether the keys are always protected by a TEE/TPM - in which case this chip can provide throttling when trying to extract the keys. This is what happens in an iPhone and this is why bruteforce attacks on the storage fail.
    – WoJ
    Commented May 28, 2016 at 11:15
  • From the Android M-6-23 CDD 9.9. Full-Disk Encryption "If the device provides a hardware-backed keystore, the password stretching algorithm MUST be cryptographically bound to that keystore."
    – Dori
    Commented May 28, 2016 at 20:20
  • From the Android M-6-23 CDD 9.11 Keys and Credentials "The lock screen authentication MUST rate limit attempts and SHOULD have an exponential backoff algorithm as implemented in the Android Open Source Project." and "MUST perform the lock screen authentication in the secure hardware if the device has a hardware-backed keystore implementation and only when successful allow the authentication-bound keys to be used. "
    – Dori
    Commented May 28, 2016 at 20:25

The closest that I know of is Google's project vault. It's a system that has a secondary CPU inside a locked down SD card which performs all of the sensitive processes and key handling. Google hopes to cook the system into androids APIs so any android device with an SD card reader can use the chip.

There are some companies that are claiming that they're doing the same thing but with researchers still finding flaws in those systems, this looks like the most promising avenue to provide strong security for android so far.

  • The TTE I mentioned does this as well. The point is that these systems (...) ensures that encryption keys and other secure data can never be accidentally leaked to the untrusted host device. This does not handle the throttling concern I referred to in bold in my question.
    – WoJ
    Commented Oct 28, 2015 at 21:31
  • To answer the bold question specifically, it's equivalent to it as a chicken is equivalent to a turkey. Technically, both work as a dinner of meaty bird for multiple people while at the same time they're not the same species. In this case they both accomplish the same thing and both are proven to work, they just work differently. There are a lot of people challenging project vault and most of the challenges are answered thoroughly and those that weren't are being solved with Google's work towards building it into android. As for current production systems, nothing has been openly proven. Commented Oct 28, 2015 at 22:03
  • I do not understand. How is that linked to throttling capabilities when handling authentication? You mention an interesting project to manage encryption keys, akin to a TPM.
    – WoJ
    Commented Oct 28, 2015 at 22:13
  • Take this portion with a grain of salt because I only gave it the amount of attention that a project that has not come to market yet actually deserves. If I remember correctly, the argument against the card being brute forced was the other discovery that they were trying to push forward which authenticated the devices user by compiling metrics such as the natural shaking in your hand, how you like to hold your phone, and the interval at which you type certain characters. Basically, the project is trying to get away from the pin by collecting as much data as they can from only common sensors. Commented Oct 28, 2015 at 22:53

You must log in to answer this question.

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