We're attempting to assess the information security on our mobile devices, and information seems rather varied on the question of encryption. Is the encryption technology employed by Android-based phones uniform, and is it secure? I'm also particularly interested in protection from any malicious attackers who may have a decent amount of computing power at their disposal.

As per this question, my impression seems to be that any phone that comes with standard Google-linked (and likely, manufacturer-linked) Android is entirely vulnerable to being unlocked by Google. Do encrypted phones with LineageOS (which I realise has a lot of versions, but in a general sense, at least) use a secure full-disk encryption without backdoors? Or do they at least securely encrypt all user data?

There's clearly some basic security, as my vague attempts to gather any information off a LineageOS phone without unlocking it hasn't gotten anywhere. But again, I can't find great wells of information on the matter, and I realise LineageOS is open-source, though, so surely a knowledgeable attacker could work out what needs doing without too much effort.

Is encryption on standard-Google-android phones secure? Is the encryption on an up-to-date LineageOS install more or equally secure? Are there any better ways to encrypt phone data such that knowledgeable attackers would have a hard time gather any actual data?

2 Answers 2


Simplified Explanation

Both Android and Lineage use the same encryption. Both are secure enough against the threats it is designed to protect against. Specifically, an attacker with physical access to a powered-off phone.

Bad analogy time:

Think of device encryption like a document safe. You have the only key.

Think of the lock screen like the security guard you hire to keep people away from your safe.

If an attacker wants to read your documents, if your safe is locked, the security guard is irrelevant. There is no way for them to get into the safe to get your documents. This is when your phone is powered off.

When you go to read your documents, you send your security guard off for lunch, as you are watching after the safety of your documents now. You use your key to unlock the safe. Now you can read your documents. This is when you are actively using your phone.

You have a full work day ahead of you. You step away from the room, leaving the safe unlocked. In a few minutes, the security guard comes back. They will prevent anyone else from getting into the room. This is when your phone is turned on but locked with a lockscreen password.

Your security guard gets a call from their boss. There is a search warrant out for the contents of your safe. They are instructed to allow the police into the room with the safe and keep you out of it. This is Google or other device management software remotely unlocking your phone or even changing the lockscreen password.

They could even remove your documents from the safe, putting them into a new safe, just in case you manage to come back and attempt to lock your safe again. This is Google changing or removing your encryption password, which you will note is only possible because the safe was already unlocked. Had you locked your safe/encrypted your phone, they would need your key, which only you have, to do anything.

A Little More Detail

If I remember correctly, and if it has not changed since I learned about it, the device encryption key is randomly generated and actually stored on the device. This encryption key is then itself encrypted using a mix of your supplied password/PIN/pattern and some device-specific hardware-backed information that is hard to access without destroying the device (and hopefully the data as well). When you turn on your phone, you supply the password to Android, which lets Android decrypt the encryption key, which it can now use to decrypt your data as needed, until you power off your phone again.

Modern Android devices come already encrypted. They use a hard-coded default password mixed with the device-specific stuff to encrypt the encryption key. This lets you use your phone right away out of the box without entering a password. It also lets you set your own password without waiting for all the 128+ GB of data on your phone to be re-encrypted with a new key; the same key is used for encryption, that has not changed, you just re-encrypt the key itself with a new key.

Since the encryption key is already decrypted while your device is powered on, it is easy for Android to just re-encrypt that key whenever it needs to, with a new password, or with the default password again. This is exactly what happens when you change your password, when you enable an accessibility service, or theoretically when Google gets a lawful order to do so (I have not heard of this last one happening). The lockscreen is only software-enforced, if someone has control over the software running on the device, it could easily be bypassed. There are occasionally software bugs (especially in unofficial Android ports like Lineage that mess with the lockscreen behavior) allowing lockscreen bypass without any special access. Without those bugs, or if the phone is off (the encryption key is still encrypted), either special software must already be present on the device, or an automatic update must push such software without user intervention to allow access.

