"Los hombres son criaturas muy raras: la mitad censura lo que practica;
la otra mitad practica lo que censura;
el resto siempre dice y hace lo que debe"
[ Benjamin Franklin - Político y científico estadounidense - 1706-1790 ]


197 - Análisis del modelo de criptografía utilizado en Telegram - 23/02/2014


En este Boletín, te contamos en qué consisten los ataques KPA, CPA, CCA y realizamos un análisis al esquema de cifrado de la aplicación Telegram.

Además, publicamos el informe de cibercrimen en Argentina con detalles de las operaciones contra delitos informáticos en el país.

ISSA Argentina está organizando junto a Centro de Ciberseguridad Industrial (CCI) de España el CURSO DE CIBERSEGURIDAD INDUSTRIAL Y PROTECCIÓN DE INFRAESTRUCTURAS CRÍTICAS, que se dictará en Buenos Aires los días 12, 13 y 14 de marzo del corriente año.

Todos aquellos que se inscriban y mencionen a Segu-Info accederán a un 10% DE DESCUENTO.

1. Análisis del modelo de criptografía utilizado en Telegram
2. Informe de cibercrimen en Argentina
3. Segu-Info busca autores
4. Desafío de la semana


1. Análisis del modelo de criptografía utilizado en Telegram

Este artículo ha sido originalmente publicado por Crypto Fail y ha sido traducido en forma exclusiva para Segu-Info por Angel Gottfriedt.

Luego de la compra de Whatsapp por parte de Facebook y de su caída masiva el pasado sábado 22 de febrero, Telegram Messenger es el nuevo protagonista del mundo de la mensajería instantánea.

Telegram es una aplicación de mensajería instantánea Open Source creada en agosto en 2013 por los hermanos Pavel y Nikolai Durov, fundadores también de VKontakte, la red social más grande de Europa. Multiplataforma y con una "seguridad inquebrantable" según sus desarrolladores, ofrecen una recompensa de 200.000 dólares en Bitcoins para quien logre acceder a una conversación privada, lo cierto es que parece tener todas las armas para luchar cara a cara con WhatsApp. Pero, ¿es esto cierto? En el presente se analiza el cifrado de la aplicación, su efectividad y su eficiencia.

El concurso de criptografía lanzado por Telegram, básicamente consiste en recuperar una dirección de correo electrónico que fue cifrada con la aplicación. Esto parece ser algo bueno porque con una recompensa tan alta, se debería lograr que los investigadores comiencen a buscar bugs y vulnerabilidades en su código fuente (libre).

Lamentablemente, el concurso es inútil. Ni los usuarios, ni los desarrolladores de Telegram van a aprender algo de él. Pero Telegram va a utilizarlo para decir: "¡Hey, miren, Nadie ganó el concurso, por lo cual nuestro software es seguro!". Los usuario ingenuos lo creerán y se sentirán seguros utilizando un cifrado inseguro.

¿Por qué este concurso es inútil? Para poder entender el porqué necesitamos aprender un poco de cómo la seguridad es definida y analizada en criptografía. Esta es una buena oportunidad para explicarlo, así que eso es lo que haremos en la siguiente sección.

¿Qué significa "seguro"?

En criptografía siempre estamos razonando acerca de la "seguridad", así que necesitamos darle una definición rigurosa a la palabra "seguro". Esto se hace mediante la definición de la seguridad con respecto a las capacidades de un adversario, una persona, una aplicación o una computadora intentando romper el sistema.

Tenemos que definir cuánto poder computacional tiene el adversario, a qué datos tiene acceso, cuáles datos puede modificar, cómo pueden comunicarse con el usuario víctima, etc.

Con los años, los criptógrafos han dado nombres a varios tipos de adversarios.

Known Plaintext Attack (KPA)

Empecemos por definir al adversario como a alguien que tiene acceso a textos cifrados del sistema (información cifrada) y vamos a darle el texto plano completo para alguno textos cifrados.

En este modelo se tiene acceso a los textos cifrados y a algunos textos planos de estos, pero igualmente el adversario es incapaz de interactuar con el sistema de alguna forma.

Este parece un modelo razonable en un principio. En el caso de los sistema de comunicación cifrada, el adversario en este modelo es alguien que puede espiar ("sniff") el tráfico de la red, pero no puede cambiar o insertar su propio tráfico.

Este modelo es bastante frágil: un sistema seguro únicamente en KPA carece de varias propiedades muy importantes que nos gustaría tener en un sistema "seguro".

