Slashdot Mirror
Next Android To Enable Local Encryption By Default Too, Says Google
An anonymous reader writes The same day that Apple announced that iOS 8 will encrypt device data with a local code that is not shared with Apple, Google has pointed out that Android already offers the same feature as a user option and that the next version will enable it by default. The announcements by both major cell phone [operating system makers] underscores a new emphasis on privacy in the wake of recent government surveillance revelations in the U.S. At the same time, it leaves unresolved the tension between security and convenience when both companies' devices are configured to upload user content to iCloud and Google+ servers for backup and synchronization across devices, servers and content to which Apple and Google do have access.
Already the industry is realizing what it needs to do.
it leaves unresolved the tension between security and convenience when both companies' devices are configured to upload user content to iCloud and Google+ servers for backup and synchronization across devices
The existence of the Third-Party Doctrine makes the decision simple for me.
Brave Sir Robin ran away. ("No!") Bravely ran away away. ("I didn't!")
You need your head read. Google has shown time and again that it does not care about your security. There is no need to trade off convenience for security in cloud backup. Encrypt locally and send the data encrypted to backup. This would be great but i bet that Google also holds they keys and decrypts on their end. Google says it wouldn't be able to use your data for their massive data mining and information theft machine if it were properly encrypted. This is why the data sits on their servers unprotected by encryption, they are the antithesis of your guardians of security. If you value your data, turn off all Google services and manage your own backups.
Most handsets won't be upgradable
Why isn't it already the default setting?
Get free satoshi (Bitcoin) and Dogecoins
We need them to implement some strong encryption on telephone calls so that the NSA cannot randomly listen in on everyone/s conversation. I realize this would only be possible for WiFi phone calls, but it would provide a much-needed measure of privacy assurance for many many Americans. It is a sad sad day when you cannot trust your own government anymore but that is where we were at and there is no reason we cannot use encryption to keep our calls private at least for domestic calls. When I place a call I would like to be able to hit a buttone and have the call be an encrypted one.
All I see from your comment is that you're also not using the Google spellchecker.
In other news Google points out that although the Sun and stars shine with bright light they also have light bulbs in the Google offices and in their next office buildings they will be eliminating the light switches so that lights shine by default.
What's the point of enabling local encryption when vendors feel free to install Carrier IQ and other vendor supplied monitoring applications which record many of the things you do with your Android device ?
Google for Carrier IQ if you have forgotten how it totally violates your reasonably assumed right to privacy...
And if you think I'd ever willingly put non encrypted data in any sot of could you're dreaming.
I thought this was about ON THE HANDSET encryption?
Which leads you to the key hiding problem.... Keys need to be plain text to be used, so they are in memory when you have a device that is encrypted. Which leads you to the problem of how to get a sufficiently complex key into the device on boot? Providing keys is where most crypto systems start to break down, and people do stupid stuff like reduce everything to a 4 digit pin or some such nonsense...
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
That's great that Google is going to enable device encryption by default. But are they going to fix the usability and security problems for Android L?
If you enable device encryption on Android, you can no longer back up and restore your data over USB or through third party tools. You can create encrypted backups over USB, but you can't restore them because of bugs in the ADB tools. The only way to back up and restore is by uploading your data to Google's cloud servers, where your data is much more likely to be purloined than if you had just left your device unencrypted in the first place.
When you enable encryption, you set a password. The encryption password becomes your lock screen PIN and there is no way to change it. So, which are you going to choose? A secure encryption password that you'll spend 15 seconds entering on the tiny keyboard every time you want to unlock your phone? Or a useable PIN that is trivial to crack if an attacker gets your encrypted data?
It's clear someone added device encryption to Android to check it off the list and didn't intend for anyone to use it. I hope their product team realizes this before they bring it to a wider audience.
SO FUCK YOU GOOGLE
http://www.computerworld.com/article/2474851/android-google-knows-nearly-every-wi-fi-password-in-the-world.html
It is nice that Apple added encryption to iOS 4 including the encryption of email attachements. But it seems like it was a mistake to depend on it since the protection was silently removed from iOS 7. Does additional encryption in iOS 8 really matter if the feature can be silently removed with an future revision?
I would prefer that data be encrypted by the application regardless of the OS so I can count of the behavior remaining consistent across OS upgrades.
Apple and Google (Android) are blowing smoke.
"If any question why we died, Tell them because our fathers lied."
Because it affects the speed of the device.
Unless something has changed with a recent system update, last time I checked the local device encryption for Android disabled the Gesture and PIN input, leaving Password as the only option. I don't exactly care to enter a full-on alphanumeric password every time I take my phone out of stand-by, so the feature is of limited use.
I prefer to use TextSecure. This hooks into the SMS and MMS handlers and redirects them from the internal store, to an encrypted store with an application passphrase. Keeps my phone easy to open up, but keeps the only data I have an interest in protecting safe.
See also https://code.google.com/p/andr...
Unfortunately, this is a total show stopper for full device encryption.
Well, it doesn't do any good right now if it's on an android version that nobody uses. What about Pre L versions?
And won't this really be a carrier option? And what about that sharing data part?
And if you think I'd ever willingly put non encrypted data in any sot of could you're dreaming.
I thought this was about ON THE HANDSET encryption?
Which leads you to the key hiding problem.... Keys need to be plain text to be used, so they are in memory when you have a device that is encrypted. Which leads you to the problem of how to get a sufficiently complex key into the device on boot? Providing keys is where most crypto systems start to break down, and people do stupid stuff like reduce everything to a 4 digit pin or some such nonsense...
Why not generate the key on the device and store it in a secure piece of hardware? That's been a pretty standard solution for a while now. I kind of imagined Android would also do the same.
So, riddle me this batman... If you store the key on the device and read it automatically on boot, how's that protect you? Or are you saying that it's on an external device so I now have to keep the "key" around to boot my phone? One offers zero protection, the other consumers will hate.
See this is what usually happens...The consumer doesn't want two devices to manage, they want one. We implement strong encryption using long keys, then we store these keys someplace "on the device" and protect them with a 4 digit pin. Consumers demand it. So we've really reduced the protection level of all that nifty encryption to that of a 4 digit encryption key.
Sort of like what happened to WEP.... It used good encryption (in fact we STILL use the same encryption for the most part) it just bungled the key management side of things to make it useable by consumers. (OK, they did some other stuff wrong too, but the problem was key management..)
So, I'm not saying that having a "boot key" device, simiar to an RSA token isn't a bad idea, I'm saying that most users won't stand for having something separate from their phone that they need to power it on, nor will they suffer though entering sufficiently long and complex passwords.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Doesn't need to be only wifi. BUT, if the provider had the key they would have to decrypt the call or turn over the key on request.
Nothing requires the provider to interfere with me making an end-to-end encrypted call to another similar phone user. There are reliability issues that would need to be addressed, but it can be theoretically be done
It would basically need PKI or a variant and we know how stupid people are when it comes to accepting unsigned or new certificates. I can only imagine the stupidity induced outrage that would arise when they were told that the bypasses they chose to use left their phone less secure.
The NSA and other TLAs would work hard to compromise any central public key repository, leaving something like direct exchange or NFC the only way to really securely share public keys for the people who cared.
The only way to back up and restore is by uploading your data to Google's cloud servers, where your data is much more likely to be purloined than if you had just left your device unencrypted in the first place.
As an Android fan, let me just say that these problems do not just stop with encryption. Unless you root your phone, you can't back it up properly because Google doesn't let you have access to your own files on your own f'ing device. Apparently nobody sees a problem in the fact that users are forced to make the decisions to either run stock or be able to access all their files. I'm sure it's to reduce piracy or something, but it's a nightmare. Unless your apps keep their data in an accessible folder or you let them keep all your settings in the cloud (if they even support that), just upgrading your handset to this years Nexus is going to mean data loss.
I get that it makes the security stronger, but Android badly needs some kind of super-user mode that makes the entire filesystem accessible to selected apps.
California law will require that handsets be able to be remotely disabled by the user. This is one of the easiest ways to do that - to encrypt the phone so that there is no way to operate it without entering the passcode. No resets, no workarounds. Both Google and Apple know that this is the chance to get it into the only x.0 release before that deadline.
It's not high and mighty, it's just getting into compliance. IMHO, it's a good thing, but it's not some special high road either one is taking.
Is it just my observation, or are there way too many stupid people in the world?
The biggest problem with entering long and complex password when powering on my phone? I'd forget the password, since I boot my phone when I run out of battery - aka. almost never.
Android has had this option since approximately forever.
And take 5 years to get across the fragmentation mess and still probably won't be completed!
Just so that I understand google play can install shit on your device when it feels like, google reads all of your email, google further nerfs intentionally nerfed permissions system and just about everything by volume in the app store is spyware designed to sell YOU to the highest bidder.
Relax folks your device is "encrypted" ...LOL..
As others already said, iOS had mandatory full device encryption (that you even can't disable) since 2009, when the iPhone 3G added hardware for that. What was added now is a different thing (encryption of single apps data with the key dropped from memory as soon as the device is locked).
Full device encryption is not enough since the key needs to be in memory as long as the device runs (or no process will be able to access the file system when the device is locked).
Also Apple's full device encryption uses a key saved in a safe enclave in the SoC, while Google's uses the PIN or password you setup for unlocking your device. If you use a PIN, this is easily brute-forced. If you use a strong password you have to type this in every time you want to use your phone. With a swipe pattern you can't use encryption at all.
Still, it's a start. I would like to see some performance tests though, encryption in software isn't free.
Smoke and mirrors, that just precludes recovering any of your own data if the flash memory gets corrupted.
An Android 4.1.2 that allows me to encrypt the entire storage on the phone. So it's nothing new.
That's why you do it in another layer, without a service provider being involved. OS and application developers aren't telephone service providers.
Verizon-to-government: "Here's the data you asked for."
Government: [pats gun, grinning] "Oh, I didn't ask for it..."
Verizon: "Just a polite euphemism."
Government: "This is ciphertext. Um, CALEA, remember?" [strokes gun handle, stares]
Verizon: "Sir, this binary snow is the plaintext. The ciphertext that we transported was this [more snow], and we reversed the encryption that we had added, to get you the data I just gave you. The user or his agent must have originally encrypted the data before they passed it to us. Someone else might be able to get that key, but I run the network, not the user's computer."
Government: "But the someone-else isn't governed by CALEA."
Verizon: "Look, you have the gun. Quit pretending you care who is governed by what. I sincerely and truthfully told you whom threatening can result in getting the key. Go get 'em, tiger!"
ARM TrustZone can do it quite effectively... which brings about the opposite problem. The key isn't under the user's direct control, and can't be recovered by the user. The same evil can be used to encrypt proprietary binaries so they can't be pulled off and used with AOSP-derived ROMs. It doesn't matter how nominally-open the operating system is if the hardware it's running on is a black box without public documentation or drivers.
Robust encryption whose key is under YOUR direct control (as the device's owner and end user) is a very good thing. Robust encryption that uses keys known only to the device itself is just another insidious form of DRM aiming to lock down and control the entire user experience.
It's shit like this that's forcing me to leave AT&T and go to T-Mobile so I can have a rootable Galaxy Note 4 with unlocked bootloader. Yeah, in theory, I could buy the T-mo variant and use it on AT&T... but AT&T's new pricing structure unsurprisingly manages to be at least $10/month more than I'm spending now... and that's WITH their alleged BYOD discount. And on the slight chance they allowed me to insure a T-mobile Galaxy Note 4, I'd be completely fucked if I had to use that insurance, because they'd almost certainly replace it with a bootloader-locked AT&T version that's the entire reason for hating them in the first place.
So, riddle me this batman... If you store the key on the device and read it automatically on boot, how's that protect you?
There are ways to store a key on the device and not need to read it automatically on boot. Page nine of the iOS Security Guide from September 2014 describes how Apple solves the problem.
After reading the FA today, I enabled encryption on my i9300 (after doing a backup, of course)
About an hour later, I had my phone back -- sluggish to do everything. And I had to enter a pin every time to unlock, not just at boot as promised (I'd be OK with that -- I can use the Android Device Manager if I lose my phone). Then I went for a TWRP restore -- and TWRP couldn't read my existing partition even after I entered my passkey, so I guess there's some mixup there... I restored from my sd card and it's like I did a factory reset -- all my user data is gone. I guess I shouldn't be surprised.
The point is that encryption is all good and well, but if a quad-core 1.2 gHz device becomes sluggish with it on, I'm not altogether sure that I want it that badly. Especially when I can just remote-wipe with the device manager.