Proteja la confidencialidad e integridad de la información sensible con GO-ITS 25.12

El programa de Normas de Tecnología de la Información del Gobierno de Ontario (GO-ITS) establece las directrices, normas y prácticas que deben seguir los ministerios del Servicio Público de Ontario y sus proveedores. La norma GO-ITS 25.12, Requisitos de seguridad para el uso de criptografía , indica a cada ministerio, organismo y tercero que trabaje con datos del gobierno de Ontario qué algoritmos criptográficos , longitudes de clave y protocolos están aprobados para proteger la confidencialidad e integridad de la información sensible.

En la norma, los requisitos expresados ​​con «debe» son obligatorios, y los expresados ​​con «debería» son recomendaciones. GO-ITS 25.12 se aplica a los ministerios del gobierno de Ontario, las antiguas agencias de los Anexos I y IV, los proveedores de servicios en la nube y cualquier proveedor o tercero contratado por el Gobierno de Ontario que cree, almacene, transmita o procese información del Servicio Público de Ontario.

Publicado: marzo de 2022. Actualizado: agosto de 2026. Revisado por el equipo de Asesoría en Cumplimiento Normativo de Encryption Consulting.

¿Qué requisitos tiene GO-ITS 25.12?

La norma GO-ITS 25.12 exige que la información confidencial del gobierno de Ontario se proteja mediante algoritmos criptográficos aprobados en cada etapa: creación, almacenamiento, distribución, uso, revocación, destrucción y recuperación de las claves involucradas. Los requisitos se organizan en áreas diferenciadas, y cada una se corresponde con un control operativo real, en lugar de un principio vago.

• Educación y entrenamiento. El personal técnico que desarrolla, implementa o gestiona sistemas que utilizan criptografía debe comprender los requisitos del estándar antes de trabajar con sistemas de producción.
• Información almacenada. Los datos confidenciales deben cifrarse en reposo, y los datos almacenados durante más de dos años deben utilizar un cifrado adecuado para entornos de alto riesgo. Los dispositivos móviles deben utilizar cifrado de disco completo, y los campos confidenciales deben cifrarse a nivel de columna o celda antes de que lleguen al repositorio de datos.
• Seguridad en las comunicaciones. La información confidencial debe cifrarse durante su transmisión y su integridad debe verificarse mediante un código de autenticación de mensajes aprobado o una firma digital que contenga una marca de tiempo precisa y fiable.
• Despliegue de criptografía. Las aplicaciones deben utilizar un generador de números aleatorios o pseudoaleatorios aprobado, validar los certificados antes de confiar en ellos, eliminar los datos descifrados de la caché o la memoria temporal inmediatamente después de su uso y superar las pruebas y evaluaciones de seguridad (STE) antes de su lanzamiento.
• Protección de material criptográfico. El acceso a las claves está restringido a usuarios y servicios autorizados, la protección de las claves se ajusta a la sensibilidad de los datos y la generación de claves debe realizarse en un módulo de software aprobado o en un módulo de seguridad de hardware (HSM), en las instalaciones donde la información sea altamente sensible.

¿Quiénes deben cumplir con GO-ITS 25.12?

La norma GO-ITS 25.12 tiene un alcance mayor que el de los ministerios que emiten los cheques. Cualquier persona que maneje datos del Servicio Público de Ontario mediante un contrato hereda las obligaciones de dicha norma.

• Ministerios del gobierno de Ontario y antiguas agencias incluidas en los Anexos I y IV.
• Proveedores de servicios externos e integradores de sistemas que trabajan bajo contrato con el Gobierno de Ontario.
• Proveedores de servicios en la nube que alojan cargas de trabajo o datos del Servicio Público de Ontario.
• Cualquier organización que cree, almacene, transmita o procese información del gobierno de Ontario, independientemente del lugar físico donde se realice dicho procesamiento.

En la práctica, esto significa que un proveedor que se presente a una licitación para un contrato con el gobierno de Ontario debe demostrar su conformidad con la norma GO-ITS 25.12 durante el proceso de contratación, no implementarla posteriormente tras la firma del contrato. Los Servicios de Asesoramiento en Cumplimiento de Encryption Consulting existen precisamente para cubrir esta necesidad: comparar la postura criptográfica actual de un proveedor con el Apéndice A de la norma antes de que se presente la oferta.

