demo · v142

Key Attestation Trust

DBSC is only as strong as the place the key actually lives. The spec lets the browser pick — software-only, TEE, TPM, or hardware enclave — depending on the device. Click each keystore to compare resistance to the attacks DBSC is designed to stop.

SW

Software-only key

Private key kept in the browser's normal disk store. No hardware isolation. Fallback when nothing else is available.

low-endVMslinux
tier 0
TEE

Trusted Execution Environment

Key lives in a CPU-isolated mode (TrustZone, SEV-SNP). The browser process can't read the bytes directly — it asks the secure world to sign.

AndroidChromeOS
tier 1
TPM

TPM 2.0 (discrete or fTPM)

Dedicated module sealed against firmware exfiltration. Standard on modern Windows / Linux desktops since Windows 11.

WindowsLinux
tier 2
SE

Secure Enclave / Strongbox

Physically distinct chip (Apple's Secure Enclave, Google Titan M, Samsung Strongbox). Independent boot, side-channel hardened.

macOSiOSPixel
tier 3

resistance scoreboard

malware exfil
—
side-channel
—
cold-boot
—
hardware tamper
—

concrete attacks

Cookie jar exfiltration Attacker steals the cookie file but not the key.

All four tiers: cookie alone is useless without the key.

Userland malware reading memory Attacker has code running in the browser process and dumps private keys.

software: yes

Kernel-mode rootkit signing on behalf Attacker has ring-0 and asks the OS to sign refresh JWTs without user knowing.

software/TEE: yes

Physical chip extraction / glitching Hardware lab attack on the keystore.

enclave/TPM: hard; SW: trivial

spec language

// The Browser SHOULD use the strongest key store available.
// The Sec-Session-Response JWS includes the public key in its `jwk` header.
// The server can ask for attestation (TBD), but DBSC v1 doesn't require it —
// the *fact* that the browser is gating the refresh on a hardware key is
// already enough to break the cookie-replay economy.

see also