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.
--
Too many emails? Unsubscribe, change to digest, or change password by emailing
moderator at compa...@stanford.edu or changing your settings at
https://mailman.stanford.edu/mailman/listinfo/liberationtech