Here Lineage and similar ROMs provide a trade-off:

With Lineage, assuming you do not have Google's services installed (or any other software with similar access or exploitable bugs), there is not any preloaded software or automatic update mechanism that would allow lockscreen bypass or changing encryption passwords. The security guard does not have a phone, so they never get the call to allow the police inside. However, with Lineage you must unlock your bootloader to install Lineage in the first place.

Back to the bad analogy: a locked bootloader is like tamper-proof features on the safe that automatically incinerate the contents if someone removes them. The tamper-proof features prevent affixing anything to the lock, so an attacker cannot attach a device that captures a mould of your key when you insert it, or fit it with some automated system that can somehow try keys much faster than a person casting one key after another and trying each manually (ok, the analogy is stretched to its limit here).

When you unlock your bootloader, all your data gets wiped. But the phone simply will not run any software other than from Google or your device manufacturer, unless the bootloader is unlocked. An attacker probably would love to install a low-level keylogger or a password brute-force cracking program that runs before you even enter your password, but cannot, because the bootloader is locked. If they unlock it to install their software, the data they wanted is now gone. So, they're limited to manually entering one password after another, and can't really speed things up.

But Lineage requires an unlocked bootloader. An attacker with physical access could reboot to "recovery" (the same method used to install Lineage) and then install whatever they want without decrypting your phone first. Then they can either give your phone back and capture your password when you enter it, or brute-force your password in software, guessing thousands or more per second instead of one every few seconds.

If you have a strong password (unlikely for most people, because it's a phone) you'll still be fine. If not, Google as a potential adversary may be preferable.

Note: it is actually possible to have a separate lockscreen password compared to your encryption password. There isn't a UI for it in the system settings (Lineage removed their UI due to flaws in the implementation a while ago), and it may not be possible on "stock" Android at all, but it's technically supported. This might make using a strong encryption password less onerous.

Update: File-Based Encryption

All the above was written with "full-disk encryption" (FDE) in mind. Older versions of Android used FDE, where after rebooting, you could not unlock and use your phone at all until you entered your password or PIN. But, newer Android devices almost universally use "file-based encryption", or FBE. With FBE, your phone boots all the way to Android's lock screen, where you can make and receive calls and see a few notifications before ever entering your PIN. This complicates the situation quite a bit, because the idea of FBE is that only certain files get encrypted with secret data: many of the files on the phone–specifically all files required to boot, make phone calls, and some other tasks–are left unencrypted, or encrypted only with data saved on the device and accessible to Android without user input (I'm not 100% clear on whether it is fully unencrypted or encrypted in an accessible way). In particular, if you're using an SD card with "adoptable storage", the SD card encryption key is available at boot without user interaction. Adoptable storage has been removed from many stock Android ROMs because it renders the SD card usable only on the device where it was formatted (which apparently confuses a lot of users), but is still present as an option in Lineage OS.

Revisiting the analogy, FBE is like you only keep a few of your documents in the safe. The rest of your documents are left lying around the room and rely fully on the security guard to keep away from prying eyes. You even have a locked file cabinet for some documents that won't fit in your primary safe (your SD card), but you leave the key for the file cabinet on a hook on the wall, rather than in the secure safe for which you keep the key.

Unfortunately it can be difficult to know which documents are kept in the safe and which are left out on the table.

FBE adds another trade-off to installing Lineage. In stock Android, there are normally no built-in features that allow ADB or any other methods to get files off the device until the device is successfully booted. While it may be possible for well-funded experts to do so, there are no official features allowing it, so your average petty criminal will not be able to get your data even if it happens to be one of the files FBE does not fully secure. Lineage and other ROMs are often installed with a special "recovery" image that allows filesystem access as a built-in feature. Even if you use a recovery without full filesystem access, such as Lineage's recovery, with an unlocked bootloader (back to that again) an adversary could easily boot whichever recovery they choose and access your filesystem that way. Thus adoptable storage and any other files not fully protected with encryption under FBE are more at risk with Lineage than with a stock Android image, which may outweigh the risk of those files actually protected by encryption under FBE from being compromised by backdoor access from Google or your phone manufacturer while your phone is already unlocked (e.g. in response to court orders).

