Llegamos a ustedes gracias a:



Reportajes y análisis

Trasladarse de SHA-1 a SHA-2

Todo lo que necesita saber

[21/07/2017] Durante los últimos dos años, me he dedicado a ayudar a los clientes de Public Key Infraestructure (PKI) a prepararse para y se mueven a SHA-2, el conjunto de funciones hash criptográficas que han superado a SHA-1. El año pasado, pasar a SHA-2 antes de la fecha límite global fue un agradable paso preparatorio. Este año, ahora que el plazo de migración ha concluido, es un requisito. 

Muchos dispositivos y aplicaciones que consumen certificados digitales ya muestran advertencias/errores o fallan operacionalmente, si se presenta un certificado digital que contiene el hash SHA-1 (o anterior) y, muy pronto, todos ellos lo harán. ¿Por qué el cambio forzado? Debido a que el hash SHA-1 ha demostrado sufrir graves deficiencias criptográficas tales que sus días de protección útil han terminado. 

Hasta el año 2017, el SHA-1 era el hash más común utilizado para la firma criptográfica, y algunos, usualmente más antiguos, las aplicaciones y dispositivos aún no aceptan o entienden los hashes o certificados relacionados con SHA-2. Ahí está el problema. 

¿Qué es un hash?

Una buena función criptográfica hash es un algoritmo matemático que, cuando se ejecuta contra cualquier contenido (por ejemplo, documento, sonido, video, imagen, etc.) siempre devolverá un resultado de salida único (a menudo llamado resultado de hash o hash) para un contenido de entrada único. No hay dos entradas diferentes que devuelvan siempre la misma salida hash, y entradas idénticas siempre deben dar como resultado la misma salida. Usando estas propiedades criptográficas, se puede usar una salida de hash en dos entradas presentadas de forma diferente para ver si son idénticas o no. Los hashes criptográficos son la columna vertebral de casi todos los procesos de autenticación e integridad digital. 

Los servicios de autoridad de certificación (CA) de PKI utilizan hashes criptográficos para confirmar identidades y solicitudes de certificados digitales, y para permitir la confirmación (es decir, la firma) de certificados digitales y listas de revocación de certificados (CRLs) emitidos por otras partes que confían (por ejemplo, computadoras, software, usuarios, etc.). Si el hash criptográfico utilizado por los servicios de PKI no otorga la confianza de ser fuerte (es decir, "inquebrantable"), las partes que confían no pueden confiar en la validez de los certificados digitales y otros contenidos firmados por la CA. Es la fuerza del hash criptográfico la que crea la confianza en todo el sistema PKI. 

Nota: Los "checksums" o sumas de comprobación son verificadores de tipo hash, pero sin ninguna prueba criptográfica detrás de ellos para probar que proporcionan salidas razonablemente únicas para entradas únicas. En general, los hashes criptográficos se consideran más seguros que las sumas de comprobación, aunque las sumas de comprobación se utilizan a menudo para verificaciones de integridad y autenticación no críticas. 

Ataques de hash

La fuerza de un hash criptográfico reside en su capacidad inherente para asegurar que todo el contenido único enviado, siempre da como resultado la misma salida única. Al mismo tiempo, cualquier persona que obtenga solo la salida de resultado de hash de contenido no debería ser capaz de crear el contenido original enviado para crear el resultado de hash simplemente a partir del resultado de hash solo. Si alguien puede hacerlo, se llama ataque "preimagen". Y nunca dos entradas diferentes pueden dar misma salida idéntica de hash. Si lo hacen, se considera una "colisión". 

Los estándares de hash criptográficos generalmente aceptados se consideraron fuertes en su inicio; pero con el tiempo, los atacantes criptográficos desarrollaron maneras inteligentes de usar matemáticas para debilitar la fuerza protectora de la longitud de bit del hash elegido. Todos los hashes tienen una longitud de bit indicada, que es el número de 1s y 0s (dígitos binarios) que se representan en la salida de hash. 

