Can the bootloader be locked?

[Zamasu 258]

8 hours ago, damion said:

Your phone has to be decrypted to boot

From what little I read, this seems to be wrong. It can technically boot without decrypting, it just can't do anything past that. That's the whole point of not encrypting everything, to ensure faster boot and have it be available in emergency situations.

[netman 1,424]

7 minutes ago, Zamasu said:

From what little I read, this seems to be wrong. It can technically boot without decrypting, it just can't do anything past that. That's the whole point of not encrypting everything, to ensure faster boot and have it be available in emergency situations.

The kernel has to not be encrypted since it has the filesystem drivers and will be doing the decryption. The /data partition is what gets encrypted as far as I can tell from this: https://source.android.com/security/encryption/full-disk

I suppose the rest of the OS is also not part of /data and not encrypted as there has to be some way to enter the password/pattern for decrypting, it'd only need a few things but it makes more sense to just selectively encrypt only the user data. At this point I am guessing though.

Edited November 26, 2019 by netman
I am sleepy, being coherent is hard xD

[Hook 3,043]

Any information from those that have the Pro 1 on whether it's encrypted by default.  I have always had my phones unencrypted and prefer that.

[EskeRahn 5,471]

2 hours ago, Hook said:

Any information from those that have the Pro 1 on whether it's encrypted by default.  I have always had my phones unencrypted and prefer that.

Mine is encrypted, but I honestly do not recall if I accepted that at some point during the wizard, or it just was by default.

[silversolver 849]

On 11/26/2019 at 3:40 PM, EskeRahn said:

Mine is encrypted, but I honestly do not recall if I accepted that at some point during the wizard, or it just was by default.

Is it easily decrypted?

[ksal95 227]

2 minutes ago, silversolver said:

Is it easily decrypted?

If I'm remembering correctly, you'd just wipe data in twrp and it should get rid of the encryption on userdata.

[mcdinner 375]

6 minutes ago, ksal95 said:

If I'm remembering correctly, you'd just wipe data in twrp and it should get rid of the encryption on userdata.

then userdata is not encrypted ?

[netman 1,424]

13 minutes ago, ksal95 said:

If I'm remembering correctly, you'd just wipe data in twrp and it should get rid of the encryption on userdata.

deletion is not decryption though

[Gigadoc2 54]

On 11/23/2019 at 12:56 PM, okayphoneme said:

Encryption only covers user data, not the system files, and as I mentioned above, there are attacks which may be able to extract keys from a device with an unlocked bootloader. Most Android users are using PINs / patterns or weak passwords and so the encryption is worthless to someone with a bit of knowledge and determination.

This is actually the first plausible argument I've heard as to why a locked bootloader could benefit the user (as opposed to only the HW vendor): If you have an attacker who gains physical access to your phone, with an unlocked bootloader they could dump the encrypted content from the phone and then either brute-force the key (if you used a PIN or a weak password), or (if you used a strong password) repace the OS with a version that logs the encryption password and sends it to the attacker, who then decrypts the previously gained dump when you unlock your phone the next time. With a locked bootloader (and no exploit for it known to the attacker), the attacker would first have to wipe your data, which would make them unable to dump and decrypt it later.

However, I still think that this is a really niche case that is not worth the downside of often not being able to unlock the device at will (not the case for fxtec as we have alrady found out, but for other manufacturers). If an attacker is capable and motivated enough to gain physical access and replace your phones OS with a custom one that leaks your passphrase, they are likely also capable of disassembling the phone and dumping the flash memory directly, at which point they can then unlock (+ wipe) the bootloader and continue as above. And if the disassembly takes too much time, it is not that far-fetched that they can just replace your phone with a modified one entirely.

For a bootloader lock to be really effective, I believe the phone should also authenticate itself to the user: If the phone shows you a password, you can better ensure that the phone has neither been modified, nor entirely replaced. Of course, to not leak this password, you first need to enter another password, so it would go like this "User enters stage 1 password" -> "device shows stage 2 password to user" (if it is incorrect, you can abort here an know that your device has been tampered with and that stage 1 has just been leaked) -> "user enters stage 3 (disk encryption) password". But this is probably too much of a hassle to ever go mainstream ;)