¿Cómo seleccionar los algoritmos y las longitudes de clave adecuados?

La criptografía protege la confidencialidad e integridad de la información sensible mediante tres familias de algoritmos: cifrado simétrico para la confidencialidad masiva, cifrado asimétrico para firmas digitales e intercambio de claves, y funciones hash para la verificación de integridad. El Apéndice A de GO-ITS 25.12 establece una longitud mínima de clave para uso estándar y una mayor para entornos de alto riesgo, y cada opción se corresponde con un estándar NIST subyacente, ya que GO-ITS no define sus propias primitivas criptográficas.

Categoría de algoritmo	Algoritmo aprobado	Longitud mínima de clave	Entorno de alto riesgo	Estándar NIST subyacente	Estado
Encriptación simétrica	AES	128 bits	256 bits	FIP 197	Aprobado
Cifrado simétrico (heredado)	3DES (triple DES)	168 bits nominales, 112 bits efectivos	No recomendado	SP 800-131A Rev. 2	Obsoleto, se eliminará gradualmente para 2030 según GO-ITS; NIST ya prohíbe su nuevo uso.
Cifrado simétrico (flujo)	ChaCha20-Poly1305	256 bits	256 bits	RFC 8439	Aprobado
Cifrado y firmas asimétricas	RSA	2048 bits	3072 bits	FIPS 186-5	Aprobado
Firmas asimétricas (curva elíptica)	ECDSA	P-256	P-384	FIPS 186-5	Aprobado
Firmas asimétricas (curva de Edwards)	EdDSA	Equivalente a Ed25519	Equivalente a Ed448	FIPS 186-5	Aprobado
Funciones hash	Familia SHA2-256, familia SHA3-256	Salida de 256 bits	Salida de 256 bits o superior	FIPS 180-4, FIPS 202	Aprobado
Funciones hash (heredado)	MD5, SHA-1	N/A	N/A	SP 800-131A Rev. 2	Prohibido para firmas digitales; solo verificación heredada SHA-1.
Autenticación de mensajes	HMAC (SHA2-256+), CMAC, GMAC, Poly1305	Coincide con el algoritmo subyacente	Coincide con el algoritmo subyacente	SP 800-38B, SP 800-38D, RFC 8439	Aprobado

Tabla: Algoritmos aprobados por GO-ITS 25.12, asociados a sus estándares NIST correspondientes.

El umbral de seguridad de 112 bits en NIST SP 800-131A Rev. 2 es la base de los mínimos RSA-2048 y ECC P-256 de GO-ITS 25.12: RSA necesita un módulo de 2048 bits y los esquemas de curva elíptica necesitan aproximadamente un orden de grupo de 224 bits o más para alcanzar ese mismo nivel mínimo de seguridad de 112 bits. Para un análisis más detallado de cómo FIPS 140-3 clasifica estos mismos algoritmos según su estado de aprobación, consulte nuestra publicación sobre la transición a FIPS 140-3.

¿Contra qué amenazas protege GO-ITS 25.12?

Cada requisito de GO-ITS 25.12 se remonta a una forma específica en que se exponen datos gubernamentales confidenciales. Comprender el modelo de amenazas hace que los requisitos parezcan menos arbitrarios y facilita su priorización cuando los recursos son limitados.

