Overview of Mobile Projects - That focus on either/and/or security, privacy, anonymity, source-available, Freedom Software.

[Patrick]

@madaidan

Only a local attacker can unlock the bootloader.

I see. For phones, that’s because of “BIOS” is root of trust is read-only in hardware, which verifies the first stage, the bootloader which then verifies in a chain kernel and so forth.

Verified boot can work in principle also on computers using SecureBoot and/or heads. It uses a TPM and measured boot. Doesn’t extend to user space but that’s just a lack of implementation rather than conceptual impossibility.

GitHub - linuxboot/heads: A minimal Linux that runs as a coreboot or LinuxBoot ROM payload to provide a secure, flexible boot environment for laptops and servers.

Example implementation (see “boot integrity”):
https://insurgo.ca

I am writing this to show that I don’t see the conceptual differences between computer hardware and phone hardware which somehow introduce a (conceptual) difference which in one case allows for secure root-enabled boot mode without user data wiping (computer) but not in another case (android) that’s not possible.

@madaidan

Encryption doesn’t cover everything such as the bootloader.

Indeed but there’s also no strong reason why bootloader contents would have to remain secret.

@madaidan

Encryption doesn’t cover everything such as the bootloader. If you allow the attacker to unlock the bootloader without wiping user data, the attacker can just replace the bootloader with a malicious one that uploads all of your data the next time you decrypt it.

That’s a rather complex attack. Similar to installing a hardware keylogger, microphone (can guess keystrokes) and/or miniature camera during the absence of the victim into/near a computer.

Also “just replace the bootloader” sounds simple but for phones there are many phones where people would like to unlock the bootloader but that freedom is refused by the device vendor. For many phones, mortals cannot replace the bootloader.

@madaidan

Encryption doesn’t cover everything such as the bootloader. If you allow the attacker to unlock the bootloader without wiping user data, the attacker can just replace the bootloader with a malicious one that uploads all of your data the next time you decrypt it.

That feature might have a point. But should have an opt-in or opt-out. (Probably opt-out since it’s default already.) If it’s possible to securely implement booting into normal boot mode, enabling OEM unlocking in android settings, then it conceptually must also be possible to add an option to disable “wipe user data when bootloader gets unlocked”.

@Patrick

Seems like saying “when booting into superadmin delete /home/user first”.

We don’t have local attackers in our threat model. Android does.

Let’s consider local attackers. If figured out it’s infeasble it can be ignored but would be good to at least consider and describe why that is. heads / insurgo make that seem realistic to cover some local threat models.

For that purpose, I’ve refined (better wrote down the concept) of multiple boot modes just now.

multiple boot modes for better security: persistent user | live user | persistent secureadmin | persistent superadmin | persistent recovery mode

I am copying over the conceptual notes to a wiki page and refining the concept. Please check: What would probably cause chaos is to have sometimes 1 word and sometimes 2 words. root super root also admin super admin “But I used root.” “You need super root.” “I mean, I used super root.” Therefore I think single words should be avoided. Documentation should introduce and consistently use two words. Which ones? limited admin / limited root super root / super root But limited not sound …

Multiple Boot Modes for Better Security: an Implementation of Untrusted Root

@Patrick

If local attacker doesn’t know password, it’s considered secure.

They don’t need the password to modify unencrypted parts.

Agreed but I don’t see how that’s related.
Modified unencrypted parts would be hopefully caught by verified boot implementation.

That is independent of let’s say app X vs app Y is installed. I.e. it doesn’t matter if the fully booted android allows root or not.

@madaidan

With the way it is now, the attacker has to compromise the device remotely first to enable OEM unlocking and then have physical access to the device to unlock the bootloader which then wipes all user data so they can’t access anything.

Current model:

1. “the attacker has to compromise the device remotely first to enable OEM unlocking”
2. “then have physical access to the device to unlock the bootloader which then wipes all user data so they can’t access anything.”

Comments:

1. If attacker can remotely enable OEM unlocking they already do have root access? Otherwise how could a remote attacker enable OEM unlocking?
2. Is irrelevant due to 1).

@madaidan

The purpose of verified boot is to prevent the attacker from persisting as root. It doesn’t matter if the attacker has unlimited capabilities, verified boot will still revert their changes.

The only thing required in step 1) is enable OEM unlocking. Remote root compromise (suppose which would be undone by verified boot) to enable OEM unlocking would be the only thing the attacker would care about. The attack would succeed so far.

My premise is:
remote exploit that gained root on android → can enable OEM unlocking in android settings

If that is the only thing the attacker does… And accept premise verified boot will undo attacker root… Then still, after reboot OEM unlocking is still activated. Now back to what you said…

@madaidan

With the way it is now, the attacker has to compromise the device remotely first to enable OEM unlocking and then have physical access to the device to unlock the bootloader which then wipes all user data so they can’t access anything.

And again my summary / rewrite of the current model into steps.

Current model:

1. “the attacker has to compromise the device remotely first to enable OEM unlocking”
2. “then have physical access to the device to unlock the bootloader which then wipes all user data so they can’t access anything.”

1. in this threat model suppose a root exploit gained root temporarily and enabled OEM unlocking
2. then have physical access

Again, the current model:

@Patrick

Steps include, simplified:

• do something on your computer - skipable [1]
• boot in normal mode and enable something (USB debugging and OEM unlock) in android settings (usability still good if this is kept)
• connect USB - skipable [1]
• do something on your computer - skipable [1]
• automatic factory reset (I don’t see need for this except DRM which is a bad reason.)

As I wrote before:

I don’t see why this procedure couldn’t be simplified in principle. Slightly refined:

• boot in normal mode and enable something
• reboot
• bootloader now allows to boot into root mode (require physical button press)

What you said “With the way it is now, the attacker has to compromise the device remotely first to enable OEM unlocking and then have physical access to the device to unlock the bootloader which then wipes all user data so they can’t access anything.” is still the same under my proposed model. Just that has better usability, because less steps required.