Zpět na domů

DBSC v Chrome 146: ochrana relací TPM

Chrome 146 implementoval DBSC pro ochranu relacních cookies přes TPM. Soukromý klíč zůstává v čipu, obnova tokenu vyžaduje hardwarovou podpis. Rozbor architektury, backendová implementace a srovnání s předchozími řešeními.

TPM-ochrana relací v Chrome 146: DBSC funguje
Advertisement 728x90

Chrome 146 zavádí DBSC: relace přivázané k TPM pro ochranu proti infostiléru

Chrome 146 na Windows zapnul Device Bound Session Credentials (DBSC) – protokol, který činí ukradené relační cookies bezcenné na jiných zařízeních. Soukromý klíč relace je uložen v čipu TPM a nikdy jej neopouští, vyžaduje hardwarovou podpisovou operaci pro aktualizaci tokenu. Tímto zásahem se radikálně mění způsob ochrany přihlášení, obejde omezení softwarových řešení.

Architektura DBSC: od generování klíčů po aktualizaci

DBSC řeší problém infostilérů jako LummaC2 nebo Vidar, kteří krádají cookies z paměti prohlížeče. Místo dlouhodobých tokenů server vydává krátkodobé, které lze aktualizovat pouze po kryptografické verifikaci vlastnictví klíče v TPM.

Postup je následující:

Google AdInline article slot
  • Registrace relace: Chrome požaduje od TPM párový klíč. Soukromý klíč zůstává v čipu, veřejný je odeslán serveru.
  • Počáteční cookie: Server si uloží veřejný klíč a vydá krátký token.
  • Aktualizace: Po vypršení cookie získá prohlížeč výzvu, podepíše ji soukromým klíčem prostřednictvím TPM a odešle podpis.
  • Verifikace: Server ověří podpis veřejným klíčem a prodlouží relaci novým tokenem.

Klíčový kompromis: relace je přivázaná ke konkrétnímu zařízení. Bez původního TPM je podpis nemožný, i když by bylo cookie zkopírováno. Google testoval s Okta: úspěch byl, ale konkrétní metriky nezveřejnil.

Výhody hardwarové ochrany:

  • Soukromý klíč je nečitelný ani pro Chrome ani pro malware.
  • Unikátní klíč na relaci zabrání sledování.
  • Plynulé přechodné řešení pro nepodporované prohlížeče.

Učení z App-Bound Encryption: proč TPM vítězí

Předchozí pokus Googlu v Chrome 127 (App-Bound Encryption) šifroval cookies systémovým službou Windows. Malware to obešlo za dva měsíce: MeduzaStealer, LummaC2 a Rhadamanthys prolomili bez oprávnění SYSTEM reverzním inženýrstvím.

Google AdInline article slot

DBSC přesouvá logiku do hardwaru:

| Aspekt | App-Bound Encryption | DBSC |

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

Google AdInline article slot

| Uložení klíče | Paměť Windows | Čip TPM |

| Přístup malware | Softwarový útok | Pouze fyzický |

| Čas obcházení | 2 měsíce | Nemožné bez hardwaru |

| Soukromí | Možnost identifikace zařízení | Pouze veřejný klíč |

Toto není jen záměna, ale změna základního důvěry: TPM 2.0 (povinný v Windows 11) zajišťuje klíče, které nelze exportovat.

Implementace na backendu: minimální změny

Frontend zůstává nedotčen – Chrome bere kryptografii na sebe. Stačí přidat dva endpointy:

  • /register-session: Přijímá veřejný klíč (formát WebCrypto), spojuje ho s relací.
  • /refresh-session: Vydává výzvu, ověřuje podpis, rotuje cookie.

Logika:

  • Nastavíme TTL cookie (např. 5–15 minut).
  • Při aktualizaci: generujeme nonce, ověříme ECDSA podpis.
  • Fallback: Pokud DBSC není dostupné, použijeme starší cookies.

Příklad pseudokódu (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();
  }
});

Specifikace W3C je otevřená (Google + Microsoft). Edge ji přijme, Firefox/Safari jsou v nejistotě.

Platformová omezení a budoucnost

  • Windows: TPM 2.0 – připraveno v Chrome 146.
  • macOS: Secure Enclave v budoucích verzích.
  • Linux: Žádný standardní ekvivalent TPM.
  • Mobilní: Android StrongBox možná, iOS závisí na Safari.

Při selhání TPM (výměna hardwaru) – opětovné přihlášení, nová dvojice klíčů. Pro VDI bez hardwarového TPM – nevhodné.

Důležité:

  • DBSC zničí monetizaci infostilérů: ukradené cookie jsou bezcenné bez TPM.
  • Nepřichází místo 2FA, doplňuje ji: chrání relaci po přihlášení.
  • Minimální refaktoring backendu: 2 endpointy + logika TTL.
  • Přivázání k hardwaru zabrání překročení zařízení.
  • Otevřený standard W3C – šance na širokou adopci.

Pro middle/senior: implementujte v high-value službách (IAM, bankovnictví). Testujte fallback a edge případy, jako chybějící TPM.

— Editorial Team

Advertisement 728x90

Číst dál