• Intercepción en tránsito. El tráfico de red no cifrado o débilmente cifrado puede ser interceptado y leído por un atacante ubicado en la ruta de la red, razón por la cual el estándar exige el cifrado para todas las comunicaciones y prohíbe SSL y las primeras versiones de TLS que son vulnerables a ataques de degradación de protocolo.
• Exposición de datos en reposo. Un ordenador portátil robado, una base de datos mal configurada o una brecha en la seguridad de un depósito de almacenamiento exponen directamente datos confidenciales sin cifrar, lo que justifica los requisitos de cifrado de disco completo y de cifrado a nivel de columna.
• Criptoanálisis de primitivas débiles o heredadas. Tanto MD5 como SHA-1 presentan ataques de colisión prácticos, y 3DES es vulnerable a ataques de encuentro en el medio y ataques basados ​​en fechas de nacimiento con grandes volúmenes de datos, razón por la cual el estándar los desaconseja en favor de SHA2/SHA3 y AES.
• Compromisos clave y abuso por parte de personas internas. Una clave mal protegida socava todos los controles construidos sobre ella, razón por la cual GO-ITS 25.12 restringe el acceso a las claves a usuarios y servicios autorizados y exige procedimientos documentados de generación, distribución, rotación y destrucción.
• Fallos de implementación. Reutilizar un vector de inicialización en AES-GCM, o usar el modo de libro de códigos electrónico (ECB), filtra información estructural sobre el texto plano incluso cuando el algoritmo subyacente es correcto. GO-ITS 25.12 prohíbe explícitamente el modo ECB por este motivo.
• Cosecha ahora, descifra después. Los adversarios pueden capturar el tráfico cifrado hoy y descifrarlo una vez que exista una computadora cuántica criptográficamente relevante. GO-ITS 25.12 aún no exige algoritmos post-cuánticos, pero su propio texto destaca la agilidad criptográfica como una defensa contra las amenazas emergentes, que es la misma postura que recomienda el NIST en su guía de migración post-cuántica. Consulte nuestra guía para Plazos de migración de la criptografía postcuántica para saber cómo otras jurisdicciones están gestionando esta misma transición.

¿Cómo se logra el cumplimiento de la norma GO-ITS 25.12?

El cumplimiento de GO-ITS 25.12 es un proceso secuencial, no una simple casilla de verificación. Las organizaciones que lo consideran una auditoría única tienden a incumplir la normativa la próxima vez que se descontinúa un algoritmo o se implementa un nuevo sistema.

1. Inventariar activos criptográficos. Identifique cada algoritmo, clave, certificado y protocolo en uso, y clasifique la sensibilidad de los datos que protege cada uno. Sin este inventario, ninguno de los pasos siguientes tiene un punto de partida fiable.
2. Compare el estado actual con el Apéndice A. Compare cada algoritmo y longitud de clave del inventario con la tabla de algoritmos aprobados de GO-ITS 25.12, señalando cualquier elemento prohibido, obsoleto o cuya longitud de clave sea inferior a la requerida para su nivel de riesgo.
3. Retire los sistemas primitivos prohibidos y obsoletos. Elimine DES, el modo ECB, MD5 para firmas, SHA-1 para firmas y SSL o TLS antiguo dondequiera que todavía aparezcan, dando prioridad a los sistemas conectados a Internet.
4. Seleccione los algoritmos aprobados y la longitud de las claves según el nivel de riesgo. Los datos de riesgo estándar obtienen las longitudes mínimas de clave del estándar; los datos de alto riesgo (o cualquier dato conservado durante más de dos años) obtienen los mínimos de alto riesgo de la tabla anterior.
5. Implementar la generación y el almacenamiento de claves respaldados por HSM. Cumpla con el nivel 2 de FIPS 140-2 o FIPS 140-3 / ISO/IEC 19790:2012 como mínimo, y con el nivel 3 para información de alto riesgo o implementaciones fuera de las instalaciones, manteniendo la generación de claves de alta sensibilidad en las instalaciones siempre que la norma lo recomiende.
6. Elabore procedimientos documentados para la gestión de llaves. Proteja la generación, asignación, distribución, rotación, revocación y destrucción, y mantenga las claves de prueba y las claves de producción en entornos estrictamente separados.
7. Pruebas y evaluación de seguridad completas (STE). Cualquier aplicación que procese o acceda a datos confidenciales necesita pruebas de integridad de señal (STE) antes de llegar a producción, no después.
8. Establecer programas continuos de capacitación, auditoría y seguimiento. El personal técnico debe estar siempre al tanto de los requisitos, y los HSM y los sistemas de gestión clave necesitan una supervisión continua, no una revisión anual.

¿Cuáles son las ventajas y desventajas en términos de rendimiento e interoperabilidad?

