Sistemas de comunicación seguros

Parece que fue el otro día cuando estuve con mi gran amigo Víctor Seva (@linuxmaniac) dando una charla en la RootedCon sobre sistemas de comunicaciones seguros, y la verdad es que ya han pasado más de 4 años. El vídeo de la conferencia se puede ver aquí:

En la charla se muestra cómo podemos ver un sistema aparentemente seguro y que luego no lo es. La finalidad de este proyecto, o prueba de concepto, no era ofrecer una herramienta al usuario sino concienciarle, es decir, hacerle ver que aunque algo parezca seguro, puede no serlo. De hecho, si buscamos en el Play Store, en el Apple Store o por Internet aplicaciones para mantener comunicaciones de voz seguras, nos vamos a encontrar un montón pero, ¿qué hacen realmente? ¿podemos fiarnos de ellas? Cuando una persona tiene la necesidad de cifrar una comunicación es por algo importante (no confundir con ilegal) y no puede correr riesgos.

4 años más tarde, sí que tengo implementado un sistema para poder realizar llamadas seguras, sin que nadie pueda interceptarlas, escucharlas o grabarlas. Pero si has visto la charla, no te vas a fiar ahora de lo que te diga, ¿verdad? y por eso, antes de hablar del sistema, creo que es necesario entender una serie de conceptos. Cuando alguien tiene la necesidad de mantener una comunicación privada, no puede arriesgarse a usar una aplicación mágica sin entender realmente cómo funciona o cómo se gestionan los datos. Por tanto, creo que el primer paso antes de usar alguna herramienta es entender cómo se cifra una comunicación de voz, qué alcance tiene y cómo podemos verificar si la comunicación está o no cifrada realmente.

VoIP

Vamos a partir de la base de que todas las comunicaciones que vayamos a cifrar van a ser de VoIP, por tanto, tráfico IP que circulará por Internet. A diferencia de un sistema convencional donde se ‘pincha’ una línea física para realizar una escucha, con VoIP, al igual que cualquier otro servicio que funcione a través de redes IP, la interceptación se realiza esnifando o monitorizando datos. Por tanto, nuestros objetivos serán bastante precisos: cifrar las comunicaciones y evitar ataques MitM.

Sin entrar en demasiados detalles técnicos acerca de la VoIP y de los protocolos involucrados en este tipo de infraestructuras, para poder mantener una comunicación realizaremos 2 fases:

Fase de señalización

La misión de la señalización es permitir el intercambio de información entre los diferentes dispositivos o servidores, con la finalidad de que la llamada pueda ser establecida y terminada correctamente. En el caso de la VoIP usaremos el protocolo SIP (también pueden usarse otros, pero SIP es el más extendido). Este protocolo es muy similar al HTTP, donde usaremos una serie de mensajes o métodos para comunicarnos. Aquí podemos ver los más relevantes:

Y obtendremos unos códigos de respuesta:

Como decía, el formato de los mensajes es muy similar al HTTP, donde nos encontramos con una serie de cabeceras y el cuerpo del mensaje:

Añadido al protocolo SIP tenemos el protocolo SDP que ofrece información adicional sobre cómo se va a negociar la comunicación. El SDP se corresponde con el cuerpo del mensaje y se incluye sólo en los métodos cuyo objetivo es establecer una comunicación entre los interlocutores (en este caso es lo que aparece bajo el Content-Length). En la imagen de arriba vemos que se especifica la IP (72.12.135.250) y puerto (27252) para la comunicación RTP de audio, así como los códecs (BV32 Speech, G.729) que el dispositivo soporta. El otro dispositivo contestará con un mensaje OK, también con SDP, donde aparecerá la información de su IP y puertos para el media, así como los códec soportados. Finalmente se comunicarán usando un códec que ambos soporten o, en el peor de los casos, el servidor tendrá que hacer una trascodificación. Como ejemplo imaginemos en un lenguaje humano que una persona habla español e inglés y la otra inglés y francés. Para comunicarse usarán el inglés. Sin embargo si una habla ingles y español y la otra sólo francés, si el servidor soporta ambos idiomas, hará de traductor.

Y la forma de cifrar esta comunicación es utilizando TLS.