[ksal95 227]

47 minutes ago, netman said:

deletion is not decryption though

Big rip, guess I remembered incorrectly 😅

[EskeRahn 5,471]

14 minutes ago, Gigadoc2 said:

For a bootloader lock to be really effective, I believe the phone should also authenticate itself to the user: If the phone shows you a password, you can better ensure that the phone has neither been modified, nor entirely replaced. Of course, to not leak this password, you first need to enter another password, so it would go like this "User enters stage 1 password" -> "device shows stage 2 password to user" (if it is incorrect, you can abort here an know that your device has been tampered with and that stage 1 has just been leaked) -> "user enters stage 3 (disk encryption) password". But this is probably too much of a hassle to ever go mainstream 😉

Interesting idea, but in principle that would only be a further level or security, or a complication, as you previous method could be used twice. Of course that is a serious complication so would certainly make it more secure. But from an academic standpoint it is not.

But talking academic it would most likely be easier to open the phone and insert something that logs every display and touch,

[netman 1,424]

4 minutes ago, ksal95 said:

Big rip, guess I remembered incorrectly 😅

Well the encryption will be gone, just also the encrypted data :D. Decryption translates to transforming the encrypted data into a not encrypted form.

Edited November 27, 2019 by netman

[ksal95 227]

3 minutes ago, netman said:

Well the encryption will be gone, just also the encrypted data :D.

Oh, I meant before setting up the phone.  In that case let me clarify haha.  Wiping data in twrp before setting up your device will remove the encryption.  Doing so after, will remove any and all currently encrypted data, 

 

including your dearly beloved clacking memes

 do so at your own risk.

Edited November 27, 2019 by ksal95

[netman 1,424]

1 minute ago, ksal95 said:

Oh, I meant before setting up the phone.  In that case let me clarify haha.  Wiping data in twrp before setting up your device will remove the encryption.  Doing so after, will remove any and all currently encrypted data, 

  Hide contents

including your dearly beloved clacking memes

 do so at your own risk.

I know it but I was being dense and it has to be said so that onlookers will not be confused and remove any and all currently encrypted data.

[okayphoneme 28]

26 minutes ago, Gigadoc2 said:

For a bootloader lock to be really effective, I believe the phone should also authenticate itself to the user: If the phone shows you a password, you can better ensure that the phone has neither been modified, nor entirely replaced. Of course, to not leak this password, you first need to enter another password, so it would go like this "User enters stage 1 password" -> "device shows stage 2 password to user" (if it is incorrect, you can abort here an know that your device has been tampered with and that stage 1 has just been leaked) -> "user enters stage 3 (disk encryption) password". But this is probably too much of a hassle to ever go mainstream 😉

Well, we have Verified Boot for this, which is where each part of the system is checked (with a key stored in the hardware) before it is loaded. This is what happens with an OEM ROM on most(?) phones, but you lose that when you unlock.

