demo · v147 · security · DBSC

Binding Strength Demo

Three attack scenarios — plain cookie theft, DBSC hardware binding, and hybrid migration — each with a live attack trace. A strength meter rates each approach's resistance to session theft.

The DBSC path calls the same backend endpoints as the replay lab: the server stores a real dbsc+jwt public-key proof and rejects refresh attempts signed with the attacker's key. Plain-cookie and hybrid traces show the contrasting policy decisions around that live check.

1 — Cookie theft

Session stored as a plain cookie. An attacker who steals the cookie file can replay it from any machine — the server has no way to distinguish.

binding strength

2 — DBSC binding

Session bound to a device key in the TPM. The attacker steals the cookie but cannot sign the proof-of-possession challenge — the key never leaves hardware.

binding strength
95 / 100
—

3 — Hybrid migration

Existing sessions remain as cookies; new logins get DBSC binding. Over time the cookie sessions expire and only hardware-bound ones remain — no hard cutover needed.

binding strength
55 / 100
—

Comparison

Property Plain cookie DBSC Hybrid migration
Cookie replayable from attacker device? Yes No — PoP sig required Depends on session age
Key stored in TPM / Secure Enclave? No Yes Yes (new sessions)
Requires server-side changes? No Yes — /dbsc-register + PoP endpoint Partial — additive path
Works offline / no network? Yes No — refresh requires PoP round-trip Legacy sessions only
Malware exfil risk High Low — key not exportable Medium (mixed fleet)

SubtleCrypto in the browser

// DBSC uses a P-256 keypair generated and stored in hardware
const keyPair = await crypto.subtle.generateKey(
  { name: 'ECDSA', namedCurve: 'P-256' },
  false,       // not extractable — key never leaves the device
  ['sign', 'verify']
);

// Per-request proof-of-possession signature
const signature = await crypto.subtle.sign(
  { name: 'ECDSA', hash: 'SHA-256' },
  keyPair.privateKey,
  challenge  // nonce from server, prevents replay
);

// Server verifies: if signature fails → session invalid, evict attacker
Checking SubtleCrypto availability…

see also

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