Fase media

Se trata de la transmisión de audio, es decir, la comunicación entre los interlocutores una vez se ha negociado cómo se va a realizar la comunicación en la fase anterior. El tráfico se enviará siguiendo el protocolo RTP (sin cifrar) o SRTP (cifrado).

Creo que hasta aquí queda más o menos claro el funcionamiento, pero vamos con las dudas y puntualizaciones:

¿Podemos cifrar una llamada a un móvil o a cualquier otro número de teléfono?

La respuesta es NO.  Para poder realizar una llamada el teléfono IP debe estar conectado a un servidor de VoIP (por ejemplo a una PBX) y si el servidor soporta SRTP, podremos mantener comunicaciones cifradas entre extensiones, es decir, entre dispositivos conectados a esa misma PBX. Pero si necesitamos hablar con un número externo, esa llamada la enrutará el servidor hacia un operador de VoIP mediante un SIP-trunk, y este lo mandará a otro operador o a un wholesale o a un carrier, pero en cualquier caso, cuando salga de nuestro servidor, el tráfico ya no estará cifrado. Por lo que no podemos tener una llamada cifrada si la cursamos a un teléfono externo a nuestro sistema.

Resumiendo, si queremos mantener una comunicación cifrada con otra persona, es primordial que ambos estemos conectados al mismo sistema y usemos un único canal cifrado. En este caso se crea un canal seguro entre nuestro teléfono y nuestro servidor pero luego se utiliza un canal inseguro entre el servidor y el destino (que además pasará por otras infraestructuras de las que no tenemos ningún control). Es decir, no podemos tener un teléfono mágico que nos cifre cualquier llamada que hagamos a cualquier parte.

¿Por qué no puedo establecer una comunicación entre dos teléfonos, sin un servidor de por medio?

La respuesta corta es … por temas de NAT. Si nosotros desde casa conectamos con una página web, nuestro router aplica NAT y la petición se realiza con la IP pública y un puerto asignado por el router. Cuando vienen los datos de vuelta, nuestro router consulta la tabla NAT y sabe a qué dirección IP:puerto privada debe enviar los datos. Por el contrario, en una comunicación con el protocolo SIP todos los datos de conexión vienen encapsulados en el paquete, por lo que el teléfono al construir ese paquete va a poner como IP origen la suya privada y cuando llegue al otro dispositivo, a pesar de que el paquete llegará bien porque el router hará su trabajo, en las cabeceras vendrá la IP privada, que será a la que tratará de responder el otro dispositivo. Y evidentemente, el mensaje de vuelta nunca va a llegar al destino.

Para el caso de la señalización, configurando rutas estáticas en el router y forzando puertos, podemos llegar a redirigir el tráfico, pero tampoco tiene mucho sentido puesto que un servidor de señalización sirve para otras muchas cosas. Por eso mediante mensajes REGISTER el dispositivo indica al servidor dónde se le puede localizar si alguien intenta contactar con él.

Otra opción sería usar SIP ALG que incorporan la mayoría de routers y lo que hace es intentar arreglar las cabeceras y cambiar las IPs locales por la pública, pero esto tiene varios incovenientes:

• Si usamos cifrado TLS el router ya no tiene acceso al contenido del paquete y, por tanto, no puede alterar los datos.
• A día de hoy no me encontrato un sólo router que aplique bien SIP ALG y más que arreglar lo que hace es estropear los paquetes.

Y con el media ocurre lo mismo. Si nosotros tuviéramos IPs públicas en nuestros teléfonos, sería posible una comunicación directa entre dos dispositivos, a pesar de que la señalización se realice a través de una PBX. Pero como nuestros dispositivos van a crear el mensaje INVITE rellenando el SDP con una IP:puerto de la red privada, cuando el otro dispositivo trate de responder, no va a llegar nunca el audio. Por eso se requiere de un servidor de relay para el media, cuya función será arreglar estos datos y enviar el tráfico al lugar correcto.

¿Es seguro el protocolo SRTP?

