Tradicionalmente hemos entendido la criptogafía como las técnicas para mantener un mensaje confidencial y que solo pueda leerlo la persona para la que está destinado. Pero hay mucho más detrás: ¿cómo nos aseguramos que realmente solo el receptor puede leer un mensaje? ¿Es posible demostrar matemáticamente que solo el receptor puede leerlo? ¿ Y cómo se asegura el receptor que el emisor es realmente quien dice ser?

Solo el primer punto trata de mantener un mensaje secreto. Además vamos a querer saber con quién estamos hablando, entre otros servicios. ¡Si estamos hablando con un malo, da igual que el mensaje esté perfectamente cifrado!

¿Contra quién queremos proteger la información? - Una persona que quiere consumir un servicio sin pagar - Una persona que quiere invadir nuestra privacidad - Un competidor que quiere acceso a nuestros documentos secretos - Una grupo financiado por un estado nación

Fondo: https://pixabay.com/photos/binding-contract-contract-secure-948442/ Uso comercial libre

El objetivo más evidente de un sistema criptográfico es alcanzar confidencialidad: no queremos que nadie pueda leer nuestras comunicaciones aparte de la persona a la que están destinadas Pero un sistema que solo ofrezca confidencialidad no es seguro casi nunca. Por ejemplo, si estamos hablando con un adversario en vez de nuestro banco, da igual que nadie más pueda leer nuestras comunicaciones. Tenemos que estar seguros de que al otro lado está realmente el banco: autenticidad En ocasiones, un adversario puede modificar un mensaje a pesar de que no sepa qué es lo que hay en él. O puede que lo realmente importante para un banco es asegurar que uno de sus clientes ordenó una trasferencia desde sus cuentas y no hacia sus cuentas. Los objetivos de un sistema criptográfico son los servicios de seguridad que ofrece El NIST es la agencia de estandarización de EEUU, y entre las cosas que estandariza también está la seguridad del gobierno de EEUU. Sus estándares son sencillos de leer e incluyen un glosario que viene muy bien para introducirse en la criptografía.

Nos centraremos en los servicios de confidencialidad, integridad y autenticación. Además, podemos conseguir no-repudio como consecuencia de juntar autenticidad e integridad. También veremos, aunque a más alto nivel, los servicios de acuerdo de claves, PRNG, partición de secretos... porque están relacionados con los primeros Otros servicios como la autorización, aunque sin duda son importantes para que un sistema sea seguro, quedan fuera de este curso por limitación de tiempo.

Aquí tenemos un ejemplo de un protocolo de comunicaciones donde el objetivo no es la confidencialidad. Estos son unos ladrones robando un coche, que se abre cuando la llave está cerca. La persona de la derecha está utilizando una antena enorme para "hacer relay" de la comunicaciones entre la llave (que se supone dentro de la casa, cerca de la pared) y el coche. Aquí el protocolo no tiene que proteger la confidencialidad del mensaje: todos sabemos que la llave envía "ABRETE". Fíjate que el protocolo tampoco está protegido con contraseñas, ni con una firma digital. Lo que se necesita en esta caso es detectar cuándo el atacante está accediendo a los mensajes y ampliando su radio de acción diseñado ¿Se te ocurre alguna manera de proteger contra esta situación?

Este es el modelo sobre el que trabajaremos: dos personas "Alice y Bob" comunicándose por un canal inseguro porque puede haber un adversario "Maloy" en medio. Alice y Bob no tienen otra forma de comunicación: no pueden confirmar una operación bancaria enviada por correo electrónico usando una clave enviada al teléfono, por ejemplo. En criptografía asumiremos que no existen estas vías alternativas de comunicación, aunque en la realidad sí existen y los utilizamos en la vida real para mejorar aún más la seguridad del sistema. Imagen: https://www.tutorialspoint.com/cryptography/images/cryptosystem.jpg

Kerckhoffs enunció sus principios en 1883. Los principios 1, 2 y 6 guiarán todo el desarrollo de la criptografía actual 1. Confidencialidad computacional (capítulo 3) 2. No basarse en seguridad por oscuridad 3. Requisito de complejidad (capítulo 4) Pero atención: la criptografía actual - En cuanto a clave, tienen que ser específicamente aleatorias y por tanto no fácilmente memorizables. - Los resultados son binarios, y por tanto no son alfanuméricos en general. Aún así y aunque no sea estrictamente necesario, la criptografía tiene como "costumbre" guardar claves codificadas en Base64, es decir, usando solo caracteres imprimibles. El principio 4 se sigue cumpliento parcialmente, aunque no sea estrictamente necesaria. - El sistema completo suele necesitar de varias personas para operar, y en particular una "tercera parte de confianza" Kerckhoffs definió sus principios para un contexto en que una persona solitaria pudiese utilizar el criptosistema fácilmente y escribir el resultado. Ahora tenemos la ayuda de ordenadores y esos principios no son ni necesarios, ni recomendables. Eso nos lleva a que: la seguridad a veces es cuestión de opinión. "Buenas prácticas". "Recomendaciones". Por ejemplo, el NIST solo emite recomendaciones. Pero son recomendaciones muy informadas.

