Create a new version of paste:

An Open Letter to the Privacy & Security Community: Beyond the Sandbox – A Call for User-Centric Hardware Sovereignty

To the Developers of GrapheneOS, Security Researchers, and the Global Privacy Community,

GrapheneOS has set the gold standard for mobile software hardening. However, we have reached a plateau where software-level security is increasingly undermined by a deeper, structural vulnerability: the opacity and irreparability of the hardware layer.

To protect user autonomy in an era of state-level threats, we must adopt the philosophy of OpenBSD—recognizing that security is only as strong as the transparency of the entire stack. We believe GrapheneOS has the potential to lead a global shift from "Vendor-Enforced Security" to "User-Centric Hardware Sovereignty."


1. The Myth of the "Secure" Black Box
A modern smartphone is not a single computer; it is a distributed network of dozens of autonomous micro-controllers (Baseband, UFS, Wi-Fi, PMIC), each running its own proprietary operating system. Currently, these represent the ultimate "shadow" attack surface.
    • The Persistence Threat (UFS/eMMC): Modern devices use managed flash like UFS. These modules have independent controllers. Because the OS lacks "raw flash access," these controllers can host persistent rootkits that survive a complete OS re-install.
    • The Invisible Fleet (Subsystems): The Cellular Baseband, Wi-Fi, and Power Management (PMIC) chips run closed-source firmware with high-level access to system memory (DMA). If these are subverted, no software-level sandbox (like GrapheneOS) can see or stop the intrusion.
    • Microarchitectural Flaws: History (Spectre/Meltdown) shows that hardware-level isolation is not absolute. Users need the power to disable or reconfigure hardware features (like Hyper-Threading or memory timings) when silicon-level flaws emerge.

2. Hardware Attestation: Surveillance in disguise
Current "integrity" models rely on Hardware Attestation—a unique, traceable digital fingerprint. That acts as an immutable tracking mechanism. True privacy requires Statelessness: the ability of a device to "forget" its identity and rotate its hardware-bound keys at the user's discretion.

3. A Mandate for the Future: Hardware Sovereignty
We propose that the security community and projects like GrapheneOS advocate for a Hardware Compliance Standard based on the following pillars:
    • Open and Replaceable Firmware: All embedded controllers (UFS, Baseband, Security Chips) must run Open Source, Auditable, and Replaceable code. Users must have the power to reflash a compromised component with verified code.
    • Hardware Feature Toggles: Users should have "Advanced Toggles" to logically or physically disconnect tracking-capable or compromised components.
    • Trust Minimization toward Manufacturers: We must move away from a model where we trust the manufacturer's "black box" secrets and toward a model where every gate in the silicon is verifiable.

4. The Gatekeeping Risk: Hardware as a Kill Switch for Innovation
The current reliance on mandatory hardware features (like TPM or Titan M2) creates a dangerous dependency. If a project like GrapheneOS requires a proprietary "Root of Trust" to function, it remains at the mercy of the hardware vendor.
    • Vendor Lock-in: If Google or Motorola decides to change the requirements for signing keys or modifies the Hardware Attestation API, they can effectively lock out third-party operating systems overnight.
    • The Irony of Security: By mandating these hardware "protections," we are inadvertently giving corporations the power to decide which OS you can run on the hardware you own.
    • Future-Proofing Freedom: It is in the strategic interest of GrapheneOS and the entire privacy community to ensure the OS can run—and remain secure—on hardware without these external gatekeepers. We must decouple high-level security from mandatory vendor-controlled silicon to prevent a future where "security" is used as a pretext to ban alternative operating systems.

5. The Weaponization of "Security": From DRM to Bootloader Lock-in
History shows that hardware-level security is frequently repurposed as a tool for Vendor Lock-in and Planned Obsolescence. When the "Root of Trust" is controlled by the manufacturer, it becomes a tool to prevent the user from exercising their rights.
    • Remote Deactivation: Manufacturers have used hardware-level controls to "kill" devices remotely, bypassing user consent (e.g., Samsung’s remote disabling of Galaxy Note 7). While done for safety, the same mechanism can be used for policy enforcement.
    • The "SafetyNet" and "Play Integrity" Wall: Google uses hardware attestation to prevent "unapproved" OSs from accessing essential services (banking, streaming). This is a direct use of TPM-like features to enforce a corporate monopoly on the software stack.
    • Preventing Repair and Reuse: Security chips are increasingly used for "Parts Pairing," where a replacement screen or battery is rejected by the hardware because it lacks a proprietary cryptographic signature, effectively banning independent repair.


