DBSC w Chrome 146: ochrona sesji TPM

Chrome 146 wprowadza DBSC: sesje powiązane z TPM ochroną przed infostealerami

Chrome 146 na Windowsie aktywował Device Bound Session Credentials (DBSC) — protokół, który sprawia, że skradzione ciasteczka sesyjne są bezużyteczne na innych urządzeniach. Prywatny klucz sesji przechowywany jest w czipie TPM i nigdy go nie opuszcza, wymagając podpisu sprzętowego do odświeżenia tokenu. To drastycznie zmienia sposób ochrony uwierzytelniania, obejmując ograniczenia rozwiązań programowych.

Architektura DBSC: od generowania kluczy po odświeżanie

DBSC rozwiązuje problem infostealerów typu LummaC2 czy Vidar, które kradną ciasteczka z pamięci przeglądarki. Zamiast długotrwałych tokenów serwer wydaje krótko żyjące, które można odświeżyć tylko po kryptograficznej weryfikacji posiadania klucza w TPM.

Proces działa następująco:

• Rejestracja sesji: Chrome żąda pary kluczy od TPM. Klucz prywatny pozostaje w czipie, publiczny wysyłany jest do serwera.
• Początkowe ciasteczko: Serwer zapisuje klucz publiczny i wydaje krótki token.
• Odświeżenie: Po wygaśnięciu ciasteczka przeglądarka otrzymuje challenge, podpisuje je kluczem prywatnym przez TPM i przesyła podpis.
• Weryfikacja: Serwer sprawdza podpis za pomocą klucza publicznego i przedłuża sesję nowym tokenem.

Kluczowy kompromis: sesja jest powiązana z urządzeniem. Bez oryginalnego TPM podpis jest niemożliwy, nawet jeśli ciasteczko zostanie skopiowane. Google testowało z Okta: ilość kradzieży sesji spadła, choć szczegółów nie ujawniono.

Zalety ochrony sprzętowej:

• Klucz prywatny nie jest czytelny nawet dla Chrome czy malwarów.
• Unikalny klucz na sesję zapobiega śledzeniu.
• Wygodne przejście do trybu zastępczego dla nieobsługiwanych przeglądarek.

Lekcje z App-Bound Encryption: dlaczego TPM wygrywa

Poprzednia próba Google w Chrome 127 (App-Bound Encryption) szyfrowała ciasteczka systemowym usługą Windows. Malware obejrzało to w ciągu dwóch miesięcy: MeduzaStealer, LummaC2 i Rhadamanthys złamali bez uprawnień SYSTEM przez reverse engineering.

DBSC przenosi logikę do sprzętu:

| Aspekt | App-Bound Encryption | DBSC |

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

| Przechowywanie klucza | Pamięć Windows | Czip TPM |

| Dostęp malwarów | Programowe | Tylko fizyczne |

| Czas obejścia | 2 miesiące | Niemożliwe bez sprzętu |

| Prywatność | Możliwy ID urządzenia | Tylko klucz publiczny |

To nie jest obfuskacja, ale zmiana trust root: TPM 2.0 (wymagany w Windows 11) zapewnia klucze nieprzenoszone.

Wdrożenie na backendzie: minimalne zmiany

Frontend nie zmienia się — Chrome bierze kryptografię na siebie. Dodajemy dwa punkty końcowe:

• /register-session: Przyjmuje klucz publiczny (format WebCrypto), kojarzy go z sesją.
• /refresh-session: Wydaje challenge, weryfikuje podpis, rotuje ciasteczko.

Logika:

• Ustawiamy TTL ciasteczka (np. 5–15 minut).
• Na odświeżeniu: generujemy nonce, sprawdzamy podpis ECDSA.
• Tryb zastępczy: jeśli brak DBSC, używamy starszych ciasteczek.

Przykład pseudokodu (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();
  }
});

Specyfikacja W3C jest otwarta (Google + Microsoft). Edge ją przyjmie, Firefox/Safari — wątpliwe.

Ograniczenia platformowe i przyszłość

• Windows: TPM 2.0 — gotowe w 146.
• macOS: Secure Enclave w przyszłych wersjach.
• Linux: Brak standardowego odpowiednika TPM.
• Mobilne: Android StrongBox możliwe, iOS zależy od Safari.

W przypadku awarii TPM (zamiana sprzętu) — ponowne logowanie, nowa para kluczy. Dla VDI bez hardware TPM — nie nadaje się.

Co ważne:

• DBSC niszczy model monetizacji infostealerów: skradziony token jest bezużyteczny bez TPM.
• Nie zastępuje 2FA, ale uzupełnia: chroni sesję po zalogowaniu.
• Minimalny refactor backendu: 2 punkty końcowe + logika TTL.
• Powiązanie z hardwarem zapobiega nadużyciom między urządzeniami.
• Otwarty standard W3C — szansa na przyjęcie.

Dla developerów średnich i seniorów: wdrażajcie w usługach wysokiej wartości (IAM, bankowość). Testujcie tryb zastępczy i przypadki graniczne, np. brak TPM.

— Editorial Team