Slashdot Mirror

← Back to Stories (view on slashdot.org)

Security Researcher Publishes How-To Guide To Crack Android Full Disk Encryption (thehackernews.com)

Posted by BeauHD on from the security-flaw dept.

An anonymous reader writes: Google first implemented Full Disk Encryption in Android by default with Android 5.0 Lollipop in an effort to prevent criminals or government agencies from gaining unauthorized access to one's data. What it does is it encodes all the data on a user's Android device before it's ever written to disk using a user's authentication code. Once it is encrypted, it can only be decrypted if the user enters his/her password. However, security researcher Gal Beniamini has discovered issues with the full disk encryption. He published a step-by-step guide on how one can break down the encryption protections on Android devices powered by Qualcomm Snapdragon processors. The source of the exploit is posted on GitHub. Android's disk encryption on devices with Qualcomm chips is based only on your password. However, Android uses your password to create a 2048-bit RSA key (KeyMaster) derived from it instead. Qualcomm specifically runs in the Snapdragon TrustZone to protect critical functions like encryption and biometric scanning, but Beniamini discovered that it's possible to exploit a security flaw and retrieve the keys from TrustZone. Qualcomm runs a small kernel in TrustZone to offer a Trusted Execution Environment known as Qualcomm Secure Execution Environment (QSEE), which allows small apps to run inside of QSEE away from the main Android OS. Beniamini has detailed a way for attackers to exploit an Android kernel security flaw to load their own QSEE app inside this secure environment, thereby exploiting privilege escalation flaw and hijacking of the complete QSEE space, including the keys generated for full disk encryption. The researcher also said Qualcomm or OEMs can comply with government or law enforcement agencies to break the FDE: "Since the key is available to TrustZone, Qualcomm and OEMs [Original Equipment Manufacturers] could simply create and sign a TrustZone image which extracts the KeyMaster keys and flash it to the target device," Beniamini wrote. "This would allow law enforcement to easily brute force the FDE password off the device using the leaked keys."

