Las definiciones criptográficas de seguridad no son las mismas que se aplican a la seguridad informática general. La principal diferencia entre la seguridad del software y la seguridad criptográfica es que esta última se puede cuantificar. A diferencia del mundo del software, donde las aplicaciones generalmente se consideran seguras o inseguras, en el mundo criptográfico a menudo es posible calcular la cantidad de esfuerzo requerido para romper un algoritmo criptográfico. Además, mientras que la seguridad del software se centra en evitar que los atacantes abusen del código de un programa, el objetivo de la seguridad criptográfica es hacer que problemas bien definidos sean imposibles de resolver.
Los problemas criptográficos involucran nociones matemáticas, pero no matemáticas complejas, o al menos no en este post. Este post lo guía a través de algunas de estas nociones de seguridad y cómo se aplican para resolver problemas del mundo real. En las siguientes secciones, analizo cómo cuantificar la seguridad criptográfica de formas que sean teóricamente sólidas y prácticamente relevantes. Analizo las nociones de seguridad informática versus seguridad computacional, seguridad de bits versus costo total de ataque, seguridad demostrable versus heurística y generación de claves simétricas versus asimétricas. Concluyo el post con ejemplos reales de fallas en la criptografía aparentemente fuerte.
definiendo lo imposible
Ya se describió la seguridad de un cifrado en relación con las capacidades y objetivos de un atacante, y consideremos que un cifrado era seguro si era imposible alcanzar estos objetivos dadas las capacidades conocidas de un atacante. Pero, ¿qué significa imposible en este contexto?
Dos nociones definen el concepto de imposible en criptografía: seguridad de la información y seguridad computacional. En términos generales, la seguridad de la información se trata de una imposibilidad teórica, mientras que la seguridad computacional se trata de una imposibilidad práctica. La seguridad de la información no cuantifica la seguridad porque ve un cifrado como seguro o inseguro, sin un término medio; por lo tanto, es inútil en la práctica, aunque juega un papel importante en la criptografía teórica. La seguridad computacional es la medida más relevante y práctica de la fuerza de un cifrado.
SEGURIDAD EN LA TEORIA. LA SEGURIDAD DE LA INFORMACION
La seguridad de la información no se basa en lo difícil que sea descifrar un cifrado, sino en si es posible descifrarlo. Un cifrado es seguro desde el punto de vista de la información solo si, incluso con un tiempo de cálculo y una memoria ilimitados, no se puede descifrar. Incluso si un ataque exitoso a un cifrado llevaría billones de años, dicho cifrado es inseguro desde el punto de vista de la información.
Por ejemplo, el one-time pad presentado anteriormente es seguro desde el punto de vista de la información. Recuerde que el pad de una sola vez cifra un texto plano, P, en un texto cifrado, C = P ⊕ K, donde K es una cadena de bits aleatoria que es única para cada texto plano. El cifrado es seguro desde el punto de vista de la información porque, dado un texto cifrado y un tiempo ilimitado para probar todas las claves posibles, K, y calcular el texto plano correspondiente, P, todavía no podría identificar el K correcto porque hay tantas P posibles como Ks.
SEGURIDAD EN LA PRACTICA. SEGURIDAD COMPUTACIONAL
A diferencia de la seguridad de la información, la seguridad computacional considera que un cifrado es seguro si no se puede descifrar en un período de tiempo razonable y con recursos razonables como memoria, hardware, presupuesto, energía, etc. La seguridad computacional es una forma de cuantificar la seguridad de un cifrado o cualquier algoritmo criptográfico.
Por ejemplo, considere un cifrado, E, para el que conoce un par de texto plano cifrado (P, C) pero no la clave de 128 bits, K, que sirvió para calcular C = E (K, P). Este cifrado no es seguro desde el punto de vista de la información porque podría romperlo después de probar los 2128 K posibles de 128 bits hasta encontrar el que satisfaga E (K, P) = C. Pero en la práctica, incluso probando 100 mil millones de claves por segundo, tardariamos más de 100.000.000.000.000.000.000 años. En otras palabras, hablando razonablemente, este cifrado es computacionalmente seguro porque es prácticamente imposible de descifrar.
La seguridad computacional a veces se expresa en términos de dos valores:
- t, que es un límite en la cantidad de operaciones que realizará un atacante
- ε (llamado «épsilon»), que es un límite en la probabilidad de éxito de un ataque
Luego decimos que un esquema criptográfico es (t, ε) -seguro si un atacante que realiza como máximo t operaciones, cualesquiera que sean esas operaciones, tiene una probabilidad de éxito que no es mayor que ε, donde ε es al menos 0 y como máximo 1. La seguridad informática establece un límite sobre la dificultad de romper un algoritmo criptográfico.
Aquí es importante saber que t y ε son solo límites: si un cifrado es (t, ε) -seguro, ningún atacante que realice menos de t operaciones tendrá éxito (con probabilidad ε). Pero eso no implica que un atacante que realice exactamente t operaciones tendrá éxito, y no le dice cuántas operaciones se necesitan, que pueden ser mucho más grandes que t. Decimos que t es un límite inferior en el esfuerzo de cómputo necesario, porque necesitaría al menos t operaciones para comprometer la seguridad.
A veces sabemos con precisión cuánto esfuerzo se necesita para descifrar un cifrado; en tales casos decimos que una (t, ε) de seguridad nos da un límite estrecho cuando existe un ataque que rompe el cifrado con probabilidad ε y exactamente t operaciones.
Por ejemplo, considere un cifrado simétrico con una clave de 128 bits. Idealmente, este cifrado debería ser (t, t / 2128) -seguro para cualquier valor de t entre 1 y 2128. El mejor ataque debería ser la fuerza bruta (probando todas las claves hasta encontrar la correcta). Cualquier ataque mejor tendría que explotar alguna imperfección en el cifrado, por lo que nos esforzamos por crear cifrados donde la fuerza bruta sea el mejor ataque posible.
Dada la declaración (t, t / 2128) de seguridad, examinemos la probabilidad de éxito de tres posibles ataques:
- En el primer caso, t = 1, un atacante intenta una clave y tiene éxito con una probabilidad de ε = 1/2128.
- En el segundo caso, t = 2128, un atacante intenta todas las 2128 claves y una tiene éxito. Así, la probabilidad ε = 1 (si el atacante prueba todas las claves, obviamente la correcta debe ser una de ellas).
- En el tercer caso, un atacante intenta solo t = 264 claves y tiene éxito con una probabilidad de ε = 264/2128 = 2−64. Cuando un atacante solo prueba una fracción de todas las claves, la probabilidad de éxito es proporcional al número de claves probadas.
Podemos concluir que un cifrado con una clave de n bits es en el mejor de los casos (t, t/ 2n) -seguro, para cualquier t entre 1 y 2n, porque no importa cuán fuerte sea el cifrado, un ataque de fuerza bruta contra él siempre será tener éxito. Por lo tanto, la clave debe ser lo suficientemente larga como para frenar los ataques de fuerza bruta en la práctica.
En este ejemplo, contamos el número de evaluaciones del cifrado, no el tiempo absoluto o el número de ciclos de reloj del procesador. La seguridad computacional es independiente de la tecnología, lo cual es bueno: un cifrado que es (t, ε) -seguro hoy será (t, ε) -seguro mañana, pero lo que se considera seguro en la práctica hoy puede no serlo mañana.
cuantificando la seguridad
Cuando se encuentra un ataque, lo primero que debe saber es qué tan eficiente es en teoría y qué tan práctico es, si es que lo es. Del mismo modo, dado un cifrado que supuestamente es seguro, desea saber qué cantidad de trabajo puede soportar. Para abordar esas preguntas, explicaré cómo se puede medir la seguridad criptográfica en bits (la visión teórica) y qué factores afectan el costo real de un ataque.
MIDIENDO LA SEGURIDAD EN BITS
Cuando hablamos de seguridad computacional, decimos que un cifrado es t-seguro cuando un ataque exitoso necesita al menos t operaciones. Por lo tanto, evitamos la notación poco intuitiva (t, ε) asumiendo una probabilidad de éxito de ε cercana a 1, o lo que nos importa en la práctica. Luego expresamos la seguridad en bits, donde “seguridad de n bits” significa que se necesitan alrededor de 2n operaciones para comprometer alguna noción de seguridad en particular.
Si sabe aproximadamente cuántas operaciones se necesitan para descifrar un cifrado, puede determinar su nivel de seguridad en bits tomando el logaritmo binario del número de operaciones: si se necesitan 1000000 operaciones, el nivel de seguridad es log2 (1000000), o aproximadamente 20 bits (es decir, 1000000 es aproximadamente igual a 220). Recuerde que una clave de n bits dará como máximo una seguridad de n bits porque un ataque de fuerza bruta con las 2n claves posibles siempre tendrá éxito. Pero el tamaño de la clave no siempre coincide con el nivel de seguridad, solo proporciona un límite superior o el nivel de seguridad más alto posible.
Un nivel de seguridad puede ser menor que el tamaño de la clave por una de dos razones:
- Un ataque rompió el cifrado en menos operaciones de las esperadas, por ejemplo, utilizando un método que recupera la clave probando no todas las claves 2n, sino solo un subconjunto de ellas.
- El nivel de seguridad del cifrado difiere intencionalmente del tamaño de su clave, como ocurre con la mayoría de los algoritmos de clave pública. Por ejemplo, el algoritmo RSA con una clave secreta de 2048 bits proporciona una seguridad de menos de 100 bits.
La seguridad de bits resulta útil al comparar los niveles de seguridad de los cifrados, pero no proporciona suficiente información sobre el costo real de un ataque. A veces es una abstracción demasiado simple porque simplemente asume que un cifrado seguro de n bits necesita 2n operaciones para romperse, sean cuales sean estas operaciones. Por lo tanto, dos cifrados con el mismo nivel de seguridad de bits pueden tener niveles de seguridad del mundo real muy diferentes cuando se tiene en cuenta el costo real de un ataque para un atacante real.
Digamos que tenemos dos cifrados, cada uno con una clave de 128 bits y seguridad de 128 bits. Cada uno debe evaluarse 2128 veces para que se rompa, excepto que el segundo cifrado es 100 veces más lento que el primero. Evaluar el segundo cifrado 2128 veces toma el mismo tiempo que 100 × 2128 ≈ 2134.64 evaluaciones del primero. Si contamos en términos del primer cifrado rápido, romper el más lento requiere 2134,64 operaciones. Si contamos en términos del segundo cifrado lento, solo se necesitan 2128 operaciones. ¿Deberíamos decir entonces que el segundo cifrado es más fuerte que el primero? En principio, sí, pero rara vez vemos una diferencia de rendimiento de cien veces mayor entre los cifrados de uso común.
La definición inconsistente de una operación plantea más dificultades al comparar la eficiencia de los ataques. Algunos ataques afirman reducir la seguridad de un cifrado porque realizan 2120 evaluaciones de alguna operación en lugar de 2128 evaluaciones del cifrado, pero la velocidad de cada tipo de ataque se deja fuera del análisis. El ataque de 2120 operaciones no siempre será más rápido que un ataque de fuerza bruta de 2128.
No obstante, la seguridad de bits sigue siendo una noción útil siempre que la operación esté razonablemente definida, es decir, tan rápido como una evaluación del cifrado. Después de todo, en la vida real, todo lo que se necesita para determinar si un nivel de seguridad es suficiente es un orden de magnitud.
coste de un ataque total
La seguridad de bits expresa el costo del ataque más rápido contra un cifrado estimando el orden de magnitud del número de operaciones que necesita para tener éxito. Pero otros factores afectan el costo de un ataque, y estos deben tenerse en cuenta al estimar el nivel de seguridad real. Explicaré los cuatro principales: paralelismo, memoria, precomputación y número de objetivos.
paralelismo
El primer factor a considerar es el paralelismo computacional. Por ejemplo, considere dos ataques de 256 operaciones cada uno. La diferencia entre los dos es que el segundo ataque se puede paralelizar pero no el primero: el primer ataque realiza 256 operaciones secuencialmente dependientes, como xi + 1 = fi(xi) para algun x0 y algunas funciones fi
(con i de 1 a 256), mientras que el segundo realiza 256 operaciones independientes, como xi= fi(x) para algunos x entre 1 a 256, que se puede ejecutar en paralelo. El procesamiento paralelo puede ser de ordenes de magnitud más rápidos que el procesamiento secuencial. Por ejemplo, si tuvieras 216 = 65536 procesadores disponibles, podría dividir la carga de trabajo de los ataques paralelos en 216 tareas independientes, cada una de las cuales realiza 256/216 = 240 operaciones. El primer ataque, sin embargo, no puede beneficiarse de tener múltiples núcleos disponibles porque cada operación se basa en el resultado de la operación anterior. Por lo tanto, el ataque paralelo se completará 65536 veces más rápido que el secuencial, a pesar de que realizan el mismo número de operaciones.
memoria
El segundo factor al determinar el costo de un ataque es la memoria. Los ataques criptoanalíticos deben evaluarse con respecto a su uso del tiempo y espacio: ¿cuántas operaciones se realizan a lo largo del tiempo, cuánta memoria o espacio se consumen, cómo utilizan el espacio que consumen y cuál es la velocidad de la memoria disponible? Desafortunadamente, la seguridad se preocupa únicamente por el tiempo que lleva realizar un ataque. En cuanto a la forma en que se utiliza el espacio, es importante considerar cuántas búsquedas de memoria son necesarias como parte de un ataque, la velocidad del acceso a la memoria (que pueden diferir entre lecturas y escrituras), el tamaño de los datos accedidos, el patrón de acceso (direcciones de memoria contiguas o aleatorias), y cómo se estructuran los datos en la memoria. Por ejemplo, en uno de los
CPU de propósito general, la lectura de un registro toma un ciclo, mientras que
la lectura de la memoria caché de la CPU toma alrededor de 20 ciclos (para la cache L3) y la lectura de DRAM suele tardar al menos 100 ciclos. Un factor de 100 puede marcar la diferencia entre un día y tres meses.
precomputacion
Las operaciones de precomputación son aquellas que deben realizarse solo una vez y se puede reutilizar en ejecuciones posteriores del ataque. La precomputación a veces se denomina etapa de fuera de línea. Por ejemplo, considere el ataque de compensación de tiempo-memoria. Al realizar este tipo de ataque, el atacante realiza un gran cálculo que
produce grandes tablas de búsqueda que luego se almacenan y reutilizan para realizar la
ataque real. Por ejemplo, un ataque al cifrado móvil 2G requirió dos meses para construir dos terabytes de tablas, que luego se usaron para romper el cifrado en 2G y recuperar una clave de sesión secreta en solo unos segundos.
numero de objetivos
Finalmente, llegamos al número de objetivos del ataque. Cuanto mayor sea el número de objetivos, mayor superficie de ataque y más atacantes deben conocer las claves que buscan. Por ejemplo, considere una búsqueda de clave de fuerza bruta: si apunta a una
clave de n bits, tomará 2n intentos encontrar la clave correcta con certeza. Pero si apuntas a múltiples claves de n bits, digamos, un número M, y si para una sola P, tienen M textos cifrados distintos, donde C = E (K, P) para cada una de las teclas M (K) que buscas, volverá a tomar 2n intentos encontrar cada clave. Pero si estas solo interesado en al menos una de las claves M y no en todas, toma un promedio de 2n/M intentos tener éxito. Por ejemplo, para romper una clave de 128 bits de 216 = 65536 claves de destino, tomará un promedio de 2128 – 16 = 2112 evaluaciones del cifrado. Es decir, el costo (y la velocidad) del ataque disminuye a medida que aumenta el número de objetivos.
eligiendo y evaluando niveles de seguridad
La elección de un nivel de seguridad a menudo implica seleccionar entre 128 y 256 bits porque la mayoría de los algoritmos e implementaciones criptográficas estándar están disponibles en uno de estos dos niveles de seguridad. Por debajo de 128 bits encontrará esquemas con seguridad de 64 u 80 bits, pero generalmente no son lo suficientemente seguros para el uso en el mundo real.
En un nivel alto, la seguridad de 128 bits significa que debe llevar a cabo
aproximadamente 2128 operaciones para romper ese sistema criptográfico. Para darte un
sentido de lo que este número significa, considere el hecho de que el universo tiene aproximadamente 288 nanosegundos de edad (hay mil millones de nanosegundos en un
segundo). Dado que probar una clave con la tecnología actual requiere no menos de un
nanosegundo, necesitarías varias veces la edad del universo para que un ataque por fuerza bruta tuviera éxito (240 veces para ser precisos) si se necesita exactamente un nanosegundo para probar una llave. ¿El paralelismo y los objetivos múltiples no pueden reducir drásticamente el tiempo que lleva completar un ataque exitoso? No exactamente. Supongamos que está interesado en romper cualquiera del millón de objetivos y que tiene un millón núcleos paralelos disponibles. Eso reduce el tiempo de búsqueda de 2128 a
(2128/220) / 220 = 288, lo que equivale a la edad del universo. Otra cosa a considerar al evaluar los niveles de seguridad es la evolución de la tecnología. La ley de Moore postula que la eficiencia informática se duplica aproximadamente cada dos años. Podemos pensar en esto como una pérdida de un poco de seguridad cada dos años: si hoy un presupuesto de $1000 le permite romper, digamos, una clave de 40 bits en una hora, la ley de Moore dice que dos años después, podría romper una clave de 41 bits en una hora por el mismo presupuesto de $1000 (estoy simplificando). Nosotros podemos extrapolar esto para decir que, de acuerdo con la ley de Moore, tendremos 40 bits menos de seguridad en 80 años en comparación con hoy. En otras palabras, en 80 años haciendo 2128 operaciones pueden costar tanto como hacer 288 operaciones hoy. Teniendo en cuenta el paralelismo y los objetivos múltiples, como se discutió anteriormente, estamos a 248 nanosegundos de cálculo, o unos tres días. Pero esta extrapolación es muy inexacta, porque la ley de Moore no puede ni puede escalar tanto. Aún así, te haces una idea: lo que hoy parece inviable puede ser realista en un siglo. Habrá ocasiones en las que se justifique un nivel de seguridad inferior a 128 bits. Por ejemplo, cuando necesita seguridad solo por un período corto de tiempo y cuando los costos de implementar un mayor nivel de seguridad impactarán negativamente en el costo o usabilidad de un sistema. Un ejemplo del mundo real es el de los sistemas de televisión de pago, donde las claves de cifrado son 48 o 64 bits. Esto suena ridículamente bajo, pero ese es un nivel de seguridad suficiente porque la clave se actualiza cada 5 o 10 segundos. Sin embargo, para garantizar la seguridad a largo plazo, debe elegir 256 bits o un poco menos. Incluso en el peor de los casos, la existencia de computadoras cuánticas es poco probable que se pueda romper un esquema seguro de 256 bits en el futuro previsible. Más de 256 bits de seguridad son prácticamente innecesarios, excepto como marketing. Como dijo una vez el criptógrafo del NIST John Kelsey, «La diferencia entre 80 bits y 128 bits de espacio de claves es como la diferencia entre una misión para Marte y una misión a Alpha Centauri. Por lo que podemos ver, no hay una diferencia significativa entre las claves de 192 bits y las de 256 bits en términos de ataque práctico de fuerza bruta; imposible es imposible «.
logrando seguridad
Una vez que haya elegido un nivel de seguridad, es importante garantizar que su esquemas criptográfico funcione. En otras palabras, quieres confianza, no solo esperanza e incertidumbre, que las cosas funcionen según lo planeado, todo el tiempo. Al generar confianza en la seguridad de un algoritmo criptográfico, puedes confiar en las pruebas matemáticas, un enfoque llamado seguridad demostrable, o en evidencia de intentos fallidos de romper el algoritmo, que llamaremos seguridad heurística (aunque a veces se le llama seguridad probable). Estos dos enfoques son complementarios y ninguno es mejor que el otro, como veremos.
seguridad demostrable
La seguridad demostrable consiste en demostrar que romper su esquema de cifrado es al menos tan difícil como resolver otro problema conocido por ser difícil. Tal prueba de deguridad garantiza que su criptografía permanece segura mientras el problema difícil
permanezca sin batir. Este tipo de prueba se llama reducción, y proviene de campo de la teoría de la complejidad. Decimos que romper algún cifrado se reduce a problema X si cualquier método para resolver el problema X también produce un método para romper
el cifrado. Las pruebas de seguridad vienen en dos formas, dependiendo del tipo de problema presuntamente difícil utilizado: pruebas relativas a un problema matemático y
pruebas relativas a un problema criptográfico.
pruebas relativas a un problema matematico
Muchas pruebas de seguridad (como las de la criptografía de clave pública) muestran que romper un esquema de criptografía es al menos tan difícil como resolver algunos problemas matemáticos difíciles. Estamos hablando de problemas para los que se sabe que existe una solución, y es fácil de verificar una vez que se conoce, pero es computacionalmente difícil de encontrar. Por ejemplo, considere el desafío de resolver el problema de factorización, que es el problema matemático más conocido en criptografia: dado un número que se sabe es el producto de dos números primos (n = pq), hallar dichos primos. Por ejemplo, si n = 15, la respuesta es 3 y 5. Eso es fácil para un número pequeño,
pero se vuelve exponencialmente más difícil a medida que aumenta el tamaño del número. Por ejemplo, si un número, n, tiene una longitud de 3000 bits (alrededor de 900 dígitos decimales), se cree que la factorizacion es prácticamente inviable. RSA es el esquema de cifrado más famoso que se basa en el problema de factorización: RSA cifra un texto plano, P, visto como un gran número, mediante la computación C = Pe mod n, donde el número e y n = pq son la clave pública. Descifrado recupera un texto plano de un texto cifrado calculando P = Cd mod n, donde d es la clave privada asociada a e y n. Si podemos factorizar n, entonces podemos romper RSA (recuperando la clave privada de la clave pública), y si podemos obtener la clave privada, entonces podemos factorizar n; en otras palabras, recuperar una clave privada RSA y factorizar n son problemas igualmente difíciles. Ese es el tipo de reducción que buscamos en seguridad demostrable. Sin embargo, no hay garantía de que recuperar un texto sin formato RSA sea tan difícil como factorizar n, ya que el conocimiento de un texto sin formato no revela la clave privada.
No hay pruebas reales de que los problemas matemáticos aparentemente difíciles sean realmente difíciles. De hecho, demostrar esto para una clase específica de problemas es uno de los mayores desafíos en el campo de la teoría de la complejidad, y mientras se escribe esto, hay una recompensa de $1,000,000 para cualquiera que pueda resolverlo, otorgado por el Clay Mathematics Institute.
pruebas relativas a otro problema matematico
En lugar de comparar un esquema de cifrado con un problema matemático, puede compararlo a otro esquema criptográfico y demuestrar que solo puede romper el segundo si puedes romper el primero. Las pruebas de seguridad para cifrados simétricos suelen seguir este enfoque. Por ejemplo, si todo lo que tiene es un solo algoritmo de permutación, entonces puede construir cifrados simétricos, generadores de bits aleatorios y otros objetos criptográficos como funciones hash mediante la combinación de llamadas a las permutaciones con varios tipos de entradas. Las pruebas muestran entonces que el nuevo esquema creado es seguros si la permutación es segura. En otras palabras, nosotros
sabemos con certeza que el algoritmo recién creado no es más débil que el original. Estas pruebas suelen funcionar creando un ataque sobre el componente más pequeño dado un ataque sobre el más grande, es decir, mostrando una reducción. Cuando demuestra que un algoritmo criptográfico no es más débil que otro, el principal beneficio es el de una superficie de ataque reducida: en lugar de analizar tanto el algoritmo central como la combinación, simplemente puede mirar el nuevo algoritmo central de cifrado. Específicamente, si escribe un cifrado que usa una nueva permutación desarrollada y una nueva combinación, puede demostrar que la combinación no debilita la seguridad en comparación con el algoritmo central. Por lo tanto, para romper la combinación, debe romper la nueva permutación,
advertencias
Los investigadores de criptografía dependen en gran medida de las pruebas de seguridad, ya sea con con respecto a los esquemas de problemas matemáticos u otros esquemas de cifrado. Pero la existencia de una prueba de seguridad no garantiza que un esquema criptográfico es perfecto, ni es una excusa para descuidar los aspectos más prácticos de la implementación. Después de todo, como dijo una vez el criptógrafo Lars Knudsen, «Si es
demostrablemente seguro, probablemente no lo sea «, lo que significa que una prueba de seguridad no debería ser tomada como garantía absoluta de seguridad. Peor aún, existen múltiples razones por las cuales un esquema «demostrablemente seguro» puede conducir a un fallo de seguridad. Un problema es la propia frase «prueba de seguridad». En matemáticas, una prueba es la demostración de una verdad absoluta, pero en cripto, una prueba es solo la demostración de una verdad relativa. Por ejemplo, una prueba de que su cifrado es tan difícil de romper como de calcular logaritmos discretos: encontrar el número x dado g y gX mod n: garantiza que si su cifrado falla, una gran cantidad de
otros cifrados también fallarán y nadie te culpará si ocurre lo peor. Otra advertencia es que las pruebas de seguridad generalmente se prueban con respeto a una sola noción de seguridad. Por ejemplo, puede probar que recuperar la clave privada de un cifrado es tan difícil como el problema de factorización. Pero si puedes recuperar textos sin formato a partir de texto cifrado sin la clave, omitiremos la prueba, y recuperar la clave apenas importa. Por otra parte, las pruebas no siempre son correctas y puede ser más fácil romper un algoritmo de lo que se pensaba originalmente.
Otra consideración importante es que los problemas matemáticos difíciles a veces resultan más fáciles de resolver de lo esperado. Por ejemplo, ciertos parámetros débiles facilitan la ruptura de RSA. O el problema matemático puede ser difícil en ciertos casos, pero no en promedio, como sucede a menudo cuando el problema de referencia es nuevo y no se comprende bien. Eso es lo que sucedió cuando el esquema de cifrado Knapsack 1978 de Merkle y Hellman fue más tarde totalmente roto en 1978 utilizando técnicas de reducción.
Finalmente, aunque la prueba de la seguridad de un algoritmo puede estar bien, la implementación del algoritmo puede ser débil. Por ejemplo, los atacantes pueden
explotar la información del canal lateral, como el consumo de energía o la ejecución
tiempo para aprender acerca de las operaciones internas de un algoritmo con el fin de romperlo, pasando así por alto la prueba. O los implementadores pueden hacer un mal uso del esquema de cifrado: si el algoritmo es demasiado complicado con demasiada configuración, es probable que el usuario o el desarrollador obtenga una configuración incorrecta, lo que puede hacer que el algoritmo sea completamente inseguro.
seguridad heuristica
La seguridad demostrable es una gran herramienta para ganar confianza en un esquema de cifrado, pero no se aplica a todo tipo de algoritmos. De hecho, la mayoría de los cifrados simétricos no tiene prueba de seguridad. Por ejemplo, todos los días confiamos en AES para comunicarse de forma segura utilizando nuestro móvil, laptops y computadoras de escritorio, pero AES no es demostrablemente seguro; no hay pruebas de que sea tan difícil de romper como un problema conocido. AES no puede estar relacionado con un problema matemático o con otro algoritmo porque es problema difícil en sí. En los casos en que no se aplique la seguridad demostrable, la única razón para confiar un cifrado se debe a que muchas personas capacitadas intentaron descifrarlo y fallaron. Esto es a veces llamado seguridad heurística.
¿Cuándo podemos estar seguros de que un cifrado es seguro? Nunca podremos ser
seguro, pero podemos estar bastante seguros de que un algoritmo no se romperá
cuando cientos de criptoanalistas experimentados han gastado cientos de horas tratando de descifrarlo y publicando sus hallazgos, generalmente al intentar ataques a versiones simplificadas de un cifrado (a menudo versiones con menos operaciones o menos rondas, que son series cortas de operaciones que cifran e iteran para mezclar bits). Al analizar un nuevo cifrado, los criptoanalistas primero intentan romper uno, luego dos, tres o tantos como puedan. El margen de seguridad es entonces la diferencia entre el número total de rondas y el número de rondas que fueron atacadas con éxito. Cuando después de años de estudio un cifrado el margen de seguridad sigue siendo alto, confiamos en que (probablemente) sea seguro.
generando claves
Si planeas encriptar algo, tendrás que generar claves, ya sea «claves de sesión» temporales (como las que se generan al navegar por un sitio HTTPS) o claves públicas a largo plazo. Recuerde que las claves secretas son el quid de la seguridad criptográfica y deben generarse aleatoriamente para que sean impredecibles y secretas. Por ejemplo, cuando navega por un sitio web HTTPS, su navegador recibe la clave pública del sitio y la utiliza para establecer una clave simétrica que solo es válida para la sesión actual, y la clave pública de ese sitio y su clave privada asociada puede ser válida por años. Por lo tanto, será mejor que sea difícil de encontrar para un atacante. Pero generar una clave secreta no siempre es tan simple como descargar suficientes bits pseudoaleatorios. Las claves criptográficas se pueden generar de una de estas tres formas:
• De forma aleatoria, utilizando un generador de números pseudoaleatorios (PRNG) y,
cuando sea necesario, un algoritmo de generación de claves
• De una contraseña, utilizando una función de derivación de clave (KDF), que transforma la contraseña proporcionada por el usuario en una clave
• A través de un protocolo de acuerdo clave, que es una serie de intercambios de mensajes
entre dos o más partes que termina con el establecimiento de una clave compartida
Por ahora, explicaremos el método más simple: generación aleatoria.
generacion de claves simetricas
Las claves simétricas son claves secretas compartidas por dos partes, y son las más simples de generar. Suelen tener la misma longitud que el nivel de seguridad que proporcionan: una clave de 128 bits proporciona seguridad de 128 bits, y cualquiera de los 2128 posibles claves es una clave válida que puede hacer el trabajo tan bien como cualquier otra clave. Para generar una clave simétrica de n bits utilizando un PRNG criptográfico, simplemente pregúntele por n bits pseudoaleatorios y use esos bits como clave. Eso es, puede, por ejemplo, usar el kit de herramientas OpenSSL para generar una clave simétrica aleatoria volcando bytes pseudoaleatorios, como en el siguiente comando
(obviamente, tu resultado será diferente al mío):
> openssl rand 16 -hex
65a4400ea649d282b855bd2e246812c6generando claves asimetricas
A diferencia de las claves simétricas, las claves asimétricas suelen ser más largas que el nivel de las claves de seguridad proporcionan. Pero ese no es el problema principal. Las claves asimétricas son más difíciles de generar que los simétricos porque no puede simplemente volcar n bits de su PRNG y ya esta. Las claves asimétricas no son solo
secuencias de bits sin procesar; en su lugar, representan un tipo específico de objeto, como un gran número con propiedades específicas (en RSA, un producto de dos primos). Es poco probable que el valor de la cadena de bits aleatoria (y por lo tanto un número aleatorio) tenga las propiedades específicas necesarias y, por lo tanto, no será una clave válida. Para generar una clave asimétrica, envía bits pseudoaleatorios como seed a un algoritmo de generación de claves. Este algoritmo de generación de claves toma como entrada un valor inicial que sea al menos tan largo como el nivel de seguridad previsto y luego construye a partir de ella una clave privada y su respectiva clave pública, asegurando que ambos satisfacen todos los criterios necesarios. Por ejemplo, una generación de claves para el algoritmo RSA generaría un número, n = pq, mediante el uso de un algoritmo para generar dos números primos aleatorios de aproximadamente la misma longitud. Ese algoritmo elegiría números aleatorios hasta que uno sea primo, por lo que también necesita un algoritmo para probar si un número es primo.
Para ahorrarse la carga de implementar manualmente el algoritmo de generación de claves, puede usar OpenSSL para generar una clave privada RSA de 4096 bits , como esta:
$ openssl genrsa 4096
Generating RSA private key, 4096 bit long modulus
……………………………………………………………………
………………………….++
………………………………………..++
e is 65537 (0x10001)
-----BEGIN RSA PRIVATE KEY-----
MIIJKQIBAAKCAgEA3Qgm6OjMy61YVstaGawk22A9LyMXhiQUU4N8F5QZXEef2Pjq
vTtAIA1hzpK2AJsv16INpNkYcTjNmechAJ0xHraftO6cp2pZFP85dvknsMfUoe8u
btKXZiYvJwpS0fQQ4tzlDtH45Gj8sMHcwFxTO3HSIx0XV0owfJTLMzZbSE3TDlN+
JdW8d9Xd5UVB+o9gUCI8tSfnOjF2dHlLNiOhlfT4w0Rf+G35USIyUJZtOQ0Dh8M+
--snip--
zO/dbYtqRkMT8Ubb/0Q1IW0q8e0WnFetzkwPzAIjwZGXT0kWJu3RYj1OXbTYDr2c
xBRVC/ujoDL6O3NaqPxkWY5HJVmkyKIE5pC04RFNyaQ8+o4APyobabPMylQq5Vo5
N5L2c4mhy1/OH8fvKBRDuvCk2oZinjdoKUo8ZA5DOa4pdvIQfR+b4/4Jjsx4
-----END RSA PRIVATE KEY-----Tenga en cuenta que la clave viene en un formato específico, es decir, codificado en base64 entre los marcadores BEGIN RSA PRIVATE KEY y END RSA PRIVATE KEY. Eso es
un formato de codificación estándar compatible con la mayoría de los sistemas, que luego convierte esta representación en bytes de datos sin procesar. Las secuencias de puntos al principio son una especie de barra de progreso, y e es 65537 (0x10001) indica el parámetro
para usar al encriptar (recuerde que RSA encripta calculando C = Pe mod n)
protegiendo las claves
Una vez que tenga una clave secreta, debe mantenerla en secreto, pero disponible cuando
lo necesita. Hay tres formas de abordar este problema.
Encapsulado de claves (cifrado de la clave con una segunda clave)
El problema con este enfoque es que la segunda clave debe estar disponible cuando necesite descifrar la clave protegida. En la práctica, esta segunda clave a menudo se genera a partir de una contraseña proporcionada por el usuario cuando necesita usar la clave protegida. Así es como las claves privadas son protegidas por el protocolo Secure Shell (SSH)
Generación sobre la marcha a partir de una contraseña
Aquí, no es necesario almacenar ningún archivo cifrado porque la clave viene directamente de fuera de la contraseña. Los sistemas modernos como miniLock utilizan este método. Aunque este método es más directo que el ajuste de claves, está menos extendido, en parte porque es más vulnerable a contraseñas débiles. Decir, por ejemplo, que un atacante captura algún mensaje cifrado: si la clave se utilizó como envoltura, el atacante primero necesita obtener el archivo de clave protegida, que generalmente se almacena localmente en el sistema de archivos del usuario y, por lo tanto, no es
fácil de acceder. Pero si se utilizó la generación sobre la marcha, el atacante puede
busque directamente la contraseña correcta intentando descifrar el mensaje encriptado con contraseñas candidatas. Y si la contraseña es débil, la clave está comprometida.
Almacenamiento de la clave en un token de hardware (tarjeta inteligente o dongle USB)
En este enfoque, la clave se almacena en una memoria segura y permanece segura
incluso si la computadora está comprometida. Este es el enfoque más seguro para la clave
almacenamiento, pero también el más costoso y menos conveniente porque requiere
debe llevar consigo el token de hardware y corre el riesgo de perderlo. Las tarjetas inteligentes y los dongles USB generalmente requieren que ingrese una contraseña
para desbloquear la llave de la memoria segura.
Para probar el ajuste de claves, ejecute el comando OpenSSL que se muestra aquí con el
argumento -aes128 para decirle a OpenSSL que cifre la clave con el cifrado AES-128
(AES con una clave de 128 bits):
$ openssl genrsa -aes128 4096
Generating RSA private key, 4096 bit long modulus
……….++
……………………………………………………………………
………………………………………..++
e is 65537 (0x10001)
Enter pass phrase:La frase de contraseña solicitada se utilizará para cifrar la clave recién creada.
cosas que pueden ir mal
La seguridad criptográfica puede fallar de muchas formas. El mayor riesgo es cuando
tenemos una falsa sensación de seguridad gracias a pruebas de seguridad o de bien estudiados protocolos, como se ilustra en los dos ejemplos siguientes.
prueba de seguridad incorrecta
Incluso las pruebas de seguridad de investigadores de renombre pueden estar equivocadas. Uno de los ejemplos más sorprendentes de una prueba que salió terriblemente mal es la de OAEP, un método de cifrado seguro que utilizó RSA y se implementó en muchas aplicaciones. Sin embargo, una incorrecta prueba de seguridad de OAEP contra atacantes de texto cifrado fue elegida como válida por siete años, hasta que un investigador encontró la falla en 2001. No solo fue la prueba incorrecta, el resultado también fue incorrecto. Una nueva prueba mostró más tarde que OAEP solo es casi seguro contra atacantes de texto cifrado elegido. Ahora tenemos que confiar en la nueva prueba y esperar que sea impecable. (Para más detalles, consulte el documento de 2001 «OAEP Reconsidered» de Victor Shoup.)
Teclas cortas para soporte heredado
En 2015, los investigadores descubrieron que algunos sitios HTTPS y servidores SSH admitían criptografía de clave pública con claves más cortas de lo esperado: a saber
512 bits en lugar de al menos 2048 bits. Recuerde, con esquemas de clave pública,
el nivel de seguridad no es igual al tamaño de la clave y, en el caso de HTTPS, las claves
de 512 bits ofrecen un nivel de seguridad de aproximadamente 60 bits. Estas llaves podrían romperse después de sólo dos semanas de cálculo utilizando un grupo de 72 procesadores. Muchos sitios web se vieron afectados, incluido el del FBI. A pesar de que
el software finalmente se solucionó (gracias a parches para OpenSSL y para otro software), el problema fue una sorpresa bastante desagradable.
mas alla
Para obtener más información sobre la seguridad demostrable para cifrados simétricos, lea la documentación de funciones de sponge (http://sponge.noekeon.org/). Las funciones de sponge introdujeron el enfoque basado en permutación en la criptografía simétrica,
que describe cómo construir un montón de funciones criptográficas diferentes usando solo una permutación. Algunas lecturas obligatorias sobre el costo real de los ataques incluyen en 2005 el artículo «Understanding Brute Force» y el artículo de Wiener de 2004 «The Full Cost of Cryptanalytic Attacks ”, ambos disponibles en línea de forma gratuita.
Para determinar el nivel de seguridad para un tamaño de clave determinado, visite http: // http://www.keylength.com /. Este sitio también ofrece una explicación sobre cómo las claves privadas están protegidos en utilidades criptográficas comunes, como SSH, OpenSSL,
GnuPG y así sucesivamente. Por último, como ejercicio, elija una aplicación (como una aplicacion de mensajería segura) e identifique sus esquemas criptográficos, la longitud de la clave y los niveles de seguridad respectivos. A menudo encontrará inconsistencias sorprendentes, como un primer esquema proporcionando un nivel de seguridad de 256 bits, pero un segundo esquema que proporciona solo 100 bits seguridad. La seguridad de todo el sistema suele ser tan fuerte como la de su componente más débil.
BlockchainLanzarote 