7

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?

Specifically:

  • 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)

Community
  • 1
WoJ
  • 8,957
  • 2
  • 32
  • 51
  • Did you mean during an ONline attack (after asking about offline attacks in your [previous question](http://security.stackexchange.com/questions/84120/is-androids-fde-secure-from-offline-attacks))? – Gilles 'SO- stop being evil' Jan 01 '16 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. – Gilles 'SO- stop being evil' Jan 01 '16 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 Jan 01 '16 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). – Gilles 'SO- stop being evil' Jan 01 '16 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 Jan 01 '16 at 22:05
  • Apple makes all the parts on an iPhone, but Google doesn't make all the parts on an Android phone. The part that stores the encryption key isn't made by Google and varies from phone to phone. I still don't understand what you mean by “offline-online”: if the key is in a TEE then you have to go through the TEE (online attack) (you could try an offline attack but unless the crypto implementation is broken it would require brute-forcing a secret key), if there's no TEE then you can brute-force the PIN offline. – Gilles 'SO- stop being evil' Jan 01 '16 at 22:12
  • I mean "offline" when I take the disk off the device and try to decrypt it. This is not feasible as the key is string thanks to the TEE. The "offline-online" one is when you work on the device itself because you need the TEE together with your disk (but via, say, the USB port as it was demonstrated some time ago (using a vuln)). There is also the "online" attack where you type in the PIN every time (which was also done - there is an Arduino-based device which does the typing for you). But the key problem for me is how the throttling is implemented (specifically if via a hardware part which ... – WoJ Jan 01 '16 at 22:18
  • ... one must go though to try decryption. – WoJ Jan 01 '16 at 22:18
  • So is your question about “offline-online” attacks? I'd just call those “online attacks”. In any case, please clarify: as it stands, you seem to be asking about “offline-offline” attacks, except that throttling makes no sense for those. – Gilles 'SO- stop being evil' Jan 01 '16 at 22:31
  • @Gilles: I updated the question, thanks for the comments. – WoJ Jan 01 '16 at 23:37

2 Answers2

4

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.

Community
  • 1
Dori
  • 156
  • 1
  • 6
  • *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 May 27 '16 at 14:10
  • Have edited the above answer - we are using the terms **online** and **offline** in a semantically different way – Dori May 28 '16 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 May 28 '16 at 11:15
  • From the [Android M-6-23 CDD 9.9. Full-Disk Encryption](https://source.android.com/compatibility/android-cdd.html#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 May 28 '16 at 20:20
  • From the [Android M-6-23 CDD 9.11 Keys and Credentials](https://source.android.com/compatibility/android-cdd.html#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 May 28 '16 at 20:25
  • So, it depends if the device has a hardware `KeyStore` or not, which is mandatory in N. In the case where hardware of this kind is present, the software level attack satisfies the definition _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._ for me, regardless of weather the communication to the legitimate system is via local silicon or a remote network. Hope this answers your question :) – Dori May 28 '16 at 20:29
  • The document you linked to is very interesting, thank you. After reading it, it unfortunately does not address the security of the **storage** from the throttling perspective. So the keys must be stored in the chip (good), the screen lock must be throttled (good, but not related to storage) -- which leaved the question whether the storage is protected by throttling. This is not answered in the document so I believe that it is not the case. Thanks again for the links. – WoJ May 29 '16 at 08:31
  • _"it unfortunately does not address the security of the storage from the throttling perspective"_. Well, if the device has a hardware keystore, and the disk encryption key stretching is bound to that keystore then there are three attacks. (1) is to brute force the UI, which is rate-limited, (2) is to call the functions directly, which would be require a rooted system, and should still be rate limited (but probably wouldnt take long) and (3) lift the whole filesystem and decrypt, which may take a while depending on the keystore binding, which i read somewhere was via a 128bit rand in hardware! – Dori May 31 '16 at 11:38
  • So in answer, it seems to me it **does** address security of storage, but not only via throttling. Throttling is important if you can call the keystore api or automate screen input, as pin numbers can be short (4 digits), but less important if you lift the whole disk image which is protected by a 128bits key (baked into hardware) plus some user input (even if short). I think for consumer grade stuff this is pretty good! – Dori May 31 '16 at 11:41
1

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.

codykochmann
  • 277
  • 1
  • 6
  • 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 Oct 28 '15 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. – codykochmann Oct 28 '15 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 Oct 28 '15 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. – codykochmann Oct 28 '15 at 22:53