DBSC dans Chrome 146 : protection des sessions TPM

Chrome 146 introduit DBSC : des sessions liées au TPM pour une protection anti-phishing renforcée

Chrome 146 sous Windows active désormais les identifiants de session liés au périphérique (DBSC) — un protocole qui rend les cookies de session volés inutilisables sur les appareils non autorisés. La clé privée de la session est stockée en toute sécurité dans le chip TPM et n’en sort jamais, nécessitant une signature matérielle pour actualiser le jeton. Cette innovation repense fondamentalement la sécurité d’authentification, dépassant les limites des solutions logicielles classiques.

Comment fonctionne DBSC : de la génération de clés à la mise à jour

Le système DBSC combat efficacement les menaces phishing comme LummaC2 ou Vidar, qui récupèrent les cookies navigateur depuis la mémoire vive. Contrairement aux jetons longue durée, le serveur émet des jetons courts, actualisés uniquement après preuve cryptographique de possession de la clé privée stockée dans le TPM.

Voici le processus :

• Enregistrement de la session : Chrome demande une paire de clés au TPM. La clé privée reste dans le chip ; la clé publique est envoyée au serveur.
• Cookie initial : Le serveur stocke la clé publique et délivre un jeton temporaire.
• Actualisation : À l’expiration du cookie, le navigateur reçoit un défi, le signe avec la clé privée via le TPM, puis renvoie la signature.
• Vérification : Le serveur valide la signature à l’aide de la clé publique et délivre un nouveau jeton pour prolonger la session.

Le principal compromis ? Les sessions sont liées à l’appareil. Sans le TPM original, même des cookies copiés ne peuvent être utilisés. Google a testé cette solution avec Okta — le vol de sessions a chuté nettement, bien que les chiffres précis n’aient pas été divulgués.

Avantages de la sécurité matérielle :

• La clé privée reste inaccessible même à Chrome ou aux logiciels malveillants.
• Des clés uniques par session empêchent le suivi entre sites.
• Fallback fluide pour les navigateurs sans prise en charge DBSC.

Leçons tirées de l’encryption liée aux applications : pourquoi le TPM l’emporte

Google avait tenté une approche similaire dans Chrome 127 (Encryption liée à l’application), chiffrant les cookies via les services système Windows. En seulement deux mois, des malwares comme MeduzaStealer, LummaC2 ou Rhadamanthys ont contourné cette mesure grâce à une analyse inverse, sans besoin de privilèges SYSTEM.

DBSC transfère la logique dans le matériel :

| Aspect | Encryption liée à l’application | DBSC |

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

| Stockage des clés | Mémoire Windows | Chip TPM |

| Accès par malware | Exploitation logicielle | Seul accès physique |

| Temps de contournement | 2 mois | Impossible sans matériel |

| Confidentialité | ID appareil potentiellement exposé | Seule la clé publique partagée |

Ce n’est pas de la simple obfuscation — c’est un changement fondamental de la racine de confiance. Le TPM 2.0 (obligatoire sous Windows 11) garantit des clés non exportables, faisant de DBSC une solution véritablement matérielle.

Implémentation côté serveur : des modifications minimales requises

Le frontend reste inchangé — Chrome gère automatiquement la cryptographie. Vous devez simplement ajouter deux points d’accès :

• /register-session : accepte la clé publique (format WebCrypto), l’associe à la session.
• /refresh-session : émet un défi, vérifie la signature, rotate le cookie.

Logique d’implémentation :

• Définir un TTL court pour le cookie (ex. 5–15 minutes).
• À l’actualisation : générer un nonce, valider la signature ECDSA.
• Fallback : si DBSC n’est pas disponible, revenir aux cookies classiques.

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

La spécification W3C est open source (Google + Microsoft). Edge l’adopte ; Firefox et Safari restent incertains.

Limites des plateformes et perspective future

• Windows : prêt avec TPM 2.0 dans Chrome 146.
• macOS : Secure Enclave attendu dans les futures versions.
• Linux : Aucun équivalent standard TPM pour l’instant.
• Mobile : StrongBox Android possible ; iOS dépend de la prise en charge de Safari.

Si le TPM échoue (ex. remplacement matériel), les utilisateurs doivent se reconnecter et générer une nouvelle paire de clés. Non adapté aux environnements VDI sans TPM matériel.

Points clés :

• DBSC détruit le modèle économique des voleurs d’informations : les cookies volés sont inutiles sans le TPM.
• Il ne remplace pas la 2FA — il la complète en sécurisant les sessions post-connexion.
• Modifications côté serveur minimes : deux endpoints et logique TTL.
• L’ancrage matériel empêche l’abus cross-appareil.
• Standard W3C ouvert augmente les chances d’adoption.

Pour les ingénieurs intermédiaires à confirmés : implémentez-le dans les services critiques (IAM, banque). Testez les fallbacks et les cas limites comme l’absence de TPM.

— Editorial Team