Se considera que un hash criptográfico fuerte es tan fuerte como su longitud de bit efectiva indicada menos 1 bit. Por lo tanto, se considera que un hash de 128 bits fuerte tiene 127-bits (2 ^ 127) de protección efectiva cuando no se conocen defectos. Cada vez que alguien puede presentar matemáticas probables que el hash se puede romper en menos de su longitud de bits efectiva menos uno, el hash se considera debilitado. 

En general, o al menos hasta ahora, todos los hashes generalmente aceptados se han debilitado con el tiempo, ya que los ataques criptográficos mejoran la capacidad de acortar la longitud de bits efectiva del hash. A medida que se acorta la longitud del bit efectivo, el hash se vuelve menos protector y menos valioso. En el momento en que se cree que alguien puede "crackear" un hash dentro de un período razonable de tiempo y recursos (a menudo aún se mide entre cientos de miles a millones de dólares), el hash se considera "roto" y ya no debe ser usado. Los hashes rotos han sido utilizados por el malware y los atacantes, para poseer como legítimo software firmado digitalmente. Un buen ejemplo de esto es el programa de malware Flame. En resumen, los hashes débiles importan y no deben ser usados. 

Introducción a SHA

SHA-1 fue diseñado por la Agencia Nacional de Seguridad de los Estados Unidos (NSA, por sus siglas en inglés) y publicado como un estándar federal en 1995 por el Instituto Nacional de Estándares y Tecnología de los Estados Unidos (NIST). Los estándares criptográficos publicados por NIST suelen ser de confianza para gran parte del mundo, y se requieren a menudo en todas las computadoras que hacen negocios críticos con el gobierno o el ejército de los Estados Unidos. El SHA-1 reemplazó hashes criptográficos previamente debilitados, como el MD-5. 

Con el tiempo, varios ataques criptográficos continuos contra el SHA-1 comenzaron a acortar su longitud de clave efectiva. Debido al éxito continuo contra el SHA-1, la NSA y el NIST identificaron a su sucesor relacionado, SHA-2, como el nuevo estándar de hashing recomendado en el 2002. Esto fue bastante antes de que el SHA-1 fuera considerado como roto. En febrero del 2017, un ataque exitoso de colisión reveló que esencialmente hizo que SHA-1 ya no sea útil para la protección de firma criptográfica. 

Una gran discusión acerca de la ruptura de SHA-1 y documentos de ejemplo se puede encontrar aquí 

Familia SHA-2

SHA-2 es el estándar de cifrado criptográfico que todo software y hardware debe utilizar ahora, al menos durante los próximos años. El SHA-2 a menudo se le conoce como la familia SHA-2 de hashes porque contiene muchos hashes de diferentes tamaños, incluyendo 224, 256, 384 y 512 bits. 

Cuando alguien dice que está usando el hash SHA-2, no se sabe qué longitud de bits está empleando, pero el más popular es el de 256 bits (por un gran margen). Aunque SHA-2 comparte algunas de las mismas características matemáticas que SHA-1, y se han descubierto pequeñas debilidades, en la criptografía, todavía se considera "fuerte" en el futuro previsible. Sin duda, es mucho mejor que SHA-1, y cualquier certificado crítico, aplicación y dispositivo de hardware que utilice SHA-1 debe moverse a SHA-2. 

Manejo de la depreciación SHA-1

Todos los principales proveedores de navegadores web (por ejemplo, Microsoft, Google, Mozilla, Apple) y otros terceros de confianza, han solicitado (y lo han estado haciendo durante años) que todos los clientes, servicios y productos que utilizan actualmente SHA-1 se muevan a SHA-2, aunque lo que tiene que ser movido varía dependiendo del fabricante. Por ejemplo, la mayoría de fabricantes solo se preocupan por los certificados TLS (es decir, el servidor web), y uno, Microsoft Corporation, solo se preocupa actualmente si SHA-1 se utiliza en un certificado digital de una CA "pública".  

