[liberationtech] Android Full-Disk Encryption Cracked

[Dev Random]

It's important for the data-at-rest password to have lots of entropy.
But using a long password for unlocking the screen annoys the user, and
they will choose a shorter one. Therefore it's important to separate them.

See this open source app to set them separately:
https://play.google.com/store/apps/details?id=org.nick.cryptfs.passwdmanager

The screen unlock password is used for authentication while the OS is
running, so throttling is enough to defend against password guessing.

On 04/29/2013 12:09 PM, Seth David Schoen wrote:
> Griffin Boyce writes:
> 
>> Hashkill can now determine the master password for Android's full-disk
>> encryption scheme.
>>
>> image showing the process: http://i.imgur.com/bFUf7lR.png
>> script: https://github.com/gat3way/hashkill
>>
>> Thoughts?
> 
> It seems like this is just a tool for doing dictionary and
> brute force attacks against these passwords, not a class-break
> that is inherently able to decrypt every single Android device.
> 
> So, if your Android FDE passphrase is long and unpredictable
> enough, this tool should still not be able to crack it.
> 
> There are a lot of problems about disk encryption on small
> mobile devices.  One that was highlighted by Belenko and
> Sklyarov at Black Hat EU 2012 is that mobile device CPUs are
> relatively slow, so it's difficult to do very large numbers of
> iterations of key derivation functions, which would make
> brute-force cracking slower.
> 
> http://www.elcomsoft.com/WP/BH-EU-2012-WP.pdf
> https://en.wikipedia.org/wiki/Key_derivation_function
> 
> The more KDF iterations that are used, the slower _both_
> unlocking by the legitimate authenticated user and offline
> cracking will be.  But if the legitimate user's device has
> a slow CPU, the user may not accept the human-perceptible
> delays that would result from using a lot of iterations.
> 
> This tradeoff is a pretty fundamental problem.  The user
> wants to unlock their device using a very short, easy-to-
> remember code.  They want the device to be able to unlock
> quickly when this code is entered, using information that
> can be calculated from the code in a short time on a
> comparatively slow mobile CPU.  Then they also want someone
> with a very fast cracking device like a desktop GPU not to
> be able to brute-force that same code quickly.
> 
> Belenko and Sklyarov also observed that some mobile crypto
> applications were just not using KDFs at all or were using
> them improperly, but I don't know of an indication that
> that's true of the official Android FDE.  Another problem
> is that, especially if people are using touchscreens, they
> may want a very short unlock PIN rather than a long
> passphrase, which will inherently favor cracking.  (For
> example, if you imagine a system with a 5-digit numeric
> PIN, you can quickly conclude that there is no number of
> KDF iterations that will be acceptable to the mobile device
> user and be a practical deterrent to a brute-force attacker
> with even a single desktop GPU, at least for KDFs that can
> be implemented efficiently on a GPU.)
> 
> I don't think this problem is very well appreciated by
> mobile device crypto users!
> 
> Two ways to address this that come to mind would be using
> tamper-resistant hardware (which apparently Apple is doing
> for crypto in iOS devices) to store or generate the
> decryption keys using cryptographic secrets kept inside
> the particular device itself, and finding some way for
> the user to somehow input a much higher entropy unlock
> password.
>