Imaginen un sistema que siempre cifra el mismo mensaje con el mismo "texto-cifrado" (ciphertext): si dos mensajes distintos son cifrados, sus ciphertext son distintos, pero si un mismo mensaje es cifrado dos veces, sus ciphertext son iguales. Un ejemplo sería un sistema que utiliza la misma llave para cifrar mensajes con AES en modo CBC con un vector de inicialización (IV por sus siglas en inglés) con un valor igual a cero.

Al adversario se le otorga un ciphertext y se le dice que, es el cifrado de "UNO" o de "DOS". Asumiendo que al adversario no se le otorga uno de los pares de texto plano conocido, no puede descifrar si el podría que tiene es el cifrado de "UNO" o de "DOS". Eso es bueno porque el adversario no puede romper el sistema.

Pero, ¿y si pidiéramos hacer que el sistema cifre un mensaje de nuestra elección? Como todos los mensajes son cifrados igual, podríamos enviar "UNO", obtener su ciphertext, y compararlo con el que estamos intentando descifrar. Si es igual, podemos saber que es el cifrado de "UNO" y, en caso contrario sería el de "DOS".

Esto no es solo una habilidad teórica. En la mayoría de los casos, podemos hacer que el sistema cifre un mensaje de nuestra elección. Un ejemplo real de esto es la conexión TLS entre un navegador web y google.com. Si otra pagina web, digamos bing.com, incluye una imagen de google.com en una de sus páginas, el navegador cifrara la URL de la imagen y se la enviara a google.com.

El modelo KPA no concuerda con nuestra noción intuitiva de "seguridad". Necesitamos hacer a nuestro adversario más poderoso con el fin de hacer nuestra definición de "seguridad" más fuerte.

Este es el punto clave: si le damos más poder a nuestro adversario en el modelo, esto nos da una definición de "seguridad" más fuerte (si estuviéramos construyendo un tanque, no probaríamos su armadura con disparos de armas pequeñas, le dispararemos con un RPG).

Chosen PlainText Attack (CPA)

Ya dijimos que si el adversario puede cifrar un mensaje de su elección, puede quebrar un sistema que es seguro únicamente contra KPA. ¿Qué pasaría si dejáramos que el adversario cifre mensajes aleatorios en el sistema?

Este es el modelo de Chosen Plaintext Attack (CPA): el adversario puede hacer que el sistema cifre mensajes de su elección, aunque con este poder no debería ser capaz de aprender nada acerca del ciphertext.

Este es un modelo mucho más razonable de seguridad, pero sigue sin ser lo suficientemente bueno. Un verdadero adversario puede "modificar" los ciphertext.

Supongamos que hay un sistema bancario, el cual cifra las transferencias monetarias utilizando AES en modo CTR con un "nonce" único para cada mensaje. Esto es seguro en el modelo CPA, lo cual es bueno, porque un usuario puede realizar su propia transferencia para obtener el par de texto plano deseado.

Supongamos que la orden de transacción se viera de esta forma:
"Transfer $100 from Alice to Bob"

Cifrada podría verse de esta manera:
yAOB972Fs1KTDr8Mn84LT6psaT+w3qh8F/76n9F922Y68UQ4YYs7

El cifrado (modo CTR) es maleable, por lo cual un "verdadero" adversario podría cambiar la última parte (encerrada entre asteriscos):
yAOB972Fs1KTDr8Mn84LT6psaT+w3qh8F/76n9F922Y68UQ4**XQPR**

Debido al cambio, esta serie descifrada quedaría:
"Transfer $100 from Alice to Eve"

Por lo cual, cambiando uno de los ciphertext, el adversario puede redireccionar el dinero que Alice le estaba enviando a BoB, hacia Eve. Obviamente necesitamos fortalecer más todavía nuestro modelo. Necesitamos estar seguros que, aunque el adversario pueda modificar los ciphertext, el sistema sigue siendo seguro.

Chosen Ciphertext Attack (CCA)

Esto nos lleva al último modelo de seguridad que vamos a discutir, llamado Chosen Ciphertext Attack (CCA). En este modelo al adversario también se le permite seleccionar el ciphertext y además puede llegar a ver su descifrado. El adversario puede básicamente hacer lo que quiera, excepto decirle al sistema que descifre el ciphertext que esta intentado descifrar. El adversario puede modificar mensajes en tránsito, eliminar mensajes, responder mensajes, etc.

