Criptografía poscuántica para MCP: blindar los servidores antes de que llegue la amenaza

El Model Context Protocol lleva meses consolidándose como la capa de integración estándar entre Claude y herramientas externas. Cuantos más equipos lo despliegan en entornos de producción, más superficie de ataque crece: cada MCP server que se configura en `claude_desktop_config.json` o vía Claude Code es un endpoint que maneja credenciales, datos sensibles y llamadas a sistemas internos. Esta semana, Security Boulevard publica un análisis técnico detallado sobre cómo aplicar criptografía resistente a ordenadores cuánticos —los algoritmos que el NIST estandarizó en 2024— a este tipo de despliegues.

El problema: MCP no fue diseñado pensando en la era poscuántica

MCP define cómo un modelo de lenguaje llama herramientas externas, pero no prescribe qué esquema criptográfico debe proteger esa comunicación. En la práctica, la mayoría de implementaciones actuales se apoyan en TLS 1.3 con curvas elípticas clásicas (ECDHE, P-256), que son suficientes hoy, pero vulnerables a un ordenador cuántico suficientemente potente que ejecute el algoritmo de Shor.

Esta amenaza no es inmediata; las estimaciones más conservadoras sitúan los primeros ordenadores cuánticos capaces de romper RSA-2048 en la década de 2030. Sin embargo, existe un vector de ataque conocido como harvest now, decrypt later: un adversario puede interceptar y almacenar tráfico cifrado hoy para descifrarlo cuando disponga del hardware adecuado. En entornos donde los MCP servers transmiten tokens de API, contexto de conversaciones o accesos a bases de datos internas, eso representa un riesgo real a medio plazo.

Qué propone el análisis

El artículo de Security Boulevard articula lo que llama un blueprint (marco de referencia) con varias capas:

• Algoritmos NIST PQC en el canal de transporte. Sustituir o complementar ECDHE por ML-KEM (antes Kyber) para el intercambio de claves, e integrar ML-DSA (antes Dilithium) para firmas digitales en la autenticación de servidores MCP.
• Autenticación mutua entre agente y servidor. Cada subagente o instancia de Claude Code que invoque un MCP server debería presentar un certificado firmado con algoritmos poscuánticos, evitando que un servidor comprometido en la cadena pueda impersonar a otro.
• Gestión de secretos en hooks y plugins. Los hooks de Claude Code —que se ejecutan en eventos como `PreToolUse` o `PostToolUse`— suelen manejar credenciales en variables de entorno. El análisis recomienda integrar gestores de secretos compatibles con PQC (como variantes de HashiCorp Vault con soporte para CRYSTALS) en lugar de pasar claves en texto plano.
• Auditoría de la cadena de skills. Las skills pueden encadenar llamadas a múltiples herramientas; cada salto debería validar la integridad del contexto transmitido mediante firmas poscuánticas para detectar manipulaciones en tránsito.

Para quién es relevante esto ahora mismo

La lectura honesta es que este documento va dirigido principalmente a dos perfiles: equipos de seguridad en empresas grandes que ya despliegan MCP en producción con datos regulados (sanidad, finanzas, legal), y arquitectos que están diseñando infraestructura nueva y pueden incorporar estos requisitos desde el inicio sin coste de migración.

Para el desarrollador individual o el equipo pequeño que monta un MCP server para automatizar su flujo de trabajo interno, la urgencia es baja. TLS 1.3 bien configurado sigue siendo robusto para la inmensa mayoría de casos de uso en 2026. La ventana en la que actuar sin prisa existe, y conviene usarla para entender qué tráfico generan los servidores antes de blindarlos.

Donde el análisis resulta más inmediatamente útil es en el apartado de autenticación mutua y gestión de secretos: esas recomendaciones son válidas independientemente del panorama cuántico y corrigen vectores de ataque clásicos que hoy están abiertos en muchas instalaciones de Claude Code.

Una nota sobre el estado de las herramientas

La adopción de PQC en librerías estándar (OpenSSL, BoringSSL, rustls) ha avanzado notablemente desde la estandarización del NIST, pero el soporte en clientes HTTP de ecosistemas como Node.js o Python todavía requiere configuración explícita o dependencias adicionales. Quien quiera implementar lo descrito en el artículo encontrará que el camino existe, pero no es trivial ni está automatizado.

---

El análisis de Security Boulevard no es alarmista ni pretende que los equipos migren su infraestructura MCP este trimestre. Lo que sí hace bien es situar la conversación de seguridad poscuántica dentro del ecosistema Claude antes de que sea urgente, que es exactamente cuando tiene sentido tenerla. En ElephantPink lo vemos como una señal de madurez del ecosistema: cuando un protocolo empieza a recibir este tipo de escrutinio técnico, es porque ya importa lo suficiente para que valga la pena atacarlo.