GO-ITS 25.12 aprueba más de un algoritmo para la mayoría de las categorías precisamente porque ninguna opción es la mejor en todos los aspectos. Elegir el algoritmo adecuado para un sistema determinado implica sopesar el rendimiento frente a la interoperabilidad y el hardware realmente implementado.

Libertad de decidir	Desempeño relativo	Interoperabilidad	Mejor ajuste
AES-256-GCM frente a AES-128-GCM	AES-256 ejecuta más rondas y es ligeramente más lento, aunque la diferencia es insignificante en hardware con aceleración AES-NI.	Universal en pilas TLS y HSM modernos.	AES-256 para datos de alto riesgo y larga retención; AES-128 aceptable en otros casos.
RSA-2048 frente a ECDSA P-256	RSA firma más lentamente y verifica más rápido; ECDSA firma más rápido con un tamaño de clave y firma mucho menor.	RSA tiene el soporte más amplio para clientes heredados; ECDSA necesita una pila TLS razonablemente moderna.	ECDSA para nuevas implementaciones y clientes con recursos limitados; RSA cuando la interoperabilidad con sistemas heredados es un requisito indispensable.
TLS 1.3 frente a TLS 1.2	TLS 1.3 completa su protocolo de enlace en un solo viaje de ida y vuelta (o cero, con reanudación), lo que reduce la latencia.	TLS 1.2 aún cuenta con un soporte más amplio entre clientes y dispositivos intermedios más antiguos.	TLS 1.3 como predeterminado; mantener TLS 1.2 disponible solo donde los clientes heredados lo requieran.
HSM local frente a HSM externo/en la nube	La instalación local evita los viajes de ida y vuelta de la red a un HSM remoto, aunque con un coste inicial más elevado.	Cloud HSM escala más rápido, pero debe cumplir con FIPS 140-2/140-3 Nivel 3 para uso fuera de las instalaciones de alta sensibilidad según GO-ITS 25.12.	En las instalaciones para la generación de claves más sensibles; HSM en la nube para escalabilidad una vez confirmada la validación de nivel 3.
ChaCha20-Poly1305 frente a AES-GCM	ChaCha20 es más rápido en dispositivos sin aceleración de hardware AES-NI; AES-GCM es más rápido donde existe dicha aceleración.	Ambas son opciones de conjuntos de cifrado estándar en TLS 1.2 y 1.3.	Adapta el algoritmo de cifrado al perfil de hardware del dispositivo: ChaCha20 para dispositivos móviles e IoT, AES-GCM para hardware de servidor estándar.

Tabla: Ventajas y desventajas en cuanto a rendimiento e interoperabilidad entre las opciones aprobadas por GO-ITS 25.12.

¿Qué dependencias de gestión clave crea GO-ITS 25.12?

La gestión de claves es donde la mayoría de los programas GO-ITS 25.12 realmente tienen éxito o fracasan, porque la selección del algoritmo es una decisión que se toma una sola vez, mientras que la gestión de claves es una disciplina operativa continua.

• El gobierno es propietario de las llaves. El Gobierno de Ontario conserva la propiedad de las claves criptográficas que protegen su información, lo que limita la forma en que cualquier servicio gestionado o proveedor de servicios en la nube puede diseñar la custodia de las claves.
• dependencia de HSM. La generación y el almacenamiento de claves de alta sensibilidad requieren un HSM que cumpla con el nivel FIPS 140-2/140-3 adecuado al nivel de riesgo de los datos, lo que significa que la adquisición y la gestión del ciclo de vida del HSM se convierten en una dependencia de cumplimiento, y no solo en una decisión de infraestructura.
• obligaciones de recuperación. Las claves de descifrado deben seguir siendo recuperables después de su vencimiento para que las copias de seguridad archivadas sigan siendo legibles, lo que requiere un mecanismo documentado de custodia o recuperación de claves, no solo una política de rotación.
• Separación entre pruebas y producción. Las claves creadas para pruebas nunca deben aparecer en producción, y las claves de producción nunca deben aparecer en entornos de prueba, lo que tiene implicaciones reales en la forma en que se aprovisionan las canalizaciones de CI/CD y los entornos de preproducción.
• Gestión de la transferencia de propiedad. Cuando la custodia de los datos pasa a otra organización, esos datos deben volver a cifrarse con una nueva clave, en lugar de que la clave antigua simplemente cambie de manos, lo que afecta a cualquier proyecto de migración o desvinculación de empleados.
• La visibilidad es un requisito previo. Nada de lo anterior es posible sin saber primero qué claves, certificados y algoritmos existen en el entorno, razón por la cual una herramienta de inventario criptográfico como CBOM seguro Suele ser el primer paso práctico en un programa GO-ITS 25.12, en lugar de una ocurrencia tardía.