El modelo CCA es el estándar que tenemos en los sistemas criptográficos en el día de hoy. Si alguien propone un sistema que no es seguro en el modelo CCA, este será rechazado, excepto en casos muy específicos, como cifrado de base de datos, donde se evalúa otras propiedades como el rendimiento.

El concurso de Telegram

Al pasar por los distintos modelos de ataques, quería transmitir que es muy importante cuando se razona sobre la seguridad criptográfica: si quieres demostrar que un sistema es seguro, dale al adversario el mayor poder posible y si así y todo no logra quebrarlo, su seguridad es buena. Sabiendo que el sistema es seguro en uno de los modelos débiles, como KPA, no significa que sea seguro en uno más fuerte (o realista) como CCA, (si un tanque es aprueba de balas, no significa que sea aprueba de RPG's).

Suficiente teoría de criptografía, volvamos al verdadero problema: el concurso de Telegram.

El concurso funciona de la siguiente manera:
Cada día, Paul envía un mensaje, que contiene una dirección de correo electrónico, a Nick. El concurso se gana enviando un correo a la dirección que figura en el mensaje. Se recibe una transcripción del tráfico de red que entra y sale de la cuenta de Paul. De acuerdo a la FAQ, usted puede enviar paquetes arbitrarios hacia el servidor, pero no puede interceptar o modificar la comunicación.

El problema debería estar claro: el concurso de Telegram no le da al adversario suficiente poder. El adversario no recibe textos planos, no puede seleccionar los textos planos, tampoco los ciphertext, modificar el tráfico de red o cualquiera de las cosas que cubrimos en la secciones anteriores. El concurso apenas ingresa en la categoría conocida de Known PlainText Attack (KPA).

Si nadie gana el concurso, no significa que Telegram sea seguro: significa que Telegram "puede" ser seguro dentro de las normas que plantea el concurso. Aunque, hay varios sistemas extremadamente débiles que sobreviven al estilo de concurso de Telegram, esto no significa que esos sistemas sean seguros o brinden confianza.

 

Entonces, ¿qué tan seguro es el cifrado de Telegram?

El diseño de Telegram parece descartar todas las investigaciones importantes que se realizaron en criptografía en las pasadas dos décadas. Su protocolo es descrito en este diagrama:

En el diagrama son evidentes varios problemas:

  • Se utilizan funciones SHA1, algoritmo en el que ya se han probado varias vulnerabilidades.
  • Incluyen Hash de texto plano en sus ciphertext. Esencialmente lo que están intentando realizar es: "MAC and Encrypt", lo cual no es seguro.
  • Se debería hacer "Encrypt-then-HMAC" con HMAC-SHA512
  • Usan un tipo de cifrado oscuro y desconocido al que llaman "Infinite Garble Extension".
  • Hacen algunas "cosas muy raras" como factorizar enteros de 64-bits.
  • No se autentican las llaves publicas.

Si este protocolo es seguro, es por accidente, no por diseño. Ellos afirman que "el protocolo fue diseñado por seis campeones de ACM y un PhD en matemática". Para ser sincero, el protocolo parece haber sido hecho por un amateur. El estrecho acoplamiento entre las primitivas sugiere que el diseñador no estaba familiarizado con construcciones básicas, como el cifrado en la autenticación, el cual puedes encontrar en cualquier libro de criptografía.

¿Qué debería hacer Telegram?

La criptografía de Telegram es mala, y tiene que ser rediseñada. Se que es difícil tirar a la basura todo ese trabajo, pero si quieren construir un programa confiable, es lo que necesitan hacer. Su protocolo es muy complejo para analizarlo y mucho menos para probar que es "seguro". Añadir correcciones (parches) solo lo empeoraría.

Deberían cambiarlo por un protocolo existente y analizar el utilizado por TextSecure. Un verdadero criptógrafo debería auditar su diseño (y el proceso de diseño) y estar seguros que los programadores que contrataron están calificados para escribir código criptográfico (la mayoría no lo está).

La respuesta de Telegram

Telegram respondió sobre este artículo y aquí hay un resumen de sus respuestas.

  • Telegram señala en el FAQ del concurso que el alcance de la competencia se extenderá a ataques activos si nadie gana esta etapa.
  • Telegram justifica el uso de SHA1 señalando que nunca fue quebrado en la práctica (aunque hay ataques teóricos) y que además que SHA1 es más rápido. Esta no es una buena razón para utilizar SHA1, ya que las pruebas de desempeño muestran que SHA256 es únicamente 1.5x veces más lento. El cuello de botella generalmente se encuentra en la red y no en la criptografía utilizada.
  • Telegram explica el uso de "MAC and Encrypt" en su FAQ. No dan explicación de porque utilizan su sistema en vez de utilizar el estándar "Encrypt-then-HMAC", el cual se encuentra bien explicado por los criptógrafos y ha sido probado como seguro.

La factorización de 64-bit es parte de un esquema de protección contra DoS. Presumiblemente es una "prueba de trabajo" y no forma parte del modelo de criptografía. Aunque la factorización es una mala elección como prueba de trabajo ya que es vulnerable a ataques de búsqueda en tablas. Una prueba de trabajo tipo Bitcoin hubiese sido una mejor elección.

Telegram argumenta acerca de la seguridad de sus sistema bajo KPA, CPA y CCA. Aunque sus argumentos no son convincentes, simplemente porque AES en modo IGE es seguro contra ataques conocidos de texto plano, no significa que toda la construcción lo sea, debes mirar todo el panorama.

La razón por la que Telegram creó su propio protocolo es la siguiente: "obtener confiabilidad y velocidad en las conexiones móviles lentas, cuando se trata con archivos grandes (como fotos, videos de hasta 1GB, documentos)".

En otras palabras, ellos diseñaron su modelo criptográfico para obtener confiabilidad y velocidad. Aunque no veo como "Encrypt-then-HMAC" es incompatible con la confiabilidad mencionada. Con respecto a velocidad, "Encrypt-then-HMAC-SHA1" sería más rápido y "Encrypt-then-HMAC-SHA256" no sería mucho más lento. Además, actualmente BLAKE2 es igual o más rápido que SHA1 y mucho más seguro.

¡Gracias Angel!

2. Informe de cibercrimen en Argentina


El 15 de noviembre de 2012, la Fiscalía General de la Ciudad de Buenos Aires (CABA) dictó la Resolución 501/12, a través de la cual, creó un Equipo Fiscal Especializado en Delitos y Contravenciones Informáticas, con el fin de investigar los delitos informáticos que se cometen a través de Internet y que por su complejidad en la investigación o su dificultad en individualizar a los autores, merecen un tratamiento especializado.

El objetivo del grupo es investigar delitos informáticos en los que la justicia de la CABA resulte competente y en los delitos cometidos mediante la utilización de medios informáticos.

El Equipo Especializado en Delitos Informáticos de CABA, Argentina ha publicado un extenso informe sobre la forma en que la República Argentina actúa en casos de delitos informáticos y específicamente en casos de pornografía infantil, pedofilia y daño informático.

Este informe de cibercrimen, de lectura muy recomendada, analiza cada una de las operaciones llevadas a cabo y los datos obtenidos por el grupo de trabajo.

Se puede acceder al documento completo en formato PDF desde el siguiente enlace: http://j.mp/1hHWBS0#PDF

3. Segu-Info busca autores


Segu-Info siempre está abierto a la publicación de documentos de interés desarrollados por la comunidad por lo que;

  • si te interesan la Seguridad de la Información,
  • si conoces de Legislación en Seguridad,
  • o, si la Seguridad de la Información es uno de tus temas de lectura/búsqueda preferidos...

Esta propuesta es para tí.

Segu-Info busca autores/escritores/redactores independientes que deseen compartir sus escritos/pensamientos/experiencias con la comunidad.

Para que Segu-Info siga siendo un lugar en donde la información es de todos y para todos, te invitamos a que seas parte. Si quieres compartir tus creaciones, contáctate con nosotros.

4. Desafío de la semana


Solución al desafío del Boletín anterior

Como el primer prisionero no dice nada, se deduce que ni el segundo ni el tercero tienen los dos negros, por lo que pueden tener negro y blanco, blanco y negro, o blanco y blanco, y como el segundo tampoco dice nada, se deduce que el primero tiene el blanco.

Respondieron correctamente: [email protected], [email protected], [email protected], [email protected], [email protected]

Desafío de esta semana:

Una línea ferroviaria de circunvalación (cerrada sobre si misma) tiene tres estaciones. En cada estación se encuentra un tren parado. Los trenes al arrancar puede ir hacia delante o hacia atrás.

Cuando los trenes se ponen en marcha, ¿cuál es la probabilidad de que no colisionen?

Nota: se suponen velocidades iguales de los trenes y equidistancia entre las estaciones. Caso contrario siempre hay colisión (aunque sea a largo plazo).

Con más de 24 años de experiencia compartiendo la mejor información de Seguridad

Contacto