Establecimiento de claves seguro mediante códigos sonoros en dispositivos móviles

Actas de las XIII Jornadas de Ingeniería Telemática (JITEL 2017), Valencia (España), 27-29 de Septiembre de 2017. This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) EDITORIAL UNIVERSITAT POLITÈCNICA DE VALÈNCIA Establecimiento de claves seguro mediante c´ odigos sonoros en dispositivos m´ oviles Ricardo Ruiz Tueros, Isaac Agudo Departamento de Lenguajes y Ciencias de la Computaci´ on Universidad de M´ alaga {rrt,isaac}@lcc.uma.es Resumen—El objetivo de este trabajo ha sido investigar el uso de canales sonoros para el intercambio de claves en tel´ efonos inteligentes. Para ello, se ha realizado un dise˜ no y un an´ alisis del problema a resolver, teniendo en cuenta factores como la necesidad de sincronizaci´ on, los par´ ametros de escucha, la longitud de la clave que podemos obtener, los ataques a los que ser´ ıa vulnerable el protocolo, la necesidad de cierta persistencia a nivel local, el uso de la nube, etc. Se ha realizado un an´ alisis de tecnolog´ ıas relacionadas, eligiendo aquellas que mejor se adaptan a los requisitos del problema y se ha implementado un prototipo capaz de realizar un intercambio de claves y autenticar mutuamente a un par de dispositivos, creando as´ ı un canal seguro a trav´ es del cual puedan comunicarse en el futuro, sin necesidad de que una tercera parte confiable que certifique la identidad de las partes. Palabras Clave—Autenticaci´ on, Seguridad, Sonido , Intercambio de claves, iOS, Nube I. INTRODUCCI ´ ON La motivaci´ on inicial detr´ as de este trabajo es la implementaci´ on de una aplicaci´ on para tel´ efonos inteligentes que permita establecer una clave compartida entre dos dispositivos de forma que los respectivos usuarios tengan un control total sobre el proceso. Para ello se han analizado diferentes aproximaciones al problema y se ha implementado un prototipo que resuelve el problema usando canales sonoros. Existe una gran variedad de protocolos de intercambio de claves [1] en la literatura, si bien uno de lo m´ as conocidos y usados en la actualidad, por ejemplo en los protocolos TLS e IPSEC, es Diffie Hellman (DH) [2]. Uno de los requisitos para que DH funcione correctamente es que los usuarios implicados en el protocolo tengan la certeza de que han calculado la misma clave compartida, para de esa forma evitar un ataque de Man-in-the-middle (MitM). Una posible soluci´ on al problema se basa en la autenticaci´ on de las claves p´ ublicas DH, tal y como ocurre en TLS cuando se utiliza el intercambio de claves basado en DH. Esto requiere de una tercera parte confiable (Autoridad Certificadora) que certifique la identidad de las partes, mediante un certificado de clave p´ ublica, y del establecimiento de relaciones de confianza que pueden ser complejas de administrar. Nuestra propuesta se basa en la utilizaci´ on de un canal ”fuera de banda” , que nos permita realizar la autenticaci´ on de los dispositivos sin necesidad usar claves autenticadas. Esto se engloba dentro de las t´ ecnicas de ”Key Fingerprint Verification” usando canales fuera de banda [3]. Nuestro objetivo final no es saber quien es la otra persona, sino tener la certeza de que cuando queramos enviar algo a un dispositivo que ya hemos enlazado previamente, solo ese dispositivo ser´ a capaz de leerlo. Por tanto, se cuenta con una primera fase donde la autenticaci´ on en el intercambio de claves est´ a fundamentada solo en la proximidad y la capacidad que tienen los usuarios de observar el intercambio de informaci´ on, y una segunda fase de comunicaci´ on donde la autenticaci´ on de basa en la clave negociada en la primera fase. Si bien inicialmente se valoraron diferentes protocolos inal´ ambricos para comunicaciones de corto alcance (Bluetooh, NFC, etc. ) como canal fuera de banda, se descart´ o esta aproximaci´ on debido a dos factores principales: •El uso de antenas de gran tama˜ no y/o potencia puede ampliar el rango de comunicaciones, de forma que el sentido de proximidad se pierda. •Los usuarios no tienen una constancia directa de cuando se est´ an comunicando los dispositivos ni pueden identificar visualmente que dispositivos son los que se est´ an emparejando. Esto ´ ultimo es un problema reconocido en los sistema de pago sin contacto[4]. Existen diversas t´ ecnicas para el emparejamiento de dispositivos m´ oviles que no recurren al uso de tecnolog´ ıas de radio frecuencia. Un ejemplo ser´ ıa el uso del canal h´ aptico (vibraci´ on) [5], es decir, las vibraciones del tel´ efono. Una de las ventajas o limitaciones, seg´ un los requisitos que se tengan en cuenta, de este canal es que solo funciona entre un par de dispositivos y adem´ as, estos tienen que estar ISBN: 978-84-9048-595-8 DOI: http://dx.doi.org/10.4995/JITEL2017.2017.6562 79 Ruiz Tueros, Agudo, 2017. en contacto. Esto podr´ ıa ser bueno porque evitar´ ıa ataques de intermediarios pero puede resultar intrusivo al requerir que se coloquen los dos dispositivos en contacto. Como alternativa se busc´ o un canal de comunicaci´ on a´ un m´ as b´ asico, las personas intercambian secretos mediante susurros, esto es, en definitiva sonido... ¿Y si un dispositivo pudiera ”susurrar” un secreto a otro?. El canal sonoro cumple las condiciones que necesitamos: Es un canal de dispersi´ on entre esos dos dispositivos que puede ser controlado sencillamente, mediante el volumen, y que es percibido por los usuarios de forma directa. Es independiente de la plataforma y f´ acilmente accesible desde cualquier sistema operativo y hardware, ya que el sonido sigue siendo el mismo (o al menos tan s´ olo ligeramente distinto), sumado a que hoy en d´ ıa casi cualquier dispositivo digital incorpora un micr´ ofono y un altavoz lo hacen el canal fuera de banda ideal para nuestro esquema. Los canales sonoros tambi´ en se han utilizado con otros prop´ ositos. Por ejemplo, [6] utiliza el sonido ambiente recibido por dos dispositivos m´ oviles como segundo factor en la autenticaci´ on, si el sonido ambiente grabado por los dos dispositivos es el mismo, podemos asumir que se encuentran en la misma localizaci´ on. Si la calidad del sonido ambiente no es buena, se podr´ ıan utilizar dispositivos externos que emitan un patr´ on predecible para los dispositivos cuya escucha garantice que ambos se encuentran en la misma localizaci´ on. El problema de esta aproximaci´ on es que requiere del despliegue de un sistema de ”balizas” que emitan este tipo de se˜ nales. II. TECNOLOG´ IAS RELACIONADAS A continuaci´ on se analizan algunas tecnolog´ ıas relacionadas con el trabajo realizado. Signal360 1(Anteriormente SonicNotify) es una tecnolog´ ıa propietaria en la que participa Oracle, permite que el dispositivo reciba notificaciones con informaci´ on por ultrasonidos, se orienta a la obtenci´ on de informaci´ on adicional de un evento concreto, por ejemplo, los grupos que est´ a actuando en un festival de m´ usica o para fines de marketing y publicidad, sorteos en eventos, compartici´ on de im´ agenes mediante redes sociales, etc... Desgraciadamente al ser una soluci´ on propietaria no cuenta con un SDK (Software Development Kit) o librer´ ıas de car´ acter p´ ublico. Audio Modem 2ha sido desarrollada por la empresa francesa Appdilium, en su p´ agina se analizan las distintas frecuencias que podr´ ıan ser utilizadas y razona la utilizaci´ on de un rango de frecuencias de 18.4kHz20.8kHz (ultrasonidos). Adem´ as, utilizan su propia implementaci´ on para la modulaci´ on de onda, siguiendo el algoritmo DBPSK [7] que permite hacer m´ as robusto el canal gracias a la redundancia de datos, as´ ı como facilitar la demodulaci´ on con un oyente de tipo no coherente. En la actualidad las tecnolog´ ıas basadas en ultrasonidos son el objetivo de grandes empresas, prueba de ello es la publicaci´ on de la API Nearby de Google para Android 1http://newatlas.com/sonicnotify-audio-signals/21385/ 2https://applidium.com/en/news/data transfer through sound/ e iOS 3que combina Bluetooth, Bluetooth Low Energy, WiFi y ultrasonidos para intercambiar c´ odigos de emparejamiento entre dispositivos. Al utilizar ultrasonidos, los usuarios no pueden identificar a los dispositivos que participan en el emparejamiento. De hecho, recientemente, investigadores de la Universidad de Brunswick han descubierto aplicaciones Android en Google Play Store que hacen uso de t´ ecnicas de ultrasonidos en anuncios, para poder relacionar cuales son los dispositivos del usuario con objeto de realizar campa˜ nas de marketing dirigido sin el conocimiento del usuario, es lo que se conoce como ”ultrasound CrossDevice Tracking (uXDT)” [8]. Todo esto nos lleva a buscar tecnolog´ ıas audibles de forma que los usuarios sean conscientes de los intercambios realizados. Para el desarrollo del prototipo se recurri´ o a “Chirp” (ver secci´ on IV) que tiene como finalidad el intercambio de contenido multimedia entre dos o m´ as dispositivos cercanos mediante sonidos similares a los m´ odem anal´ ogicos. En realidad lo que se env´ ıa a trav´ es del sonido es un enlace al archivo, que ha sido alojado en su servidor desde el dispositivo, al recibirlo el otro usuario lo descarga en su aplicaci´ on y lo visualiza casi de forma instant´ anea. Chirp incluye un SDK tanto en Android como en iOS as´ ı como en plataformas web. Chirp permite el uso de la SDK durante un periodo de tiempo limitado de forma gratuita a los desarrolladores que lo soliciten. Este fue uno de los puntos que decant´ o la elecci´ on de esta tecnolog´ ıa. III. SOLUCIONES PROPUESTAS En el desarrollo de nuestro prototipo hemos asumido que el atacante no tiene acceso de forma simultanea a los dos canales de comunicaci´ on que utilizamos: el canal sonoro implementado usando la SDK de Chirp y un canal a trav´ es de Internet implementado usando Firebase (ver secci´ on IV). Con respecto al canal de comunicaciones a trav´ es de Internet asumimos que todos los usuarios tienen un ID temporal diferente ´ unico, por lo que el atacante no puede apoderarse de la sesi´ on de un usuario existe, aunque si puede leer los mensajes de todos los usuarios y enviar mensajes con su propio ID a cualquier usuario del sistema. Tambi´ en puede conseguir nuevos IDs simplemente estableciendo una nueva conexi´ on. Con respecto al canal sonoro o canal fuera de banda, asumimos que el atacante no puede enviar ning´ un c´ odigo sonoro, ya que en ese caso, el usuario receptor podr´ ıa identificar que la fuente del sonido no se corresponde con el dispositivo del otro usuario y abortar el emparejamiento. Estamos por tanto ante un atacante pasivo en el canal fuera de banda, que si podr´ ıa enviar tr´ afico en el canal de comunicaciones pero no puede secuestrar sesiones existentes. Durante el desarrollo del prototipo se han tenido en cuenta diferentes dise˜ nos para el protocolo, en funci´ on de las capacidades del atacante. Tambi´ en se ha tenido en cuenta una limitaci´ on de Chirp en cuanto al env´ ıo de informaci´ on, que no puede superar los 50 bits4. 3https://developers.google.com/nearby/ 4http://developers.chirp.io/docs/online-and-offline-operation This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) EDITORIAL UNIVERSITAT POLITÈCNICA DE VALÈNCIA 80 Preparaci´ on art´ ıculos XIII Jornadas de Ingenier´ ıa Telem´ atica La primera aproximaci´ on (Figura 1) consiste en el env´ ıo directo de la clave mediante un c´ odigo sonoro. Esta opci´ on es la m´ as simple de implementar pero presenta el problema de que un usuario que se encuentre en la misma zona de influencia puede tener acceso a la clave e interceptar todas las comunicaciones, por tanto solo ser´ ıa segura antes atacantes sin acceso al canal fuera de banda. AB Chirp (P) P = 50 bits shortcode Fig. 1. Primera iteraci´ on del protocolo Tambi´ en se podr´ ıa impersonar al segundo usuario frente al primero en el canal de comunicaciones al disponer de la clave de comunicaciones. Por tanto solo es recomendable en escenarios donde solo los dos dispositivos tengan acceso al canal sonoro. Por ejemplo, en entornos con mucho ruido de fondo, ajustando el nivel de volumen, la distorsi´ on del ruido har´ ıa que un dispositivo que estuviera fuera del rango visual de los usuarios no fuera capaz de recibir correctamente la clave P. Sin embargo, en entornos sin ruido, y con un volumen suficientemente alto, el atacante podr´ ıa ser capaz de capturar la clave sin ser visto. Otro problema es que la clave al tener solo 50 bits como m´ aximo tiene una entrop´ ıa limitada. La primera idea que podr´ ıamos plantear para mejorar la situaci´ on ser´ ıa usar un protocolo DH donde cada usuario enviara su clave p´ ublica usando el canal fuera de banda, desgraciadamente el limite de dicho canal hace que esta aproximaci´ on sea insegura. Por tanto, se defini´ o una segunda aproximaci´ on (Figura 2) que intenta resolver esos problemas, implementando el protocolo Diffie Hellman dentro del canal de comunicaciones con una verificaci´ on de la clave intercambiada usando el canal fuera de banda. AB Genera XA < max (P, G) Genera XB < max (P, G) YA = GXA (mod P) YB = GXB (mod P) Firebase (IDA, P, G,YA) Firebase (IDB, YB) K = YBXA (mod P) K = YAXB (mod P) Chirp (IDB) Chirp (H (IDA, IDB, P, G, YA,YB)_0_50) Chirp (H (IDA, IDB, P, G,YA,YB)_50_100) Fig. 2. Segunda iteraci´ on del protocolo En concreto, se realiza la autenticaci´ on mediante c´ odigos sonoros de las identidades de los usuarios en canal de comunicaciones, as´ ı como de las claves p´ ublicas y par´ ametros del protocolo Diffie Hellman. Para ello se comparte el hash de todos los elementos mencionados anteriormente por el canal fuera de banda, aunque debido a la limitaci´ on de 50 bits, se divide el c´ odigo de verificaci´ on en dos partes, teniendo que enviar cada usuario una de las dos partes para que el otro la verifique. En este protocolo un atacante no podr´ ıa impersonar a ninguno de los usuarios leg´ ıtimos, ya que aunque intercepte el ID del primer usuario no podr´ ıa utilizarlo dentro del canal de comunicaciones con lo que sus mensajes ser´ ıa descartados por el segundo usuario. Tampoco podr´ ıa impersonar al segundo usuario porque no ser´ ıa capaz de enviar el c´ odigo de autenticaci´ on de vuelta usando el canal fuera de banda. Aunque este esquema es m´ as seguro que el anterior, el principal problema que presenta es que se necesita enviar al menos tres mensajes con c´ odigos sonoros, uno para iniciar la comunicaci´ on con el ID y dos m´ as para la autenticaci´ on con el HMAC, lo cual introduce problemas de sincron´ ıa entre ambos canales y adem´ as resulta poco pr´ actico debido al tiempo que tardan en enviarse los mensajes por el canal fuera de banda. Se podr´ ıa reducir el env´ ıo de mensajes a dos, solo para la verificaci´ on de la clave, pero en ese caso habr´ ıa que acompa˜ nar a las claves p´ ublicas de ambos usuarios de alguna informaci´ on que le permitiera relacionar ambos mensajes. Una forma de calcular un identificador ´ unico compartido entre ambos ser´ ıa usar una funci´ on HASH sobre los dos par´ ametros siguientes: 1) Hora actual: En horas y minutos, de esta forma sabemos que la sincronizaci´ on se est´ a llevando a cabo en un instante de tiempo determinado. Esto tambi´ en permitir´ ıa evitar ”Replay Attacks” [9]. 2) Redes WiFi disponibles: Podemos comprobar que ambos dispositivos se encuentran pr´ oximos si detectan las mismas redes WiFi. Para ello utilizamos el SSID de las redes con mayor se˜ nal. De esta forma podemos tambi´ en mitigar los conocidos como ”Wormhole Attacks” [10] en redes ad-hoc. Enviado las claves p´ ublicas en difusi´ on, acompa˜ nadas de este identificador, por el canal de comunicaciones, cada usuario podr´ ıa identificar la clave p´ ublica de la otra parte y completar el intercambio de claves. Si queremos implementar un prototipo con un solo mensaje por el canal fuera de banda, siempre ser´ a posible que el receptor de ese mensaje sea impersonado por un atacante que se encuentre pr´ oximo a ambos usuarios. Es decir, el iniciador nunca podr´ a tener la certeza que el dispositivo que est´ a viendo es el que responde a trav´ es del canal de comunicaciones. Lo m´ as que se puede hacer en ese escenario es una validaci´ on mutua a posteriori de la identidad de ambos usuarios, usando otro canal fuera de banda como puede ser el visual. Una opci´ on es enviar informaci´ on personal de cada usuario, como el nombre o alguna foto, que permita a cada usuario reconocerla en el dispositivo de la otra parte. A´ un as´ ı, un atacante que tenga acceso, aunque solo sea de escucha, a ambos canales de This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) EDITORIAL UNIVERSITAT POLITÈCNICA DE VALÈNCIA 81 Ruiz Tueros, Agudo, 2017. forma simultanea ser´ ıa capaz de leer todos los mensajes. Bajo al asunci´ on de que el atacante no puede observar el canal de fuera de banda, se puede mantener la misma usabilidad de la primera versi´ on, pero usando una clave de mayor calidad. Para ello se defini´ o una tercera aproximaci´ on (Figura 3) que hace uso de la funci´ on PBKDF2 [11] (Password Based Key Derivation Function) para a partir de la clave de 50 bits enviada por el canal fuera de banda generar una clave de mayor extensi´ on, usando como ”salt” la hora y las redes wifi disponibles. Firebase (IDB, IDA, EK(UB, IMGB, NameB) ) AB Chirp (P) S = (Hora, SSID, Sensores…) S = (Hora, SSID, Sensores…) K = PBKDF2 (P, S, 4096, 128) K = PBKDF2 (P, S, 4096, 128) Firebase (IDA, IDB, EK(UA, IMGA, NameA) ) Firebase (IDB, IDA, ACK) Firebase (IDA, IDB, HMAC (P, S)) Confirma hash, luego P es correcta P = 50 bits shortcode Fig. 3. Tercera iteraci´ on del protocolo Una vez calculada la clave por ambos dispositivos se procede a enviar la informaci´ on privada del usuario (nombre e imagen) cifradas, as´ ı como un c´ odigo HMAC que servir´ a para autenticar al receptor y confirmar que la clave se ha calculado correctamente. Si el c´ odigo HMAC es correcto se procede a a˜ nadir la informaci´ on transmitida como un nuevo contacto y establecer una ID para el canal de comunicaci´ on con el mismo. En caso contrario la informaci´ on se descarta y no se responde con la informaci´ on propia al mensaje recibido. La informaci´ on de los contactos a˜ nadidos se almacena de forma local en la aplicaci´ on y no es accesible por el servidor, por otra parte las IDs de los usuarios se generan aleatoriamente en cada comunicaci´ on, por lo que se almacenan las ID utilizadas por el emisor y el receptor en la sincronizaci´ on y se emplean (en un orden determinado) para establecer la ID del canal de comunicaci´ on entre ellos. El objetivo de esta sincronizaci´ on es que ´ unicamente se env´ ıen al servidor dos tipos de informaci´ on: IDs aleatorias de comunicaci´ on y mensajes cifrados. De esta forma, aunque alguien pudiera atacar y observar la informaci´ on del servidor no podr´ ıa conocer el contenido de los mensajes enviados, ni siquiera podr´ ıa identificar usuarios concretos, ya que en cada canal de comunicaci´ on utilizan ID distintos, garantizamos as´ ı no solo la confidencialidad de los mensajes sino tambi´ en la privacidad de los usuarios. En la Tabla I se puede ver un resumen comparativo de los tres esquemas que se han mencionado. Tabla I COMPARATIVA DE LOS DISTINTOS PROTOCOLOS PLANTEADOS Protocolo Bits de clave Mensajes Resiste ambos canales Claro 50 1 No DH > 50 3 Si P BKDF 2 50 + salt 1N o IV. TECNOLOG´ IAS UTILIZADAS La plataforma sobre la que se desarrolla el prototipo es iOS, esto se debe principalmente a que la primera tecnolog´ ıa que tratamos de utilizar fue Audio Modem que trabaja sobre iOS, aunque posteriormente se opt´ o por Chirp pensando en la portabilidad de la aplicaci´ on a otros sistemas operativos. A. Chirp Tal y como se ha adelantado, Chirp5es una tecnolog´ ıa que permite la comunicaci´ on de informaci´ on entre dispositivos utilizando el canal sonoro. Para ello emplean una asociaci´ on un´ ıvoca entre un byte y una determinada frecuencia, de forma que el car´ acter ’a’ podr´ ıa, por ejemplo, tener asociada la frecuencia de 500Hz, el car´ acter ’b’ la de 510Hz sucesivamente. Distinguen dos tipos de mensajes en su SDK: 1) Shortcodes: Son mensajes de un m´ aximo de 50 bits, enviados en forma de 10 caracteres que no pasan por el servidor de Chirp y que se env´ ıan a trav´ es del canal sonoro de un dispositivo a otro siguiendo la codificaci´ on en frecuencias anteriormente explicadas. 2) Mensajes de diccionario: Son estructuras de datos m´ as complejas que se env´ ıan con una clave, esta clave es, precisamente, un ”shortcode” de los anteriormente mencionados. Estos mensajes con diccionario son, en ´ ultima instancia, una clave de 10 caracteres que identifica un mensaje en formato JSON con la informaci´ on estructurada. Los mensajes con diccionario, a diferencia de los ”shortcode”, s´ ı necesitan subirse al servidor de Chirp. En su funcionamiento, el usuario final recibe mediante el canal sonoro un ”shortcode” que utiliza como ”token” frente al servidor de Chirp para obtener la estructura de datos en formato JSON. Adem´ as, la SDK de Chirp tambi´ en permite entre otras cosas la visualizaci´ on en tiempo real de la onda sonora captada por el micr´ ofono. B. Firebase Firebase6es una tecnolog´ ıa relativamente nueva, que comenz´ o como un proyecto independiente y ha sido comprada por Google. Aunque ahora ha integrado muchos servicios con Google podemos definir Firebase en su origen como una ”Base de datos NoSQL online basada en JSON”. En la actualidad incorpora gran cantidad de servicios adicionales en colaboraci´ on con Google como 5Chirp: http://chirp.io 6Firebase: https://firebase.google.com/ This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) EDITORIAL UNIVERSITAT POLITÈCNICA DE VALÈNCIA 82 Preparaci´ on art´ ıculos XIII Jornadas de Ingenier´ ıa Telem´ atica Analytics, Autenticaci´ on, Almacenamiento de ficheros, Hosting, Monetizaci´ on de aplicaciones mediante Google Admob. Dentro de Firebase la informaci´ on se estructura en subramas en forma de arbol, con un nodo inicial: nuestro identificador de Firebase. Esto permite definir f´ acilmente ciertas pol´ ıticas de control de acceso, por ejemplo, dando acceso a un elemento se concede acceso a todos los elementos de la rama. C. CyptoSwift CryptoSwift7, tal y como su nombre sugiere, es una librer´ ıa criptogr´ afica en el lenguaje de programaci´ on Swift (utilizado conjuntamente con Objective-C a lo largo del desarrollo del proyecto iOS). Se trata de un proyecto de c´ odigo abierto en Github que incluye las operaciones b´ asicas de criptograf´ ıa que se utilizan actualmente, entre ellas: Funciones hash (MD5, SHA1.. 512), CRC, Algoritmos de cifrado (AES128..256, ChaCha20, Rabbit), C´ odigos de autenticaci´ on HMAC (MD5, SHA1..256, Poly1305), Modos de operaci´ on en bloque (ECB, CBC, CTR...), Funciones de derivaci´ on de claves (PBKDF 1 y 2) y Esquemas de relleno (PKCS5/PKCS7). Para las aislar las operaciones criptogr´ aficas del control de la aplicaci´ on hemos creado un interfaz en una clase llamada ”CustomCrypto” que contiene los m´ etodos necesarios para realizar todas las operaciones criptogr´ aficas con CryptoSwift ofreciendo el resultado esperado al control de la aplicaci´ on. D. JSQMessages Por ´ ultimo, JSQMessages8es otro proyecto ”open source” que conforma una librer´ ıa de gr´ aficos y control para crear de forma sencilla los elementos b´ asicos y con un dise˜ no estandarizado de una ventana de chat en iOS. Entre los elementos se incluyen diferentes burbujas con mensajes: texto, contenedoras de v´ ıdeos o im´ agenes, localizaci´ on geogr´ afica. Todo a nivel de interfaz de usuario. Dado que se trata de una librer´ ıa compleja y la elaboraci´ on de un chat es s´ olo una excusa para poner de manifiesto la soluci´ on te´ orica propuesta hemos hecho un uso reducido de esta librer´ ıa limit´ andonos a la creaci´ on de ventanas de chat, burbujas de mensajes e indicadores de “escribiendo...”. V. NUESTRO PROTOTIPO: CHATCHAT Como aplicaci´ on prototipo para la utilizaci´ on del canal sonoro con Chirp e implementaci´ on del protocolo propuesto hemos elaborado una aplicaci´ on de chat para dispositivos iOS, que hemos denominado ChatChat. En la pantalla principal (Figura 4) podemos apreciar tres botones: 1) General: Chat general compartido por todos los usuarios de ChatChat. No tiene cifrado. 7CryptoSwift: https://github.com/krzyzanowskim/CryptoSwift 8https://github.com/jessesquires/JSQMessagesViewController/tree/master 2) Profile (Perfil): Permite editar nuestro perfil, nombre de usuario e imagen. 3) Contacts (Contactos): Permite establecer un chat con un usuario sincronizado o sincronizar la informaci´ on de dos usuarios, poniendo en pr´ actica nuestro protocolo La ventana de chat general (Figura 5) muestra en burbujas los mensajes enviados al ”Chat General” de Firebase. En este chat general pueden enviar mensajes todos los usuarios, usando un nuevo ID cada vez que entremos. Estos mensajes “an´ onimos” se almacenar´ an en Firebase en claro y ser´ an visibles para el resto de usuarios de la sala. N´ otese que si salimos y volvemos a entrar en el chat general Firebase nos asigna un nuevo ID aleatorio, por lo que no hay forma de identificar los mensajes pertenecientes a un mismo dispositivo o usuario. Fig. 4. Men´ u principal Fig. 5. Pantalla de chat En la ventana de perfil (Figura 6) podemos editar la informaci´ on de usuario: nuestro nombre y nuestra imagen. Esta informaci´ on se almacena en un fichero local y es persistente aunque cerremos la aplicaci´ on. ´ Esta es tambi´ en la informaci´ on que se env´ ıa al otro dispositivo despu´ es de un intercambio correcto y es la que deben usar los usuarios para verificar que no hay un impostor. Si en el men´ u principal pulsamos sobre el bot´ on ”Contacts” iremos a la ventana de contactos existentes y sincronizaci´ on de los mismos (Figura 7). En la parte central encontramos un bot´ on ”Add New” que al pulsarlo pondr´ a en marcha nuestro protocolo de sincronizaci´ on, generando el ”shortkey” de chirp para reproducirlo a trav´ es del altavoz del dispositivo, calculando la clave con PBKDF (fecha + WiFi) y enviando los mensajes correspondientes a trav´ es de Firebase. En esta ventana y sin haber pulsado el bot´ on nos encontrar´ ıamos en la situaci´ on de receptor de la sincronizaci´ on (inicialmente ambos), estando suscrito a una rama de mensajes de Firebase que se utiliza en exclusiva para gestionar las sincronizaciones. En la parte inferior de la pantalla, de un color azul m´ as claro, hemos incluido la visualizaci´ on en tiempo real de la captaci´ on de sonido del micr´ ofono. Despu´ es de un intercambio exitoso en ambos disposThis work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) EDITORIAL UNIVERSITAT POLITÈCNICA DE VALÈNCIA 83 Ruiz Tueros, Agudo, 2017. Fig. 6. Pantalla de perfil. Fig. 7. Pantalla de contactos. itivos se agregar´ a el dispositivo opuesto como contacto. El n´ umero inferior al nombre de usuario es la ID del canal (construida a partir de la ID de ambos contactos en la sincronizaci´ on) que ser´ a la rama en Firebase en la que ambos realizar´ an la comunicaci´ on. Si tocamos la imagen del contacto agregado podemos acceder a tener una conversaci´ on con ´ el en una ventana de chat similar a la del canal general. Distinguimos en nuestro esquema de Firebase (Figura 8) dos grandes ramas: 1) Contact Sync: Es la rama en la que se env´ ıan los mensajes de sincronizaci´ on. Tiene dos subramas: Receiver y Sender, en funci´ on de qui´ en haya iniciado la sincronizaci´ on con Chirp y quien haya recibido el mensaje sonoro. Se env´ ıa la informaci´ on de usuario cifrada, el HMAC y el ID aleatorio 2) Messages: Es la rama dedicada al env´ ıo de mensajes, distinguimos una rama General en la que podemos observar que se env´ ıan los mensajes en claro (texto ”Hola” y ”Que tal” ) y una rama con un ID de canal coincidente con el ID que aparec´ ıa debajo del nombre del contacto agregado constituido por el ID aleatorio que ambos ten´ ıan. En esta subrama (canal de contactos sincronizados) podemos observar que los mensajes se env´ ıan efectivamente cifrados De esta forma, por el servidor de Firebase ´ unicamente pasan dos tipos de informaci´ on: IDs aleatorios cada vez que establecemos un canal de comunicaci´ on (que garantizan la privacidad de los usuarios al no poder identificarse con los mensajes enviados) y mensajes cifrados. Tambi´ en se almacenan mensajes en claro, pero ´ unicamente en el canal general. VI. CONCLUSIONES Y TRABAJO FUTURO Podemos concluir sobre este proyecto que los resultados que pretend´ ıamos alcanzar son viables con la tecnolog´ ıa actual y se ha conseguido implementar un prototipo funcional de c´ odigo abierto que est´ a disponible en la Fig. 8. Esquema de chat de Firebase plataforma GitHub 9. Por desgracia, la usabilidad est´ a re˜ nida con el nivel de seguridad que se dese´ e obtener por lo que uno de los puntos a mejorar ser´ ıa la tecnolog´ ıa para el env´ ıo de informaci´ on utilizando el canal sonoro, que a´ un est´ a en v´ ıas de desarrollo y, como hemos visto, en Chirp tiene una extensi´ on m´ axima de 50 bits. En cuanto a las posibles mejoras sobre el prototipo elaborado, una de las deficiencias de nuestra propuesta es que no proporcionan ”Perfect Forward Secrecy (PFS)” de forma directa. Es decir, si un atacante consiguiera hacerse con la clave privada de un canal, mediante el robo de uno de los dispositivos, podr´ ıa descifrar todos los mensajes pasados de ese canal. Una forma f´ acil de solucionar este problema, ser´ ıa usar la clave negociada en la sincronizaci´ on de los dispositivos solamente como mecanismo de autenticaci´ on y no para establecer un canal confidencial. De esta forma, se requerir´ ıa una fase extra que podr´ ıa consistir en un protocolo Diffie-Hellman donde al final, ambos usuarios utilizan la clave secreta negociada usando el canal sonoro para confirmar que no ha habido intermediarios en el protocolo Diffie-Hellman. Otra l´ ınea de trabajo futuro ser´ ıa integrar este desarrollo con alguna aplicaci´ on de mensajer´ ıa instant´ anea, como por ejemplo Telegram. REFERENCIAS [1] Boyd C., Mathuria A: ”Key establishment protocols for secure mobile communications: A selective survey”. In: Boyd C., Dawson E. (eds) Information Security and Privacy. ACISP 1998. Lecture Notes in Computer Science, vol 1438. Springer, Berlin, Heidelberg 9ChatChat: https://github.com/RicardoRuizTueros/ChatChat This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) EDITORIAL UNIVERSITAT POLITÈCNICA DE VALÈNCIA 84 Preparaci´ on art´ ıculos XIII Jornadas de Ingenier´ ıa Telem´ atica [2] Whitfielf Diffie, Martin E. Hellman, , ”New Directions in Cryptography”, 644 IEEE Transactions on Information Theory, Vol. IT-22, No. 6, 1976 [3] N. Unger et al., ”SoK: Secure Messaging,” 2015 IEEE Symposium on Security and Privacy, San Jose, CA, 2015, pp. 232-249. doi: 10.1109/SP.2015.22 [4] Roland, Michael, and Josef Langer. ”Cloning Credit Cards: A Combined Pre-play and Downgrade Attack on EMV Contactless.” WOOT. 2013. [5] Sebastian U. et al. ”Tactile One-Time Pad: Leakage-Resilient Authentication for Smartphones”, Ruhr-University Bochum, Germany, 2015 [6] Nikolaos K et al. ”Sound-Proof: Usable Two-Factor Authentication Based on Ambient Sound”, 24th USENIX Security Symposium, Washintong DC, 2015 [7] F. Gardner ”A BPSK/QPSK Timing-Error Detector for Sampled Receivers”, IEEE Transactions on Communications. Volume: 34, Issue: 5, 1986 [8] Daniel A. et al. ”Privacy Threats through Ultrasonic Side Channels on Mobile Devices”, Technische Universit¨ at Braunschweig, Brunswick, Germany. 2017 [9] Han G. et al. ”A Formal Analysis for Capturing Replay Attacks in Cryptographic Protocols”, Informatics and Mathematical Modelling, Technical University of Denmark and Dipartimento di Informatica, Universita di Pisa [10] Mariano G, Adri´ an P. ”Detection of wormhole attacks in wireless sensor networks using range-free localization”, IEEE 17th International Workshop on Computer Aided Modeling and Design of Communication Links and Networks (CAMAD). 2012 [11] K. Moriarty et al. ”PKCS 5: Password-Based Cryptography Specification Version 2.1”, RFC 8018, Internet Engineering Task Force (IETF), 2017 This work is licensed under a Creative Commons 4.0 International License (CC BY-NC-ND 4.0) EDITORIAL UNIVERSITAT POLITÈCNICA DE VALÈNCIA 85