Inicio / Blog / Llegó la hora de reemplazar SHA1

Llegó la hora de reemplazar SHA1

Publicado el 25/09/2014, por Jesús Díaz (INCIBE)
SHA1

Siguiendo la recomendación del NIST, que aconseja no utilizar algoritmos de hashing criptográfico que proporcionen una seguridad igual o menor a 80 bits de información (entre los que se encuentra SHA1), Microsoft anunciaba en noviembre de 2013 su plan para la renovación de certificados digitales (para CAs adscritas al Microsoft Root Certificate Program), o más bien, para acabar con el uso de aquellos en los que la CA emisora utilice SHA1 como algoritmo de hashing para el firmado del certificado. Este anuncio ha sido respaldado por Google en agosto de 2014 en el grupo security-dev de Chromium y posteriormente en su blog, en los que Google también ha hecho público su calendario para la adopción de certificados más seguros.

En resumen, las acciones que llevarán a cabo las compañías de Redmond y Mountain View son:

Fecha Microsoft Google
01/01/2016 Fin emisión certificados code signing Aviso a usuarios
01/01/2017 Rechazar certificados SSL Aviso a usuarios, Contenido tratado como mixed

 

Con más detalle, por un lado, a partir del 1 de enero de 2016, Microsoft empezará a rechazar los certificados que se usen para firmar código (los que tienen el flag de uso de code signing activo), que estén firmados con SHA1 y que tengan una fecha de emisión posterior al 1 de enero de 2016. A partir del 1 de enero de 2017, dejará de aceptar certificados que utilicen SHA1 para sesiones SSL.

 

Por otro lado, Google centrará sus actuaciones en las siguientes versiones de Chrome. A partir de la versión 39, los certificados que utilicen SHA1 y expiren a partir del 1 de enero de 2017 serán tratados como seguros, pero con errores menores. A partir de la versión 40, los certificados que usen SHA1 y caduquen entre el 1 de junio de y el 31 de diciembre de 2016 (inclusive) serán considerados como seguros, pero con errores menores; los que caduquen a partir del 1 de enero de 2017 serán tratados como neutrales, pero con seguridad insuficiente. Por último, a partir de la versión 41, los certificados que usen SHA1 y caduquen entre el 1 de enero y el 31 de diciembre de 2016 serán tratados como seguros, con errores menores, mientras que los que caduquen a partir del 1 de enero de 2017 serán tratados como inseguros, siendo el contenido "protegido" por ellos clasificado como mixed.

Las implicaciones de ambas estrategias son algo distintas. En el Foro de Autoridades de Certificación y Navegadores (CAB forum), en 2012, se establecieron nuevos requisitos para la emisión de certificados. En concreto, se definió que, a partir del abril de 2015, los certificados emitidos por CAs a usuarios finales tendrían una validez máxima de 39 meses, en lugar de 60 meses. Esto quiere decir que, según los criterios de Microsoft, un certificado para la firma de código emitido en marzo de 2015 podría ser considerado válido hasta marzo de 2020. Aunque Microsoft ya anunció en su aviso original que revisará este último criterio en función de cuándo consideren ellos mismos que SHA1 es vulnerable a ataques de pre-imagen.

En cualquier caso, queda claro que tanto Microsoft como Google apuestan por mejorar la seguridad en la web. Pero, ¿cuál es el impacto real de estas medidas?, ¿a cuántos sitios web afecta actualmente?

Para hacernos una idea de las respuestas a estas preguntas, utilizamos como referencia tres rankings ofrecidos por Alexa:

De las web que aparecen en dichos rankings, y que soportan conexión SSL, hemos cogido el certificado devuelto, apuntando el algoritmo de hashing criptográfico utilizado (sigAlgo) y la fechas de caducidad (notAfter). Los scripts utilizados están disponibles tanto en Bash como en Python en Github.

Los datos obtenidos, a 11 de septiembre de 2014 se muestran a continuación (hacer click en la imagen para ampliarla). Como se puede observar, en las tres categorías, más del 80% de los sitios web utilizan SHA1 y entre el 1% y el 2% de los sitios web aún usan MD5, para el que se conocen desde 2009 ataques que permiten crear certificados falsos en menos de 1 día.

En cuanto a las fechas de expiración sólo entre un 27% (Top Global) y un 39% (Top Computer Security) de los certificados caducan antes de 2016, por lo que el resto (entre el 61% y 73% de los sitios web) tendrían que actualizar sus certificados para no ser considerados como inseguros.

 

Certificados Alexa

 

 

Causas y consecuencias

Más allá de los avisos y restricciones de servicio que impondrán tanto Microsoft como Google, ¿cuáles son las causas y las consecuencias que tendrá este cambio?

Sobre las causas, desde aproximadamente 2005 comenzaron a publicarse ataques que reducían la seguridad de SHA1 más allá de los teóricos 80 bits de seguridad ante colisiones (es decir, un atacante por fuerza bruta tendría que calcular 280 hashes en media para encontrar una colisión). Hasta ahora, el más efectivo de ellos es probablemente el ataque de Stevens, que puede llegar a reducir la seguridad a unos 60 bits (260 operaciones).

Con los costes del ataque de Stevens en mente, y teniendo en cuenta el coste de calcular un hash SHA1 (214 ciclos de CPU), el número de CPUs por servidor y la evolución de la capacidad de cómputo según la ley de Moore, Jesse Walker estimó cuánto tardaría un atacante en encontrar una colisión. Sus estimaciones para los siguientes años son:

  • En 2015, se tardaría unos 211 = 2048 años de servidor (es decir, habría que “destinar” un servidor durante 2048 años, aproximadamente, a encontrar una colisión).
  • En 2018, se tardaría unos 29 = 512 años de servidor.
  • En 2021, se tardaría unos 27 = 128 años de servidor.

Esto puede parecer demasiado para ser preocupante pero, como sigue Jesse Walker, teniendo en cuenta el coste de alquiler de potencia de cálculo en Amazon ($0,04/hora o $350/año a octubre de 2012), los costes anteriores, en dólares, serían:

  • $700.000 en 2015.
  • $173.000 en 2018.
  • $43.000 en 2021.

Teniendo en cuenta los beneficios que se podrían obtener consiguiendo un certificado ilegítimo, de por ejemplo un gran banco, estas cantidades dejan de ser desorbitadas (especialmente para grandes organizaciones criminales). Además, en caso de que los precios de Amazon bajasen, o que se descubrieran nuevos ataques más eficientes que el de Stevens, habría que revisar estos cálculos. Del mismo modo, estos costes están asociados a servidores con hardware genérico, por lo que utilizando hardware especializado (como GPUs) también se reduciría el tiempo de ataque.

Sobre las consecuencias, en cuanto a compatibilidad de navegadores, servidores y otros dispositivos y componentes software, este cambio en principio no supondrá un mayor problema ya que la mayoría de ellos (o al menos sus versiones relativamente recientes) incluyen soporte para hashes de tipo SHA256. Y, evidentemente, los propios certificados también son compatibles con las alternativas más seguras a SHA1 (ver por ejemplo el RFC 5754 o el RFC 5758 para la definición de los OIDs que combinan hashes de la familia SHA2 con distintos algoritmos de firma y cifrado).

Así que, volviendo al estado actual de la migración de SHA1 a SHA2, aún queda mucho trabajo por hacer. Por suerte, esta vez Microsoft y Google han sido previsores, para evitar otro 8 de abril de 2014, aunque todavía queda por ver cómo se adaptan las CAs.