DBSC en Chrome 146: protección de sesiones TPM

Chrome 146 introduce DBSC: sesiones vinculadas al TPM para protección contra phishing

Chrome 146 en Windows ahora activa las Credenciales de Sesión Vinculadas al Dispositivo (DBSC) — un protocolo que hace que los cookies de sesión robados sean inútiles en dispositivos no autorizados. La clave privada de la sesión se almacena de forma segura dentro del chip TPM y nunca sale de él, requiriendo una firma basada en hardware para renovar el token. Esto cambia fundamentalmente la seguridad de la autenticación, superando las limitaciones de soluciones únicamente software.

Cómo funciona DBSC: desde la generación de claves hasta la renovación

DBSC combate amenazas de phishing como LummaC2 o Vidar, que roban cookies del navegador desde la memoria. En lugar de tokens de larga duración, el servidor emite tokens cortos, renovados únicamente tras una prueba criptográfica de propiedad de la clave privada almacenada en el TPM.

Así es cómo funciona:

• Registro de sesión: Chrome solicita un par de claves al TPM. La clave privada permanece en el chip; la pública se envía al servidor.
• Cookie inicial: El servidor almacena la clave pública e emite un token de corta duración.
• Renovación: Cuando la cookie expira, el navegador recibe un desafío, lo firma con la clave privada mediante el TPM y envía la firma de vuelta.
• Verificación: El servidor valida la firma usando la clave pública y emite un nuevo token para prolongar la sesión.

¿Cuál es el principal intercambio? Las sesiones están ligadas al dispositivo. Sin el TPM original, incluso copiar las cookies no sirve. Google probó esto con Okta: el robo de sesiones disminuyó significativamente, aunque no se revelaron métricas específicas.

Ventajas de seguridad de hardware:

• La clave privada sigue inaccesible incluso para Chrome o malware.
• Claves únicas por sesión evitan el rastreo entre sitios.
• Fallback elegante para navegadores sin soporte DBSC.

Lecciones del cifrado vinculado a aplicaciones: por qué el TPM gana

El intento anterior de Google en Chrome 127 (Cifrado Vinculado a Aplicaciones) cifraba cookies usando servicios del sistema de Windows. Malware lo vulneró en solo dos meses: MeduzaStealer, LummaC2 y Rhadamanthys lo rompieron mediante ingeniería inversa sin necesidad de privilegios SYSTEM.

DBSC traslada la lógica al hardware:

| Aspecto | Cifrado Vinculado a Aplicaciones | DBSC |

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

| Almacenamiento de claves | Memoria de Windows | Chip TPM |

| Acceso de malware | Explotación de software | Solo acceso físico |

| Tiempo de bypass | 2 meses | Imposible sin hardware |

| Privacidad | ID del dispositivo podría exponerse | Solo se comparte clave pública |

Esto no es obfuscación — es un cambio en la raíz de confianza. El TPM 2.0 (requerido en Windows 11) ofrece claves no exportables, convirtiéndolo en una solución verdaderamente respaldada por hardware.

Implementación en backend: cambios mínimos necesarios

El frontend permanece intacto — Chrome maneja automáticamente la criptografía. Solo necesitas añadir dos endpoints:

• /register-session: acepta la clave pública (en formato WebCrypto), la asocia con la sesión.
• /refresh-session: genera un desafío, verifica la firma y rota la cookie.

Lógica de implementación:

• Establece un TTL corto para la cookie (por ejemplo, 5–15 minutos).
• Al renovar: genera un nonce, verifica la firma ECDSA.
• Fallback: si DBSC no está disponible, vuelve a las cookies tradicionales.

Ejemplo de pseudocódigo (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 especificación de W3C es de código abierto (Google + Microsoft). Edge la adoptará; Firefox y Safari aún son inciertos.

Limitaciones de plataforma y perspectivas futuras

• Windows: listo para TPM 2.0 en Chrome 146.
• macOS: Se espera el Secure Enclave en versiones futuras.
• Linux: aún no hay equivalente estándar de TPM.
• Móvil: StrongBox en Android posible; iOS depende del soporte de Safari.

Si el TPM falla (por ejemplo, reemplazo de hardware), los usuarios deben volver a iniciar sesión y generar un nuevo par de claves. No es adecuado para entornos VDI sin TPM físico.

Conclusiones clave:

• DBSC rompe el modelo de negocio de los estafadores: las cookies robadas son inútiles sin TPM.
• No reemplaza el 2FA — lo complementa al proteger sesiones post-inicio de sesión.
• Cambios en backend mínimos: solo dos endpoints y lógica de TTL.
• El vínculo con hardware previene abusos entre dispositivos.
• Estándar abierto de W3C aumenta potencial de adopción.

Para ingenieros de nivel medio a senior: implementa en servicios de alto valor (IAM, banca). Prueba fallbacks y casos extremos como ausencia de TPM.

— Editorial Team