Architecture notes. Based on a documented GrapheneOS deployment in my portfolio (the nullbyte project). Concepts and verification workflow only — no device-specific values are reproduced here.
Most conversations about Android hardening happen at the app layer — permissions, VPNs, which messenger to trust. The more interesting work happens below the operating system, in the boot chain and the silicon, and it answers a harder question: how do you know the OS you are typing into is the one you installed? GrapheneOS on modern Pixel hardware gives the most complete consumer-grade answer to that question, and it is worth understanding exactly why.
What verified boot actually verifies
Verified boot is a chain of cryptographic signatures evaluated on every power cycle, where each stage measures the next before handing over control:
boot ROM (immutable, in silicon)
→ secure element / root of trust
→ bootloader
→ vbmeta (signed metadata: hashes of every verified partition)
→ OS image (dm-verity hash tree over the system partition)
The root of the chain lives in hardware that cannot be reflashed, and every subsequent stage is only executed if its signature checks out against the stage before. The practical property: modify any verified partition — by malware that gained root, or by an attacker with the device in hand — and the chain breaks and the device refuses to boot that image. Persistence below the OS becomes detectable by default, which inverts the usual economics of an "evil maid" attack: tampering is no longer silent.
Android's dm-verity makes this continuous rather than boot-time-only — system partition blocks are verified against the hash tree as they are read, so a runtime modification of system files is caught on access, not just at next reboot.
The relocked bootloader — the part most custom ROMs cannot do
Here is the detail that separates GrapheneOS from almost every other aftermarket OS: after installation, the bootloader is relocked, and verified boot is re-enforced with GrapheneOS's own signing keys. The device boots in what Android calls the yellow state — custom trusted key, full verification — rather than the orange state (unlocked, verification effectively waived) that most custom ROMs require permanently. An unlocked bootloader is a standing invitation: anyone with brief physical access can flash, modify, and rewrite without resistance. Relocking closes that door while keeping the custom OS.
Verifying the chain yourself
A signed boot chain is only as good as your ability to check whose signature it is. Android exposes this cleanly, and it is worth knowing the workflow:
- On every boot in the yellow state, the device displays the fingerprint of the signing key it verified against — a SHA-256 hash shown on screen before the OS loads, originating from firmware, below anything malware could reach.
- The same value is queryable from a running system:
getprop ro.boot.vbmeta.digest. - GrapheneOS publishes its release signing keys, so the on-screen fingerprint can be checked against the project's published values — confirming the installed build is authentic and unmodified, independent of anything the OS itself claims.
That last clause is the point. Self-reporting is worthless under compromise — a tampered OS would simply lie. The fingerprint is displayed by the boot stack before the OS runs, and corroborated by hardware attestation (below), which is what makes it evidence rather than assertion. In my own deployment documentation I record this verified-boot key hash as a confirmed device value, because it converts "I run a hardened OS" from a claim into something independently checkable.
Secure element vs TEE — why the discrete chip matters
Two pieces of isolated hardware get conflated constantly, and the distinction is load-bearing:
| TEE (e.g. Trusty) | Secure element (e.g. Titan M2) | |
|---|---|---|
| Where it runs | Isolated mode of the main application processor | Physically separate chip: own CPU, memory, firmware |
| Shares silicon with the OS? | Yes | No |
| Survives full AP compromise? | Weaker claim — same die, shared microarchitecture | Yes, by design — the AP talks to it only over a constrained interface |
On the Pixel platform the two are layered, not alternatives: the Tensor SoC's security core and the Trusty TEE handle isolated execution, while the discrete Titan M2 holds the root of trust — verified-boot enforcement, key storage, lockscreen throttling and tamper resistance. The threat-model consequence is concrete: an attacker who fully compromises the running OS still cannot extract keys held in the secure element, and cannot forge the attestation chain without it. The secure element also enforces brute-force throttling on the lockscreen credential in hardware, which is what makes a six-digit PIN survivable against an attacker with unlimited physical time — the guessing rate is capped by a chip, not by software policy.
This also underpins per-profile encryption: each profile's data is encrypted with keys derived from its own credential and protected by the secure element, so a seized device with one profile unlocked discloses exactly that one profile.
Attestation — closing the loop
Verified boot tells you, at the device, that the chain held. Hardware-backed attestation extends that to a second device: the secure element signs a statement about the booted OS (which key, which version, locked or not) with a key that never leaves the hardware. GrapheneOS's Auditor model uses this for ongoing verification — a paired second device can detect downgrades, unlock-state changes, or a switched signing key over time. It is the difference between checking the lock once and having the lock report when it changes.
Honest limits
Worth stating plainly, because this architecture is good and still not magic. Verified boot protects integrity of the boot chain and OS partitions — it does not protect a session that is compromised at runtime through the browser or a malicious app (that is what process sandboxing, exploit mitigations and profile compartmentalisation are for), it does not make the cellular baseband trustworthy (that is a separate processor, contained on modern hardware by IOMMU isolation rather than verified by this chain), and it assumes the hardware root of trust itself is sound. The claim is narrower and more valuable than "unhackable": the software stack you boot tomorrow is the one you verified today, or the device will tell you otherwise.
The full deployment this draws on — profile architecture, network policy and the documented hardware stack — is written up in the nullbyte project.