Slashdot Mirror
Google Makes Full-Disk Encryption Mandatory For Some Android 6.0 Devices (itworld.com)
itwbennett writes: Google's plan to encrypt user data on Android devices by default will get a new push with Android 6.0, also known as Marshmallow. Devices with enough memory and decent cryptographic performance will need to have full-disk encryption enabled in order to be declared compatible with the latest version of the mobile OS. From the ITWorld article: "The move is likely to draw criticism from law enforcement officials in the U.S. who have argued over the past year that the increasing use of encryption on devices and online communications affects their ability to investigate crimes. In addition to encryption, Google also mandates verified boot for devices with AES performance over 50MB/s. This is a feature that verifies the integrity and authenticity of the software loaded at different stages during the device boot sequence and protects against boot-level attacks that could undermine the encryption."
The terrorists and criminals have won :(
Do you have ESP?
Does anybody even proofread these summaries? What, precisely, is the point of a link from the words "need to have full-disk encryption enabled" to a page that doesn't mention the word encryption even a single time?
Google also mandates verified boot for devices with AES performance over 50MB/s.
Who verifies it?
Google verifies it (with NSA consent)?
Or is it completely, 100% open source such that I can compile my own boot loader and sign it with my own key and install it myself?
Anything else really just means that the NSA have a backdoor to your device that you cannot remove because your boot loader is locked against you.
...they'll have already done what I do the instant the battery is over 85% charged (with my current Nexus 5, that's right out of the box).
Seeing as most people are NOT criminals, we have every right to encrypt our data and keep it out of the police's hands. This being said, it would be logical to take this right away from digital offenders (child porn, people selling prostitutes, etc) in order to prevent continued offenses. I fully support encryption getting better and better, because increasing amounts of our lives are on our devices. Not encrypting is a lot like leaving our door unlocked and putting a sign up for thieves that says "Come get free stuff"
First Apple and now Google are pushing back on the US government, which is trying its hardest to spy on people. These companies are compelled to give up information, in secret, without warrants, due to PATRIOT Act and other government "intelligence". This has hurt business for Apple, Google, Microsoft, and others. It seems that they've decided that they are going to make it hard/impossible for the US government to steal their customers' data. Bravo to them.
I'm gone a bit too cynical to think this is an altruistic effort by Google to protect De People from the government spying on them. Could it just be an attempt to make their DRM more robust?
Google will surely "do the right thing" and keep their encryption keys for easy government decryption.
Thanks, but I'll stick with my iPhone.
Though this is a welcome move, Google has its priorities totally wrong.
As it stands right now, a large percentage of the Android population is running insecure software which, in some cases, is remotely exploitable without user intervention, with no way to mitigate the risk.
This is utterly embarrassing for Android if you think about it. Here we have a (mostly) open source stack that is MUCH LESS secure than its most significant opposition - Apple, which is closed source and absolutely restricted - but we can't do anything about the vulnerabilities because someone in the supply chain decided that it isn't cost-effective to provide something as simple as root access to the OS.
This is partly the manufacturer's and carrier's fault, but it is very much also Google's fault.
If I understand correctly, Google has a set of conditions that manufacturers must meet to be able to ship Google apps with their phone. One of the conditions that Google should be forcing RIGHT NOW is that manufacturers (and carriers) must provide a mechanism to allow updating the operating system (or to replace it entirely).
This shouldn't be a hard thing for Google to do. Heck, for all the evil they do, Microsoft gives you unrestricted access to the Operating System (recent host file shenanigans notwithstanding), and I've never seen a x86 PC that doesn't allow you to wipe Windows and install something else, despite the whole "secure boot" scare.
So, Google, good move, but get your priorities straightened out.
So basically, if I'm a government... all I have to do is deny you regulatory certification because "you have too much RAM" or because "your encryption runs too fast", and the you, the phone vendor, get to walk the regulatory and Android licensing tightrope of breaking either the RAM or the encryption library to get your certification.
Check.
Encryption is great! It keeps data private. However only private to those who hold the keys to the encryption. What is preventing Google from creating a master key that would allow them or a government to decrypt the data. Without such a backdoor mechanism are there some countries where Google would not be allowed to deploy the newest OS? I will be curious about the legal ramifications and privacy notice connected to this next update. What legal recourse would consumers have if it were found out later that Google did in fact create a backdoor. In the US, for instance, would the patriot act absolve Google of any class action even if they did not disclose facts to the consumer?
There is or can be built a machine that can simulate any physical object. -Church-Turing principle
I know this is an unpopular opinion but most people don't need to encrypt their phone because they have no sensitive data on it. There is always a trade-off between encryption and data integrity, and the latter is way more important for most ordinary use cases. Good voluntary encryption is nice and important for business, but mandatory encryption ... why?
Full encryption does nobody any good if the OS, as deployed, is so full of holes that the encryption isn't much of an impediment to gaining full access to everything on the device.
I'm pretty sure that neither Android nor iOS is a true bar to getting at what's on your phone (iOS almost certainly has plenty of exploitable bugs your tax dollars have discovered or paid for information on), though it might not be information that's going to be admissible in a trial.
This is technically possible IF Apple and Google are lying about how the symmetric key itself is generated and stored.
The passcode is used to secure the "real" key, which is used for data encryption. This symmetric key is supposedly not predictable or retrievable. However, it could in fact be the output of crypt('$1$hfgfydhjd$', imei + masterkey)
That would allow anyone who knows the imei and master key to derive the symmetric key.
So, if I get this right, Google just made boot-level customization useless, because verified boot will pretty much prevent CWM, TWRP, unlocking the bootloader etc. There goes also easy rooting, easy custom ROMs (CyanogenMod), easy backups, MultiROM, fastboot de-bricking for the semi-knowledgeable, sideloading, custom flashing............. Right? RIGHT?
"The move is likely to draw criticism from law enforcement officials in the U.S. who have argued over the past year that the increasing use of encryption on devices and online communications affects their ability to investigate crimes."
...the move is also more likely to hinder U.S. law enforcement from ABUSING their power... so you'll forgive me if I'm a little salty in saying...
" You kinda brought this on yourselves. "
They have published some code which they say is used to generate the initial master key. They are probably telling the truth, but there's no way to know - they master key looks like random bits.
for all the evil they do, Microsoft gives you unrestricted access to the Operating System (recent host file shenanigans notwithstanding)
As of Windows 10, you need to buy and renew an EV code signing certificate in order to run any drivers that you have built. This is cost prohibitive for many individual hardware hackers.
I've never seen a x86 PC that doesn't allow you to wipe Windows and install something else
Xbox was this way, at least until mods were figured out. So is Xbox One. So is PlayStation 4, though it comes with a FreeBSD-based operating system called Orbis OS instead of Windows.
Another issue is drivers. A PC maker can ship Windows on its PCs and refuse to ship drivers for other operating systems, as ASUS does with its current EeeBook and Transformer Book laptops.
That one does not mean what you think it does. "Protest" meant promise, specifically the protestations of eternal love and faithfulness of the queen to her husband. I know the bar for literacy isn't very high around here, but still.
Thanks for taking the time to reply with such a reply response.
> Actually, I wrote chunks of that code, and work with the guys who wrote the rest, so I know *exactly* how the key is generated.
In that case perhaps you can clarify whether I'm misunderstanding or just didn't communicate clearly. My understanding is:
The symmetric AES key is generated ~once, then that key is encrypted based on the password or pattern.
By the time an end-user is using the device, the key has -already- been generated (or may have been).
Therefore the binary will not generate a new key, because it's already there in the footer.
Therefore even if the binary matches the source - it won't generate a key from /dev/urandom because the key is already there.
Therefore even if we knew that the binary matches the source, we don't know how the (pre-existing) key was generated.
In other words, everything about generating the key is conditional on there not already being a key. IF an OEM put a bad key in the footer, it would stay there.
On a somewhat different topic, it's nice to meet someone will similar interests. I don't really remember names on Slashdot, don't remember who said what. I don't know if you've noticed I post a lot on information security since that's what I've been doing for fifteen years. Feel free to shoot me a message sometime if you ever care to - if you're looking for a job in the Dallas, Houston, Denver, or Cardfiff areas, or if you have an open source project that could use an extra hand.
Thanks for taking the time to reply with such a reply response.
> Actually, I wrote chunks of that code, and work with the guys who wrote the rest, so I know *exactly* how the key is generated.
In that case perhaps you can clarify whether I'm misunderstanding or just didn't communicate clearly. My understanding is:
The symmetric AES key is generated ~once, then that key is encrypted based on the password or pattern.
It's generated once when the file system is first encrypted, yes.
By the time an end-user is using the device, the key has -already- been generated (or may have been).
May have been, but generally isn't. Usually the first time a device is booted is when the customer turns it on. Key generation and encryption happens at that point in time. This used to be a usability problem because dm-crypt didn't distinguish between in-use and unused blocks, which meant that when the user first turned on a device with on-by-default encryption, they immediately had to wait several minutes for the device to encrypt a whole bunch of empty space before they could use it. We fixed that so it only encrypts in-use blocks, and since there are very few of those on a new device, it's fast.
A related problem is the fact that the key is generated very early during first boot, when /dev/random's pool hasn't accumulated much entropy. So we do in fact end up leaning more heavily on the hardware RNG than I'd like.
Therefore the binary will not generate a new key, because it's already there in the footer.
Therefore even if the binary matches the source - it won't generate a key from /dev/urandom because the key is already there.
Therefore even if we knew that the binary matches the source, we don't know how the (pre-existing) key was generated.
In other words, everything about generating the key is conditional on there not already being a key. IF an OEM put a bad key in the footer, it would stay there.
I suppose, though I've never seen any evidence of OEMs shipping devices with keys in the footer at all.
If you want to fix this, though, there's a very easy way: Just factory-reset the device. That wipes all user data, including the crypto footer, so on next boot a new key will be generated. You can validate that this happened by looking at logcat.
On a somewhat different topic, it's nice to meet someone will similar interests. I don't really remember names on Slashdot, don't remember who said what. I don't know if you've noticed I post a lot on information security since that's what I've been doing for fifteen years.
I don't notice names so much, either. I post quite a bit on topics related to information security, and especially crypto. Though lately it seems like I post more corrections of erroneous assumptions/beliefs about Google than anything else. I should probably stop doing that.
Feel free to shoot me a message sometime if you ever care to - if you're looking for a job in the Dallas, Houston, Denver, or Cardfiff areas,
I'm quite happy at Google, but thanks.
or if you have an open source project that could use an extra hand.
Keyczar could use some assistance. https://github.com/google/keyc.... Theoretically I'm the lead maintainer, though I cringe to say that given how little time I put into it.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Note that if verification fails at any stage, the user must be visibly notified and always be given an option to continue using the device at their own discretion. (source: https://source.android.com/dev...)
So everything I expected could be rendered useless will actually still have a chance to run. *Exales in relief*