No soy un experto en criptografía pero teóricamente es un protocolo seguro, aunque siempre podemos ser objetivo de un ataque MitM, por lo que aunque la comunicación vaya cifrada, alguien puede interceptarla y descifrar los datos. Además, tal y como se ve en la charla, podemos usar una PBX para desviar el tráfico y generar 2 canales de datos, de forma que haya un canal cifrado entre el servidor y el primer interlocutor y otro canal cifrado entre el servidor y el segundo interlocutor, pero al ser 2 canales diferentes el servidor ve los datos en claro y puede llegar a grabar las conversaciones.

Esto es un problema  por ejemplo si usamos una aplicación que nos permite emitir llamadas cifradas, monitorizamos el tráfico y vemos que realmente va todo cifrado, pero el servidor, que no sabemos ni dónde está ni de quién es, puede estar guardando todas las conversaciones. Por eso no es muy seguro fiarse de las Apps que hay por Internet si no las conocemos bien o no tenemos una fiabilidad de que realmente es segura.

¿Cómo podemos asegurarnos de que nadie hace un MitM en nuestra comunicación?

A pesar de que el cifrado SRTP es seguro, como he comentado antes siempre tenemos la duda de si alguien está realizando un ataque MitM y, por tanto, monitorizando o grabando nuestras conversaciones. Para saber si el canal es realmente seguro podemos usar el protocolo ZRTP. Este protocolo fue diseñado por Phil Zimmermann (creador de PGP) y describe un intercambio de claves Diffie-Hellman para el protocolo SRTP.

En realidad el tráfico va a seguir siendo SRTP, pero tras establecer la comunicación, ambos dispositivos generarán una clave compartida que deberá coincidir. Para ello se eligen dos números públicos y cada interlocutor uno secreto. Tras aplicar una fórmula matemática y realizar una serie de operaciones con los números públicos y cada uno con su secreto, deberá llegarse al mismo resultado.

La verificación será visual, es decir, cada uno de los dispositivos verá en su pantalla la clave generada y que deberá ser la misma. En otro caso, estaremos sufriendo un ataque MitM.

El uso de este protocolo no influye en las configuraciones de nuestro servidor sino que es una negociación entre los dos teléfonos.

Sistema de comunicaciones seguro

Tras toda esta charla creo que podemos sacar en claro que para establecer una comunicación segura lo mejor es tener nuestro propio sistema y no tener que fiarnos de terceros, pero si hay que usar un sistema externo, deberemos:

• Asegurarnos de que se cifra la señalización usando TLS. Esto implica que tanto el servidor como los clientes soporten TLS.
• Asegurarnos de que se cifra el media usando SRTP. Esto implica que tanto el servidor como los clientes soporten SRTP.
• Asegurarnos de que sólo hay una canal y que va cifrado de extremo a extremo, sin que nadie esté en medio y que el servidor no pueda tampoco almacenar las comunicaciones. Y para ello usaremos ZRTP. Esto implica que ambos clientes soporten ZRTP.

Como posibles soluciones tenemos por ejemplo Signal (antes Red Phone) del más que conocido Moxie Marlinspike. Si echáis un vistazo al proyecto o a la descripción en el Play Store de Google, hay comentarios que te hacen pensar sobre todo esto. Me refiero a referencias al código fuente como prueba de que puedes fiarte de él y de que no se hace nada malo ni se graban las conversaciones. Y esto es debido a que, como comentaba antes, se necesita un servidor de relay para poder establecer la comunicación de audio y, evidentemente el servidor es suyo. Lo mismo que ocurre con mi proyecto. La diferencia es que Moxie ha desarrollado la App para móvil y aquí es donde tiene que convencernos de que no hay nada extraño, ya que la negociación Diffie-Hellman se realiza entre los dispositivos, en este caso desde su App, y siempre puede darse el caso de que los códigos que nos muestra por pantalla no sean los derivados de la negociación sino que hayan sido alterados. De ahí a que publique el código fuente y ponga referencias para que se pueda ver y podamos fiarnos. en cualquier caso, Moxie es de fiar, ¿no?  🙂

Para mi proyecto yo no tengo ninguna App sino que he usado Softphones gratuitos que soportan ZRTP, que no hay muchos, la verdad. Por ejemplo para Android se puede utilizar CSipSimple y para Escritorio (Linux, Mac OS X y Windows) tenemos Jitsi.

