Qué cifrado vale y cuál no para el ENS. Aquí no se improvisa.
♙Miguel Ángel Carriazo
▣18 junio 2026
◷13 min de lectura
LEE ESTA GUÍA CUANDO...
Necesites trabajar sobre criptología dentro del ENS.
En vez de buscar una frase aislada, sigue el recorrido de la guía y relaciona cada conclusión con el sistema, el responsable y la evidencia que debería existir.
CCN-STIC 807 · Criptología
Dónde encaja esta guía en una revisión práctica
Utiliza la guía para orientar la revisión y contrasta siempre la versión vigente en el portal oficial del CCN-CERT.
Qué es
Qué es y para qué vale
La CCN-STIC 807 establece los algoritmos, longitudes de clave y usos criptográficos admitidos en el marco del ENS, así como cuándo se exige el empleo de productos certificados o cualificados. Es la referencia para no «inventar» criptografía en sistemas sujetos al Esquema, y su Anexo 1 aborda los Prestadores de Servicios de Confianza.
La criptografía es uno de los puntos donde más se improvisa y donde un error pasa desapercibido hasta que llega el auditor. Asumir que «TLS por defecto basta» o seguir usando algoritmos y longitudes ya desaconsejados es habitual. La 807 fija qué es aceptable, en qué condiciones y con qué productos, especialmente en categorías MEDIA y ALTA.
La guía clasifica los mecanismos criptográficos en dos categorías: Recomendados (R) (ofrecen seguridad a largo plazo) y Legacy (L) (solo aceptables a corto plazo, con fecha límite). La fortaleza de seguridad se mide en bits (112, 128, 192, 256).
Mi lectura
La criptografía suele parecer fuerte justo hasta que preguntas quién gestiona las claves.
En criptología es fácil dejarse impresionar por algoritmos, tamaños de clave y nombres de productos. Yo empezaría por algo menos elegante: inventario de usos, propiedad de claves y ciclo de vida. Porque un algoritmo robusto con una clave compartida por correo sigue siendo un problema.
La 807 debe aterrizarse en decisiones de arquitectura. Qué información necesita protección, en tránsito o reposo, qué mecanismos están autorizados, quién genera y custodia claves, cómo se rotan, qué ocurre ante compromiso y cómo se retiran mecanismos obsoletos.
No pregunto solo “¿cifráis?”. Pregunto “¿qué cifráis, con qué, quién controla la clave y cómo sabéis que sigue siendo seguro?”.
CCN-STIC 807 · Ciclo de vida criptográfico
Cómo pasar del algoritmo a la gestión real de claves
Lectura técnica GRCREAL: una manera práctica de conectar la guía con arquitectura, operación y evidencia.
Explicación técnica
Qué me interesa técnicamente de esta guía
La dimensión técnica de la 807 no se reduce a elegir algoritmos fuertes. En la práctica, el punto crítico es el ciclo de vida criptográfico: qué información o flujo requiere protección, qué mecanismo se emplea, quién gestiona el secreto, cómo se distribuye, cuándo se rota y qué ocurre si el material criptográfico se compromete o expira.
También conviene separar claramente protección en tránsito, en reposo, firma, autenticación y gestión de certificados. Muchas organizaciones creen tener “la criptografía resuelta” porque fuerzan TLS en el frontal, mientras internamente mantienen claves compartidas, certificados olvidados o cifrados de base de datos sin una gobernanza clara de acceso y rotación.
Para mí, la guía aporta mucho cuando se usa para revisar arquitectura y no solo inventario de algoritmos. Cada decisión criptográfica tiene implicaciones operativas: compatibilidad, recuperación, segregación de funciones y dependencia de proveedores.
Inventario criptográfico mínimo
Algoritmo, longitud de clave, protocolo, ubicación, propietario, almacén de claves, fecha de expiración, rotación, dependencias y procedimiento de revocación. En aplicaciones, buscaría secretos embebidos, reutilización entre entornos y certificados sin dueño.
La capacidad de rotación debería probarse en servicios críticos. Una clave que no puede cambiarse sin una interrupción grave es una deuda operativa.
Error habitual
Dónde suele torcerse en proyectos reales
DONDE SUELE TORCERSE
Confiar en la fortaleza del algoritmo e ignorar la debilidad del ciclo de vida. El secreto incrustado en código, la clave compartida entre entornos, el certificado sin propietario o la falta de inventario suelen generar más riesgo que el hecho de usar una suite concreta u otra.
El otro error clásico es no preparar la respuesta: el día que una clave se compromete, la organización descubre que rotarla afecta a más sistemas de los que pensaba.
Ejemplo práctico
Cómo lo aterrizaría en un caso real
CASO
Piensa en una aplicación que expone TLS hacia Internet, cifra copias de seguridad y firma integraciones con terceros. A simple vista “usa criptografía” en tres puntos. Sin embargo, la pregunta técnica útil es otra: ¿quién controla cada clave, dónde se almacena, con qué acceso, cómo se rota, cómo se audita el uso y qué plan existe si un certificado caduca o un secreto se filtra?
Cuando haces ese ejercicio, la criptología deja de ser un checkbox de cumplimiento y se convierte en una conversación seria sobre arquitectura y operación segura.
Ejemplo técnico de infraestructura
Certificados TLS en el frontal y secretos embebidos en la aplicación
EJEMPLO TÉCNICO · INFRAESTRUCTURA
Componentes implicados en el caso
INFRA
El servicio usa TLS correctamente en el balanceador, pero la aplicación contiene credenciales de base de datos en un fichero de configuración y comparte la misma clave entre preproducción y producción.
Arquitectura técnica: ADC, servidores web, aplicación, base de datos, vault y PKI. Fallo: se protege el canal externo, pero no el ciclo de vida de secretos internos. Riesgo: exposición de credenciales, dificultad de rotación y compromiso cruzado entre entornos. Qué haría: secret vault, identidades administradas, separación por entorno, rotación automatizada e inventario de certificados y claves.
Pregunta incómoda
¿Puedes revocar una clave comprometida sin detener medio negocio?
NO RESPONDAS CON LA POLÍTICA
La respuesta revela mucho sobre arquitectura y dependencia. Si las claves están embebidas en aplicaciones, compartidas entre entornos o sin inventario, la respuesta a un compromiso será lenta y arriesgada.
También miraría certificados vencidos, algoritmos heredados y excepciones. La deuda criptográfica suele permanecer invisible porque el sistema sigue funcionando.
Ref.
Qué pediría
Qué necesito ver
GR-01
Inventario criptográfico
Usos, algoritmos, certificados y propietarios.
GR-02
Gestión de claves
Generación, custodia, acceso, rotación y destrucción.
GR-03
Configuración
Protocolos y suites realmente habilitados en sistemas.
GR-04
Respuesta
Procedimiento y pruebas ante compromiso o expiración.
Mi enfoque
Cómo la aterrizaría yo en un entorno real
GRCREAL
Elegiría un servicio importante y seguiría la criptografía completa: cliente, balanceador, aplicación, base de datos, copias y comunicaciones con terceros. Muchas inconsistencias aparecen entre capas.
La criptografía no se gobierna desde una lista de algoritmos permitidos. Se gobierna desde un ciclo de vida que puedas operar bajo presión.
Contenido
Qué contiene la guía
Los algoritmos y longitudes de clave admitidos para cada uso (cifrado simétrico, firma digital, resumen, acuerdo de claves, cifrado asimétrico, MAC y AEAD).
Las condiciones de empleo de la criptografía en tránsito y en reposo.
Cuándo se exigen productos certificados o cualificados (catálogo CPSTIC).
Pautas de gestión del ciclo de vida de las claves (generación, transporte, custodia, archivado y destrucción).
El Anexo 1 sobre Prestadores de Servicios de Confianza y la transición algorítmica de RSA.
Algoritmo y longitud de clave admitidos por el ENS para un uso concreto. La guía clasifica los mecanismos en "Recomendados" (R) y "Legacy" (L).
Producto cualificado/certificado
Producto criptográfico evaluado (Common Criteria / CCN) exigible en ciertos casos. El catálogo CPSTIC (CCN-STIC 105) recoge los productos certificados.
Gestión de claves
Generación, distribución, custodia, rotación y destrucción de claves a lo largo de su vida. Los medios de generación deben estar aislados de los medios de explotación.
Prestador de Servicios de Confianza
Entidad que presta servicios de firma, sello, certificados u otros conforme a la normativa eIDAS. El Anexo 1 extiende la autorización de RSA para estos prestadores.
Aplica en cuanto manejas confidencialidad o autenticidad relevantes, y se vuelve crítica en categorías MEDIA y ALTA, donde se exige cifrado conforme y, en ciertos casos, productos cualificados. Cualquier sistema con datos sensibles entra en su ámbito. La guía es aplicable a todas las entidades del ámbito del ENS, incluyendo prestadores de servicios de confianza.
Implantación
Cómo lo implanta una empresa, paso a paso
Inventaría tus usos de criptografíaLocaliza dónde ciframos (en tránsito, en reposo), dónde firmamos y dónde hay funciones resumen. No puedes proteger lo que no has mapeado.
Sustituye lo no conformeReemplaza algoritmos y longitudes desaconsejados por los admitidos en la 807. Esto incluye configuraciones TLS heredadas (SSL, TLS 1.0, TLS 1.1).
Usa productos cualificados donde se exijaEn MEDIA/ALTA, prioriza productos certificados/cualificados (catálogo CPSTIC) allí donde la guía lo requiera (ej. cifrado de disco, VPN, firma electrónica).
Gestiona las claves con ciclo de vidaDocumenta generación, custodia, rotación y destrucción. La gestión de claves improvisada es un riesgo y un hallazgo. Usa KDF autorizadas (PBKDF2, scrypt) para derivar claves.
Revisa periódicamente la conformidadLos criterios criptográficos evolucionan; revisa que tus algoritmos siguen siendo admitidos. Ejemplo: RSA 2048 es Legacy desde 2025; RSA 3072+ es Recomendado.
Auditoría
Para qué sirve en una auditoría
El auditor revisa algoritmos, longitudes y gestión de claves.
Comprueba el uso de productos certificados donde la categoría lo exige (CPSTIC).
Verifica la configuración real de TLS (versiones 1.2 o 1.3, cipher suites autorizadas) y del cifrado en reposo.
Cifrado «casero» o algoritmos obsoletos son hallazgo directo (ej. RC4, MD5, SHA-1, RSA 1024).
La ausencia de gestión de claves documentada se señala.
Verifica que las suites TLS usadas están en la lista autorizada y no usan "NULL" o "anon".
Serie 800
Relación con otras guías de la serie
CCN-STIC 804804 — La criptografía es una de las medidas de protección a implantar (mp.com, mp.si, mp.info).
CCN-STIC 823823 — En cloud, el cifrado y la gestión de claves requieren atención específica.
CCN-STIC 808808 — La verificación comprueba que la criptografía empleada es conforme.
CCN-STIC 105 — Catálogo CPSTIC de productos certificados.
Mapeo
Equivalencia con otros marcos
Cómo se conecta esta guía con los marcos que probablemente ya manejas:
Aspecto en el ENS
ISO 27001
NIS2 / DORA
Criptografía conforme
ISO 27001: A.8.24 (uso de criptografía)
DORA: protección de datos en tránsito y reposo
Productos certificados
Common Criteria / productos cualificados CCN
NIS2: seguridad de la cadena de suministro TIC
Gestión de claves
ISO 27001: gestión de claves (A.8.24)
DORA: gestión de activos criptográficos
TLS/SSL configuración
ISO 27001: A.8.24 (criptografía)
DORA: comunicaciones seguras
Firma electrónica
ISO 27001: A.5.13 (identificación)
eIDAS: servicios de confianza
Sin humo
Errores típicos
Usar algoritmos o longitudes ya desaconsejados (ej. SHA-1, MD5, RC4, RSA 1024, SSL).
Gestión de claves improvisada, sin ciclo de vida documentado.
Asumir que «TLS por defecto» basta sin verificar la conformidad de la cipher suite.
No emplear productos cualificados donde la categoría los exige (CPSTIC).
Usar funciones hash débiles en firmas o resúmenes.
No considerar la transición de RSA Legacy (2048 bits) a Recomendado (3072+ bits).
Checklist
Checklist práctico
Inventario de usos criptográficos completo.
Algoritmos y longitudes conformes a la 807 (Recomendados vs Legacy).
Configuraciones TLS y cifrado en reposo revisadas (TLS 1.2/1.3).
Productos certificados donde la categoría lo exige (CPSTIC).
Gestión de claves documentada (ciclo de vida completo).
Funciones hash autorizadas (SHA-2, SHA-3, no SHA-1).
Firma electrónica conforme al nivel (BÁSICA/MEDIA/ALTA).
Ficha
Ficha y enlace oficial
Esta es una lectura práctica de GRCreal, no la guía oficial. Consulta siempre la versión vigente en el portal del CCN-CERT, ya que estas guías se actualizan periódicamente (esta ficha: publicada Jul 2011, actualizada May 2022).
Nota: Los mecanismos Legacy (L) tienen fecha límite (31/12/2025 para la mayoría) y deben ser reemplazados por Recomendados.
Protocolos
Protocolos criptográficos autorizados
La guía especifica qué versiones y configuraciones de protocolos criptográficos son aceptables:
TLS: Solo TLS 1.2 y TLS 1.3. Prohibidas TLS 1.1, 1.0 y SSL. Cipher suites autorizadas: ECDHE con AES-GCM/CCM/ChaCha20. No se autorizan suites con NULL, anon, PSK, RC4, IDEA o MD5.
SSH: Solo SSHv2. Key exchange: diffie-hellman-group14-sha256, ecdh-sha2-nistp256 (R). Cifrado: AES-CTR y AEAD. MAC: HMAC-SHA2.
IPsec: IKEv2 (R), IKEv1 solo Legacy con Main/Quick mode. ESP con confidencialidad + integridad. Grupos DH: 2048/3072/4096 bits o curvas elípticas. Autenticación: certificados X.509 con ECDSA o RSA (3072+ bits).
PSC
Anexo 1: Prestadores de Servicios de Confianza
El Anexo 1 de la guía, actualizado en octubre de 2025, aborda específicamente a los Prestadores de Servicios de Confianza (PSC):
Autorización RSA extendida: Se autoriza el uso de RSA para servicios de firma y autenticación con módulos entre 1900 y 3000 bits hasta el 31 de diciembre de 2026.
Validez de certificados: Los certificados emitidos con RSA entre 1900 y 3000 bits tienen validez máxima hasta el 31 de diciembre de 2028.
Transición: A partir del 1 de enero de 2027, los certificados basados en RSA deberán emitirse con módulos de al menos 3000 bits.
Esquema de firma: Se recomienda RSA-PSS, aunque RSA-PKCS#1v1.5 se acepta hasta el 31 de diciembre de 2030.
Recomendación: Se insta a implementar mecanismos más robustos (RSA de mayor longitud y algoritmos postcuánticos) a la mayor brevedad posible.
Ficha y enlace oficial
Contrasta esta lectura con la publicación del CCN-CERT
La guía oficial sigue mandando. Aquí queda la ficha documental y el acceso directo a la fuente para cerrar la lectura con el contraste adecuado.
ℹ️ Resumen práctico de GRCreal. Consulta siempre la versión oficial vigente en el portal del CCN-CERT.
Resumen realizado a fecha 29/06/2026 con la información disponible en https://www.ccn-cert.cni.es/es/guias.html. Las fechas de publicación y actualización proceden del portal oficial.