DBSC in Chrome 146: TPM-Sitzungsschutz

Chrome 146 führt DBSC ein: Sitzungen gebunden an TPM für besseren Phishing-Schutz

Chrome 146 unter Windows aktiviert nun Gerätegebundene Sitzungscodes (DBSC) – ein Protokoll, das gestohlene Sitzungs-Cookies auf unbefugten Geräten nutzlos macht. Der private Schlüssel der Sitzung wird sicher im TPM-Chip gespeichert und verlässt ihn niemals. Eine Aktualisierung des Tokens erfordert eine hardwarebasierte Signatur. Damit wird die Authentifizierungssicherheit grundlegend verbessert und die Grenzen reiner Software-Lösungen überwunden.

So funktioniert DBSC: Von der Schlüsselerzeugung bis zur Aktualisierung

DBSC bekämpft Phishing-Bedrohungen wie LummaC2 oder Vidar, die Browser-Cookies aus dem Arbeitsspeicher stehlen. Anstatt langlebiger Token gibt der Server nur kurzlebige aus, die erst nach kryptografischer Beweisführung der Besitzrechte am TPM-gespeicherten privaten Schlüssel aktualisiert werden können.

So läuft es ab:

• Sitzung registrieren: Chrome fordert ein Schlüsselpaar vom TPM an. Der private Schlüssel bleibt im Chip; der öffentliche Schlüssel wird an den Server gesendet.
• Erster Cookie: Der Server speichert den öffentlichen Schlüssel und stellt einen kurzlebigen Token aus.
• Aktualisierung: Wenn der Cookie abläuft, erhält der Browser eine Herausforderung, signiert sie mit dem privaten Schlüssel über das TPM und sendet die Signatur zurück.
• Überprüfung: Der Server validiert die Signatur mit dem öffentlichen Schlüssel und stellt einen neuen Token aus, um die Sitzung zu verlängern.

Der zentrale Kompromiss? Sitzungen sind an das Gerät gebunden. Ohne den ursprünglichen TPM lassen sich selbst kopierte Cookies nicht nutzen. Google testete dies mit Okta – Die Zahl gestohlener Sitzungen sank deutlich, konkrete Zahlen wurden jedoch nicht veröffentlicht.

Vorteile der Hardware-Sicherheit:

• Der private Schlüssel ist selbst für Chrome oder Malware unzugänglich.
• Eindeutige Schlüssel pro Sitzung verhindern Tracking über Websites hinweg.
• Glatte Fallback-Mechanismen für Browser ohne DBSC-Unterstützung.

Erfahrungen aus der App-basierten Verschlüsselung: Warum TPM gewinnt

Google hatte bereits in Chrome 127 mit App-basierter Verschlüsselung versucht, Cookies mit Windows-Systemdiensten zu schützen. Doch Malware brach diese Lösung innerhalb von zwei Monaten: MeduzaStealer, LummaC2 und Rhadamanthys entschlüsselten sie durch Reverse Engineering, ohne SYSTEM-Rechte benötigt zu haben.

DBSC verlegt die Logik in die Hardware:

| Aspekt | App-basierte Verschlüsselung | DBSC |

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

| Schlüsselspeicherung | Windows-Speicher | TPM-Chip |

| Malware-Zugriff | Softwareausnutzung | Nur physischer Zugriff |

| Bypass-Zeit | 2 Monate | Unmöglich ohne Hardware |

| Datenschutz | Gerät-ID könnte preisgegeben werden | Nur öffentlicher Schlüssel geteilt |

Das ist kein bloßes Verstecken – es ist ein Wechsel des Vertrauensgrundpfeilers. TPM 2.0 (erforderlich in Windows 11) liefert nicht exportierbare Schlüssel und macht DBSC zu einer echten hardwarebasierten Lösung.

Backend-Implementierung: Minimaler Aufwand erforderlich

Frontend bleibt unverändert – Chrome übernimmt die Kryptografie automatisch. Sie müssen lediglich zwei Endpunkte hinzufügen:

• /register-session: Akzeptiert den öffentlichen Schlüssel (im WebCrypto-Format), bindet ihn an die Sitzung.
• /refresh-session: Stellt eine Herausforderung aus, überprüft die Signatur und rotiert den Cookie.

Implementierungslogik:

• Setzen Sie eine kurze TTL für den Cookie (z. B. 5–15 Minuten).
• Bei Aktualisierung: Generieren Sie einen Nonce, überprüfen Sie die ECDSA-Signatur.
• Fallback: Falls DBSC nicht verfügbar ist, greifen Sie auf Legacy-Cookies zurück.

Beispiel-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();
  }
});

Die W3C-Spezifikation ist Open Source (Google + Microsoft). Edge wird sie übernehmen; Firefox und Safari bleiben ungewiss.

Plattformbeschränkungen und Zukunftsaussichten

• Windows: TPM 2.0 ready in Chrome 146.
• macOS: Secure Enclave erwartet in zukünftigen Versionen.
• Linux: Noch kein Standard-TPM-Äquivalent vorhanden.
• Mobile: Android StrongBox möglich; iOS hängt von Safari-Unterstützung ab.

Falls das TPM ausfällt (z. B. bei Hardwareaustausch), müssen Benutzer sich neu anmelden und ein neues Schlüsselpaar generieren. Nicht geeignet für VDI-Umgebungen ohne Hardware-TPM.

Wichtige Erkenntnisse:

• DBSC zerstört das Geschäftsmodell von Info-Stehlern: Gestohlene Cookies sind ohne TPM nutzlos.
• Es ersetzt keine 2FA – sondern ergänzt sie, indem es Sitzungen nach der Anmeldung schützt.
• Backend-Änderungen minimal: Nur zwei Endpunkte und TTL-Logik nötig.
• Hardwarebindung verhindert Missbrauch über Geräte hinweg.
• Offene W3C-Standard steigert die Implementierungschancen.

Für mittlere bis erfahrene Entwickler: In hochwertigen Diensten (IAM, Banking) umsetzen. Fallbacks und Randfälle testen.

— Editorial Team