All of this discussion is relevant only to the scope in which device encryption is intended to protect your data: i.e. when an attacker gains physical access to your locked device. There may be other security considerations that weigh into a user's decision to install a custom ROM, e.g. for out-of-support devices Lineage may provide protection from known network-exploitable vulnerabilities that have since been fixed by Google. But that just means there are more things to weigh against the trade-off in the security offered by device encryption.

  • 5
    Side note, you can actually run other software on the phone with a locked bootloader, if you flash the keys for it while the bootloader is unlocked. This is how GrapheneOS allows you to relock the bootloader. Jun 1, 2019 at 19:16
  • 2
    An excellent point. Some devices, IIUC Google's Nexus and Pixel lines prominent among them, support loading alternative keys to run with custom software and a locked bootloader. But as I don't know the details on that, and Lineage specifically discourages it, I decided not to mention it. :-)
    – Ben
    Jun 1, 2019 at 21:39
  • 3
    All this is great, thank you. And I never take issue with an attempt at analogy. You make good points about loading malicious software via unlocked bootloader, and that security is far from perfect while the phone is still on. This pretty much covers what I wanted to know, thank you! Jun 3, 2019 at 9:22

If the phone's bootloader is locked, which almost never happens with custom roms, your data is relatively safe. Situation, however, severely changes with unlocked bootloader.

Unlocked bootloader, among other things, means access to fastboot flashing, and here is the terrifying scenario: attacker boots TWRP recovery via fastboot. He is greeted with a prompt for pin/password/pattern. Instead of entering the same, he presses 'cancel' button, which will result in TWRP having the full access to system partitions. After that he can remove pin/password/pattern without ever knowing them. Depending on the device, those are stored in 1-4 files usually starting with lock*** in system/data (Android encryption scheme does not include system partitions, which are always unencrypted). After removing the files, a simple reboot would result in system falling back to the hard-coded 'default_password' which in turn will be used to re-encrypt the master key. On boot, the attacker will have full access to the phone including data.

  • > a simple reboot would result in system falling back to the hard-coded 'default_password' which in turn will be used to re-encrypt the master key Why would it? Where such a fallback is required and specified?
    – ᄂ ᄀ
    Dec 10, 2023 at 20:16
  • I don't think this is correct -AFAIK Android uses LUKS for FDE - the master key is kept encrypted - and there is no reason to believe the default password would be kept in one of the key slots. Importantly there can be no hard-coded default password which unlocks the master key (there can be multiple key slots). Normally changing the password will require the phone to reinitialize - wiping out all user data if the key changes.
    – davidgo
    Dec 26, 2023 at 6:32
  • @davidgo > there is no reason to believe the default password would be kept in one of the key slots Default password is well-known by design (default_password). There is no need to keep it anywhere. It is what makes default encryption possible (and pretty much useless as concerns protection) > Importantly there can be no hard-coded default password which unlocks the master key Default password is just that.
    – ᄂ ᄀ
    Mar 15 at 10:40
  • @davidgo > Normally changing the password will require the phone to reinitialize - wiping out all user data if the key changes I'm not sure what you mean by "reinitialize" here. I also have no idea what wiping you are talking about. Just resetting the encryption key renders the encrypted data unrecoverable (assuming the encryption was strong enough). There is no "wiping" in Android as there's no need for it.
    – ᄂ ᄀ
    Mar 15 at 10:46
  • @ᄂᄀ I think we are actually in agreement but usung different terms to say the same thing. My first comment was not targetted at you - it was targetted at the answer. To be clear - I dont believe you can bypass LUKS encryption (I expect a skilled attacker can change the firmware so it can sniff the password when its entered - but that still requires a valid password to be entered).
    – davidgo
    Mar 15 at 18:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .