Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Tuesday March 03 2015, @10:29PM   Printer-friendly

Encryption-by-Default in Android 5.0 "Lollipop" Actually Optional

The Register and Ars Technica report that Google has backtracked on its promise that all Android Lollipop devices would feature full-disk encryption by default, due to differences in hardware:

For example, the Qualcomm Snapdragon 805 system-on-chip in the Motorola Nexus 6 will do AES encryption and decryption of data in hardware – which should be fast and power efficient. However, the driver for that feature is not available to the Android project, so Android 5 must do the file encryption and decryption in software, which is terribly slow – forcing people to switch it off. Some manufacturers may not bother turning encryption on in the first place if there's no acceleration available for whatever reason, and Google's allowing them to do just that. Meanwhile, the Google Nexus 9 fondleslab uses an Nvidia Tegra K1 processor with a 64-bit ARMv8-compatible processor. This architecture has standardized AES encryption/decryption instructions that can be used by Android 5 without a specialized driver. That means Lollipop happily encrypts-by-default on the Nexus 9. This whole mess will make Apple fans very smug. Apple has had a separate coprocessor for accelerating encryption for years, and as a result iOS encryption is a much easier process.

Google expects that "recommended" full-disk encryption will become a requirement in future versions of Android.

Previously, the FBI and Director James B. Comey have spoken out against encrypted devices.

XPosed Framework for Android Lollipop released

XPosed is a framework for modules that can be used to customise the behaviour of Android devices without needing to flash a custom ROM. There is a large selection of modules available for XPosed that do all kinds of nifty things like unlock using NFC tags, change the battery icon to something more informative, or even add advanced privacy and app controls.

This has been a godsend for those who like to retain a level of control over their devices. However, the change from the original Dalvik runtime system to ART starting with Android 5.0 (Lollipop) broke the XPosed framework, and it had taken some time for the developer to make the necessary changes to get XPosed to work with the new runtime system. That time has finally come. It's still considered alpha software however and there are some reports of incompatibilities and instability but it seems to be already usable.

Related Stories

FBI Director Concerned about Encryption on Smartphones 21 comments

PC World reports:

The U.S. Federal Bureau of Investigation is concerned about moves by Apple and Google to include encryption on smartphones, the agency’s director said Thursday.

Quick law enforcement access to the contents of smartphones could save lives in some kidnapping and terrorism cases, FBI Director James Comey said in a briefing with some reporters. Comey said he’s concerned that smartphone companies are marketing “something expressly to allow people to place themselves beyond the law,” according to news reports.

An FBI spokesman confirmed the general direction of Comey’s remarks. The FBI has contacted Apple and Google about their encryption plans, Comey told a group of reporters who regularly cover his agency.

[Additional Coverage]:
http://www.theregister.co.uk/2014/09/25/fbi_boss_slams_google_apple_for_encryption_that_puts_users_above_law/
http://www.huffingtonpost.com/2014/09/25/james-comey-apple-encryption_n_5882874.html

F.B.I. Director Calls "Dark" Devices a Hindrance to Crime Solving 104 comments

The New York Times published an interesting story about the fears of the current FBI director:

The director of the F.B.I., James B. Comey, said Thursday that federal laws should be changed to require telecommunications companies to give law enforcement agencies access to the encrypted communications of individuals suspected of crimes.

... Mr. Comey warned that crimes could go unsolved if law enforcement officers cannot gain access to information that technology companies like Apple and Google are protecting using increasingly sophisticated encryption technology.

“Unfortunately, the law hasn’t kept pace with technology, and this disconnect has created a significant public safety problem,” he said.

Mr. Comey said that he was hoping to spur Congress to update the 20-year-old Communications Assistance for Law Enforcement Act, which does not require companies to give law enforcement direct access to individuals’ communications.

The F.B.I. has long had concerns about devices “going dark” — when technology becomes so sophisticated that the authorities cannot gain access to them. But now, Mr. Comey is warning that the new encryption technology has evolved to the point that it could adversely affect crime solving.

The kicker is this line:

“Those charged with protecting our people aren’t always able to access the evidence we need to prosecute crime and prevent terrorism, even with lawful authority."