84 comments

  1. Re:Linux is dying by Anonymous Coward · · Score: 0

    Funny. My systemd-enabled desktop runs without any issues whatsoever. But hey, i'm positive other end users are picky about the init system used by their PCs.

  2. Unlocked access still required by NotInHere · · Score: 5, Informative

    From reading TFA, I conclude that you still need unlocked access to the phone? so if somebody gets hold of your turned off phone, they can't use it.

    1. Re:Unlocked access still required by AmiMoJo · · Score: 2

      Yep, it's an attack on a running system. The encryption key is derived from your password and stored in secure memory for use. If someone can get hold of your unlocked device they can potentially access that memory.

      Similar to attacks on encryption on running PCs etc, only harder because PCs don't usually have secure memory to hold the key in.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  3. The solution is horribly obvious by Anonymous Coward · · Score: 1

    Don't use TrustZone; store the stuff as a proper LUKS volume and stop using "trusted" proprietary crap. People complain about how these hypervisor sideband processors are not open or auditable and are always dismissed as paranoid fools by naysayers (it can't POSSIBLY happen!) then this kind of thing happens and the hand-wavers desperately try to do some damage control so they won't be wrong somehow. It's the same story with Intel ME. Can we just admit already that having supervisory-processor-within-a-processor stuff is inherently insecure?

    1. Re:The solution is horribly obvious by Opportunist · · Score: 1

      "Trusted" stuff cannot be trusted. It's called "trusted" because its maker trusts it to keep you from doing anything its maker didn't intend you to.

      Why the fuck should I trust something like that?

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    2. Re:The solution is horribly obvious by JohnFen · · Score: 1

      That's a nice, specific little clarification of the larger life rule: never trust anyone who says "trust me".

    3. Re:The solution is horribly obvious by swillden · · Score: 1

      Don't use TrustZone; store the stuff as a proper LUKS volume and stop using "trusted" proprietary crap

      TrustZone isn't proprietary; it's part of the standard ARM feature set. In many cases (not all[*]) the software running in it is. As for using an LUKS volume, the problem with that is that it's no more secure than the Linux kernel, which is popped by another security researcher every week. The kernel is so large and complex that hardening it is really difficult.

      Can we just admit already that having supervisory-processor-within-a-processor stuff is inherently insecure?

      No, because it's not.

      The purpose of having TrustZone isn't that it's inherently more secure. It's still just software, and subject to all of the same kinds of problems as any other software. The reason we have it is because by keeping it very small and simple we can reasonably expect it to have fewer problems. It can still have vulnerabilities (as we see here), and it still needs to be updated. In fact the vulnerabilities used by this researcher have already been patched, and the updates already pushed out to devices.

      The fact that TrustZone code isn't immune to bugs doesn't mean that there's no value in having a smaller, simpler, and isolated execution environment. In fact it highlights just why it's so important, because as vulnerable as it may be, the vastly larger amount of code running in the regular execution environment has orders of magnitude more attack surface, and orders of magnitude more bugs.

      [*] Google's Trusty is a free, open source implementation of a TrustZone trusted OS. The F/LOSS Genode OS has also been used in TrustZone. There's no technical reason TZ code must be secret or proprietary. The makers of the most widely-used versions keep theirs proprietary, but that's a business decision, not something inherent to the concept of a trusted execution environment.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    4. Re:The solution is horribly obvious by swillden · · Score: 4, Informative

      "Trusted" stuff cannot be trusted. It's called "trusted" because its maker trusts it to keep you from doing anything its maker didn't intend you to.

      No, the only thing that makes it "trusted" is that it's small, and isolated. Those characteristics reduce its attack surface and reduce the number of bugs it has, on average.

      I'll grant that the primary purpose of TrustZone in Android devices, historically, has been DRM, which is absolutely something the maker doesn't want you to muck with. That's not the case with Keymaster. If you want to know what it does, there's a full open source reference implementation in AOSP. That's not the implementation used in Qualcomm devices; they wrote their own and it's closed -- but it does as close to the same thing as what the reference implementation does as the engineers involved could make it. Some other devices do use the code from AOSP.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    5. Re: The solution is horribly obvious by Anonymous Coward · · Score: 0

      You are factually incorrect. The thing that makes something "trusted" is if you *must trust it*. If you hand 1000 dollars over to some guy and say "give this back to me in 10 minutes", and run off, he *trusted* with your money. He could be trustworthy- he could be your father, or your lawyer. Or he could be a bum, a thief, or a policitian. Whether or not he is trustWORTHY, you have TRUSTED him. That's why these are TRUSTED components, etc.

    6. Re:The solution is horribly obvious by Anonymous Coward · · Score: 0

      "Trusted" stuff cannot be trusted. It's called "trusted" because its maker trusts it to keep you from doing anything its maker didn't intend you to.

      Why the fuck should I trust something like that?

      Trusted technology simply means someone controls what is going to run somewhere, which is essentially what you said, but in different words. That means you have those in control usually trying to prevent bad things from running, and occasionally using that ultimate power to do those bad things. It also prevents some good things. You allude to that by the phrase, "keep you from doing anything its maker didn't intend you to."

      I suppose my answer is this. If you are an average consumer, and have no interest in running your own code or any of those good things, then the trusted technology is a net benefit, since the device is able to run fewer things that can be seriously damaging. After all, the bad things run even easier without the trusted technology.

      Now, the true solution is not a single chain of trust, but multiple chains. Computers/Tablets/Phones may one day have to verify multiple chains of trust, so not only do you have to pass the public key verification from Google/Apple, but also from a major United States provider, a major China provider, a major Swiss provider, etc, etc. Sure it may be possible that every one of their private keys is compromised and in various 3 letter agencies hands, but well, your still no worse off than you were without the signing, unless of course you want to run your own code.

      Basically, all code that executes, at least with any significant privileges, would have to be signed by multiple signing agencies who generally do not trust each other. This would make it more difficult for a single source to be compromised. In essence you would have trust by way of the Ven diagram creating full coverage.

      In essence, If you forced google/apple to create a compromised image, then it would have to go all over the globe before it would execute on standard commodity hardware, making it very difficult to only apply that image to a few devices without someone noticing.. Of course, in the really ideal case that code would be open source and audited by people in all those countries before being signed. That part might take awhile, but in that case you might, finally, at long last get to "trusted", at least statistically.

    7. Re:The solution is horribly obvious by sjames · · Score: 1

      There is an important distinction though. If I do not control the code running in that processor (or trust zone), it *IS* inherently insecure for me. If I do control it, it may improve security or it might be neutral WRT security.

    8. Re:The solution is horribly obvious by mlts · · Score: 1

      IIRC, CyanogenMod doesn't touch TZ... it just uses dm-crypt, prompts for the passphrase that unlocks the /data volume key, then goes from there.

    9. Re:The solution is horribly obvious by davester666 · · Score: 1

      You shouldn't. In this case "trusted" means that the processor/ram/rom/code can be trusted to not be altered by YOU. Only the corporations that paid the cpu manufacturer for access to it can 'trust' it...

      --
      Sleep your way to a whiter smile...date a dentist!
    10. Re:The solution is horribly obvious by arglebargle_xiv · · Score: 2

      No, the only thing that makes it "trusted" is that it's small, and isolated. Those characteristics reduce its attack surface and reduce the number of bugs it has, on average.

      No, what makes it "trusted" is that ARM and/or the chip vendor repeatedly tell you it is in press releases. There have been several attacks on TrustZone devices which take advantage of the fact that it's often very poorly implemented, and much less secure than the non-TrustZone stuff. The classic example of this was the rooting of a Motorola phone which hacked the insecure TrustZone, then attacked the secure non-TrustZone stuff from inside the "trusted" environment. It was the presence of TrustZone that allowed the device to be rooted.

    11. Re:The solution is horribly obvious by marcansoft · · Score: 1

      The problem is not "trusting" the proprietary crap, the problem is trusting it to improve security in any measurable way.

      Android full disk encryption is just as secure as LUKS (in fact, under the hood it's dm-crypt just like LUKS, the key derivation is just different). This doesn't break the FDE. You still need the passphrase. What this does is break the "you need the hardware to access the FDE and we're going to impose additional non-provable restrictions such that you can keep using your 4-digit PIN and it'll be secure, promise" bunch of hot air that vendors like to sell you. Just like the FBI cracked that iPhone's FDE - by bruteforcing the passcode. This lets you bruteforce Android's FDE offline after a one-time attack on the hardware.

      I use CyanogenMod on my phone. I have my FDE passphrase set to a long string, independent of my (shorter) unlock code. This attack doesn't affect me because my FDE passphrase is not bruteforceable in a reasonable amount of time. This only affects people who still think using a 4-digit PIN to secure FDE on their phone is a good idea because Apple and Qualcomm pinkie-promise that their secure tamperproof hardware can limit bruteforce attempts enough to make that a reality.

    12. Re:The solution is horribly obvious by marcansoft · · Score: 1

      CyanogenMod still uses TZ/QSEE on phones where that is used in the original firmware.

      However, that never reduces security, only increases it. If your passphrase is long enough not to be at risk of a bruteforce, then this attack does not affect you.

    13. Re:The solution is horribly obvious by Opportunist · · Score: 1

      I prefer to be able to determine myself what I consider bad things and good things. History is rife with examples how allowing other entities, especially such you have no control over whatsoever, define what "good" and what "bad" is leads to them defining them in a way you would not agree with and clashes with your interests.

      Because, by definition, these entities will define it in such a way that it benefits them. If your interests are the same, you're lucky, but relying on it is stupid.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    14. Re:The solution is horribly obvious by swillden · · Score: 1

      No, what makes it "trusted" is that ARM and/or the chip vendor repeatedly tell you it is in press releases. There have been several attacks on TrustZone devices which take advantage of the fact that it's often very poorly implemented, and much less secure than the non-TrustZone stuff.

      Utter nonsense. Go take a look at the CVE reports of vulnerabilities in the Linux kernel, and compare them to the CVE reports of TrustZone OS vulnerabilities. The kernel is two orders of magnitude worse. That's not because it's bad, or TZ code is good... I'll readily concede that kernel code is almost certainly higher in quality than closed-source TZ OSes. But it's also vastly larger and more complex, with so much more attack surface.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    15. Re:The solution is horribly obvious by swillden · · Score: 1

      There is an important distinction though. If I do not control the code running in that processor (or trust zone), it *IS* inherently insecure for me. If I do control it, it may improve security or it might be neutral WRT security.

      There's lots of code that you do not control running in every computing device you use. If you insist on that exceedingly strict definition, you should just avoid them entirely. Also, your assertion that if you do control it it's either neutral or positive is patently false. It is entirely possible to exercise control in ways that decrease your security. It's pretty common, for example, for people who root their Android devices to believe that they're improving their device security by taking control over it, when they've actually just poked gaping holes in the security model designed to protect them.

      Code that you do not control may be good, bad or neutral from a security perspective. It depends both on the goals of the people who do control it, and on their ability to achieve their goals. Code that you do control may be good, bad or neutral. You know what goals you're trying to achieve, but there's still the question of your ability to achieve them.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    16. Re:The solution is horribly obvious by sjames · · Score: 1

      There's not actually a lot on the machines I am using. That doesn't mean that I have written or even audited every line myself, just that it is open for me to do so.

      Of course, in embedded devices the code is less open for my audit or modification, but those devices also don't have much exposure to my personal data.

    17. Re:The solution is horribly obvious by swillden · · Score: 1

      You're using some very unusual machines, then. Or you're mistaken about how many binary firmware blobs there are.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    18. Re:The solution is horribly obvious by sjames · · Score: 1

      There was even less when I was working on coreboot.

      Keep in mind, the BIOS is a nasty pile of hair but it IS open to audit.

      The ME, OTOH loads an encrypted and signed blob.

    19. Re:The solution is horribly obvious by swillden · · Score: 1

      Just to be clear, I don't like or support the presence of opaque binaries in systems. One of the things I'm trying to achieve in the Android ecosystem is to move OEMs to using open source code in TrustZone. There is tremendous security value in having a trusted execution environment which is small and isolated, because making full consumer OSes secure is simply impossible, but having the code in that TEE be closed doesn't add anything to the security proposition, and arguably reduces it. That's why Google has Trusty, and why the OS and apps are developed directly in AOSP.

      One of the things on my to-do list (far down the list at the moment, given that hardly any devices use Trusty) is to find ways to enable (technically-capable) users to verify that the TEE software running on their device matches the source code. In addition, users should be able to sign and install their own TEE software, as well as their own non-secure world software. The Nexus devices have always allowed the latter, but the TEE has been solely controlled by the SoC vendor. The only exception to that, as far as I know, is the Pixel C tablet from Google. It uses a hardware switch analogous to (and based on) the "dev screw" in Chromebooks. If you flip that switch then you can install your own verification keys for both system and TEE. Your TEE OS won't have access to the DRM keys baked into the hardware, of course, but outside of that limitation you can do whatever you want in the TEE.

      Of course, there are a lot of other opaque, highly-privileged binaries in mobile devices. Almost all of the firmware for radios, GPUs, GPS, etc., etc., is all closed, proprietary code written by the component manufacturer and kept secret even from the OEMs. I don't have any idea how we can fix that.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    20. Re:The solution is horribly obvious by sjames · · Score: 1

      In a cellphone, the radio is the worst of the bunch. It has the ability to snoop on the main CPU and controls the boot process. that's why rooting many Android phones involves re-flashing the radio. An actual free and open radio probably isn't permitted by the FCC and other nation's equivalents around the world, but I would like to see it demoted to just another component with a narrow interface to the main system. Preferably it would require the cpu to feed it digitized audio rather than having a direct connect to the microphone.

    21. Re:The solution is horribly obvious by swillden · · Score: 1

      In a cellphone, the radio is the worst of the bunch. It has the ability to snoop on the main CPU and controls the boot process.

      I've heard that said by many people, but as far as I can tell by examining the architecture of the devices I've worked on, it's not true. The baseband radio does have DMA access, like most every peripheral, but it doesn't have any special sort of access to the CPU.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    22. Re:The solution is horribly obvious by sjames · · Score: 1

      If there isn't an IOMMU, DMA access is enough to overwrite any code in the system, and so control the CPU.

    23. Re:The solution is horribly obvious by swillden · · Score: 1

      There is an IOMMU. Among other things, TrustZone relies on it.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    24. Re:The solution is horribly obvious by sjames · · Score: 1

      I should be more specific, an IOMMU exclusively controlled by the CPU. In this case, the secure side necessarily controls it (or it wouldn't be secure), not the user side. This makes the user side at the secure side's mercy. A narrow interface would leave the radio secure, but would also make the user side secure from the radio.

    25. Re:The solution is horribly obvious by swillden · · Score: 1

      I should be more specific, an IOMMU exclusively controlled by the CPU. In this case, the secure side necessarily controls it (or it wouldn't be secure), not the user side. This makes the user side at the secure side's mercy. A narrow interface would leave the radio secure, but would also make the user side secure from the radio.

      The IOMMU is controlled by the CPU, by which I mean the AP (application processor). The non-secure mode software (EL0 and EL1) controls most of its configuration, including allocating DMA pages for the baseband, though it can't override the configuration provided by the secure mode (EL3). That's my understanding, anyway. Most of my work is at a slightly higher level.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    26. Re:The solution is horribly obvious by sjames · · Score: 1

      The difference may just be the phones we're dealing with. Do the ones you've worked with/on do locked bootloader/network? The ones I've seen do, and use the processor in the radio to lock it down. It may be the ones you know of simply don't do that. It could also be a matter of the generation of phone. My knowledge is a couple years out of date at this point.

      There is still the question of the radio though. Does it have independent access to the microphone or does it depend on the AP for that? can it access the GPS without help?

  4. This fella shopuld get a lawyer... by bogaboga · · Score: 1

    He published a step-by-step guide on how one can break down the encryption protections on Android devices powered by Qualcomm Snapdragon processors.

    I do not think Qualcomm or Google will be impressed.

    My advice to him: "Get a lawyer, quick!"

    1. Re: This fella shopuld get a lawyer... by Anonymous Coward · · Score: 0

      Or just don't go to that big, stupid country over there.

  5. And this is why DRM is bad... mmmkay? by WorBlux · · Score: 1

    And exploit of the widevine DRM subsystem running in trust-zone. The second exploit is possible because you don't control the keys to the kingdom.

  6. Aww by Anonymous Coward · · Score: 0

    Snap

    1. Re:Aww by Anonymous Coward · · Score: 0

      dragon, yes.

  7. Not feasible against a good password. by BitterOak · · Score: 4, Interesting

    I read the article and it looks like this exploit merely allows offline brute forcing of the password. Now, of course, many people choose short passwords on their portable devices, but if you choose a password with sufficient entropy (at least 100 bits, or better yet, 128) you should be safe from this attack. Note: that would require a fairly long and random alphanumeric password.

    --
    If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
    1. Re:Not feasible against a good password. by Anonymous Coward · · Score: 0

      Achieving a greater number of high-entropy key bits is always desirable, but in cases like this it's really the choice of key derivation function(s) that tends to have the largest practical impact on long term security across a large user base. -PCP

    2. Re:Not feasible against a good password. by Anonymous Coward · · Score: 0

      Yes, for a large user base.

      But for an individual that can understand the concept of entropy (admittedly rare creatures), higher-entropy keys are the way to go.

    3. Re:Not feasible against a good password. by AmiMoJo · · Score: 1

      Additionally, they need to get to your phone in an unlocked state. As soon as you power off or reboot the key is lost.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    4. Re: Not feasible against a good password. by bill_mcgonigle · · Score: 1

      Just MMS them a malformed mp4.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    5. Re: Not feasible against a good password. by nehumanuscrede · · Score: 1

      not to point out the obvious, but no one is going to use a giant password they have to put in via the tiny little keyboard on the phone everytime they want to use it.

      Great from a security standpoint, not so much from a convenience one.

    6. Re: Not feasible against a good password. by AmiMoJo · · Score: 1

      If you are including old, long patched vulnerabilities then why not just steal the encrypted information directly from the victim's phone? Encryption doesn't mitigate that threat on any system, that's not what it's for.

      Encrypted protects you from law enforcement and theft.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  8. Easier ways by Anonymous Coward · · Score: 0

    Why not just uncompressed the initramfs, load a binary or other tool to siphon off the users pw on key entry?

    The kernel is unencrypted as the system needs to boot from it

    1. Re:Easier ways by Shakrai · · Score: 1

      That assumes you can get the user's device from them without their knowledge. Such an attack is feasible on desktops, and many laptops, but phones are the one electronic device even layman carry with them EVERYWHERE. When was the last time your phone was out of your immediate sight and direct control?

      --
      I want peace on earth and goodwill toward man.
      We are the United States Government! We don't do that sort of thing.
    2. Re:Easier ways by vux984 · · Score: 1

      When was the last time your phone was out of your immediate sight and direct control?

      5-8 hours per night. plus the odd nap. plus when i leave it in the locker at the pool or gym. There are some other times too... like swimming at the beach.

      That assumes you can get the user's device from them without their knowledge.

      Just steal it from them when they are out and about. Sure they'll know its gone missing. So what? You want what's on it, it doesn't always matter if they know or not -- and most of us aren't paranoid enough to assume it was the men in black helicopters and not just some random theif. Phones get stolen ALL THE TIME.

      Hell, you can even plant something on it, and then return it to them... turn it into the carrier or lost and found or the police or something; odds are they'll be so happy/surprised that it turned up again they won't even think that it was hacked.

    3. Re:Easier ways by swillden · · Score: 1

      Why not just uncompressed the initramfs, load a binary or other tool to siphon off the users pw on key entry?

      The kernel is unencrypted as the system needs to boot from it

      If you modify the boot image on a Marshmallow device, the screen will notify the user during boot that verification failed. On a Nougat device I believe it will refuse to boot.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    4. Re:Easier ways by swillden · · Score: 5, Interesting

      Hell, you can even plant something on it, and then return it to them... turn it into the carrier or lost and found or the police or something; odds are they'll be so happy/surprised that it turned up again they won't even think that it was hacked.

      Planting something on it isn't so easy if it's locked. But, really, you don't have to do that. Want to get into someone's phone? Here's how:

      Buy an identical device. Get a good look at theirs so you can put similar scratches, cover, lockscreen background, etc. on it. Configure your device to send the password they enter to you. Steal theirs and leave yours in its place. When they enter your password, you get it and use it to get into their device. To keep it from being obvious that their device has been replaced, have it refuse to "unlock" no matter what they enter. This also helps you in the event they get their password wrong the first time, because they'll helpfully re-enter it. Meanwhile, they'll think their password on their phone has gotten messed up.

      This works on *any* model... Android, iPhone, Windows phone, Blackberry... you name it.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    5. Re:Easier ways by Shakrai · · Score: 1

      and most of us aren't paranoid enough to assume it was the men in black helicopters and not just some random theif.

      The point is that the people who do have something to hide are apt to be that paranoid, so this attack vector isn't as useful as it might seem. Then again, I suppose that many criminals are idiots, and I could see some of them being stupid enough to enter a passphrase even if the device was handed back to them by the detective running their case. Hell, they'd probably unlock it on their way out of the station to text their buddies about how they beat the system. That's pretty low hanging fruit though.

      Personally, I have little worth hiding, but I would not key a FDE passphrase into any device that I had reason to believe was no longer trustworthy. At the very least a lost and found device is getting a full reset and ROM reload. It's the same approach to dealing with malware; it never ceases to amaze me how many otherwise smart IT folks think they can "clean" a compromised system. There is no "cleaning" a compromised system, you blow it away and rebuild it. Anything short of this invites disaster and should it strike you deserve what you get.

      --
      I want peace on earth and goodwill toward man.
      We are the United States Government! We don't do that sort of thing.
    6. Re:Easier ways by Anonymous Coward · · Score: 0

      That's one reason I wouldn't want to be a criminal. If the investigator handed me my phone, I might just tap the home button to check messages, completely unlocking the device...

      However, this doesn't mean I don't encrypt stuff. There are more than just legit LEOs out there who want data, be it thieves who want to use the phone for blackmail or extortion, people who would use the info to affect my job or health insurance costs.

      Then, there is the fact that there are international treaties of extradition. Start bitching about the Thai royals in one country, in theory, one can be hauled off to ol' Siam for a long prison sentence for lese majeste violations. Same with the Saudi Arabia/EU extradition treaties. In theory, someone in Germany who might hand out a flyer for the Flying Spaghetti Monster can be hauled to Riyadh and beheaded because of heretic laws.

      Encryption raises the bar. If a blackhat wants the data, they have to mount active attacks to get it, and it is a lot more expensive to $5 wrench a bunch of people actively than it is to just sniff an unencrypted data stream.

  9. Already patched by swillden · · Score: 1

    For devices that get regular updates the Qualcomm TrustZone bug has already been fixed. It went out in the January 2016 updates: https://source.android.com/sec.... Check the patchlevel date on your device.

    Of course the other part, that someone who can compel Qualcomm to sign TrustZone software images that intentionally compromise security, is still the case, and likely will be for some time. That's a threat model that hadn't been considered important until recently, and it's one that's not easy to mitigate. That's not restricted to Qualcomm, either. In every device with a trusted execution environment, there's some organization who holds the signing keys needed to load firmware in that environment, generally (but not always) the SoC vendor.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    1. Re:Already patched by hawguy · · Score: 1

      For devices that get regular updates the Qualcomm TrustZone bug has already been fixed. It went out in the January 2016 updates: https://source.android.com/sec.... Check the patchlevel date on your device.

      Of course the other part, that someone who can compel Qualcomm to sign TrustZone software images that intentionally compromise security, is still the case, and likely will be for some time. That's a threat model that hadn't been considered important until recently, and it's one that's not easy to mitigate. That's not restricted to Qualcomm, either. In every device with a trusted execution environment, there's some organization who holds the signing keys needed to load firmware in that environment, generally (but not always) the SoC vendor.

      Can't this hole be closed by designing the trusted firmware so it requires that the passcode be entered before it will accept a firmware update?

    2. Re:Already patched by 110010001000 · · Score: 0

      "Older than that"? May was 31 days ago. Christ. Fix your shit Google.

    3. Re:Already patched by 110010001000 · · Score: 0

      Oh yeah Grandma: "check the patchlevel of your device". Android is such a clusterfuck.

    4. Re:Already patched by swillden · · Score: 1

      Can't this hole be closed by designing the trusted firmware so it requires that the passcode be entered before it will accept a firmware update?

      Yes, but it's tricky, particularly because it's not that hard to open the device and write an updated firmware blob to flash directly, bypassing any software-based gatekeeping checks. There are ways to address that, but they raise subtle issues in turn, and ways to address those, but they raise more issues. At root, the existence of Replay Protected Memory Blocks in eMMC controllers makes it feasible to have small amounts of non-volatile storage that an attacker probably can't write to, which I believe makes it feasible. But it's far from simple, especially within all of the other performance, cost, testability and other constraints.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    5. Re:Already patched by swillden · · Score: 1

      Oh yeah Grandma: "check the patchlevel of your device".

      Well, the right answer is to buy a device that has a published support policy that includes monthly security patches. Then you don't have to check the patchlevel (which actually isn't tough, even for Grandma: It's just a date and she's perfectly capable of understanding it), because you know it's good. Maybe someday consumers will demand that of all Android devices. At present, they don't, and manufacturers give them what they want.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    6. Re:Already patched by 110010001000 · · Score: 0, Offtopic

      Oh yeah grandma: "buy a device that has a published support policy". Christ. No wonder Apple is selling so many iPhones.

    7. Re:Already patched by swillden · · Score: 1

      Oh yeah grandma: "buy a device that has a published support policy". Christ. No wonder Apple is selling so many iPhones.

      Well, she knows to look at the warranty when she buys a car.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    8. Re:Already patched by Anonymous Coward · · Score: 0

      No wonder Apple is selling so many iPhones.

      Obviously it's all about the support.

    9. Re: Already patched by Anonymous Coward · · Score: 1

      No, it's not JUST buy a device with a patch policy you trust, it is buy a device from a vendor you trust, with a patch policy you trust, and also go and do a bunch of research into the vendors to figure out which ones you can trust, and way MORE research to figure out the patch policy you can trust.

      Or just buy and iPhone and skip the degree in this field that you don't have any interest in.

    10. Re: Already patched by Anonymous Coward · · Score: 0

      or buy apple instead

    11. Re: Already patched by vbguyny · · Score: 0

      No. Buying any Apple product is always a bad move.

    12. Re: Already patched by sexconker · · Score: 1

      Alternatively, don't store sensitive information on your phone.

    13. Re:Already patched by drinkypoo · · Score: 1

      Well, she knows to look at the warranty when she buys a car.

      Does she? And if she does, will she? Or will she just ask them a couple of questions about it like how long is it and what does it cover, and then move on? Legal contracts are difficult for anyone to understand, is your grandmother a lawyer?

      To be fair, Apple's legalese is plenty long.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    14. Re: Already patched by Anonymous Coward · · Score: 0

      Well it's a good thing for hackers that android phones don't get updated :P

    15. Re:Already patched by Anonymous Coward · · Score: 0

      Oh yeah Grandma: "check the patchlevel of your device". Android is such a clusterfuck.

      And what grandma would actually have anything that she would want to keep secure using full disk encryption? Most grandmas would be more at risk of phishing/scamming rather then a low level hack like this...
      Although, as I am writing this, my thoughts do go to the old lady down the street here who is rumoured to be dealing drugs for one of her kids... :\

  10. Already patched by Anonymous Coward · · Score: 0

    The 2 holes used here have been patched, in January and May. If your phone software is older than that, well... Get on your device manufacturer's ass about not offering timely updates, or root and install an updated ROM yourself.

    CVE-2015-6639: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-6639
    CVE-2016-2431: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2431

  11. Re:Linux is dying by Anonymous Coward · · Score: 0

    You still haven't explained why systemd is so bad.

    It's on my Linux desktops and I haven't had a problem with it.

  12. This just in... by vbguyny · · Score: 1

    All encryption can be eventually cracked. More at 11.

    1. Re:This just in... by sexconker · · Score: 1

      Not NULL encryption.

  13. Password Strength by Anonymous Coward · · Score: 0

    It sounds like the strength of the full-disk would be no better than the strength of the password, pin number, of whatever else is used. Anything that you could conveniently and quickly input to unlock you phone could be easily brute-forced offline.

    It may be time to start keeping the disk-keys in a NFC/RFID pendant that the user wears around their neck. They could unlock their phone in a split second by just waving it past. This would be convenient, user friendly, and moderately non-trivial to get to without the user noticing (and could be easily ditched or destroyed in a hurry in case, for example, the phone found it's way into the hands of someone with subpoena powers)

  14. It may not be so bad afterall... by mlts · · Score: 1

    The original Android implementation of dm-crypt generates a -random- key in Android 5.0, which is the key used for encryption. It then encrypts that key with the user's passphrase/PIN/whatever. This implementation is pretty secure, because other than active RAM attacks, when the phone starts up, it will ask for the decryption key for /data, and no key, no decryption.

    From what I have looked at with CyanogenMod, this ROM uses the "old fashioned way". No TrustZone, no fancy footwork with keys... just a relatively simple prompt for the passphrase at the phone startup so /data can be mounted and used. From there, the VEK (volume encryption key) is in RAM, and the screen lock is used. This is simple, but effective.

    1. Re:It may not be so bad afterall... by hankwang · · Score: 1

      "CyanogenMod (...) uses the "old fashioned way". No TrustZone, no fancy footwork with keys... just a relatively simple prompt for the passphrase at the phone startup so /data can be mounted and used."

      I'm using CM13 (Android 6/Marshmallow), which uses FDE, yet can boot without password prompt, just like stock Android 6. It will present the lock screen though. Leaving aside the security of a booted and connected phone with only the lock screen as a protection, the only way to do this seems to be to use some kind of trusted execution environment. Otherwise, you could pull the entire encrypted data partition over USB from the (obviously non-stock) boot loader and have all the necessary data to decrypt it offline.

      --
      Avantslash: low-bandwidth mobile slashdot.
  15. Make the manufacturer key replaceable by cciechad · · Score: 1

    Seems like the solution would be to allow users to wipe the manufacturer key and install their own. Although they probably don't want to do this with all their signed bootloaders and code.

    --
    https://www.fsf.org/associate/support_freedom
  16. Same method or or less as cracking iPhone by Anonymous Coward · · Score: 0

    As long as the key store is protected by something as simple as a password or finger print, it shouldn't be a problem

  17. Backdoors are always bad by markdavis · · Score: 1

    >" The researcher also said Qualcomm or OEMs can comply with government or law enforcement agencies to break the FDE: "Since the key is available to TrustZone, Qualcomm and OEMs could simply create and sign a TrustZone image which extracts the KeyMaster keys and flash it to the target device," Beniamini wrote. "This would allow law enforcement to easily brute force the FDE password off the device using the leaked keys." "

    Which also means ANYONE it was leaked to can do the same thing- criminals, spies, malware, other governments, etc. Which is why having backdoors is always bad.

  18. Surprised by nehumanuscrede · · Score: 1

    this was made public knowledge before the FBI could classify it as a National Security secret.

  19. why ChromeOS requires a real TPM by Anonymous Coward · · Score: 0

    This is why ChromeOS devices, even ARM ones, require a real TPM chip, not this second-rate arm "zone" nonsense. The arm features are meant for DRM, so they only need be good enough to convince greedy studio execs. To convince engineers who care about privacy, you need a TPM.

    It is one of many ways Android is in clown-mode compared to ChromeOS.

    I would like to know if the attack could generalize to iOS. I also note, Macs have no TPM.

  20. Explain something to me. by chasm22 · · Score: 1

    From the article in The Hacker News, "Once getting hold of this key, an attacker could perform a brute-force attack to grab the user password, PIN or lock, cracking Android's full disk encryption."

    Why not just get the user password by brute force attack to begin with since it will unlock the encrypted files for you? I know I'm missing something. If you go through this process only to wind up having to mount a brute force attack, what is gained?

    1. Re:Explain something to me. by JesseMcDonald · · Score: 1

      Why not just get the user password by brute force attack to begin with since it will unlock the encrypted files for you?

      Because the user's password won't let you unlock the encrypted files, at least not on its own. The password works in conjunction with a much stronger key randomly generated by the device itself. To decrypt the files you need both the device key and the user's password. The key is normally only available to software running inside the TrustZone, which limits the number and frequency of authentication attempts. This exploit allows an attacker to retrieve the device-specific key from the TrustZone, but they still need the password to use it. Fortunately for the attacker, human-memorable passwords are comparitively simple to break. The alternative would be brute-forcing the decryption key directly, which is effectively impossible—the human race would probably go extinct first, even assuming theoretically ideal computers and the dedication of every resource at our disposal with single-minded focus toward breaking this one key.

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
  21. Re:QSEE deez nuts by Anonymous Coward · · Score: 0

    You use Google, Chrome, and Facebook?

    Will the real stupid fucker please stand up.

  22. Re:QSEE deez nuts by Anonymous Coward · · Score: 0

    https://kat.cr/tails-1-4-1-i386-iso-multilang-tntvillage-t10922671.html
    http://lsuzvpko6w6hzpnn.onion/tails-1-4-1-i386-iso-multilang-tntvillage-t10922671.html
    http://i.imgur.com/QLGyQYf.jpg

    Solved.