I am wanting to encrypt my phone and sd card. I have been reading around about it all week and still don't understand a few things. I though that the encryption was like blackberry encryption, where you put the password in every time you turn the phone on to the screen lock. After a bit of reading, I understand that the "decryption" is only done at boot up by putting the password in once. After that, you have to put the same password in at the screen lock simply because of a limitation of Android not allowing two different passwords. I do know that there are new ways to use a different password on the screen lock, and even a pattern lock, that's not my issue.
Here are my questions....
1) If the device is technically decrypted after boot up, is the screen lock the only security on the phone once it's turned on?
2) Does the screen lock of an encrypted device have any stronger security than that of an unencrypted device? If not, it seems like the phone is still very vulnerable as long as it's turned on.
3) Finally, on a Blackberry, a wipe is performed by erasing the encryption key. This makes an almost instant wipe of the whole phone and sd card. I know an encrypted device has to be wiped the same as an unencrypted device, but is Android programmed in a way that the encryption ket is wiped first, in case someone pulls a battery or forces a phone off during a wipe? I know that's far-fetched, just curious about how it works.
I have thus far been unable to find the information I'm looking for in regards to full disk encryption for Android. When you encrypt the drive, Android uses the same password used for unlocking your phone. There are methods out there to defeat the lock screen. Does this bypass encryption as well?
I assume that if it's really encrypted then getting around the lock screen without the appropriate password/key combination would result in you being unable to access the data. If this is not the case then the question becomes whether or not the data can be considered encrypted while the hard drive remains on the phone.
Anyone have any practical knowledge of this, and of whether the key for turning the phone on is the same as for unlocking the phone? I would appreciate any input toward this discussion. Thank you!
-E
emccalment said:
I have thus far been unable to find the information I'm looking for in regards to full disk encryption for Android. When you encrypt the drive, Android uses the same password used for unlocking your phone. There are methods out there to defeat the lock screen. Does this bypass encryption as well?
I assume that if it's really encrypted then getting around the lock screen without the appropriate password/key combination would result in you being unable to access the data. If this is not the case then the question becomes whether or not the data can be considered encrypted while the hard drive remains on the phone.
Anyone have any practical knowledge of this, and of whether the key for turning the phone on is the same as for unlocking the phone? I would appreciate any input toward this discussion. Thank you!
-E
Click to expand...
Click to collapse
So, to be clear, any encryption can be bypassed. If the password is weak, then there is no issue and can be done in no time, if the password is strong (capital letters, numbers, symbols), then a brute-force attack can take years! Said that, you have to understand that Android devices has weaknesses, like every other device, and out there are also companies that guarantee they can decrypt any android device. Another way to decrypt an Android device is freezing the device at -10c (yes physically and no is not a joke). Researchers has demonstrated that if you freeze the device, and quickly disconnected and reconnected the battery will put the device in a vulnerable loophole. Even if encryption means data altering, and it requires a key to access/restore the data, this behavior probable occurs because the low temperatures causes data to fade from internal chips more slowly. That way is possible to obtain encryption keys and unscramble the phone's encrypted data. So, to reply to your question, yes, someone with enough knowledge can bypass your encryption.
Hey, thank you for your response! I read the article about bypassing encryption by slowing the rate of RAM fade and using FROST. I have a few minor follow on questions about that, however I'm not terribly concerned with tracking that down. I'm doing some research for a project, and I've just run out of time basically, so I can't try everything.
So, I know that it can be bypassed. I also know that you can run a kernel called Armored that supposedly keeps the keys for your encryption on the CPU instead of RAM, which supposedly shuts down cold boot attacks. I think that's a bit extreme for everyday situations, but it's there. I'm more curious about the authentication mechanism for the encryption I guess. It's ran through AES128, then salted with SHA, if I remember what I read. So without encryption, if you bypass the password, you're in. I'm curious, if you were to be able to bypass the encryption password (without actually getting it right). Would the system let you in, but leave everything encrypted and unreadable since you didn't provide the appropriate credentials?
-E
emccalment said:
Hey, thank you for your response! I read the article about bypassing encryption by slowing the rate of RAM fade and using FROST. I have a few minor follow on questions about that, however I'm not terribly concerned with tracking that down. I'm doing some research for a project, and I've just run out of time basically, so I can't try everything.
So, I know that it can be bypassed. I also know that you can run a kernel called Armored that supposedly keeps the keys for your encryption on the CPU instead of RAM, which supposedly shuts down cold boot attacks. I think that's a bit extreme for everyday situations, but it's there. I'm more curious about the authentication mechanism for the encryption I guess. It's ran through AES128, then salted with SHA, if I remember what I read. So without encryption, if you bypass the password, you're in. I'm curious, if you were to be able to bypass the encryption password (without actually getting it right). Would the system let you in, but leave everything encrypted and unreadable since you didn't provide the appropriate credentials?
-E
Click to expand...
Click to collapse
Encryption is carried out at boot time. After the device has booted, a lockscreen bypass will yield full access to the device's data. Encryption only protects your data when the phone isn't turned on, effectively. Or if you know the adversary won't be able to bypass the lockscreen, and would end up rebooting it without knowing it was encrypted.
pulser_g2 said:
Encryption is carried out at boot time. After the device has booted, a lockscreen bypass will yield full access to the device's data. Encryption only protects your data when the phone isn't turned on, effectively. Or if you know the adversary won't be able to bypass the lockscreen, and would end up rebooting it without knowing it was encrypted.
Click to expand...
Click to collapse
@pulser_g2 +++
Or if you have a tracking software that allows you to shut down your phone remotely... But in that case you may as well wipe your phone remotely.
I have a phone that I use for corporate purposes so there is a password requirement for each wakescreen.
This is obviously absurd, so I used Xposed module to "nuke" the password. The coorporate app still thinks there's a password and I've never lost my phone, so that's good.
However one shortcoming of this is, if on the off chance I do lose my phone, using Prey, or Android Device manager, I cannot "lock" the phone, because the xposed module takes it out.
I'd like to do the full encryption, still keep the password "nuked", but somehow be able to reactivate the lock, or at the very least shutdown the phone remotely in case I do lose it, when it comes back on the password will be active.
I could perhaps use tasker to accomplish this, but it's a bit tricky.
TlL;dr
Password Lock must think it's on, but not. (so corporate app doesn't boot me out)
Phone must be able to be remotely locked - or turned off.
The Cerberus App, does exactly what is needed, including full wipe, reboot, etc.
https://www.cerberusapp.com/
Full device encryption on mobile devices is useless for several reasons:
https://security.stackexchange.com/...ny-advantages-to-android-full-disk-encryption
Well crap! I finally decided to make the jump to encrypt my phone, Samsung Galaxy S4 using the built-in Android encryption.
I was a little disappointed that the password I choose to boot my phone is the same password I use to wake my phone. I either have to choose an annoyingly long password every time I turn on the screen, or an insecure password at boot, because they're one in the same.
I found a genius work around that could separate the passwords and fix the problem, here:
niki.hammler >o< .net/w/index.php?title=Android_Device_Encryption&oldid=1400
Worked amazing. In a nutshell, it uses Secure Settings/Tasker to change the device PW to a 4-digit pin, and then uses Terminal emulator and "cryptfs changepw" to change only the encryption keyphrase. Couldn't be happier.
One problem has just occurred, however. Using Terminal to change the cryptfs password, I made a bad mistake. I fed it a password that is 17 characters long and it was happy to take it. Turns out, Android only supports 16 characters, so when I reboot my phone, I can only type in 16 characters. I tried entering just the first 16, but it's a no go. I'm completely locked out. No clue what I can do. Please help!
I guess there's no way around it....
I found this older thread about the POCO X3 NFC: https://forum.xda-developers.com/t/phone-says-its-encrypted-but-is-it-really.4167645/
I do not know if the info there is also valid for the X3 Pro ... or if it even was correct in the first place. (Cause just 1 other user mentioned this and no one else talked about it.)
In the 2nd post there is tha guy mentioning that MIUI is not changing the decryption keys when changing the password. Is this a problem?
I have bootloader unlocked and Magisk + LSposed installed. Using the latest stock MIUI. From what I have read online ... unlocking hte bootloader just allows to tamper more with the device - and allows an attacker to bypass the hardware security stuff to run brute force without using the phone (to bypass rate limits and run brute force very fast) - shouldn'd that still be safe with a long password?
Well Android allows at max 16 chars and I am using 16 chars letter, numbers, special chars now + biometrics for screen unlock. After the boot it seems it forces you to put in the password. (Biometrics not working.) TWRP decryption is working - and only works with the password I put. (Not with "default_password".) Even when adb is enabled (I usually leave USB debugging disabled) it seems not to work unless I also change the charging options to allow file transfer (not only charging battery) - which always seems to reset to recharging battery only after a reboot. (And not allow for changes unless passwort is put in once at least.)
I am talking mainly about attacks where you are able to power off your phone and someone else gets physical access to it. (Like police or NSA lol. After I got it back I would always completely wipe it to make sure they have not installed some keyloggers.) Unless the bootloader and internal keystore somehow (I do not have much knowledge about this) just checks your passwort but is still using "default_password" in the background (and TWRP also works using this) should not a strong password be safe?
I think the key generation with "default_password" itself still would have some random compoment (every time you reset the sytsem and it gets newly encrypted)? And it only matters if that "key encryption key" gets re-encrypted when changing the password. (And not only encrypted/hashed with "default_password".) As mentioned here by Elcomsoft: https://blog.elcomsoft.com/2018/05/demystifying-android-physical-acquisition/
"It still takes effort to decrypt the smartphone even if the data is encrypted with “default_password”. Much depends on the encryption implementation of a particular vendor. As an example, some vendors will not re-encrypt the KEK (Key Encryption Key) when the user changes their passcode; this in turn allows decrypting the data regardless of the current passcode by simply using “default_password”. The same situation occurs if, at the time of the initial setup, the vendor opts to start encrypting the phone before the user sets the passcode. According to Oxygen, this is exactly what happens on Motorola smartphones, which can be extracted and decrypted regardless of the lock screen password – but only if Secure Startup is not enabled."
(This info still seems to be for the old FDE but I think it should be similar fo file based encryption which is used in the POCO X3 Pro?)
If the TWRP only works with the correct password (otherwise showing encrypted stuff for the files that are supposed to be encrypted in th FBE - not everything like in the FDE but still enough I think) ... is it safe to say that this key encryption key is getting re-encrypted?