There\u2019s been a lot of hoopla in recent weeks over claims from Apple and Google that user content, stored in the latest iterations of the iOS and Android operating systems, is encrypted in such a way that neither company has the capacity to decrypt the locally stored information.<\/p>\n
Crypto By Default<\/strong><\/p>\n Law enforcement agencies are not happy about this new reality, because it means that even with a warrant, they\u2019ll have no sure-fire way of compelling users to decrypt locally stored data. So they\u2019ve been parading their officials around in a not-so-veiled attempt to scare the public \u2013 surely with common stories of pedophiles and terrorists \u2013 into believing encryption is bad and dangerous<\/a>.<\/p>\n Meanwhile, privacy and security advocates are heralding the new disk-encryption schemes<\/a>, which seem to equip consumers with real mobile data-security.<\/p>\n Some will see these moves as reckless; others will see them as obvious reactions to an environment where it\u2019s become entirely too easy for the government to collect prosecutorial information with little to no oversight.<\/p>\n The newest version of #Google #Android, like #Apple #iOS, will enable full #crypto by default<\/p>Tweet<\/a><\/blockquote>\n We wrote about Apple\u2019s new, default-enabled encryption<\/a> earlier this month, and you can read that article for more on the law enforcement angle. Now it\u2019s time to talk technically about the by-default encryption that Google is touting as part of its newest Android Lollipop, also known simply as \u201cAndroid 5.0\u201d or \u201cAndroid L\u201d (because L is both the roman numeral for 50 and the first letter of the word \u201cLollipop\u201d).<\/p>\n A Brief History of Android Crypto<\/strong><\/p>\n According to Nikolay Elenkov of Android Explorations<\/a>, Android users have had the option to deploy full disk encryption (FDE) since Android 3.0, also known as Honeycomb. Android\u2019s FDE offering then remained largely unchanged until Google fortified it in Android 4.4. They will strengthen that cryptographic system yet again in Android L, but more importantly, they are also turning FDE on by default for the first time in Android 5.0.<\/p>\n The initial encryption scheme deployed by Google in Android was apparently quite secure. However, its implementation in the software, as is so often the case<\/a>, is where weaknesses arise. Particularly, the security of this encryption scheme depends almost entirely on the complexity of the disk encryption passphrase and its susceptibility to brute-force attacks.<\/p>\n http:\/\/instagram.com\/p\/ptPZ2dv0Fj\/<\/p>\n \u201cIf it is sufficiently long and complex, bruteforcing the encrypted master key could take years,\u201d Elenkov explains. \u201cHowever, because Android has chosen to reuse the lock-screen PIN or password (maximum length 16 characters), in practice most people are likely to end up with a relatively short or low-entropy disk encryption password.\u201d<\/p>\n In other words: the strength of the disk encryption on Android was as strong (or weak) as your lock-screen password<\/a>. And in most cases it is really weak because people are too lazy to set long lock-screen passwords.<\/p>\n A built-in rate limiting mechanism made brute-force attacks impractical because an attacker would be locked out after a certain number of login attempts<\/a>. Of course, Elenkov circumvented this protection. If you want to wade into the details about how he managed this, feel free to read his analysis, but we won\u2019t get into that here. The point is: there is a way of brute-forcing weak PINs or passwords in order to decrypt content stored on Android devices.<\/p>\n Again, this attack would be much more difficult to perform against a strong password. But if you have a typical 4 to 6 character password, you can decrypt users\u2019 data literally in only a few seconds.<\/p>\n Hashkill now cracks Android FDE images master password. Speed is ~135k on 6870, ~270k\/s on 7970. Android FDE is weak. pic.twitter.com\/mhcvEuEP48<\/a><\/p>\n \u2014 gat3way (@gat3way) April 28, 2013<\/a><\/p><\/blockquote>\n\n