docs/os: AVB does not prevent evil maid

[ignoramous]

AVB may help deter rouge firmware changes and prevent tampering of the OS.

List of changes proposed in this PR:

cc: @eylenburg / @SkewedZeppelin

[Copilot]

Pull request overview

This PR corrects the documentation about Android Verified Boot (AVB) capabilities. The change removes the technically inaccurate claim that AVB provides protection against "evil maid" attacks and replaces it with a more accurate description of what AVB actually does: protecting against boot path changes, deterring firmware tampering, preventing malware persistence, and ensuring rollback protection.

Key Changes:

• Updated the Verified Boot description to accurately reflect AVB's actual security capabilities
• Removed the incorrect claim about "evil maid" attack protection

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The phrase "protects from boot path changes" should use "against" instead of "from" for proper English grammar. The correct construction is "protects against" when referring to threats or attacks.

[github-actions]

✅ Your preview is ready!

Name	Link
🔨 Latest commit	faaa777
😎 Preview	https://pr3183.unreviewed.privacyguides.dev/en/

Please note that this preview was built from an untrusted source, so it was not granted access to all mkdocs-material features. Maintainers should ensure this PR has been reviewed locally with a full build before merging.

[SkewedZeppelin]

but it does? The encryption key is partially derived through the state of the verified boot chain.

an attacker could attempt to modify the ciphertext of the drive since that isn't authenticated but that likely isn't implied here

[SkewedZeppelin]

thinking about it more, I agree a bit more.

the heads approach for example shows you a totp key you can manually verify to confim state before entering any passwords

it would be neat if eg. GrapheneOS allowed you to use its Auditor before first unlock

cc @thestinger

[thestinger]

Don't agree with the statement that it doesn't protect against evil maid attacks, especially when considering the existence of Auditor and secondary profiles with separate encryption keys.

the heads approach for example shows you a totp key you can manually verify to confim state before entering any passwords

It doesn't prevent proxying this to another machine and also doesn't really work since it fails to implement complete verified boot. TOTP is also very cryptographically insecure due to the very small output.

it would be neat if eg. GrapheneOS allowed you to use its Auditor before first unlock

This is a planned feature but we haven't gotten around to implementing it yet. It could be done via a quick tile or lockscreen shortcut for starting Auditor in the Auditee mode.

[ignoramous]

Evil maid attacks, at least in Mediatec SoC, have been shown to bypass Verified Boot: https://blog.quarkslab.com/android-data-encryption-in-depth.html

We implemented our PoC on the Samsung A22 device (more precisely on the A226B and the A225F). These devices are using two vulnerable SoCs from Mediatek: MT6769V and MT6833V, which can be exploited using MTKClient.

This tool interacts with the Download Mode (similar to the EDL mode on Qualcomm SoCs), which exposes a USB interface that is originally used to perform support operations on it (such as flashing the firmware). To trigger the bug, physical access is required, and on some devices (such as the A225F) two pins must be shorted on the device PCB to enter Download Mode.

Once the device is booted in the right mode, the tool exploits the boot ROM vulnerability, then modifies BL2 (called preloader in the Mediatek boot schema) to disable the next secure boot check, and finally loads it on the device and boots on it.

At best, AVB may deter all but determined evil maids? Can't really prevent, I don't think?

Per https://www.cl.cam.ac.uk/teaching/1314/SecurityII/2014-security2-4-skorobogatov.pdf (2014), secure chips are eventually defeated in years, if given physical access.

And the Fuschia docs on Verified Execution scope pretty broad:

...

The goal of a defender in this security model is to recover by eliminating untrustworthy states (code and data) in which attackers could persist control across reboots.