Search Mailing List Archives
[liberationtech] Android Full-Disk Encryption Cracked
c1.devrandom at niftybox.net
Mon Jun 10 20:08:26 PDT 2013
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:
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
> 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.
> 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
More information about the liberationtech