Aunque a este tema se le podría llamar fundamentos de criptografía, el fin de gran parte de lo que hacemos está en su aplicación a distintos ámbitos de la profesión. En gran medida el aplicativo de estos fundamentos coge forma en los llamados protocolos seguros.Iniciamos el día con la típica y tópica clasificación de criptosistemas.:
- Clásicos vs. modernos. Recuerda que tarde o temprano todo modernillo se acaba pasando al bando de los clásicos.
- Bloque vs. flujo. ¿Cómo lo quieres?, “a lo bruto o poco a poco”
- Secreta (Simétricos) vs. Pública (Asimétricos). A la una, o las dos, ¡vendido!
Simétricos. Recuerdo el DES, con su gran clave de 56 bits, su elegancia y seguridad. También su muerte y paso al bando de los clásicos. Si, la longitud sí que importa, al menos en criptografía. Pero el hueco dejado por alguien siempre es cubierto por otros; 3DES, blowfish, IDEA (con sus 128 bits), o la estandarización del flexible Rijndael en la forma del AES (bloque de 128 bits y claves de 128, 192 y 256 bits). Estos tienen una clave más larga. Sobra decir que en los criptosistemas simétricos se cifra con una clave, y se utiliza la misma clave para el descifrado. En muchas de las cosas que hacemos vemos criptosistemas simétricos, por ejemplo.:
$ scp –c blowfish /etc/passwd psi@10.10.106.66:passwd
Es fundamental en seguridad el uso de la (s). Póntela (en el cliente), pónsela (en el servidor).
No se debe pensar en la familia de los md5, sha[2, 3], RIPE128-160 et al. como algoritmos criptográficos, son funciones resumen o hash. Otra cosa muy distinta es su directa aplicación en nuestros protocolos seguros, autenticación, etc. En muchos de nuestros linux se utiliza una función hash como sistema básico de autenticación. ¿Cómo funciona?. Si mi password de superusuario es “acnun1erasu2solocotorp3on4soruges;” (un poco largo este password!), la aplicación de la función hash a cualquier password de “cualquier longitud”, me proporcionará una huella digital. Cuando haga un proceso de autenticación, si la huella resultante del password tecleado coincide con la del usuario, la autenticación será correcta. Y por cierto, no todas las funciones hash son igual de seguras, como es de esperar (ciclo de vida de los algoritmos hash).
Sobre funciones hash tal vez la noticia más relevante en estos momentos sea la competición de algoritmos hash del NIST que, en la forma de SHA-3, nos proporcionará una nueva función para integrar en nuestros aplicativos y protocolos. En 2011 estamos llegando al final de la competición y únicamente quedan 5 funciones en concurso.
Cambiando de bando, cada entidad en un criptosistema asimétrico utiliza dos claves inversas, aunque podría disponer varias, una pública y otra privada. Se cifra con la pública y se descifra con la privada y viceversa. Si quiero enviar algo cifrado necesitaré la clave pública del intercepto o destinatario y cifraré el mensaje con su clave pública, para que dicho receptor la pueda descifrar con su privada. Nota que el nombre de las claves hace referencia a su grado de intimidad. La pública se va con cualquiera y la privada es muy reservada. Como ejemplos de asimétricos, Diffie-Hellman, RSA, DSA, ElGamal o CEE (Criptografía de Curvas Elípticas).
El primero que con la siguiente clave pública RSA de ssh obtenga la privada tendrá una MH en la asignatura. Recuerda que hay otras muchas asignaturas que estudiar y estamos en época de exámenes.
ssh-rsa AAAAB3NzaC1yc2GABAABIwAAAQEAsL2ZngJ0aPrtsrHrJmAAk52SnN0navtOBcDznwTHgyNE+QMVXCux7PlwhDO/fKaziyJJPoipLlGlxv8MGY3vg3YfKqdjoTedJOvqH5egk3D5+LDTd1xQ8UlE31IAlgsFd8tw13pt1axQ5WXSonbZfo5RKv+OrZ8AUSQHcddiuWRvSO3Er6Y2IUYV0hteX6t+NPM9D0gXxy4KBtmehY/xPkwZgaX1AwEQmc/Va0yRMDzlvHqPQSfYhS3FoD7h451FldglNqVYEvo0NkIGOfC14g6+v+tYEBwa01RVwBTFPkCaCUfr0oK+klgGISiqui7IMAXn0ZZP4CyAUj+bYbiEnQ== psi@dead
Aquí os dejo otra, pero esta de verdad
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAkyrFhgJeTOp1OpxgjYoeXv2y9NpTFepLP3HH9eZ4YMjBFiz4mCai4HecLBts6Z1MrViA/x/m7PIC4h7DLpdqi5ifrugaWBPXElD8J8U51JNrxBNB5i3nxWwXYbw/o8uVNItYwftEgxmphSHIn86hbvj3/BWZP59HtS9sFbwB4SxeMiSPuSUmPtC3DB+8/+X/62MxzFldTTV0aGvNaGsjREq3LoDDnBmWY3vfPIDsf8tLCNngdaIFmKWhW5QdEbyZJK1GH9Kb2aFI7w0iohPr4l0BWk+qIEmaM3GvNXEQ62SZ/9J5hbUmQxqS0i6JqysmZZZeeBEJGniibs8mBcjhuQ== psi@dead
También hemos hablado de cifradores de bloque, o a lo bruto, en los que se aplica una función a cada bloque a cifrar normalmente un número de ciclos. Y los cifradores de flujo, poquito a poquito, a nivel de bit o de carácter. Entre los cifradores por bloque, RC2, IDEA, blowfish, RC5, AES, RC6. Entre los cifradores de flujo, el RC4.
Pero bueno, en un planeta plagado de soluciones híbridas, en seguridad no íbamos a ser menos. La mayoría de nuestros protocolos seguros tienen el mismo comportamiento. Sistema asimétrico para intercambio de clave de sesión, y comunicaciones haciendo uso de la clave de sesión mediante un sistema simétrico. Por citar algunos, el GPG, SSH y SSL siguen este comportamiento.
En este punto hemos analizado el sistema de cifrado y descifrado utilizado en RSA y las características que le aportan una cierta fortaleza. Se estudian los teoremas y demostraciones que proporcionan una cierta fortaleza al RSA, que no se incluyen en esta entrada al estar disponibles en varias fuentes. Para más información al respecto recomiendo el capítulo 14 del “Libro Electrónico de Seguridad Informática y Criptografía” del Prof. Ramió Aguirre.
Finalmente hemos analizado el proceso de firma digital y el uso de autoridades certificadoras. De forma resumida, sobre el mensaje a firmar se aplica una función hash, que nos proporciona su huella digital. La huella digital se cifra con la clave privada del remitente. Se envía el mensaje y la huella cifrada. El receptor descifra el hash con la clave pública del emisor. Aplica la función hash al mensaje recibido, que podrá estar o no cifrado y, si el hash remitido y obtenido son iguales, podemos presuponer que todo está bien (que el mensaje es íntegro y que la identidad del remitente es la asociada a la pública utilizada). En el caso de que el mensaje esté cifrado habrá que descifrarlo, con nuestra privada si es un sistema asimétrico puro, o con la clave de sesión en el caso de híbridos. Pero, y las colisiones. En los últimos años mucho se ha escrito sobre que se haya escrito mucho de colisiones. Las colisiones existen en las funciones hash desde su aparición. Es imposible meter un elefante en un seiscientos, al menos sin trocearlo. La teoría de la información no nos engaña y, en toda función hash, por mucho que nos rompamos la cabeza, siempre existirán colisiones. Otra cosa es la posibilidad de poder encontrar colisiones en un tiempo computacional aceptable y su posible uso en romper la seguridad de nuestros sistemas. En este sentido, hemos asistido a la generación de certificados con distinta clave pública con colisión de hash, a colisiones en las elecciones USA, a colisiones en las declaraciones de la renta, a colisiones de tráfico, etc., etc. Hemos visto colisiones, y seguiremos viendo colisiones, nos guste o no.
Propuesta de ejercicio. Coge el ls de tu sistema y genera su hash md5. ¿Podrías encontrar un contenido que produzca una colisión con el ls y, por lo tanto, genere el mismo hash o huella?. ¿Podrías encontrar un binario “usable” que colisione con tu ls?.
Por otra parte, para garantizar que una clave pública pertenece a una determinada entidad, se utilizan certificados y autoridades certificadoras. En pocas palabras, un certificado tiene una cuanta información sobre la entidad o bicho a certificar, además de su correspondiente clave pública. El certificado estará firmado por una Autoridad Certificadora (una función hash aplicada sobre el certificado genera una huella digital que será cifrada con la clave privada de la Autoridad Certificadora). Obviamente, únicamente la AC dispondrá de la clave privada para poder cifrarla. Para verificar el certificado se aplica el hash al certificado y se descifra la huella mediante la clave pública de la AC. Si la huella obtenida y la descifrada son iguales, el certificado será verificado correctamente. Y, ¿dónde tengo la clave pública del la AC?. En gran parte del software que tienes instalado tienes los certificados de las AC, incluidas sus claves públicas. En tus navegadores sueles tener alguna opción de gestión de certificados, entre ellos de varias AC, que serán utilizadas en caso de tener que verificar algún certificado. ¿Y si me he creado una AC propia con la que firmar certificados?. Siempre podrás importar en los sistemas de gestión de certificados de tus clientes el certificado con la clave pública de tu AC. Entre los estándares de certificados digitales destacar el X509, utilizado en muchas de nuestras infraestructuras de PKI (Public Key Infraestructure). Para más información sobre firma digital recomiendo el capítulo 17 del “Libro Electrónico de Seguridad Informática y Criptografía” del Prof. Ramió Aguirre.
Y recuerda, a bicho que no conozcas, no le pises la cola
