Tabla de contenidos
Introducción
En este artículo, compararé los estándares de cifrado que consideramos seguros con la tecnología actual y lo que podría hacer que dejaran de serlo en los próximos años. También intentaré analizar cómo podemos prepararnos para el futuro a diferentes escalas en nuestra industria, el desarrollo de software.
En primer lugar, quiero exponer los dos tipos principales de cifrado en los que se basa la mayoría del software que utilizamos. Esto se basa principalmente en lo que establece el Instituto Nacional de Estándares y Tecnología (NIST) de Estados Unidos.
Cifrado simétrico
Por un lado tenemos el cifrado simétrico, que utiliza una única clave privada (o secreta) para cifrar y descifrar los datos. El secreto debe ser compartido entre las partes que necesitan comunicarse de forma segura, lo que constituye un riesgo de seguridad y su punto débil. Junto con otras medidas para garantizar una transferencia segura de la clave, puede ser una buena opción, ya que es criptográficamente más segura que otros métodos.
El algoritmo más utilizado es el Advanced Encryption Standard (AES), que hasta ahora no ha sido descifrado, y del que existen múltiples versiones como AES-128, AES-196 y AES-256 (siendo los números de la versión la longitud de la clave en bits). Un problema de este tipo de algoritmos es que son vulnerables a los ataques de fuerza bruta y se basan en la longitud de la clave como forma de reforzar el cifrado contra estos ataques. Hay que tener en cuenta que, con los ordenadores clásicos actuales, se necesitaría una cantidad de tiempo inmensa (miles de billones de años, incluso más que la vida del universo) para descifrar cualquiera de las versiones de longitud de clave de AES.
También hubo otros ataques, como el Meet-in-the-Middle (MITM), que comprometieron los algoritmos que usábamos como estándar en el pasado (o que todavía lo hacen). Un ejemplo de ello es la familia DES (Data Encryption Standard), que en su primera versión era crackeable por fuerza bruta con sólo 256 operaciones (tardaba 22 horas en 1997 y tarda 5 minutos hoy). Su sucesor Double DES arregló esto encriptando dos veces con dos claves diferentes pero sigue siendo el que terminó siendo vulnerable al ataque MITM. Luego fue reemplazado por Triple DES que también es vulnerable a más de un ataque (incluyendo MITM) y la única solución es alargar la clave, nuevamente, o hacer más operaciones con las claves para agregar complejidad.
El cifrado simétrico se utiliza sobre todo para cifrar datos en operaciones que deben ser rápidas, como las transacciones bancarias y de tarjetas de crédito, también se utiliza en el protocolo de seguridad de la capa de transporte (TLS) en todo Internet, en el almacenamiento de datos cifrados y en muchas más aplicaciones.
Cifrado asimétrico
Por otro lado, tenemos el cifrado asimétrico. Este tipo de cifrado se basa en un par de claves, la privada y la pública. La privada se utiliza para cifrar y no debe compartirse. La clave pública se utiliza para descifrar junto con la respectiva clave privada del destinatario y puede ser, como su nombre indica, pública. Aunque expone cierta información.
El estándar más conocido y actual para el cifrado asimétrico es el protocolo RSA (Rivest Shamir Adleman). Utiliza dos grandes números primos para generar el par de claves privadas-públicas y se utiliza habitualmente como algoritmo de intercambio de claves. Gracias a RSA podemos intercambiar claves privadas para utilizar el cifrado simétrico de forma más segura, y así crear otras soluciones complejas para diferentes amenazas y casos de uso. Por ejemplo, se utiliza junto con AES en TLS, para intercambiar sus claves privadas y garantizar la integridad digital. También podemos encontrarlo en los servicios de cifrado de correo electrónico, firmas digitales, blockchain, etc.
Como se ha mencionado anteriormente, la seguridad de este método se basa en la factorización de dos grandes números primos con una ecuación específica. Estos dos números son la clave privada y el resultado de la ecuación es la clave pública. Para forzar esta tarea con la computación clásica, un atacante necesitaría 300 billones de años para descifrar un par de claves RSA. Esto no parece una amenaza, ¿verdad? Bueno, la vulnerabilidad sigue ahí, y 300 billones de años en este caso es sólo una forma de relacionar el número de operaciones de cálculo y el tiempo transcurrido para cada una de esas operaciones. Pero esto sólo se basa en el marco que entendemos hoy en día para la mecánica de la potencia de cálculo.
La amenaza
Hasta ahora podríamos decir que nuestro único recurso para salvarnos de la mayoría de los ataques para el cifrado simétrico es tener una clave más larga y/o añadir tiempo de trabajo computacional (o complejidad) para la creación de la misma. Y de esta manera se necesitaría una cantidad de «tiempo de computación» que consideramos lejos de poder crackear nuestros sistemas con fuerza bruta u otros ataques que hoy conocemos. ¿Pero cómo es que consideramos esos tiempos imposibles? Bueno, eso se basa en la Ley de Moore, que establece que la potencia de cálculo se duplica cada dos años, y a ese ritmo, parece realmente difícil alcanzar los objetivos necesarios para romper la criptografía actual en un futuro próximo.
¿Y si te dijera que los 300 trillones de años necesarios para romper RSA, serían segundos para un ordenador cuántico suficientemente potente? Sí, segundos. Dicho esto, no parece demasiado descabellado esperar que el cifrado simétrico pueda ser descifrado en un tiempo razonable con esta nueva tecnología. Sería cuestión de mejorar el campo al ritmo que lo está haciendo ahora, y eso no significa que no pueda ocurrir aún más rápido si hay un avance importante. Con lo que sabemos ahora sobre el asunto, se espera tener un ordenador cuántico con la potencia necesaria para descifrar RSA para el año 2030. Esto no está tan lejos, ¿verdad?
El NIST ya tiene un plan propuesto para la transición a nuevos estándares post-cuánticos, pero en la historia pasada, sus estándares han sido erróneos y han tenido vulnerabilidades (el DES, por ejemplo, estaba en la lista que el NIST consideraba segura no hace mucho tiempo). Además, no tenemos ninguna certeza de que los nuevos esquemas de encriptación que el NIST propondrá como estándares vayan a ser a prueba de cuántica una vez que esa tecnología se despliegue.
También creo que es muy importante tener en cuenta cómo se presenta el futuro del software en los próximos años, porque es normal escuchar que los datos que deben ser seguros hoy probablemente ya no lo sean «cuando llegue la informática cuántica» y otras afirmaciones similares. Y en un mundo en el que todo parece dirigirse hacia el software que trabaja sobre datos recolectados (como la Inteligencia Artificial) y los servicios centralizados que alojan los datos de los usuarios que estarán ahí cuando llegue la cuántica, no veo ninguna razón para no preocuparse por ser lo más seguro posible para ese momento. Los servicios descentralizados que están surgiendo basados en la tecnología de encriptación actual también serán vulnerables a esta amenaza y más vale que tengamos alternativas para evitar el caos que podría surgir. Básicamente, la mayor parte de nuestra exposición al cifrado actual está en peligro y cuanto antes empecemos a pensar en cómo hacer la transición a este nuevo paradigma criptográfico, mejor.
La transición
En primer lugar, tratemos de buscar formas de manejar esta amenaza.
Uno de los enfoques es el que supuestamente ya está abordando el NIST, que es el desarrollo de nuevos esquemas criptográficos a prueba de cuántica junto con un plan para migrar de los actuales a los puntuales (esperemos).
Otra opción sería construir soluciones a prueba de cuántica sobre la infraestructura que tenemos hoy en día; por poner un ejemplo conocido, mencionemos TLS. Se podría construir una capa a prueba de cuánticos sobre TLS para protegerlo de los exploits cuánticos.
Pero lo que es bastante seguro es que la transición no va a ser fácil ni corta. Parece que vamos a estar en un entorno en el que surgirán muchas tecnologías nuevas y nosotros, como desarrolladores, tendremos que adaptarnos a ellas. Teniendo siempre en cuenta que lo que estamos construyendo hoy, podría no funcionar como esperamos en el futuro.
Como desarrolladores de software, tenemos las herramientas para estar preparados para esta era. La más importante son las «buenas prácticas». Ya sabemos cómo construir software escalable, y podemos empezar a pensar en esta transición como un tipo de escalado. Así que si utilizamos buenas prácticas de abstracción, por ejemplo, vamos en la dirección correcta. Si nos aseguramos de tener un código mantenible, y realmente hacemos el mantenimiento, deprecamos lo que sea necesario, actualizamos las dependencias y hacemos un seguimiento de ellas (AES-128 y RSA son probablemente sus dependencias); entonces deberíamos estar en una buena posición para crear un software que esté listo para esta próxima fase de la información digital.
Por parte de las organizaciones, el proceso también debe gestionarse adecuadamente, ya que son ellas las que financiarán este desarrollo. Las organizaciones van a invertir dinero en los enfoques mencionados anteriormente, y los aplicarán realmente. Así que creo que la atención debe centrarse en asegurarse de que sus equipos están preparados para lo que viene y que su software está construido de una manera que les permite mantenerlo en el futuro.
Dicho esto, parece que deberíamos (o debemos) dirigirnos a una industria en la que las empresas invierten y se centran en la calidad y la flexibilidad. Con un software de buena calidad e ingenieros preparados, la industria debería adaptarse bien a este entorno tan cambiante y evitar tantas catástrofes como sea posible.
Con la ayuda de todas las entidades implicadas, como el NIST y muchas más organizaciones que trabajan en pro de la normalización y la ciberseguridad, con optimismo deberíamos tener un marco sólido en el que apoyarnos a medida que pase el tiempo y mejore la tecnología.