Pero esperamos que todos los proveedores soliciten pasar a SHA-2 todas las aplicaciones y dispositivos para todas las funciones de hash criptográficas, si aún no lo han hecho. Hoy en día la mayoría de los navegadores mostrará un mensaje de error si se encuentra un certificado SHA-1 digital en un sitio web, pero algunos le permitirán evitar el error y entrar en el sitio web protegido por SHA-1 si lo desea. Próximamente, todos los principales proveedores de navegadores probablemente evitarán que sus navegadores vayan a sitios web protegidos por SHA-1 y eviten derivaciones de usuarios finales. 

Desafortunadamente, el paso de SHA-1 a SHA-2 es una operación unidireccional en la mayoría de los escenarios del servidor. Por ejemplo, una vez que mueva el certificado de servidor web de SHA-1 a SHA-2, los clientes que no entienden los certificados SHA-2 pueden ver advertencias o errores -o fallar. La migración a SHA-2 será un salto riesgoso para aplicaciones y dispositivos no compatibles. 

Plan de migración PKI SHA-1 a SHA-2

Cada empresa con una PKI interna que no esté usando SHA-2 necesitará crear una PKI SHA-2 o migrar su PKI SHA-1 existente a SHA-2 (en algún momento). Un plan de migración SHA-2 incluye: 

  1. Educar a los miembros del equipo involucrados sobre lo que es SHA-2, y por qué su uso está siendo mandado (este documento es un buen comienzo).
  2. Inventario de todos los hashes/certificado digital que consumen o utilizan aplicaciones y dispositivos.
  3. Determinación de qué aplicaciones o dispositivos de consumo crítico pueden utilizar SHA-2 y qué tamaños de clave, cuáles no se pueden utilizar, y cuáles pueden ser las preocupaciones operativas (esto a menudo incluye ponerse en contacto con el proveedor y las pruebas).
  4. Determinación de qué componentes de PKI pueden o serán migrados a SHA-2.
  5. Cree un plan de migración para convertir los componentes de SHA-1 a SHA-2, incluidos clientes consumidores y componentes de PKI, además del plan de fallas en caso de falla crítica.
  6. Testeo de prueba de concepto.
  7. Aceptación del riesgo de gestión y decisión de ir/no ir.
  8. Implementación del plan de migración en el entorno de producción.
  9. Pruebas y retroalimentación.

La parte más difícil de la mayoría de los proyectos de migración SHA-2 es determinar qué dispositivos y aplicaciones funcionan con SHA-2. Si los dispositivos que consumen no entienden SHA-2, espere una falla o un mensaje de error, lo cual probablemente no será tan esclarecedor como "SHA-2 no reconocido". En lugar de ello considere: "Certificado no reconocido, "Conexión no asegurada, "No se puede establecer la conexión, "Certificado incorrecto o "Certificado no fiable. 

Piense en su misión para determinar qué funcionará o no funcionará como una especie de mini proyecto Y2K. Comience intentando inventariar cada dispositivo único, sistema operativo y aplicación que necesitará entender SHA-2. A continuación, reúna un equipo de personas para probar si SHA-2 funciona. Puede confiar tentativamente en los certificados del fabricante, pero hasta que no pruebe usando un certificado de SHA-2, no estará seguro. 

Actualizar sus aplicaciones y dispositivos normalmente no es trivial y a menudo toma más tiempo del que piensa. Incluso ahora, veo una gran cantidad de dispositivos y aplicaciones que ejecutan versiones más antiguas de OpenSSL, que debería haber sido parchados después de Heartbleed, pero no lo fueron. Recuerde, también, que la actualización requiere pruebas y aceptación formal del usuario. 

Si tiene una PKI (infraestructura de clave pública) interna, deberá prepararla también para SHA-2. A veces esto significa actualizar sus CAs, obtener certificados de CA nuevos o instalar PKI completamente nuevos. Recomiendo el último por muchas razones, sobre todo porque una nueva PKI le da una ocasión de comenzar otra vez, libre de errores pasados. 

Modelos de migración PKI

