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. -- Seth Schoen <sch...@eff.org> Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 -- 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
