Field Notes

entity

Titan M secure element

StatusStableUpdatedStands on8 sourcesSupportsnotes

The Titan M and its successor Titan M2 are Google’s discrete tamper-resistant security microcontrollers for Pixel devices. Titan M shipped in the Pixel 3 (2018) as the first dedicated-hardware implementation of Android StrongBox; Titan M2 replaced it from the Pixel 6 (2021) onward, including the Pixel 10 generation. The chip is based on the open RISC-V architecture with its own SRAM, flash, and cryptographic accelerators, physically separate from the application processor so that a full Linux kernel compromise still cannot reach the secrets it holds.1

What it does

The Titan M2 anchors four mechanisms that the rest of the platform trusts:

  • Verified boot root of trust. It validates the bootloader and boot chain on every start, enforces anti-rollback, and signals tampering to the user.
  • StrongBox keystore. App keys are generated and used inside the chip and never leave it; The Android Platform Security Model describes StrongBox as the Android keystore moved into TRH for isolation beyond what a TEE sharing the main SoC provides.
  • Weaver throttled key derivation. Disk-encryption key derivation requires a Weaver token stored in the chip, released only against the correct Weaver key under hardware-enforced delays, making offline passcode brute force infeasible. GrapheneOS documents a 20-attempt schedule whose delays grow from one minute to nine years and then refusal.2 Note the design property this implies: the Weaver secret is a stored value the chip releases on correct-key presentation, unlike Apple’s Secure Enclave UID, which is fused into the silicon and never exists in a form the chip will output. Offline brute-force resistance of phone disk encryption develops why that difference matters if the chip itself is ever compromised.
  • Insider Attack Resistance. The chip refuses firmware updates unless the owner authenticates first, so even an attacker holding Google’s signing keys cannot weaken the chip to extract secrets; the secrets are wiped instead.3

Google reports that independent lab testing subjected Titan M2 to electromagnetic analysis, voltage glitching, and laser fault injection.4 The chip carries Common Criteria PP0084 certification and FIPS 140-3 CAVP algorithm validations under its internal name “Titan H1D3”.5

Why it matters for Android forensics

Leaked Cellebrite support matrices state that passcode brute force against the Titan M2 is not supported, which forces forensic extraction of stock Pixels to rely on OS-level exploits in the after-first-unlock state rather than on credential attacks. GrapheneOS builds directly on Weaver and IAR: its disk encryption design makes a seized, locked device practically opaque, and its duress feature wipes the Weaver slots to make the wipe unrecoverable.

How it compares to other mobile secure hardware

Design Isolation Notes
ARM TrustZone TEE (most Androids) Logical only; shares cores, cache, and power with the main OS Weakest against side channels; quality varies by vendor
Qualcomm/Exynos TEE implementations Logical isolation on the SoC No discrete element on most devices
Apple Secure Enclave (SEP) Dedicated core and power domain inside the SoC, encrypted memory region Strong isolation; paired with biometrics and rate limiting
Samsung Knox Vault (Galaxy S21+) Dedicated secure processor plus physically separate secure flash Tamper sensors; CC EAL4+ and deep government certifications; runs Samsung Weaver with the same release-on-correct-key design
Google Titan M2 Discrete chip off the SoC Strongest physical separation of the mainstream designs; RISC-V for auditability

Samsung’s own documentation frames Knox Vault as moving from a “safe in the branch office” (TrustZone) to a vault isolated from everyone in the building, which is the same design direction as Titan M2.6 The practical security difference among Titan M2, Knox Vault, and the Secure Enclave is small compared with the gap between any of them and a phone with only a shared-CPU TEE — the tier that includes most MediaTek-based and budget Android devices, several of which also carry unpatchable boot-ROM flaws.7

Limits

A secure element protects secrets at rest and throttles guessing; it does nothing for an unlocked, actively used device, and it cannot fix exploitable bugs in the main OS — that is the job of exploit mitigations such as hardware memory tagging and of the update cadence that the Pixel line pairs with the chip. The chip’s guarantees also end at the vendor’s support window: GrapheneOS Pixel procurement tracks the seven-year minimum support that makes Pixel 8 and later the only currently recommended hardware.

The chip is also itself attack surface. Quarkslab achieved code execution on the original Titan M via CVE-2022-20233 (a one-byte out-of-bounds write in the Keymaster task, patched June 2022) and used it to exfiltrate StrongBox-protected keys from a rooted device.8 No public equivalent exists against Titan M2, and the attack required application-processor root first, but the precedent matters architecturally: secrets stored in the chip can leave the chip when the chip is compromised, which is the property Apple’s fused-UID design eliminates. Notably, Quarkslab could not read Titan M’s internal key-ladder root, so even their exploit did not yield a full offline brute-force capability.

Is Titan M2 one exploit away from extraction?

Structurally, yes — in the same way any secure element is. Its resistance is empirical, not principled: there is no design property that makes Titan M2 unfalsifiable, only a small attack surface, a patched redesign after the Titan M1 lessons, independent fault-injection testing, and an unclaimed (up-to-$1.5-million) exploit bounty. The Samsung comparison in Samsung Knox shows what it looks like when the surrounding stack fails instead: Samsung’s BFU extractability comes from boot-chain and TEE weaknesses around a comparably rated chip, not from a public Knox Vault Processor break. The reasons Titan M2’s own record is better so far are the locked-down Pixel boot chain, faster patch propagation, and — less comfortingly — lower attacker investment in a smaller target population. A single Keymaster-task bug of the CVE-2022-20233 class would reopen the offline regime, which is why the derivation note treats the user passphrase, not the chip, as the final backstop: the chip is a strong wall with a demonstrated class of doors, and the passphrase is what protects you if a door is ever found.

  1. What is the Titan M2 security chip in Google’s Pixel phones?, Android Authority, December 2024. ↩

  2. GrapheneOS, “How is disk encryption implemented?”, project FAQ. A downstream operating-system project describing hardware it does not build, so this is an informed reading of the chip’s behaviour rather than the vendor’s own specification. Living documentation, unsnapshotted. ↩

  3. The Android Platform Security Model (Mayrhofer et al., 2023), arXiv:1904.05572v3. ↩

  4. Pixel 6: Setting a new standard for mobile security, Google Online Security Blog, October 2021. ↩

  5. Pixel security certifications on Android, Pixel Phone Help. ↩

  6. Knox Vault fundamentals, Samsung Knox documentation. ↩

  7. See Cellebrite § The asymmetry: hardware matters. ↩

  8. Attacking Titan M with Only One Byte, Quarkslab, August 2022. ↩

Built on 8 sources (8 external).

Working out connections…