19 ms·

Extracting Qualcomm's KeyMaster Keys – Breaking Android Full Disk Encryption

341 points by laginimaineb 10y ago

coldcode 10y ago
Since the security of Android depends on hardware and OEM software not under Google's control, depending on FDE is apparently pointless. I guarantee Google really wants to build their own branded phones with their own secure Android version and gain Apple's advantages in building secure systems because you own everything.
- eli 10y ago
  The (thinly sourced) rumor is that Google wants to build a new phone from scratch, a separate project from Nexus
  - Nullabillity 10y ago
    ARA?
    - jonesetc 10y ago
      Nope, that's the modular phone. This is talking about a standard phone manufactured by Google.
  - arviewer 10y ago
    For this to work they only need one little chip that can do what the secure enclave does. They can then require that chip in Android phones. That's a lot cheaper and easier. Then they need to control the manufacturing of this chip, not outsource it to China.
    - nowey 10y ago
      If only they had an OEM to do this, with a plant in Texas....
- Arnt 10y ago
  Are you guaranteeing that Nexus phones exist, or that Google will introduce a second line of phones?
  - libeclipse 10y ago
    Google don't manufacture the Nexus.
    - iamben 10y ago
      But they had a chance (and didn't) to bring that all in house with the Motorola buy, no?
      - JustSomeNobody 10y ago
        Google wanted and kept most of the patents.
- pfg 10y ago
  This vulnerability does not make FDE pointless per se. It means that your security depends completely on the complexity of your passphrase (like the iPhone prior to the introduction of Secure Enclave). Which is still fairly bad given the typical passcode complexity on phones.
- arviewer 10y ago
  > Since the security of Android depends on hardware and OEM software not under Google's control, depending on FDE is apparently pointless. For 99% of the users, this is complete nonsense. Why do we encrypt the phone? Are we afraid of the NSA or whatever agency cracking our phones? No! The reason most of us encrypt the phone is to prevent others from posting our pictures or reading our mail. When somebody else finds my phone, or steals it, the four digit PIN is enough protection. Then again, I don't use a four digit PIN, but something longer, and from six or up it's really strong enough for manual unlocking. People who have the means to read contents from the memory chips, they probably have the means to use other measures to get what they want.
  - nitrogen 10y ago
    There are levels of threat and protection between those you mentioned. As the threat from people with access to "other measures" increases, you moght at least want to make them work for it and have to go through proper channels.
  - jonknee 10y ago
    Businesses typically have rules about securing data, that covers a lot of users.
  - drauh 10y ago
    It runs the 2-factor app that secures my online accounts, which may or may not include banking.
- toyg 10y ago
  > I guarantee Google really wants to build their own branded phones Considering they just sold for scrap an entire manufacturing pipeline to do exactly that, I'd say they really don't. If they do, they're going about it in the silliest and most roundabout way.
arrty88 10y ago
Would love to see the same analysis on Samsung hardware
- laginimaineb 10y ago
  I'll definitely try and get around to it sometime soon. However, I wouldn't be surprised if the situation is the same... After all, the KeyMaster module was initially only meant to keep encryption keys on the device, not to safeguard FDE.
  - pdimitar 10y ago
    Sorry for an extremely nooby question, but your comment makes me wonder: Are Snapdragon and Exynos architectures that alike? I mean, do you have any preliminary idea how easy it would be to apply your Snapdragon method to an Exynos SoC?
    - laginimaineb 10y ago
      Actually, I would imagine they are nothing like one another. However, Exynos uses a TrustZone TEE implementation to implement the KeyMaster module, just like Qualcomm's Snapdragon. This means that unless that TEE implementation uses a hardware key which is not software accessible, the same issue would be present. Of course, reverse-engineering a new TEE implementation would take a long time... But it sounds like it could be fun.
      - pdimitar 10y ago
        Thank you. You should be aware that people like you are unsung heroes and I'd like you to know that many of us who are busy struggling to stay afloat are feeling better knowing that people like you are doing the work you do. Have that in mind. I wish you well.
bognition 10y ago
Fascinating article, the more I learn about crypto and security the more obvious it becomes how hard this stuff is to get right.
- nxzero 10y ago
  There is no getting it "right" just less wrong; aka "perfect" security does not exist.
  - drewbug 10y ago
    Isn't that still an open question?
    - JustSomeNobody 10y ago
      Maybe in the sense that one can ever really prove it to be "perfect".
  - userbinator 10y ago
    "perfect" security does not exist. For that matter, I think what "perfect security" could be like is the world in Orwell's 1984 --- definitely not something I'd want existing either.
    - msh 10y ago
      Even that was not perfect.
- zeveb 10y ago
  You know, I'm not really all that certain that it's intellectually difficult to get crypto right; it feels more likely that it's organisationally and process-wise difficult to get crypto right. What I mean is that folks want to take an existing product and layer crypto atop it, when really they need to start from the crypto and built a product over it. They want to do things which are mathematically impossible (e.g. let you read data, but not let you say that data to someone else). They want to hand the crypto to a junior developer instead of someone who knows what he's doing. Crypto's not hard to do; organisations are bad at doing crypto.
AdmiralAsshat 10y ago
Unfortunately, it seems as though fixing the issue is not simple, and might require hardware changes. So any Android phone currently on the market is basically unfixable?
- laginimaineb 10y ago
  I believe so.
  - jhallenworld 10y ago
    Well hold on.. there are several issues. One is that there is an exploit allowing arbitrary code execution in the trustzone. This immediate problem should be fixed. The second is that allowing a firmware updates to trustzone code means that Google could push an update which allows them to retrieve keys. Such updates should only be allowed if the user accepts them. How the user is supposed to know the difference between a security fix vs. Google trying to break into their phone is the real issue. But IOS has this same issue. If you accept a firmware update from Apple, maybe it includes a pin logger.
    - laginimaineb 10y ago
      You're right. Let's take a second to go over the issues: 1. The arbitrary code-execution in TZ has already been privately disclosed and fixed. 2. As for the second issue - I would argue that it's not an issue at all. TZ should be updated (otherwise how would they fix the TZ code-exec vulnerabilities?). However, in this case gaining code execution in the TZ kernel directly leads to the disclosure of the keys which are meant to bind the KDF to your device. This is in direct contract with Apple's KDF. The key here is that software shouldn't be trusted, by design. 3. As for the last issue, I would argue that this is just a clever form of social-engineering. After all, who's to say they didn't just swap the phone with a dummy phone to make you insert the correct password? However, in Android's case, you wouldn't even need to cooperate. OEMs could simply flash the new TZ code, extract the KeyMaster keys, and bruteforce the key. All without having any help from you.
  - 10y ago
devit 10y ago
It doesn't really break the encryption, as long as the password is strong enough to prevent brute forcing. Relying on a weak password and a "trusted computing" mechanism like this one from Qualcomm to prevent an attacker with physical access from brute forcing it is not really advisable. Using such a mechanism at all has downsides since it means that you lose the data if the mechanism or the entire device stops working, while otherwise you could simply move the SSD/flash/storage unit to a new identical device and have it just work as long as you type the correct password.
- lxgr 10y ago
  But how many Android users do you know that actually have a strong password? (Speaking of which: Google's decision to not allow strong encryption passwords together with short screen unlock PINs/patterns is not helping here. It's actually possible, but they don't expose the user interface to change them separately, probably for usability reasons.) Also, while I would agree as far as PCs are concerned, moving the eMMC to a new phone's mainboard is probably also not a likely scenario.
  - userbinator 10y ago
    moving the eMMC to a new phone's mainboard is probably also not a likely scenario. Data recovery is, however, which is why I don't think one-sided promotion of ubiquitous hardware-locked-FDE is a good idea --- it becomes a tradeoff between others getting access to, and you losing access to, your data. Is it more important that this data be accessible by no one but you even if it means you might also lose access to it, or that you not lose access, even if it means others can access it? Hardware-locked FDE is suited only to the former case.
    - 616c 10y ago
      As someone who deals with hardware-backed encryption in laptops, it's a huge pain. Modern phones are worse. I was at a training and happened to sit with computer forensicators and they complain about the new eMMC systems. Forensics systems for mobile devices were a piece of cake prior to that. I suspect the eMMC thing is meant to make this difficult on purpose. So, so much for that ...
dcdevito 10y ago
https://www.appmobi.com https://www.appmobi.com the only way to fly
sdl 10y ago
So if I understood correctly, there are 5 requirements for such a system to be secure: 1: secure/unmodifiable cryptographic processor 2: with unremovable rate limiting 3: and exclusive access to a hardware key 4: cryptographic processor has the only function of encrypting user data based on 5: hardware key and a user supplied pin/key Errors done by Qualcomm: Violated 3: Hardware key not exclusivly readable by cryptographic processor Violated 5: Encryption based on derived key Anything I overlooked? (edited: formatting)
woumn 10y ago
If anyone is interested when the author talked about an overview of the iOS security measures, I created a more in-depth review that is an easy read and gives you a good over-view of the security architecture used. I'm happy to hear feedback if you enjoy it. The blog can be found at: https://woumn.wordpress.com/2016/05/02/security-principles-in-ios-architecture/ https://woumn.wordpress.com/2016/05/02/security-principles-i...
koolba 10y ago
Full disk encryption (FDE) is a UX issue, not a technical one. You don't need a secure cryptographic processor, but the UX sucks without one. A simple, working, FDE setup would be something like LUKS running at boot: 1. Turn on phone 2. Phone loads up initial bootstrap OS 3. Phone prompts user for master key 4. Master key is used to unlock volume 5. Regular OS boot continues If the master key has enough entropy, brute forcing it becomes impossible. The phone won't "disable" as there's no self-destructing component (i.e. "secure crypto chip") but that doesn't mean it can be cracked. Boil as many oceans as you'd like, you're not going to brute force 256 bits of entropy. The UX problem is that the master key is a PITA to enter if it's long enough to be cryptographically secure. That's what a crypto chip is supposed to solve. A limited number of attempts with a shorter passphrase.
- williamscales 10y ago
  Wait, Android doesn't use LUKS? Argh. Just give me a stinkin' smartphone that runs Linux. These are solved problems, people.
  - halviti 10y ago
    Jolla / Sailfish ?
  - josteink 10y ago
    Last I checked, it does. I'm pretty sure for instance the Nexus 5X relies on standard LUKS for FDE. What may be protected through other means is the key used to encrypt that filesystem. The user enters a pin or a pattern to unlock said key on boot, and that key is used to initiate LUKS. Maybe that's what they have cracked here?
  - Sarkie 10y ago
    Isn't Android running a really old Linux because they can't rebase? So they have to cherry pick... or has that stopped now?
    - kllrnohj 10y ago
616c 10y ago
So out of curiosity, as someone who has a nontrivial passcode on his Android device that people constantly mock, how many characters are we talking to be safe. I have known for a long time 4 digit numeric PINs are stupid. Sadly the San Bernadino case, for all the wrong reasons, taught me all the alternative auth methods are just as risky. Should I be worried? I don't know. But as a long time Android enthusiast and power user who does not use Google Play on his phone and restrictive permission customization like XPrivacy, I am about to just give up and have a newish iPhone for secure stuff and knock around Android for the cool open source dev I aspire to with F-Droid.
- snassar 10y ago
  A friend saw me entering my longish, non-trivial passphrase into my android phone and commented that I must not have many friends if I have to enter this passphrase every time to use my phone. For a moment I was torn between being proud in my passphrase and sad at my lack of friends.
  - gcr 10y ago
    You bring up an interesting UX issue. If I need to be constantly available to my friends, "number of seconds to a text reply" is something that I need to minimize. Longer passphrases prevent me from sending quick replies.
    - 616c 10y ago
      Some of my more sophisticated friends take this a step further and taunt me for not securely hiding notifications and buying a smart watch. This confuses me because Bluetooth over the air does not strike me a secure mechanism (is it just Bluetooth; ironically scant detail unless my Google-fu is off, likely at this hour for me). http://www.wareable.com/android-wear/android-wear-hack-alert-signalled-by-security-expert-581 http://www.wareable.com/android-wear/android-wear-hack-alert... And do I need yet another smart device? The mobile first movement, with shinier crap, moving away from standard protocols, leads me to believe I have been passively perpetuating the biggest wart on computer science's labors. I am kind of embarassed, a few years in and late to the party, I bought an Android phone at all.
nickik 10y ago
I would use a longer password. But currently the unlock and the encryption password are always the same. That one of the issue I would like to see changed. I would also like to have more fine grained rules on when I can unlock with a fingerprint, when pin and when I should be forced to put in the encryption password. Additionally I would like to use U2F NFC token on my keychain as a second factor for unlock (if I have not touched the phone for X amount of time).
- ysleepy 10y ago
  You can make it use long FDE passwords and a pattern by hackery. Some sqlite fiddling necessary. See XDA.
ysleepy 10y ago
If your device is rooted, you can use a long password for encryption and a pattern or even no lock for the lockscreen. I have set it up this way, it needed some sqlite hackery. XDA dev has appropriate infos.
pooze 10y ago
Could someone explain how and why it uses "0x1337" in order to validate the key? Is that magic? https://github.com/laginimaineb/android_fde_bruteforce/blob/master/keymaster_mod.py#L43 https://github.com/laginimaineb/android_fde_bruteforce/blob/...
- rimantas 10y ago
  Isn't that just m = (m^e mod n)^d mod n? So the value itself does not matter, you could use 42 instead of 0x1337.

341 points by laginimaineb 10y ago

Since the security of Android depends on hardware and OEM software not under Google's control, depending on FDE is apparently pointless. I guarantee Google really wants to build their own branded phones with their own secure Android version and gain Apple's advantages in building secure systems because you own everything.

eli 10y ago
The (thinly sourced) rumor is that Google wants to build a new phone from scratch, a separate project from Nexus
- Nullabillity 10y ago
  ARA?
  - jonesetc 10y ago
    Nope, that's the modular phone. This is talking about a standard phone manufactured by Google.
- arviewer 10y ago
  For this to work they only need one little chip that can do what the secure enclave does. They can then require that chip in Android phones. That's a lot cheaper and easier. Then they need to control the manufacturing of this chip, not outsource it to China.
  - nowey 10y ago
    If only they had an OEM to do this, with a plant in Texas....
Arnt 10y ago
Are you guaranteeing that Nexus phones exist, or that Google will introduce a second line of phones?
- libeclipse 10y ago
  Google don't manufacture the Nexus.
  - iamben 10y ago
    But they had a chance (and didn't) to bring that all in house with the Motorola buy, no?
    - JustSomeNobody 10y ago
      Google wanted and kept most of the patents.
pfg 10y ago
This vulnerability does not make FDE pointless per se. It means that your security depends completely on the complexity of your passphrase (like the iPhone prior to the introduction of Secure Enclave). Which is still fairly bad given the typical passcode complexity on phones.
arviewer 10y ago
> Since the security of Android depends on hardware and OEM software not under Google's control, depending on FDE is apparently pointless. For 99% of the users, this is complete nonsense. Why do we encrypt the phone? Are we afraid of the NSA or whatever agency cracking our phones? No! The reason most of us encrypt the phone is to prevent others from posting our pictures or reading our mail. When somebody else finds my phone, or steals it, the four digit PIN is enough protection. Then again, I don't use a four digit PIN, but something longer, and from six or up it's really strong enough for manual unlocking. People who have the means to read contents from the memory chips, they probably have the means to use other measures to get what they want.
- nitrogen 10y ago
  There are levels of threat and protection between those you mentioned. As the threat from people with access to "other measures" increases, you moght at least want to make them work for it and have to go through proper channels.
- jonknee 10y ago
  Businesses typically have rules about securing data, that covers a lot of users.
- drauh 10y ago
  It runs the 2-factor app that secures my online accounts, which may or may not include banking.
toyg 10y ago
> I guarantee Google really wants to build their own branded phones Considering they just sold for scrap an entire manufacturing pipeline to do exactly that, I'd say they really don't. If they do, they're going about it in the silliest and most roundabout way.

arrty88 10y ago

Would love to see the same analysis on Samsung hardware

laginimaineb 10y ago
I'll definitely try and get around to it sometime soon. However, I wouldn't be surprised if the situation is the same... After all, the KeyMaster module was initially only meant to keep encryption keys on the device, not to safeguard FDE.
- pdimitar 10y ago
  Sorry for an extremely nooby question, but your comment makes me wonder: Are Snapdragon and Exynos architectures that alike? I mean, do you have any preliminary idea how easy it would be to apply your Snapdragon method to an Exynos SoC?
  - laginimaineb 10y ago
    Actually, I would imagine they are nothing like one another. However, Exynos uses a TrustZone TEE implementation to implement the KeyMaster module, just like Qualcomm's Snapdragon. This means that unless that TEE implementation uses a hardware key which is not software accessible, the same issue would be present. Of course, reverse-engineering a new TEE implementation would take a long time... But it sounds like it could be fun.
    - pdimitar 10y ago
      Thank you. You should be aware that people like you are unsung heroes and I'd like you to know that many of us who are busy struggling to stay afloat are feeling better knowing that people like you are doing the work you do. Have that in mind. I wish you well.

bognition 10y ago

Fascinating article, the more I learn about crypto and security the more obvious it becomes how hard this stuff is to get right.

nxzero 10y ago
There is no getting it "right" just less wrong; aka "perfect" security does not exist.
- drewbug 10y ago
  Isn't that still an open question?
  - JustSomeNobody 10y ago
    Maybe in the sense that one can ever really prove it to be "perfect".
- userbinator 10y ago
  "perfect" security does not exist. For that matter, I think what "perfect security" could be like is the world in Orwell's 1984 --- definitely not something I'd want existing either.
  - msh 10y ago
    Even that was not perfect.
zeveb 10y ago
You know, I'm not really all that certain that it's intellectually difficult to get crypto right; it feels more likely that it's organisationally and process-wise difficult to get crypto right. What I mean is that folks want to take an existing product and layer crypto atop it, when really they need to start from the crypto and built a product over it. They want to do things which are mathematically impossible (e.g. let you read data, but not let you say that data to someone else). They want to hand the crypto to a junior developer instead of someone who knows what he's doing. Crypto's not hard to do; organisations are bad at doing crypto.

AdmiralAsshat 10y ago

Unfortunately, it seems as though fixing the issue is not simple, and might require hardware changes. So any Android phone currently on the market is basically unfixable?

laginimaineb 10y ago
I believe so.
- jhallenworld 10y ago
  Well hold on.. there are several issues. One is that there is an exploit allowing arbitrary code execution in the trustzone. This immediate problem should be fixed. The second is that allowing a firmware updates to trustzone code means that Google could push an update which allows them to retrieve keys. Such updates should only be allowed if the user accepts them. How the user is supposed to know the difference between a security fix vs. Google trying to break into their phone is the real issue. But IOS has this same issue. If you accept a firmware update from Apple, maybe it includes a pin logger.
  - laginimaineb 10y ago
    You're right. Let's take a second to go over the issues: 1. The arbitrary code-execution in TZ has already been privately disclosed and fixed. 2. As for the second issue - I would argue that it's not an issue at all. TZ should be updated (otherwise how would they fix the TZ code-exec vulnerabilities?). However, in this case gaining code execution in the TZ kernel directly leads to the disclosure of the keys which are meant to bind the KDF to your device. This is in direct contract with Apple's KDF. The key here is that software shouldn't be trusted, by design. 3. As for the last issue, I would argue that this is just a clever form of social-engineering. After all, who's to say they didn't just swap the phone with a dummy phone to make you insert the correct password? However, in Android's case, you wouldn't even need to cooperate. OEMs could simply flash the new TZ code, extract the KeyMaster keys, and bruteforce the key. All without having any help from you.
- 10y ago

devit 10y ago

It doesn't really break the encryption, as long as the password is strong enough to prevent brute forcing. Relying on a weak password and a "trusted computing" mechanism like this one from Qualcomm to prevent an attacker with physical access from brute forcing it is not really advisable. Using such a mechanism at all has downsides since it means that you lose the data if the mechanism or the entire device stops working, while otherwise you could simply move the SSD/flash/storage unit to a new identical device and have it just work as long as you type the correct password.

lxgr 10y ago
But how many Android users do you know that actually have a strong password? (Speaking of which: Google's decision to not allow strong encryption passwords together with short screen unlock PINs/patterns is not helping here. It's actually possible, but they don't expose the user interface to change them separately, probably for usability reasons.) Also, while I would agree as far as PCs are concerned, moving the eMMC to a new phone's mainboard is probably also not a likely scenario.
- userbinator 10y ago
  moving the eMMC to a new phone's mainboard is probably also not a likely scenario. Data recovery is, however, which is why I don't think one-sided promotion of ubiquitous hardware-locked-FDE is a good idea --- it becomes a tradeoff between others getting access to, and you losing access to, your data. Is it more important that this data be accessible by no one but you even if it means you might also lose access to it, or that you not lose access, even if it means others can access it? Hardware-locked FDE is suited only to the former case.
  - 616c 10y ago
    As someone who deals with hardware-backed encryption in laptops, it's a huge pain. Modern phones are worse. I was at a training and happened to sit with computer forensicators and they complain about the new eMMC systems. Forensics systems for mobile devices were a piece of cake prior to that. I suspect the eMMC thing is meant to make this difficult on purpose. So, so much for that ...

dcdevito 10y ago

https://www.appmobi.com https://www.appmobi.com the only way to fly

sdl 10y ago

So if I understood correctly, there are 5 requirements for such a system to be secure: 1: secure/unmodifiable cryptographic processor 2: with unremovable rate limiting 3: and exclusive access to a hardware key 4: cryptographic processor has the only function of encrypting user data based on 5: hardware key and a user supplied pin/key Errors done by Qualcomm: Violated 3: Hardware key not exclusivly readable by cryptographic processor Violated 5: Encryption based on derived key Anything I overlooked? (edited: formatting)

woumn 10y ago

If anyone is interested when the author talked about an overview of the iOS security measures, I created a more in-depth review that is an easy read and gives you a good over-view of the security architecture used. I'm happy to hear feedback if you enjoy it. The blog can be found at: https://woumn.wordpress.com/2016/05/02/security-principles-in-ios-architecture/ https://woumn.wordpress.com/2016/05/02/security-principles-i...

koolba 10y ago

Full disk encryption (FDE) is a UX issue, not a technical one. You don't need a secure cryptographic processor, but the UX sucks without one. A simple, working, FDE setup would be something like LUKS running at boot: 1. Turn on phone 2. Phone loads up initial bootstrap OS 3. Phone prompts user for master key 4. Master key is used to unlock volume 5. Regular OS boot continues If the master key has enough entropy, brute forcing it becomes impossible. The phone won't "disable" as there's no self-destructing component (i.e. "secure crypto chip") but that doesn't mean it can be cracked. Boil as many oceans as you'd like, you're not going to brute force 256 bits of entropy. The UX problem is that the master key is a PITA to enter if it's long enough to be cryptographically secure. That's what a crypto chip is supposed to solve. A limited number of attempts with a shorter passphrase.

williamscales 10y ago
Wait, Android doesn't use LUKS? Argh. Just give me a stinkin' smartphone that runs Linux. These are solved problems, people.
- halviti 10y ago
  Jolla / Sailfish ?
- josteink 10y ago
  Last I checked, it does. I'm pretty sure for instance the Nexus 5X relies on standard LUKS for FDE. What may be protected through other means is the key used to encrypt that filesystem. The user enters a pin or a pattern to unlock said key on boot, and that key is used to initiate LUKS. Maybe that's what they have cracked here?
- Sarkie 10y ago
  Isn't Android running a really old Linux because they can't rebase? So they have to cherry pick... or has that stopped now?
  - kllrnohj 10y ago

616c 10y ago

So out of curiosity, as someone who has a nontrivial passcode on his Android device that people constantly mock, how many characters are we talking to be safe. I have known for a long time 4 digit numeric PINs are stupid. Sadly the San Bernadino case, for all the wrong reasons, taught me all the alternative auth methods are just as risky. Should I be worried? I don't know. But as a long time Android enthusiast and power user who does not use Google Play on his phone and restrictive permission customization like XPrivacy, I am about to just give up and have a newish iPhone for secure stuff and knock around Android for the cool open source dev I aspire to with F-Droid.

snassar 10y ago
A friend saw me entering my longish, non-trivial passphrase into my android phone and commented that I must not have many friends if I have to enter this passphrase every time to use my phone. For a moment I was torn between being proud in my passphrase and sad at my lack of friends.
- gcr 10y ago
  You bring up an interesting UX issue. If I need to be constantly available to my friends, "number of seconds to a text reply" is something that I need to minimize. Longer passphrases prevent me from sending quick replies.
  - 616c 10y ago
    Some of my more sophisticated friends take this a step further and taunt me for not securely hiding notifications and buying a smart watch. This confuses me because Bluetooth over the air does not strike me a secure mechanism (is it just Bluetooth; ironically scant detail unless my Google-fu is off, likely at this hour for me). http://www.wareable.com/android-wear/android-wear-hack-alert-signalled-by-security-expert-581 http://www.wareable.com/android-wear/android-wear-hack-alert... And do I need yet another smart device? The mobile first movement, with shinier crap, moving away from standard protocols, leads me to believe I have been passively perpetuating the biggest wart on computer science's labors. I am kind of embarassed, a few years in and late to the party, I bought an Android phone at all.

nickik 10y ago

I would use a longer password. But currently the unlock and the encryption password are always the same. That one of the issue I would like to see changed. I would also like to have more fine grained rules on when I can unlock with a fingerprint, when pin and when I should be forced to put in the encryption password. Additionally I would like to use U2F NFC token on my keychain as a second factor for unlock (if I have not touched the phone for X amount of time).

ysleepy 10y ago
You can make it use long FDE passwords and a pattern by hackery. Some sqlite fiddling necessary. See XDA.

ysleepy 10y ago

If your device is rooted, you can use a long password for encryption and a pattern or even no lock for the lockscreen. I have set it up this way, it needed some sqlite hackery. XDA dev has appropriate infos.

pooze 10y ago

Could someone explain how and why it uses "0x1337" in order to validate the key? Is that magic? https://github.com/laginimaineb/android_fde_bruteforce/blob/master/keymaster_mod.py#L43 https://github.com/laginimaineb/android_fde_bruteforce/blob/...

rimantas 10y ago
Isn't that just m = (m^e mod n)^d mod n? So the value itself does not matter, you could use 42 instead of 0x1337.