DBSC in Chrome 146: TPM session protection

Chrome 146 Introduces DBSC: Sessions Bound to TPM for Anti-Phishing Protection

Chrome 146 on Windows now enables Device Bound Session Credentials (DBSC) — a protocol that renders stolen session cookies useless on unauthorized devices. The session’s private key is stored securely within the TPM chip and never leaves it, requiring hardware-based signing to refresh the token. This fundamentally shifts authentication security, bypassing the limitations of software-only solutions.

How DBSC Works: From Key Generation to Refresh

DBSC tackles phishing threats like LummaC2 or Vidar, which steal browser cookies from memory. Instead of long-lived tokens, the server issues short-lived ones, refreshed only after cryptographic proof of ownership of the TPM-held private key.

Here’s how it works:

• Session Registration: Chrome requests a key pair from the TPM. The private key stays in the chip; the public key is sent to the server.
• Initial Cookie: The server stores the public key and issues a short-lived token.
• Refresh: When the cookie expires, the browser receives a challenge, signs it with the private key via TPM, and sends the signature back.
• Verification: The server validates the signature using the public key and issues a new token to extend the session.

The core trade-off? Sessions are tied to the device. Without the original TPM, even copied cookies can’t be used. Google tested this with Okta — session theft dropped significantly, though specific metrics weren’t disclosed.

Hardware Security Advantages:

• The private key remains inaccessible even to Chrome or malware.
• Unique per-session keys prevent cross-site tracking.
• Graceful fallback for browsers without DBSC support.

Lessons from App-Bound Encryption: Why TPM Wins

Google’s earlier attempt in Chrome 127 (App-Bound Encryption) encrypted cookies using Windows’ system services. Malware bypassed it in just two months: MeduzaStealer, LummaC2, and Rhadamanthys cracked it through reverse engineering without SYSTEM-level privileges.

DBSC moves the logic into hardware:

| Aspect | App-Bound Encryption | DBSC |

|--------|----------------------|------|

| Key Storage | Windows memory | TPM chip |

| Malware Access | Software exploitation | Only physical access |

| Bypass Time | 2 months | Impossible without hardware |

| Privacy | Device ID potentially exposed | Only public key shared |

This isn’t obfuscation — it’s a shift in trust root. TPM 2.0 (required in Windows 11) delivers non-exportable keys, making this a true hardware-backed solution.

Backend Implementation: Minimal Changes Required

Frontend stays untouched — Chrome handles cryptography automatically. You only need to add two endpoints:

• /register-session: Accepts the public key (in WebCrypto format), associates it with the session.
• /refresh-session: Issues a challenge, verifies the signature, rotates the cookie.

Implementation logic:

• Set a short TTL for the cookie (e.g., 5–15 minutes).
• On refresh: generate a nonce, verify the ECDSA signature.
• Fallback: if DBSC isn’t available, fall back to legacy cookies.

Example pseudocode (Node.js/Express):

const crypto = require('crypto');

app.post('/register-session', (req, res) => {
  const publicKey = req.body.publicKey; // JWK
  session.publicKey = publicKey;
  res.cookie('session', shortToken, { httpOnly: true, secure: true });
});

app.post('/refresh-session', (req, res) => {
  const { challenge, signature } = req.body;
  const isValid = crypto.verify(session.publicKey, Buffer.from(challenge), signature);
  if (isValid) {
    res.cookie('session', newShortToken, { httpOnly: true, secure: true });
  } else {
    res.status(401).end();
  }
});

The W3C specification is open-source (Google + Microsoft). Edge will adopt it; Firefox and Safari remain uncertain.

Platform Limitations and Future Outlook

• Windows: TPM 2.0 ready in Chrome 146.
• macOS: Secure Enclave expected in future versions.
• Linux: No standard TPM equivalent yet.
• Mobile: Android StrongBox possible; iOS depends on Safari support.

If the TPM fails (e.g., hardware replacement), users must re-login and generate a new key pair. Not suitable for VDI environments without hardware TPM.

Key Takeaways:

• DBSC breaks the business model of info-stealers: stolen cookies are useless without TPM.
• It doesn’t replace 2FA — it complements it by securing post-login sessions.
• Backend changes minimal: just two endpoints and TTL logic.
• Hardware binding prevents cross-device abuse.
• Open W3C standard increases adoption potential.

For mid-to-senior engineers: implement in high-value services (IAM, banking). Test fallbacks and edge cases like missing TPM.

— Editorial Team