Vamos al lío

Para el proyecto he usado solamente un servidor proxy Kamailio cuya función es la de gestionar y enrutar las comuncaciones (señalización) y además usa RTPProxy como servidor media para el audio.

Los únicos datos que se piden para usar el servicio son:

• Un nombre de usuario: será nuestro identificador en el sistema y a donde habrá que llamar para hablar contigo. Por ejemplo mi usuario es ‘pepelux’ (*)
• Una dirección de correo electrónico: donde se enviarán los datos de registro

(*) En VoIP no es necesario llamar a un número de teléfono. Se llama a un usuario, por lo que en lugar de poner un nuestro número de teléfono, es posible poner cualquier nombre (esto es otra cosa que no me gusta del servicio de Moxie, que tienes que poner tu número de teléfono móvil real y te mandan un SMS para verificarlo).

Para darte de alta debes entrar en http://voip.pepelux.org/ … sí, lo sé, debería tener un certificado SSL, pero no me da la vida :'( … y rellenar los datos en New User. Te llegará un mail con la contraseña y un link de activación.

Con estos datos deberás configurar tu softphone para conectar con el sistema y poder hacer llamadas a otros usuarios que también se hayan dado de alta.

Configurando CSipSimple en nuestro Android

Si queremos usar CSipSimple podemos instalarlo desde el Play Store y seguir el asistente para crear una cuenta. Para ello seleccionaremos Expert dentro del asistente genérico. y rellenaremos los siguientes datos:

• Nombre de la cuenta: Secure Call (o lo que quereamos poner ya que es una simple descripción para identificar la cuenta)
• ID de la cuenta: TU_USER <sip:TU_USER@voip.pepelux.org>
• URI de registro: sip:TU_USER@voip.pepelux.org:5061
• Nombre de usuario:TU_USER
• Contraseña:TU_PASS
• Protocolo de transporte: TLS
• Esquema uri por defecto: sips
• Modo SRTP: Por defecto
• Modo ZRTP: Crear ZRTP

Es importante para que funcione que, en los ajustes generales de la aplicación, pinchemos en Red -> Protocolo de transporte seguro y habilitar el TLS.

Configurando Jitsi

Jitsi tienes diferentes aplicaciones como el Jitsi Meet pero la que nos interesa es la de escritorio. Tenemos versiones para Windows, Linux y Mac OS X que podemos descargar aquí: https://jitsi.org/downloads/

Las opciones de seguridad para el media vienen habilitadas por defecto pero sí que deberemos especificar que en la señalización use TLS. Para ello, una vez creada la cuenta, la editaremos y cambiaremos los parámetros de conexión activando un proxy:

Otra opción sería cargar directamente el certificado en el softphone.

Si realizamos una llamada de prueba, por ejemplo desde un Jitsi a un CSipSimple, sólo debemos marcar el nombre de usuario, en este caso llamo desde un usuario ‘oficina’ configurado en el escritorio a un usuario ‘pepelux’ configurado en un Android:

Vemos que al entrar la llamada, la señalización va por TLS, por lo que viene cifrada:

Y una vez establecida la comunicación, tras descolgar, podemos comprobar la clave generada, en este caso yfmj:

En el Jitsi realizamos la misma comprobación. Por un lado, al emitir la llamada vemos que se usa ZRTP:

Y tras descolgar, al igual que en el otro extremo, debemos ver el mismo código:

Tras la comprobación de claves (donde un usuario le dirá al otro el texto que le aparece y deberá confirmarnos que es el mismo que él tiene) podemos asegurar que la llamada queda cifrada de extremo a extremo y que no hay nadie en medio.

Sobre el servicio

Este servicio es totalmente gratuito y bueno, no deja de ser un juguete que he montado para aprender y cacharrear, aunque es totalmente funcional y seguro. Como se puede ver, no se solicita ningún tipo de información para poderlo usar por lo que eres libre de utilizarlo. Si alguien tiene interés en conocer detalles más técnicos, no tiene más que preguntarme.

Y por cierto, si algún programador de dispositivos móviles se anima en hacer una App, podemos hacer un proyecto chulo 🙂

Saludos !