// STATUS — OPERATIONAL · rev 2026-06-12 · LIVING BUILD Device: Pixel 10 Pro Fold · SoC: Tensor G5 · Security chip: Titan M2 · GrapheneOS Android 16 · Profiles: 9
// IN PLAIN TERMS — Most people treat a phone as one trusted container for everything — banking, work, throwaway sign-ups, all mixed together. This one is split into nine sealed compartments, so a bad app or a hijacked account in one can't reach the others. It's the same "contain the breach" principle used to protect organisations, applied to the device in your pocket.
GrapheneOS eliminates the trust compromises baked into stock Android: no Google Play Services in the owner profile, no persistent background reporting, verified boot enforced at every power cycle. On top of the OS security model, this build imposes an additional architectural constraint — operational separation via compartmentalised user profiles.
Each profile is a distinct security boundary. An application running in one profile cannot read the filesystem, contacts, or network state of another. If a profile is compromised, the damage is contained and cannot propagate across the boundary.
The build integrates with IRONVEIL: Termux in the primary work profile provides SSH access to the IRONVEIL workstation, including the ability to trigger the dracut-sshd remote unlock sequence from the handset.
Hardware
| Component | Value |
|---|---|
| Device | Google Pixel 10 Pro Fold |
| SoC | Google Tensor G5 |
| Security chip | Titan M2 (confirmed) |
| Security stack | Tensor G5 security core + Titan M2 + Trusty TEE |
| OS | GrapheneOS — Android 16 |
| Build number | 2026060601 |
| Storage | 1 TB |
| RAM | 16 GB |
| IP rating | IP68 |
// Hardware Root of Trust — The platform layers three hardware-rooted components: the Tensor G5 security core (SoC-integrated), the discrete certified Titan M2 chip, and the Trusty TEE (Trusted Execution Environment). Titan M2 handles verified-boot attestation, cryptographic key storage, tamper detection, and secure lock-screen enforcement independently of the main SoC — physically separate from the application processor, so a compromised OS cannot extract keys it holds, and an attacker who compromises the Tensor G5 cannot forge the attestation chain without it.
Security Architecture
- Verified boot — Titan M2 root of trust → bootloader → OS image
// Verified-boot key hash — The fingerprint of the verified-boot key signing this device's GrapheneOS build, independently verifiable against the GrapheneOS release signing keys published atgrapheneos.org/releasesto confirm the build is authentic and unmodified. Shown on the yellow-state boot screen and viaadb shell getprop ro.boot.vbmeta.digest. The full fingerprint is withheld; this value is published as an annotated placeholder.
// What a mismatch would mean — The point of the hash is not that it matches today — it is that a mismatch is detectable. If this value did not match the published GrapheneOS signing key, it would indicate either a different OS version than expected or, the case that matters, a build that was not signed by the GrapheneOS project — a substituted or tampered OS. Because any silent post-installation modification of the OS partition necessarily changes this value, an evil-maid attacker cannot alter the system without the change surfacing at the next boot. That detectability is the security property; the specific hash is just how it is observed.
- Per-profile encryption — independent File-Based Encryption (FBE) key per profile; owner-profile key Titan M2-bound
- Sandboxed Google Play — no system-level privileges
- RethinkDNS — per-app network policy at VPN layer
- WireGuard — encrypted egress per-profile
- Baseband IOMMU — modem cannot DMA into app-processor memory
- Profile isolation — no shared clipboard, contacts, or call history
- Bootloader relocked post-installation
Each Android user profile has its own File-Based Encryption (FBE) key derived from the profile's lockscreen credential. The owner profile key is further protected by the Titan M2. A locked profile's data is inaccessible to all other profiles — including owner — without the profile credential.
WireGuard tunnels provide encrypted egress for profiles where network traffic confidentiality is required. RethinkDNS manages tunnel routing on a per-profile basis — not all profiles use the same exit point, and some profiles can be restricted to tunnel-only traffic with no cleartext fallback.
Compartmentalised Profile Architecture
The device is partitioned into nine compartmentalised user profiles. This is a security design decision, not an organisational convenience: each profile is an independently encrypted trust boundary with its own application stack, network policy, and operational purpose. No application spans profiles and there is no shared state, so the blast radius of any single compromise — a malicious app, a phishing foothold, a sandboxed-service zero-day — stops at the profile edge.
// Design Rationale — Threat per Boundary — Profiles are assigned by sensitivity and by network reach, and the two are deliberately kept apart. Vault (financial) is the strictest and holds no broad network access — it defeats credential theft and malicious-app exfiltration of banking data. Void (pentesting) has the broadest network reach but no financial or professional data, so compromise of the noisiest profile yields nothing sensitive. Nexus (owner) is kept off sandboxed Play entirely to minimise the trusted-code surface around hardware-key management. Plague and Ghost are expendable by design — destroyed and recreated without loss. Under a coerced single-profile unlock, every other profile remains cryptographically inaccessible.
| # | Profile | Role | Status | Stack |
|---|---|---|---|---|
| 01 | Nexus | Owner profile — device administration, hardware key management | Active | System settings, hardware-key management. No sandboxed Play. |
| 02 | Plague | Junk — disposable interactions, untrusted app testing | Expendable | Untrusted apps under test; sandboxed Play where required. |
| 03 | Ghost | Throwaway — short-lived registrations, ephemeral accounts | Expendable | Minimal messaging/registration apps; sandboxed Play as needed. |
| 04 | Abyss | Learning — courses, documentation, research reading | Active | Hardened browser, document/PDF readers, course and reference apps. |
| 05 | Void | Pentesting — offensive security tooling, CTF work | Active | Termux with offensive tooling, network/CTF clients. Broadest network access, no sensitive data. |
| 06 | Façade | Professional — work communications, productivity | Active | Termux (IRONVEIL SSH unlock), productivity and communications apps. |
| 07 | Shade | OSINT — open-source intelligence gathering and research | Active | Hardened browser, research and collection tooling. No PII linkage. |
| 08 | Vault | Financial — banking, payments, financial services | Active | Banking and payment apps only. Strictest restrictions. Sandboxed Play only where required. |
| 09 | Joker | Fallback — backup operational identity | Reserve | Minimal mirror of essential baseline apps. Held in reserve. |
// Design Principles — No personally identifying information crosses profile boundaries. Profiles with elevated sensitivity (Vault, Nexus) have the strictest app restrictions. Void (pentesting) has broadest network access but no access to financial or professional data — compromise of this profile yields no sensitive personal material. Plague and Ghost are designed to be expendable — deleted and recreated without loss of value.
A full per-profile threat model documents, for each of the nine profiles, the threat it counters, the blast radius if it is compromised, the data at risk, and the controls in place — plus the device-wide threats (theft, coercion, baseband) and an honest residual-risk statement.
Profile Isolation Matrix
Legend: ● Allowed · ◖ Conditional · ○ Restricted
| Profile | Network reach | Sandboxed Play | Termux / SSH | Sensitive data | External comms |
|---|---|---|---|---|---|
| Nexus | ◖ | ○ | ○ | ● | ○ |
| Plague | ● | ◖ | ○ | ○ | ◖ |
| Ghost | ● | ◖ | ○ | ○ | ◖ |
| Abyss | ● | ○ | ○ | ○ | ○ |
| Void | ● | ○ | ● | ○ | ◖ |
| Façade | ◖ | ○ | ● | ● | ● |
| Shade | ● | ○ | ○ | ○ | ○ |
| Vault | ◖ | ◖ | ○ | ● | ○ |
| Joker | ◖ | ○ | ○ | ○ | ◖ |
Capabilities not documented in a profile's public stack are shown restricted — the architecture is default-deny: a capability that is not part of a profile's purpose is not present in it. Per-profile app lists beyond the documented stacks stay private by policy.
Reproducible Build Detail
Installation
GrapheneOS was installed using the official web installer (WebUSB), which flashes verified factory images directly from the browser without requiring a custom recovery or third-party tools:
- Enable OEM unlocking and USB debugging; unlock the bootloader.
- Flash the GrapheneOS factory images via the web installer at
grapheneos.org/install/web. - Re-lock the bootloader after flashing — mandatory for verified boot to enforce image integrity.
- Complete first boot and confirm the verified-boot state on the yellow-state screen.
Source: architecture/grapheneos-setup.md
Boot hash retrieval
The verified-boot key hash is a device-specific, non-secret value — it identifies the GrapheneOS signing key, not the user. Retrieve it over ADB or directly on-device:
adb shell getprop ro.boot.vbmeta.digestCompare against the GrapheneOS-published release signing keys at grapheneos.org/releases to confirm the build is authentic. Source: MANUAL_INPUTS.md / README.md
App-source trust hierarchy
Applications are obtained from the most-trusted available source for each app. Source choice is a security decision — the trust hierarchy (highest to lowest):
- GrapheneOS App Store — first-party; signed by GrapheneOS
- Accrescent — modern, reproducible, signed builds
- F-Droid — FOSS, auditable, built from source
- Aurora Store — anonymous Play proxy (no Google account required)
- Sandboxed Play Store — lowest trust; runs unprivileged, confined to profiles that require it
Source: architecture/app-stack.md
SSH Integration with IRONVEIL
IRONVEIL Remote Unlock — Façade Profile. Termux is installed in the Façade (professional) profile, which has network access to the IRONVEIL workstation subnet.
Use cases: remote SSH administration of IRONVEIL; dracut-sshd remote unlock sequence on IRONVEIL boot; ed25519 key pair management for initramfs authorization.
The Termux private key for IRONVEIL unlock is stored only in the Façade profile and is not accessible from any other profile on the device.
Component Status
| Status | Component |
|---|---|
| Verified | GrapheneOS — Pixel 10 Pro Fold, Android 16 (build 2026060601), bootloader relocked |
| Verified | Verified boot key hash — published as an annotated placeholder; full fingerprint withheld |
| Verified | Titan M2 secure element — + Trusty TEE + Tensor G5 security core confirmed |
| Verified | Nine-profile architecture — Nexus, Plague, Ghost, Abyss, Void, Façade, Shade, Vault, Joker (all present on device 2026-06-11) |
| Operational | Per-profile FBE encryption — 9 profiles active; owner-profile key Titan M2-bound |
| Operational | Sandboxed Google Play — selective profiles only |
| Operational | RethinkDNS firewall — per-app rules active |
| Operational | WireGuard — profile-selective routing active |
| Active | Baseband IOMMU isolation — hardware-enforced |
| Operational | Termux SSH to IRONVEIL — Façade profile, ed25519 key enrolled |
| PENDING | Exact GrapheneOS release tag + security patch level — Android 16 / build 2026060601 captured; release-tag string pending |
| PENDING | Tensor G5 kernel version — not yet captured from device |
| PENDING | Per-profile WireGuard routing config — from RethinkDNS per-profile settings |
PENDING — the items above are secondary values not yet captured from the device (see the repo's MANUAL_INPUTS.md).Skills Demonstrated
- Mobile security — GrapheneOS deployment, relocked bootloader, verified boot
- Android hardening — per-profile FBE encryption, sandboxed Play, privilege separation
- Operational security — nine-profile compartmentalisation, no cross-profile leakage
- Network security — RethinkDNS per-app firewall, WireGuard profile routing
- Hardware security — Titan M2 root of trust, Tensor G5 IOMMU isolation
- Security architecture — threat-modelled profile design, failure containment
- Systems integration — Termux SSH to IRONVEIL, remote unlock from mobile
- Threat modelling — compartmentalisation by consequence, not by convenience
Repository
// GitHub — Full build documentation, architecture research, and threat model: github.com/rootdrifter/nullbyte — one repository in the github.com/rootdrifter portfolio.