Antes que nada, no tengo ni la mínima intención de defender a Telegram, tampoco sé si sus métodos de cifrado son los mejores o no. Se trata simplemente te aclarar unos temas básicos de cifrado para el «drama» que están montando (por ejemplo) a partir del artículo original How I Hacked Telegram’s “Encryption”. (también erróneo por sensacionalista y poor ignorar de dónde está el problema, pero vaya, es cuestión de negocios, supongo).
En primer lugar, lo que ha hecho no fue hackear ningún cifrado sino usar otra debilidad del sistema operativo en algunos dispositivos para obtener acceso privilegiado (root) a todo el dispositivo. Luego, con estos privilegios pudo acceder a la memoria y ficheros de la app, algo imposible si no fuese por el bug del sistema operativo. Básicamente, no es bug de la app de Telegram, sino del sistema operativo.
Una vez que obtuvo acceso a la memoria RAM y ficheros encontró que los mensajes no están cifrados en la memoria y que la clave de cifrado de la conversación «secret» se guardan si cifrar en un fichero (privado).
Vayamos con la primer parte. El texto que introduce el usuario en la app va siempre en plano desde el «teclado» (es un software independiente) hasta la app. Es decir, es imposible evitar que exista una copia del texto plano en la memoria, siempre existirá, y siempre podrá ser detectada si se tiene acceso «root». Además, si puede «hackear» la memoria de la app, también puede hacerlo con la del teclado, y la del sistema operativo. Es absurdo, al menos con las arquitecturas modernas, pretender que la app solucione este problema.
Por otro lado, para poder almacenar la clave de cifrado (en memoria o en el fichero) otra vez cifrada hace falta una clave privada de cifrado, por lo que esta clave debe estar almacenada y luego en memoria. Por lo tanto esta clave de cifrado de la clave de cifrado está disponible por lo que se puede obtener el texto plano de la clave de cifrado. Lo escribí así para que veáis el «bucle», en pocas palabras: cifrar un texto con una clave cifrada que tiene que estar en la misma app no agrega nada de seguridad, sólo exige un poco más de tiempo para la primera vez que se intenta encontrar (donde «más tiempo» pueden ser un par de minutos, o menos).
Resumen:
- Puede ser que los tenga, pero en este caso no se detectó problemas de seguridad de la app de Telegram.
- Mucho menos es un hackeo a su método de cifrado, es sólo aprovecharse de un problema de seguridad no relacionado con la app.
- No tiene nada que ver con hackeo o debilidad el mecanismo de cifrado de Telegram. Si una app puede obtener privilegios «root» en tu móvil puede romper la seguridad de cualquier app. Estas se basan en que el sistema operativo ya brinda protección de acceso a memoria y ficheros privados. No es sólo tema de teléfonos, también de los sistemas de PCs, ¿o crees que el texto claro en ssh no pasa nunca por memoria?, ¿o que no te pueden «robar» certificados privados si no tienes los permisos correctos y el sistema operativo no los controlase?.
- Agregar una capa de cifrado en la app cuando la propia app debe poseer el texto claro de esa clave de cifrado no agrega seguridad, sólo una sensación de falsa seguridad.
- Un poco de rigor, escepticismo y opinión informada no viene nunca mal, sobre todo en temas tan complejos como cifrado y seguridad.
Ricardo Galli, de software 
Bastante correcto. He creado algún keylog para linux y se basa en eso… o acceder al device del teclado o a la memoria o algún fichero de /proc que se use para eso.
Es totalmente sensacionalista el artículo que enlazas. Habla de la supuesta debilidad de un programa cuando la debilidad se encuentra en el SO que lo ejecuta.
De todos modos, yo no veo ni Telegram ni Watsapp tan seguros desde el momento en que: (1) son código cerrado y (2) se basan en la implementación de Diffie-Hellman que lo que hace es intercambiar una clave simétrica. En realidad es bastante seguro, pero a mi lo que me joroba es que te obliga a fiarte de la empresa en cuestión que es la propia emisora tanto de la clave como del certificado. Claro que eso, hoy en día, todo el mundo lo ha asumido porque comparte su vida tranquilamente en las redes sociales y ya no pasa nada 🙂
Pero sería mucho más seguro desarrollar un método que concienciara a la gente de utilizar claves asimétricas y la empresa utilizara sistemas más abiertos.
creo que me he explicado como el culo, por escribir tan rápido.
– mensajes entre dos personas, sin intervención del servidor: vulnerables a «man in the middle»
– comunicación con mediación del servidor de Telegram: si es un sistema abierto, me he confundido con Whatsapp. Pero sigo viendo un problema en que el propio servidor de Telegram sea la autoridad certificadora. Si consigues regenerar una clave pública y distribuirla entre clientes, obtienes el control de la autenticación. Para eso, evidentemente, volvemos a que seguramente habría que tomar el control del SO. Pero ten en cuenta que no es posible verificar mediante el propio cliente, o utilizando métodos estándar, la validez de la clave pública en el contexto de una autoridad certificadora…la clave pública está….en un puto fichero de texto.
No se si me explico…
Sergio, creo que entendí lo que dices y creo que estás equivocado.
Ya te has corregido tú mismo en la parte en la que dijiste que Telegram no es código abierto… al menos la app cliente sí es código abierto.
* Supongamos que existe un método seguro de generar claves asimétricas. Si este método no es el que usa Telegram bastaría modificar el código abierto de Telegram y usar el método que sea seguro.
Hasta aquí creo que estarás de acuerdo ¿no?
* Ese método proporcionará pares de la forma (Pública, Privada).
* Cada una de las partes que se quieren comunicar, llamémoslas Alice y Bob (A y B), generará un par de ese tipo.
* Por simplificar, obviaré la parte de criptografía simétrica que pueda ir involucrada. Cuando A quiere enviar un mensaje secreto a B cifrará el mensaje usando la clave Pública de B… y no hay problema en que la empresa Telegram ni cualquier atacante sepa esa clave pública.
Nota: Aunque no hay problema en que cualquiera vea la clave pública de B podría haber problema si se hace creer a A (o a la app que tiene instalada A) que la clave de B es otra… véase apartado 2 al final.
Dicho mensaje secreto sólo lo podrá ver B con su clave privada.
Además, si el sistema está bien hecho ni siquiera alguien que coja el móvil de B podrá ver el mensaje que envió A … porque la clave privada de B fue protegida por una contraseña que sólo conoce B (la contraseña está en su cabeza)… Tampoco importa que el mensaje cifrado se guarde en el servidor de Telegram… ni, por supuesto, que alguien vea el mensaje cifrado circulando por Internet.
POSIBLES PROBLEMAS:
1. Que alguien pueda acceder 2 veces al móvil de B, o de A.
1a. KeyLogger
La primera vez el atacante conseguiría acceso root al móvil y colocaría un KeyLogger , el cual capturaría cualquier cadena de texto escrita en el móvil … y también podría hacer un log de las aplicaciones ejecutadas o que pasen a primer plano, con la fecha en la que fueron ejecutadas. La segunda vez que acceda al móvil sólo tendría que mirar los ficheros de log guardados en el móvil.
Si era el móvil de A verá los mensajes escritos por A… pero aquí hay algunos problemas… Por ejemplo, si A hiciese copiar y pegar (escribe el mensaje secreto en su ordenador, lo transfiere a su móvil como un fichero de texto y lo abre para copiar y pegar en Telegram y luego lo borra) el atacante no vería el texto secreto en el KeyLogger. Otro problema sería que A metiese el mensaje secreto en una imagen, tampoco lo vería el atacante.
Si era el móvil de B… creo que el éxito del atacante estaría más garantizado. En algún momento B tendría que escribir su contraseña de la clave Privada asimétrica. Y eso quedaría registrado en el KeyLogger
Ahora bien, para evitar esto la app de Telegram podría usar un «teclado» que no fuese el teclado estándar del Sistema Operativo: mostraría varios caracteres en la pantalla en posiciones al azar y B escribiría así su contraseña. De esta forma el KeyLogger tampoco capturaría nada… sería necesario capturar vídeo de todo lo que ocurre en el móvil de B (lo cual es muy costoso en memoria… a menos que sólo se capture cuando se ejecuta Telegram) y capturar todas las pulsaciones en pantalla.
Otra forma sería no centrarse en buscar la contraseña de B sino en intentar conseguir todos los textos que B ve por la pantalla… y, de esa forma, conseguir el mensaje secreto que envió A.
1b. Modificando la App Telegram de la víctima.
Este sería desde mi punto de vista el método con mayor garantía de éxito… pero, claro, implica hacerlo a medida para cada app que se quiera atacar, en este caso la app Telegram.
Ahora bien, creo que el éxito tampoco está garantizado al 100% porque si la víctima reinstala Telegram cada vez que quiere enviar o recibir un mensaje importante se podría salvar.
2. Que alguien suplantase al servidor de Telegram. De esa forma se podría intentar engañar a la App Telegram de A, por ejemplo, intentando colarle una clave pública de B que no sea la verdadera sino que sea una puesta por un atacante.
Esto puede ser más complejo de explicar, pero creo que el resumen sería que usando un certificado de Telegram.com se evitaría este problema. La App de Telegram haría un HTTPS a Telegram.com y sólo aceptaría la respuesta si el servidor que responde está certificado por la autoridad de certificación válida. Las autoridades de certificación cobran bastante pasta por certificar y se supone que sólo dan certificados a los auténticos dueños de un dominio… así que no sería fácil esquivar esto.
Creo que esto resuelve lo que dice Sergio… si fuese la propia app la que certificase la clave pública de B el atacante podría colar una falsa… pero, como he dicho, es una autoridad certificadora la que certifica Telegram.com y es allí en Telegram.com donde buscamos las claves públicas de los usuarios. Con un sólo certificado (el del dominio Telegram.com), podemos solucionar el problema de las claves públicas de todos los usuarios aunque sean millones.
Bueno, acabo de ver que no era Telegram.com sino Telegram.org … pero ese detalle es lo de menos ¿no?
Acido, lo que planteas no le veo mucho sentido… Básicamente la funcionalidad principal del cifrado asimétrico es transmitir un mensaje de forma segura sobre un medio inseguro sin tener que enviar la clave del mensaje.
Es decir, no afecta para nada al almacenamiento; cifrar los mensajes que mandas a B con la clave pública de B lo único que te lleva es a mandárselos a B, pero no tendría sentido almacenarlos, sería igual de efectivo borrar el mensaje ya que no te vale para nada un mensaje cifrado con la clave pública de otro que no seas tu mismo.
Además sigues teniendo el mismo problema, tienes que almacenar el par de claves por lo que si almacenas los mensajes que recibes siempre podrás utilizar tu privada para descifrar lo que recibes y cifran con tu pública.
Este es un problema de difícil solución. Profesionalmente, que me veo obligado a proteger sistemas embebidos con cifrado, creo que la «mejor» solución que se puede utilizar son procesadores criptográficos, y ojo, digo la mejor, no que sea perfecta, al final siempre terminan existiendo ataques sobre las implementaciones cuando no el hardware tiene una backdoor en el firmware, pero el conjunto de personas que van a realizar un ataque contra ese tipo de sistemas es menor y el riesgo se reduce.
Obviamente esto no es algo extendido en el mundo de los móviles y para este caso en particular no soluciona nada.
hdk,
te has inventado cosas que yo NO HE DICHO.
Yo no dije en ningún momento que A almacene el mensaje cifrado que envía a B … en todo caso hice alusión a que un servidor intermedio de Telegram sí que guarda esos mensajes. ¿Por qué guardar el mensaje cifrado para B en algún servidor? Pues creo que es evidente que un servicio asíncrono del estilo del email debe funcionar aunque el receptor no esté conectado… A envía el mensaje sin que B esté conectado ¿qué ocurre con ese mensaje? Podría almacenarse en A pero eso no funcionaría si A se desconecta, así que se almacena en Telegram.org un servicio continuamente conectado que enviará el mensaje a B cuando B se conecte.
«Además sigues teniendo el mismo problema, tienes que almacenar el par de claves »
Pero ya di una solución a ese problema… NO guardar la clave Privada descifrada sino cifrada con una contraseña que cada usuario conoce en su cabeza. Esta contraseña no se almacena en ningún móvil ni servidor, sólo en la cabeza de cada persona.
De esta forma aún con acceso root quien busque mensajes secretos en el móvil de B sólo verá mensajes cifrados con la clave pública de B, los cuales sólo se podrán ver con la Privada de B y dicha clave privada no se almacena descifrada así que sólo B con la contraseña que él sabe podrá leerlo… Ahora bien, ya dije que no es totalmente perfecto, que en el momento que B introduce su contraseña podría haber problema (ya dije una solución a eso) y también en el momento que B lee el mensaje la información estaría descifrada en la memoria (RAM, etc) del móvil de B. Si cuando B lee el mensaje lo hace con un Sistema Operativo limpio (recién instalado) y fuerte (que no pueda ser atacado en ese momento) y con una app limpia no veo forma de atacarlo. ¿tú sí? ¿ves algún problema? Nótese que esta solución NO necesita ningún procesador criptográfico (basta un móvil normal).
Resumiendo, este sería el proceso:
* A parte de un móvil nuevo (que se supone que no tiene troyanos de ningún tipo: libre de KeyLoggers, etc)
* A instala la app (Telegram)
* A comienza un mensaje dirigido a B … para lo cual la app inicia una conexión HTTPS a Telegram.org pidiendo la clave Pública de B… Cuando alguien responde diciendo ser Telegram.org se verifica que realmente es Telegram.org mediante un certificado avalado por una autoridad como Verisign …
* A termina de escribir (o copiar y pegar) el mensaje secreto que quiere transmitir a B y dicho mensaje se cifra de forma asimétrica con la clave Pública de B: AsimCifra(PuB, Secreto)
* El mensaje se envía y queda almacenado en los servidores de Telegram.org
Ningún atacante que vea ese mensaje AsimCifra(PuB, Secreto) podrá ver el Secreto, ni siquiera Telegram
* B parte de un móvil nuevo o Sistema Operativo recién instalado
* B instala la app de Telegram
* Telegram puede verificar que es el usuario B (el número de teléfono) enviándole un código aleatorio por SMS
* En alguna parte de dicha app se podría configurar el fichero de clave privada asimétrica que se usará para leer los mensajes secretos recibidos. Es decir, el fichero Simetrica(contraseña, PrB)
* La app se conecta a Telegram.org (HTTPS) pidiendo los mensajes nuevos para B y ve que hay uno de A : AsimCifra(PuB, secreto). Esto se podría guardar en un fichero Cache en el móvil de B sin ningún problema.
* La app pide la contraseña a B, que sólo la tiene B en su cabeza. Y, con ella obtiene la clave privada de B: PrB = Simetrica (contraseña, Simetrica(contraseña, PrB) ) . En este momento se confía en que la app no envía dicha clave privada a ningún sitio (está disponible el código fuente de la app así que no hay que fiarse, basta comprobar que no se hace eso). Y con dicha clave Privada se obtiene el mensaje Secreto que se mostrará a B: Secreto = AsimDescifra(PrB, AsimCifra(PuB, Secreto) )