¿Cómo es una implementación compatible con GO-ITS 25.12?

Los requisitos anteriores se traducen en decisiones arquitectónicas concretas. Algunos ejemplos representativos:

• Aplicación web de acceso público. La conexión TLS 1.3 finalizaba en el balanceador de carga mediante un certificado ECDSA P-256, cuya clave privada se generaba y almacenaba en un HSM en lugar de en el disco del servidor de aplicaciones, y los conjuntos de cifrado se limitaban a los algoritmos de la tabla GO-ITS 25.12.
• Campos confidenciales de la base de datos. Cifrado a nivel de columna mediante AES-256-GCM para campos que contienen información personal o de salud, con las claves de cifrado de datos protegidas por una clave maestra protegida por HSM en lugar de almacenarse junto con los datos.
• Transferencia de archivos entre ministerios. Se requiere SSH 2.0 o posterior para el transporte, AES-GCM o ChaCha20-Poly1305 para la confidencialidad de la carga útil y una firma digital o HMAC-SHA2-256 para la verificación de la integridad con una marca de tiempo confiable.
• Firma de códigos y firma de documentos. Firmas RSA-3072 o ECDSA P-384 respaldadas por una clave de firma protegida por un HSM, con una marca de tiempo de una fuente de referencia válida y confiable para que la firma siga siendo verificable después de que expire el certificado.

Limitaciones

• GO-ITS 25.12 aún no exige los algoritmos post-cuánticos del NIST (ML-KEM, ML-DSA, SLH-DSA); menciona la agilidad criptográfica como un objetivo sin requerir un cronograma específico para la migración a PQC.
• El estándar nombra los algoritmos aprobados y las longitudes de clave, pero no especifica las cadenas exactas del conjunto de cifrado TLS, lo que deja margen para una implementación inconsistente entre ministerios y proveedores.
• Muchos requisitos utilizan el pronombre "debería" en lugar de "debe", lo que los convierte en recomendaciones en vez de obligaciones vinculantes, y la aplicación del lenguaje que utiliza el pronombre "debería" varía según el ministerio.
• El estándar es anterior en detalle a las arquitecturas nativas de la nube y de clave efímera de uso generalizado, y remite los controles específicos de la nube al estándar de servicios en la nube GO-ITS 25.21 relacionado, en lugar de cubrirlos directamente.
• GO-ITS 25.12 no exige por sí mismo un conjunto específico de herramientas o un inventario de criptoagilidad, aunque menciona la criptoagilidad como una defensa contra las amenazas emergentes.

¿Qué recomendaría Encryption Consulting?

La mayoría de las organizaciones con las que trabajamos en GO-ITS 25.12 no fallan en la selección de algoritmos. La tabla del Apéndice A es fácil de leer. El problema radica en la capa operativa subyacente: nadie tiene un inventario actualizado de los algoritmos y claves existentes, la adquisición de HSM lleva meses y los procedimientos de gestión de claves se basan en la experiencia personal de alguien, en lugar de estar plasmados en un documento que un auditor pueda revisar.

Nuestra recomendación es abordar el problema en este orden. Comience con una evaluación de brechas a través de los Servicios de Asesoría de Cumplimiento que mapea los algoritmos, longitudes de clave y protocolos actuales directamente con la tabla del Apéndice A de GO-ITS 25.12, generando una hoja de ruta de remediación priorizada en lugar de un informe de auditoría genérico. Cuando la brecha es el nivel de validación de HSM, HSM-as-a-Service permite a una organización alcanzar la protección de claves validada de nivel 2 o nivel 3 de FIPS 140-2/140-3 sin un ciclo de adquisición de hardware de varios meses, lo cual es importante cuando se fija una fecha límite para la licitación. Cuando la brecha es la emisión, revocación o alineación de CP/CPS de certificados, nuestro equipo de Servicios PKI desarrolla la política y el marco técnico que mantiene las prácticas de certificados auditables según el estándar en lugar de improvisadas para cada proyecto.

