Re: [liberationtech] Android Full-Disk Encryption Cracked
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
Re: [liberationtech] Android Full-Disk Encryption Cracked
Keep in mind this is just brute-force. It's pretty fast but this has always been possible, if slower. NK On Mon, Apr 29, 2013 at 2:46 PM, Griffin Boyce griffinbo...@gmail.comwrote: 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? ~Griffin -- #Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de -- 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 -- 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
Re: [liberationtech] Android Full-Disk Encryption Cracked
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
Re: [liberationtech] Android Full-Disk Encryption Cracked
Seth David Schoen sch...@eff.org wrote: 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. Yubikey combined with a short user password is a potential option for the second idea, with devices that have USB Host mode: https://guardianproject.info/2012/01/04/strong-mobile-passwords-with-yubikey-usb-token/ -- 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
Re: [liberationtech] Android Full-Disk Encryption Cracked
To add to the list of issues here, crypto implementations on mobile devices may be vulnerable to power analysis side-channel attacks. Attackers may be able to measure RF signal strength to infer power consumption during crypto operations, then derive key material. I think Cryptography Research Inc. has been researching these attacks and working on countermeasures. On Mon, Apr 29, 2013 at 12:09 PM, Seth David Schoen sch...@eff.org wrote: ... 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. -- 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
Re: [liberationtech] Android Full-Disk Encryption Cracked
We did some work on power analysis sidechannels. The NSA solution is to physically isolate anything that does crypto from anything else. Separate power supplies and Faraday cages are used. This is effective, but not practical for mobile devices. Another alternative is to use dual rail instructions in hardware, for each computation in the code, it also computes the complement. This produces a flat power consumption profile, but consumes 1.9 times the power and produces 1.9 times the heat. We added compiler support where secret variables (ex. crypto key) had tags marking them as secret. Then instructions that used this data, or anything derived from them, would use the dual rail instructions. This consumes 15% more power than normal. Other people try to just add random fluctuations to the power consumption profile. That never works. You just have to increase the amount of data that you collect. You would be amazed at how many people try to pass this off as an effective solution. The power analysis attack(especially differential power analysis) is really easy to do. We gave the grad student a paper. He had the attack running after about 1 day of work. On 04/29/2013 03:29 PM, Steve Weis wrote: To add to the list of issues here, crypto implementations on mobile devices may be vulnerable to power analysis side-channel attacks. Attackers may be able to measure RF signal strength to infer power consumption during crypto operations, then derive key material. I think Cryptography Research Inc. has been researching these attacks and working on countermeasures. On Mon, Apr 29, 2013 at 12:09 PM, Seth David Schoen sch...@eff.org mailto:sch...@eff.org wrote: ... 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. -- 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 -- === R. R. Brooks Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University 313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA Tel. 864-656-0920 Fax. 864-656-5910 email: r...@acm.org web: http://www.clemson.edu/~rrb -- 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
Re: [liberationtech] Android Full-Disk Encryption Cracked
Nathan of Guardian writes: Yubikey combined with a short user password is a potential option for the second idea, with devices that have USB Host mode: https://guardianproject.info/2012/01/04/strong-mobile-passwords-with-yubikey-usb-token/ That's pretty awesome, and very creative. I hope people will pay attention to this sentence in your post: By combining the long password from the Yubikey with a short memorized version, a certain amount of security is preserved even if the key is physically stolen along with your mobile device. So users shouldn't skip the short memorized password part! (In that scenario, the security level is probably reduced to the length of the user password. One could imagine a future Yubikey using NFC in an interactive protocol in a way where this is no longer true, but maybe tamper-resistant key storage inside phones is likely to come about sooner.) -- 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
Re: [liberationtech] Android Full-Disk Encryption Cracked
Hi Richard. Your grad student's experience corroborates what I've heard from other researchers. Simple power analysis attacks are easy to conduct against mobile devices in a lab environment. On Mon, Apr 29, 2013 at 12:56 PM, Richard Brooks r...@acm.org wrote: The power analysis attack(especially differential power analysis) is really easy to do. We gave the grad student a paper. He had the attack running after about 1 day of work. -- 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
Re: [liberationtech] Android Full-Disk Encryption Cracked
While defending against side channel attacks like power analysis is desirable, and key stretching can be used to slow down cracking... there's a much simpler win that can be done right now, much more easily that using a Yubikey. Android *NEEDS* to allow a user to have a separate unlock screen password from the disk password. Most users are wholly unwilling to have a long screen unlock password, but willing to have a long boot password. They need to be decoupled. There is no technical reason this is not possible (as demonstrated) - it's just usability concerns and UI. This issue is at https://code.google.com/p/android/issues/detail?id=29468 and I encourage you to star it to vote for it. -tom -- 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