Google Pixel phones (uniquely, as far as I know) have a way of supplying another key so that you can actually run this process with a custom ROM that you have signed yourself (or a ROM that's signed by the publisher). In addition, I believe you're given a fingerprint of the current OS on boot so you can, if you're paying attention, detect if anything has been changed.

[Gigadoc2 54]

8 hours ago, EskeRahn said:

Interesting idea, but in principle that would only be a further level or security, or a complication, as you previous method could be used twice. Of course that is a serious complication so would certainly make it more secure. But from an academic standpoint it is not.

But talking academic it would most likely be easier to open the phone and insert something that logs every display and touch,

The method can't be used twice, because you notice after the first time. Even with the current procedure of locked bootloader + encrypted data, you notice when your phone has been tampered with as your data is gone. However, you only notice after you have given away the passphrase for your encryption. With the 3-stage scenario, you notice after giving away the stage 1 password (because the stage 2 password displayed by your phone is wrong), so you can stop before you enter the stage 3 password (which is the important one, because it is your encryption key / the key to your encryption key).

BTW, this is not a new Idea, some very capable people have already implemented this for PCs: https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html

I know that this is virtually impossible for fxtec to implement on their phone (the entire Android ecosystem is just not made for this kind of thing), but I want to argue with this that locked bootloaders are way overrated. Personally (but this is just my paranoid conspiracy theory) I have the feeling that this is marketing to discourage you from removing the bundled apps which are part of the revenue generation for some Vendors (not fxtec apparently).

8 hours ago, EskeRahn said:

But talking academic it would most likely be easier to open the phone and insert something that logs every display and touch,

True, and then it would not matter anymore whether the bootloader is locked or not...

8 hours ago, okayphoneme said:

Well, we have Verified Boot for this, which is where each part of the system is checked (with a key stored in the hardware) before it is loaded. This is what happens with an OEM ROM on most(?) phones, but you lose that when you unlock.

But how do you see whether this mechanism is still in place? If the attacker unlocks your phone (or modifies it otherwise), they can alter the verified boot mechanism to not show any error messages and continue anyway. You will notice that your data and settings are gone (they have been wiped after all), but only after you gave away your passphrase, at which point you already lost (the attacker has a copy of the encrypted data and can now decrypt it).

Ok, this almost sounds like an argument for permanently locked bootloaders, so just to clarify: If the bootloader cannot be unlocked you might be safe from this kind of attack, but history shows that you will inevitably end up with an Android having known vulnerabilities, at which point the attacker can just use them (it's easier than physical access anyway). Also, when it comes to normal people like us (who are not hunted by the NSA or the Mafia), the most likely attacker is the vendor, unfortunately.

8 hours ago, okayphoneme said:

Google Pixel phones (uniquely, as far as I know) have a way of supplying another key so that you can actually run this process with a custom ROM that you have signed yourself (or a ROM that's signed by the publisher). In addition, I believe you're given a fingerprint of the current OS on boot so you can, if you're paying attention, detect if anything has been changed.

That would indeed be nice, kind of what you can do with secure boot (on x86, if properly implemented) on PCs. Though still, it will only protect you against an attacker who is capable of modifying your phones boot process but not capable of dumping the flash content. I think this kind of attacker is not very likely; if someone actually goes after your phone in person they will probably be able to disassemble it.

[_DW_ 628]

Does the pro1 have a hardware key store? no idea if thats standard on android or not

[EskeRahn 5,471]

1 hour ago, Gigadoc2 said:

Personally (but this is just my paranoid conspiracy theory) I have the feeling that this is marketing to discourage you from removing the bundled apps which are part of the revenue generation for some Vendors (not fxtec apparently).

Please note that we (oddly) are (still?) allowed to do this through ADB. I use this to clean up a Samsung S8- somewhat, see this.

[Gigadoc2 54]

9 hours ago, _DW_ said:

Does the pro1 have a hardware key store? no idea if thats standard on android or not

That is a very good point. I think it is mandatory nowadays to have some sort of hardware-backed keystore for Android. The pro1 has a qualcomm chipset, so it probably has QSEE, which uses the ARM TrustZone. The trust zone can have its own memory, but that is not mandatory, so I don't know if QSEE in particular has memory hardened against extraction. But if it does, and the encryption key (or parts necessary for it) is stored there, the locked bootloader makes way more sense to me.

I mean, several vunlerabilities of QSEE have already been found, but exploiting those still seems more difficult than reading flash with a programmer.

8 hours ago, EskeRahn said:

Please note that we (oddly) are (still?) allowed to do this through ADB. I use this to clean up a Samsung S8- somewhat, see this.

Also very good point. I guess my conspiracy theory is already disproven :D

I think I see the merit of a locked bootloader now. That is, as long as you can take over the lock or the preinstalled OS is really good ;)

[A Dude 99]

Since Android 5, devices ALWAYS get encrypted on first boot, or come in an already encrypted state.

There is no opt-out. Full-disk-encryption happens (similar to PGP/GPG) in a two-stage setting. Your have your PIN/password and then there is the encryption key (which you do not know). This encryption key is randomly generated and applied and then itself encrypted with "DefaultPassword" and stored onto your storage.

If you do not set a passphrase for "on boot", this key will sit there and the Android bootloader just knows that the default password is "DefaultPassword", decrypt your encryption key and then decrypt your /data.

If you set up a PIN/password for your lockscreen, this does not change a thing. If your bootloader is unlocked, one can simply plug in a USB cable and read your /data.

So changing your boot-password does NOT re-encrypt your device with the new password (would take way too long and be too error-prone [think out-of-battery]), but re-encrypts the actual encryption key with your new password. (Basically the same mode of operation as LUKS or TrueCrypt/VeryCrypt.)

It was mentioned before, but just to be clear: For the device to be capable to boot and ask for your password, there has to be "a program" (i.e. the kernel and some additional stuff) that resides somewhere on your phone's storage which is NOT encrypted, so it can be started and ask for your password.

Should your bootloader be unlocked, THIS "program" can be exchanged by e.g. a keylogger and then decrypt your data.

With a locked bootloader, this access should be prevented by hardware. If you now have chosen a good password (at boot), disassembling the phone does not help. Even if you could dump the flash content, you would still have an encrypted /data partition (encrypted by a random key which is encrypted with your [hopefully good] passphrase).

As for tempering/adding YOUR keys for /system verification: This is what dm-verity is for (wiki that). This can be done on any device and is a matter of code-signing, flashing, locking. There is no need for a two-stage passphrase-thingy here.

 

[Gigadoc2 54]

On 11/30/2019 at 9:45 AM, A Dude said:

If you do not set a passphrase for "on boot", this key will sit there and the Android bootloader just knows that the default password is "DefaultPassword", decrypt your encryption key and then decrypt your /data.

Are you sure that the bootloader itself decrypts anything? I was under the impression that the system partition (and whatever boot stages happen before mounting that) is unencrypted (but verified by prior stages in one way or another), the Android system partially boots and then you ask the passphrase and decrypt the data partition.

On 11/30/2019 at 9:45 AM, A Dude said:

So changing your boot-password does NOT re-encrypt your device with the new password (would take way too long and be too error-prone [think out-of-battery]), but re-encrypts the actual encryption key with your new password. (Basically the same mode of operation as LUKS or TrueCrypt/VeryCrypt.)

True (that is why I mentioned the "key to encrypt your key" earlier), but I think that detail can be abstracted away (for all intents and purposes, a key saved on insecure storage but encrypted with another key (may be the passphrase) is as secure as the other key).

On 11/30/2019 at 9:45 AM, A Dude said:

It was mentioned before, but just to be clear: For the device to be capable to boot and ask for your password, there has to be "a program" (i.e. the kernel and some additional stuff) that resides somewhere on your phone's storage which is NOT encrypted, so it can be started and ask for your password.

Should your bootloader be unlocked, THIS "program" can be exchanged by e.g. a keylogger and then decrypt your data.

With a locked bootloader, this access should be prevented by hardware. If you now have chosen a good password (at boot), disassembling the phone does not help. Even if you could dump the flash content, you would still have an encrypted /data partition (encrypted by a random key which is encrypted with your [hopefully good] passphrase).

My argument was this: If you have dumped the encrypted data via hardware access, you can then unlock the phone (which wipes the data, but you've already dumped it) and replace /system (or whatever asks the user the passphrase) to steal the passphrase. You then use the stolen passphrase to decrypt your previous flash dump.

What would make a difference here (and I hope this is done) is when a necessary part of the encryption key (or the entire passphrase-encrypted key) is stored not on the easily dumpable flash, but on some "secure storage" designed to make hardware dumping difficult. In that case the attacker can not get to the key before wiping it, so the attack no longer works. However, a more sophisticated attacker could replace your phone entirely with a similar but keylogged phone, wait for you to enter the passphrase and then enter it on the original phone. To combat this, I would use the three-stage passphrase system.