También nos opondríamos, con cautela, a considerar 2030 como una fecha límite cómoda para la retirada de 3DES. La propia guía de transición del NIST ya prohíbe el uso de nuevo cifrado 3DES, y especificar AES desde el primer día en cualquier nuevo sistema del gobierno de Ontario no supone ningún coste adicional y elimina por completo un posible problema de corrección futura.

Conclusión

GO-ITS 25.12 existe para proteger la confidencialidad e integridad de la información sensible en todo el Servicio Público de Ontario, y lo hace dirigiendo a cada ministerio y proveedor a la misma tabla de algoritmos aprobados, longitudes de clave y niveles de validación de HSM, en lugar de dejar las decisiones criptográficas a los equipos de proyecto individuales. Los requisitos técnicos no son la parte difícil. La creación del inventario, la disciplina de gestión de claves y la infraestructura HSM que garanticen el cumplimiento continuo de dichos requisitos es donde las organizaciones realmente necesitan ayuda, y es donde un programa de cumplimiento estructurado se amortiza mucho antes de que se realice una auditoría.

Preguntas frecuentes

¿Qué es GO-ITS 25.12? GO-ITS 25.12 es la norma de TI del Gobierno de Ontario titulada Requisitos de seguridad para el uso de criptografía. Establece los algoritmos criptográficos aprobados, las longitudes mínimas de clave y los protocolos que los ministerios, agencias y proveedores del Servicio Público de Ontario deben utilizar para proteger la información gubernamental confidencial, tanto almacenada como en tránsito.

¿Quiénes deben cumplir con GO-ITS 25.12? La norma se aplica a los ministerios del gobierno de Ontario, las antiguas agencias de los Anexos I y IV, los proveedores de servicios en la nube y cualquier tercero o proveedor contratado por el Gobierno de Ontario que cree, almacene, transmita o procese información del Servicio Público de Ontario.

¿Qué nivel de validación de HSM exige GO-ITS 25.12? Los módulos de seguridad de hardware que protegen las claves del gobierno de Ontario deben validarse al menos según FIPS 140-2 o FIPS 140-3 / ISO/IEC 19790:2012 Nivel 2. Los HSM que almacenan información altamente sensible fuera de las instalaciones deben cumplir con el Nivel 3.

¿GO-ITS 25.12 requiere TLS 1.3? GO-ITS 25.12 requiere compatibilidad con TLS y específicamente con TLS 1.2 y 1.3, prohibiendo SSL y las versiones antiguas y vulnerables de TLS. Los conjuntos de cifrado deben seleccionarse de la tabla de algoritmos y longitudes de clave aprobada por el estándar.

¿Sigue estando permitido 3DES según GO-ITS 25.12? La tabla de algoritmos de GO-ITS 25.12 aún incluye 3DES, y las directrices del Gobierno de Ontario prevén su descontinuación para 2030. Las propias directrices de transición del NIST ya prohíben el cifrado 3DES para nuevos usos, por lo que Encryption Consulting recomienda especificar AES en lugar de 3DES para cualquier nueva implementación del gobierno de Ontario.

Referencias

• Gobierno de Ontario: GO-ITS 25.12, Requisitos de seguridad para el uso de criptografía
• Gobierno de Ontario: Programa de Normas de Tecnologías de la Información
• NIST FIPS 140-3, Requisitos de seguridad para módulos criptográficos
• NIST FIPS 197, Estándar de Cifrado Avanzado (AES)
• NIST FIPS 186-5, Estándar de Firma Digital (DSS)
• NIST SP 800-131A Rev. 2, Transición en el uso de algoritmos criptográficos y longitudes de clave
• NIST CSRC: Esfuerzo de transición a FIPS 140-3