demo · v142
Key Store Migration
When a user gets a new device, DBSC must re-bind their session to the new device's keystore. The server re-issues Sec-Session-Registration, the new device generates a fresh key pair (at whatever hardware tier is available), and the old binding is revoked. This demo walks through the cross-tier handshake and shows the security implications of upgrading or downgrading key tier.
Old device
TPM 2.0
Key in hardware; exportable only by root-level compromise of TPM bus.
→
New device
Secure Enclave
Key in dedicated security chip; non-exportable; hardware-attested.
Key store migration handshake
waiting
Old device
TPM 2.0 key
New device
Secure Enclave
Server
DBSC endpoint
step 0/0
Session binding timeline
Session binding
Old key validity
Migration window is brief: the server re-issues registration on the first authenticated request from the new device.
Security analysis
Direction
Upgrade
Old protection
TPM 2.0 — hardware-backed, non-exportable
New protection
Secure Enclave — dedicated security chip, attested
Migration risk
Minimal — brief unauthenticated window before new key is registered
Old key fate
Revoked on server; short-lived cookie expiry enforces cutover
Session continuity
Preserved — user re-authenticates once; server rotates binding