Shanon es un gran matemático del siglo XX, que creó la teoría de la información. Le debemos la teoría detrás de la criptografía, los archivos comprimidos, la codificación digital... Su máxima se contrapone a la "seguridad por oscuridad". Es decir, la seguridad de un sistema secreto solo será segura mientras el sistema sea secreto. ¿Y si deja de serlo? ¿Y si pensamos que es seguro, pero no lo es? El paper enlazado es una estupenda introducción a los conceptos fundamentales de la criptografía y se recomienda mucho su lectura La seguridad por oscuridad es pensar que un sistema secreto es más seguro que un sistema conocido. En realidad, es muy difícil mantener un sistema en secreto. Además, la criptografía está llena de "trampas" y razonamientos no evidentes. Es muy difícil que unas pocas personas puedan diseñar un sistema realmente seguro y además mantenerlo en secreto. Eso es lo que se llama "seguridad por oscuridad", y fiar la seguridad a la oscuridad no es buena idea, como nos ha enseñado la experiencia. Un sistema no es inseguro por ser oscuro. Es simplemente oscuro. Basar tu seguridad en la oscuridad lo consideramos una mala idea porque los hackers pueden saber más que tú. No hay ningún error lógico en querer basar tu seguridad en la oscuridad. Simplemente, la experiencia nos dice que no es buena idea, y que los sistemas cuya seguridad se basa en la oscuridad caen antes. PERO que un sistema sea seguro de por sí, utilizando protocolos realmente seguros y buenas prácticas criptográficas, Y ADEMÁS lo ocultamos al mundo, es sin duda una buena idea que no perjudica. Tendrás a los adversarios entretenidos para intentar entender tu sistema, y cuando lo consigan verán que es un indescifrable AES-512. No bases tu seguridad en la oscuridad, pero añadir un poco de oscuridad siempre ayuda.

Si la clave es lo único que tiene que ser secreto, tenemos que protegerla a toda costa. En este curso no estudiaremos cómo proteger las claves, pero tened en cuenta que, al ser la pieza central de la seguridad de un sistema, es necesario que los usuarios de criptografía dispongan de algún modo de gestión segura de claves criptogrtáficas Una contraseña no es lo mismo que una clave criptográfica. Las contraseñas suelen ser mucho más inseguras que una clave (a veces no son aleatorias o están pensadas para que las pueda recordar un humano) A veces las contraseñas serán el primer paso para entrar en un sistema seguro, pero **no son buenas claves criptográficas** En muchas ocasiones un sistema se romperá no por que la criptopgrafía sea débil, sino porque incluye un paso de control con contraseña que es habitualmente la parte más débil de un protocolo.

- **Sin clave**: el emisor usa sólo el mensaje $m$ como argumento de la función criptográfica. Ejemplo: hash. - **Clave simétrica**: misma clave $k$ para cifrar y descifrar un mensaje $m$. Emisor y receptor deben tener la misma clave. Ejemplo: AES, ChaCha... - **Clave asimétrica**: claves diferentes para cifrar (pública) y descifrar (privada) un mensaje $m$. El emisor debe conoce la clave pública del receptor. Ejemplo: RSA

Aquí vemos un error provocado porque estamos usando la primitiva defectuosa. Las primitivas deben utilizarse en los contextos en que fueron diseñadas, y apoyarse entre ellas.

Ya hemos visto unas pocas primitivas. ¿Qué servicios de seguridad ofrece cada una? Lo normal será que no queramos que el sistema ofrezca un solo servicio sino varios de ellos. Es decir, juntar primitivas criptográficas. La unión de primitivas criptográficas crea un protocolo criptográfico

# Ejemplo de composición: cifrado eficiente ```sh # Generar par de claves > openssl genrsa -aes256 -out private.key 2048 > openssl rsa -in private.key -pubout -out public.key > cat public.key # Generar clave simétrica y cifrar con ella > openssl rand -hex 64 -out key.bin > openssl aes-256-cbc -a -salt -in test.mp3 -out test.aes-rsa -pass file:./key.bin # Cifrar clave simétrica con clave pública > openssl rsautl -encrypt -inkey public.key -pubin -in key.bin -out key.bin.enc # Descrifrar clave simétrica con clave privada > openssl rsautl -decrypt -inkey private.key -in key.bin.enc -out key.bin # Descifrar archivo con clave simétrica > openssl aes-256-cbc -d -a -salt -in test.aes -out test2.mp3 -pass file:./key.bin ``` <!-- Aquí vemos la manera correcta de usar la primitiva que dio error en el caso anterior: - Ciframos la información de gran tamaño con una clave simétrica - Usamos la primitiva de cifrado asimétrico para cifrar la clave simétrica, y solo ella - Enviamos a la otra parte el archivo cifrado y el cifrado de la clave simétrica - La otra parte primero descifra la clave simétrica y después con ella descifra el mensaje. - -> ## Ejemplo de composición: secuencias La sesión protege de que los mensajes (integridad de sesión): - no se pierdan - no se dupliquen - no se desordenen Las primitivas criptográficas anteriores no cumplen con estos objetivos (e.g. un atacante borrando un mensaje no tiene contramedida); puede considerarse la sesión como una primitiva criptográfica adicional --- Se puede solucionar con: - añadiendo un identificador de secuencia ${1||m_1,2||m_2,...}$ - añadiendo el hash del mensaje anterior {${1,2||hash(m_1),3||hash(m_2),...}$ <!-- Es decir, los mensajes son eslabones de una cadena, cada mensaje tiene el hash del eslabón anterior. Casi, casi, hemos definido una blockchain como bitcoin - ->