Estos son los siguientes escenarios de componentes de PKI para implementar SHA-2 (para estos ejemplos, estoy asumiendo una PKI de 2 niveles: raíz offline y emisor CA empresarial en línea -cada uno de los cuales puede ser un componente PKI nuevo o migrado: 

  • Dos árboles PKI, uno de ellos completamente SHA-1 y el otro completamente SHA-2. El resto de las opciones asumen un único árbol PKI.
  • Todo el árbol PKI, desde la raíz hasta los extremos, son todos SHA-1.
  • Todo el árbol PKI, desde la raíz hasta los extremos, son todos SHA-2.
  • Raíz SHA-1, CA emisores SHA-2, certificados terminales SHA2.
  • Raíz SHA-1, CA emisores SHA-2, certificados terminales SHA-1.
  • Raíz SHA-1, CA emisores tanto SHA-1 y SHA-2, con certificados terminales SHA-1 y SHA-2.
  • Raíz SHA-2, CA emisores SHA-1, certificados terminales SHA-1.
  • Raíz SHA-2, CA emisores SHA-2, certificados terminales SHA-1.
  • Raíz SHA-2, CA emisores tanto SHA-1 y SHA-2, con certificados terminales SHA-1 y SHA-2.

También es posible tener un CA emisor que intercale entre SHA-1 y SHA-2 según se requiera, pero esto más que probablemente causará confusión en los servicios PKI (y no es particularmente recomendable). Si es posible, para una migración más sencilla, puede ejecutar PKIs paralelas, una con SHA-1 y la otra SHA-2, y luego mover los dispositivos y las aplicaciones de consumo según lo permita la prueba.  

Nota: El certificado raíz propio de la CA no tiene que ser migrado a SHA-2 aún si es SHA-1. Todos los programas de comprobación de la depreciación solo se preocupan por todo lo que va después del certificado raíz propio de la CA (al menos por el futuro previsible). Aun así, si fuera yo, probablemente movería todo, incluyendo el certificado raíz, propio de la CA hacia SHA-2, de modo que pueda decir que toda mi PKI es SHA-2 y evitar cualquier cambio de SHA-1 en el camino. 

Las CA públicas ya se han pasado de SHA-1 a SHA-2 para cualquier certificado posterior al 1 de enero del 2017, por lo que debe concentrar sus esfuerzos en servidores y aplicaciones con certificados digitales públicos que aún no se han movido. Después de que el problema se resuelva, comience a mirar sus PKI internos y las partes de confianza. Migrar de SHA-1 a SHA-2 no es difícil técnicamente, pero es un cambio logístico masivo con toneladas de repercusiones y requiere muchas pruebas. 

No creo que la mayoría de los fabricantes conozcan la fecha final de la eliminación de SHA-1 (es decir, cuando se aplicará a todas las aplicaciones y dispositivos y causará errores "fatales"), pero supongo que llegará más pronto que tarde, ya que cada vez más los consumidores se están moviendo a SHA-2. La verdad es que ya debería estar allí. 

SHA-3 está aquí, pero ¿debería usarlo?

Aunque no se ha encontrado ninguna debilidad criptográfica significativa en SHA-2, se considera que está relacionada algorítmicamente con SHA-1. La mayoría de los expertos creen que su ciclo de vida será similar al de SHA-1. NIST ya aprobó en agosto del 2015 un algoritmo de sustitución criptográfico estándar que se llama SHA-3. SHA-3 no comparte las mismas propiedades matemáticas que SHA-1 y SHA-2, y por lo tanto debe ser resistente a ataques criptográficos más largos que SHA-2. 

Desafortunadamente, cualquier persona que esté pensando en retrasar su migración SHA-2 con la esperanza de pasar directamente a SHA-3 quedará muy decepcionada. La adopción generalizada de SHA-3 está probablemente a muchos años de distancia, mientras que SHA-2 es necesario ahora. Si se trasladó a SHA-3 ahora, la mayoría, si no la totalidad, de sus aplicaciones y dispositivos que confían criptográficamente, probablemente estarán sin error (diciendo que no pueden reconocer el certificado digital). 

Por lo tanto, si todavía no ha migrado a SHA-2, continúe. Y cuando SHA-2 empiece a debilitarse, todos podemos pasar a SHA-3.