Of course, it should be no surprise to the FBI why so many people are going "dark" and using things like Tails. For decades, the government has proven time and again that it can't be trusted to act lawfully and constitutionally. The FBI is responsible for more than its share of that. So naturally those who can are going to take steps to protect their privacy and Apple and Google, among others, are simply responding to that demand.

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Interesting) by iamjacksusername on Tuesday March 03 2015, @10:39PM

    by iamjacksusername (1479) on Tuesday March 03 2015, @10:39PM (#152781)

    XPrivacy is the best thing since sliced bread. XPrivacy is always my first install when I flash a ROM. For those who do not know, XPrivacy allows you to selectively deny permissions to apps or feed the app random data if it refuses to function with a permission denied. E.g., I have the Facebook app installed on my phone but it has no idea what my phone serial, phone number or location is among other things. I only wish there was a central repo for default XPrivacy app templates that are just "the app will function. mostly" because it is kind of annoying whenever an app updates trying to find out if something will break.

    • (Score: 4, Informative) by Kilo110 on Tuesday March 03 2015, @10:44PM

      by Kilo110 (2853) Subscriber Badge on Tuesday March 03 2015, @10:44PM (#152784)

      if you donate to xprivacy you get a key which gives you access to crowd sourced templates. I find they work fine most of the time.

    • (Score: 2) by VLM on Tuesday March 03 2015, @10:49PM

      by VLM (445) on Tuesday March 03 2015, @10:49PM (#152785)

      I have the Facebook app installed on my phone but it has no idea what my phone serial, phone number or location is among other things.

      Which brings up the excellent question of why bother encrypting storage if every corporation and .gov in the world already has access to all the data?

      Is there ANY scenario with a realistic opfor where encrypting storage buys anything, anything at all?

      • (Score: 3, Informative) by iamjacksusername on Tuesday March 03 2015, @10:55PM

        by iamjacksusername (1479) on Tuesday March 03 2015, @10:55PM (#152792)

        Well, in this case, it is mostly me not wanting to give FB real time data on my location and phone activity. I know they could probably buy access through my wireless company if they really wanted to; the idea is to keep the barrier to this data at a non-zero cost so that FB will be slightly less than 100% likely to have it.

    • (Score: 1, Insightful) by Anonymous Coward on Wednesday March 04 2015, @01:51AM

      by Anonymous Coward on Wednesday March 04 2015, @01:51AM (#152843)

      > XPrivacy is the best thing since sliced bread.

      Well, except for the fact that sliced bread has a user interface 100x better than XPrivacy.
      I love it and all, it is also my first install, but hoooleee shit is it ugly and unintuitive.

      • (Score: 2) by everdred on Wednesday March 04 2015, @08:30PM

        by everdred (110) on Wednesday March 04 2015, @08:30PM (#153223) Journal

        >> XPrivacy is the best thing since sliced bread.

        >Well, except for the fact that sliced bread has a user interface 100x better than XPrivacy.
        >I love it and all, it is also my first install, but hoooleee shit is it ugly and unintuitive.

        QFT.

  • (Score: 3, Insightful) by GungnirSniper on Tuesday March 03 2015, @11:15PM

    by GungnirSniper (1671) on Tuesday March 03 2015, @11:15PM (#152798) Journal

    If Android's primary purpose was to exist on desktops and full laptops, we'd excoriate them for not having built-in security and permissions. But because it is for phones, it's okay? Without third-party software it is as secure as Windows 95.

  • (Score: 5, Interesting) by takyon on Tuesday March 03 2015, @11:59PM

    by takyon (881) <takyonNO@SPAMsoylentnews.org> on Tuesday March 03 2015, @11:59PM (#152806) Journal

    It's easy to blame Google for this, but it's the device and SoC manufacturers that are at fault. Hardware encryption should be a standard feature, like the many other capabilities packed into a modern SoC. Unusable encryption undermines not just privacy seekers but BYOD/Android for Work.

    Android fragmentation may not be as bad as Apple has claimed over the years, but this is a clear example of the centralized "walled garden" beating the Android ecosystem. Google wanted to out-privacy Apple within the span of a few days, then reality settled in. Devices not being able to upgrade to the latest Android version is another issue.

    --
    [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
  • (Score: 3, Interesting) by kaszz on Wednesday March 04 2015, @09:20AM

    by kaszz (4211) on Wednesday March 04 2015, @09:20AM (#152943) Journal

    Considering:

    a) Compromised chip masks. How does one even know that the encryption engine is even properly implemented?

    b) Is the AES algorithm designed properly? If anyone remember Dual EC DRBG.

    I think one should question the integrity of any "AES hardware".

    • (Score: 3, Informative) by takyon on Wednesday March 04 2015, @03:08PM

      by takyon (881) <takyonNO@SPAMsoylentnews.org> on Wednesday March 04 2015, @03:08PM (#153049) Journal

      Q: Is any hardware even safe?

      A: Just these. [fsf.org]

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 3, Interesting) by kaszz on Wednesday March 04 2015, @03:20PM

        by kaszz (4211) on Wednesday March 04 2015, @03:20PM (#153063) Journal

        It's too easy to lie.

        Anyway, anyone that handles the amount of money needed to fabricate a chip will most likely bow to government wishes in order to not get business disturbances.

        • (Score: 0) by Anonymous Coward on Thursday March 05 2015, @06:13PM

          by Anonymous Coward on Thursday March 05 2015, @06:13PM (#153582)

          There is no such thing as 100% security, only a trade-off between cost to secure versus costs to compromise.

          If a particular AES implementation has been made deliberately vulnerable in secret, that fact's secrecy is of such high value that it 99.999% of the people using that implementation don't have to worry about that weakness being used against them because their data isn't worth the price. That is a net benefit to society as a whole. If your adversary is the NSA/CIA/etc, well you are still just as vulnerable as you were without AES. But against all the other adversaries, you are much safer than before.

    • (Score: 3, Informative) by stormwyrm on Wednesday March 04 2015, @03:25PM

      by stormwyrm (717) on Wednesday March 04 2015, @03:25PM (#153067) Journal

      Can't say anything about (a) but I can speak to (b). The algorithm that eventually became AES was selected by NIST in 2001 in a cipher design contest, and it was designed by two well-respected academic cryptographers from Belgium named Vincent Rijmen and Joan Daemen who were at the time associated with the Katholieke Universiteit Leuven. They have no association whatsoever with the NSA as far as anyone knows. I implemented their algorithm (it was still known as Rijndael then, a portmanteau of their surnames) myself on a microcontroller in 2000 from their original specification, and when the algorithm was selected as AES the following year, I compared FIPS 197 (the official NIST AES specification) with the original specification published by Rijmen and Daemen and saw there were absolutely no changes to the algorithm. My original code produced the expected results given the NIST-supplied known answer test vectors that are part of FIPS 197. While the NSA might have influenced NIST's decision to choose Rijndael as the Advanced Encryption Standard, they did not tamper with the algorithm in any way. They didn't fudge the Rijndael s-boxes the way they did with the original DES or make any other alterations to it. That sort of makes kleptography unlikely.

      Furthermore, the NSA later endorsed the use of AES for the US government to encrypt classified information. If the NSA was in possession of a practical break of AES and allowed the government to use the algorithm for classified information anyway, then that would be the height of stupidity and arrogance. Do you really think that they are so stupid and arrogant as to believe that they cannot be penetrated by another foreign intelligence agency or whistleblower (do the letters E.S. mean anything to you?), or that someone, somewhere, be it the academic crypto community or some other intelligence agency, will not someday independently discover their break? The NSA has been accused of many things, but stupid is not one of them.

      The NSA has, according to Snowden, instead been working hard (Project Bullrun) to systematically compromise cryptographic implementations and standards to weaken them. Your scenario A thus sounds very much like something they would try to do under this strategy. There would be no way to prove, short of popping open the chip and reverse engineering it, that a hardware AES implementation doesn't leak secret key information via a covert channel.

      --
      Numquam ponenda est pluralitas sine necessitate.