References and Technical Evidence
Subsystem & Persistence Exploitation:
    • Baseband RCE (CVE-2023-24033, CVE-2023-26496, CVE-2023-26497 and CVE-2023-26498): Multiple remote code execution vulnerabilities in Exynos basebands (used in Pixel devices). Google Project Zero
        ◦ https://projectzero.google/2023/03/multiple-internet-to-baseband-remote-rce.html	
    • Broadpwn (CVE-2017-9417): Remote takeover via the Wi-Fi chip. BlackHat 2017
        ◦ https://blackhat.com/docs/us-17/thursday/us-17-Artenstein-Broadpwn-Remotely-Compromising-Android-And-iOS-Via-A-Bug-In-Broadcoms-Wifi-Chipsets.pdf
    • BadPower (2020): Corrupting PMIC firmware via fast-chargers. hackster.io
        ◦ https://www.hackster.io/news/badpower-attack-leverages-high-speed-usb-charging-to-damage-devices-start-fires-d4cf0737b1c4
    • LogoFAIL (CVE-2023-40238) & MoonBounce: Demonstrating persistent UEFI/Firmware rootkits. Binarly.io securelist.com
        ◦ https://www.binarly.io/logofail
        ◦ https://securelist.com/moonbounce-the-dark-side-of-uefi-firmware/105468/

Silicon-Level Vulnerabilities:
    • Spectre & Meltdown (CVE-2017-5753, CVE-2017-5754, many): Fundamental flaws in speculative execution. MeltdownAttack.com developer.arm.com wikipedia.org
        ◦ https://meltdownattack.com/
        ◦ https://developer.arm.com/documentation/110280/3-0/
        ◦ https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability
    • Drammer (CVE-2016-6728): Deterministic Rowhammer attacks on Android VUSec.net
        ◦ https://www.vusec.net/projects/drammer/
    • TPM-Fail (CVE-2019-11090, CVE-2019-16863): Timing leaks in "secure" TPM chips. TPM.fail
        ◦ https://tpm.fail/
          
Storage Security:
    • Hacking Flash Memory: SSD has it own computer that can be hacked Kea.nu Blackhat.com arxiv.org
        ◦ https://www.kea.nu/files/textbooks/humblesec/thehardwarehacker.pdf
        ◦ https://blackhat.com/docs/us-14/materials/us-14-Oh-Reverse-Engineering-Flash-Memory-For-Fun-And-Benefit.pdf
        ◦ https://arxiv.org/html/2411.00439v1

References for Vendor Abuse and Hardware Lock-in:
    • Parts Pairing & Repair Monopoly: How Apple and others use security chips to prevent independent repair. kitguru.net wikipedia.org securepairs.org medium.com
        ◦ https://www.kitguru.net/lifestyle/mobile/apple/matthew-wilson/apples-t2-chip-prevents-independant-repairs-locking-down-the-imac-pro-and-macbook-pro/
        ◦ https://en.wikipedia.org/wiki/Right_to_repair
        ◦ https://securepairs.org/a-right-to-repair-isnt-a-cyber-risk-its-a-cyber-imperative/
        ◦ https://medium.com/@arnoldgunter/how-googles-quiet-android-update-is-the-end-of-open-source-freedom-5046ea6ddb64        
    • Google Play Integrity & Bootloader Bans: How hardware-backed attestation is used to lock users into the Google-approved ecosystem.  byteiota.com  dev.to sammyguru.com
        ◦ https://byteiota.com/hardware-attestation-monopoly-tool-2/
        ◦ https://dev.to/alanwest/how-to-handle-hardware-attestation-without-locking-out-real-users-3c7b
        ◦ https://sammyguru.com/breaking-samsung-removes-bootloader-unlocking-with-one-ui-8/?utm_source=twitter
    • Sony’s "OtherOS" Removal: A classic example of a manufacturer using a firmware update to remove a hardware-level feature (Linux support) from the PlayStation 3. Source: Wired.com playstation.com
        ◦ https://www.wired.com/2010/04/playstation-linux/
        ◦ https://blog.playstation.com/2010/03/28/ps3-firmware-v3-21-update/
    • John Deere & DRM: The textbook case of using proprietary hardware/software locks to prevent farmers from controlling their own machinery. Source: Bloomberg - New Farmers Fight John Deere’s Software Monopolies
        ◦ https://www.bloomberg.com/news/features/2020-03-05/farmers-fight-john-deere-over-who-gets-to-fix-an-800-000-tractor

LOGO: https://ibb.co/k2jj9KGg


Conclusion: From Managed Security to Absolute Sovereignty
True security cannot exist without user sovereignty. If we cannot audit, disable or replace the firmware running on our hardware, we do not have real security—we have a "managed" illusion of it.
To the GrapheneOS developers: You have successfully forced manufacturers to listen. Now, you have a historic opportunity to lead by defining a Hardware Compliance Standard that demands auditable silicon, user-replaceable firmware, and physical/logical kill switches for all components.

This is not just a matter of principle; it is a matter of survival. By mandating proprietary "Roots of Trust" (like TPM/Titan), the project remains at the mercy of vendor gatekeepers who can, at any moment, leverage hardware attestation to lock out third-party innovation.

Inspired by the OpenBSD commitment to a blob-free, transparent stack, let us build a future where the user—not the manufacturer—decides what code is trusted. Let’s decouple high-level security from vendor-controlled silicon to ensure that GrapheneOS remains a platform for freedom, not a guest in a corporate cage.

It is time to move from "Vendor-Enforced Security" to true User Sovereignty.