“Técnicas de seguridad y Autenticación utilizadas en diferentes redes sociales y/o Smartphones”

...

Los Protocolos anteriores carecen de algunas características de seguridad adecuadas por esto se han ido proponiendo una serie de alternativas que cumplian con los requisitos de seguridad establecidos y no suponían un impacto en el rendimiento entre ellos:

SILC

El protocolo SILC (Secure Internet Live Conferencing ) fue propuesto por Pekka Riikonen en 1977 para securizar los sistemas de mensajería instantanea e IRC.

El protocolo de intercambio de llaves silc está basado en el protocolo criptográfico de Diffie-Hellman (DH). Tras una ejecución correcta de este protocolo se procede con el protocolo de

autenticación 'SILC Connection Authentication Protocol' haciendo uso o de una 'passphrase' o de una clave pública.

La implementación del protocolo SKE es vulnerable a un ataque de tipo 'Man in the Middle' MitM aprovechando que el certificado utilizado durante el protocolo SKE no se verifica correctamente.

IMKE

En el año 2005, M. Mannan y P. C. van Oorschot propusieron el protocolo IMKE (Instant Messaging Key Exchange). Este protocolo puede descomponerse en tres estados: el intercambio de claves (fase inicial de autenticación de los usuarios en el servidor), la comunicación cliente-servidor y las conexiones cliente-cliente. Se entiende que el certificado digital del servidor está incluido en el propio cliente (o se ha instalado previamente).

Durante la fase de intercambio de claves:

El cliente genera dinámicamente un par de claves pública/privada (RSA 1024/2048-bit) y una clave simétrica aleatoria (AES-128 CBC).

Con la clave simétrica recién generada cifra los datos de autenticación (incluye el hash de la contraseña (SHA-1) y la clave pública del cliente) y envía los datos cifrados al servidor junto con la clave utilizada cifrada haciendo uso de la clave pública del servidor.

Si en el servidor concuerda la contraseña del usuario con la recibida, envía al cliente un 'challenge' cifrado con la clave pública del cliente y el hash de la contraseña (calculado con una función diferente de la utilizada en el primer caso, p.e RIPEMD-160) cifrado con la clave simétrica.

El cliente comprueba que la clave recibida es la correcta y en caso de que concuerden descifra el 'challenge' recibido y lo reenvía al servidor haciendo uso de SHA-1.

El servidor comprueba que el 'challenge' recibido es el correcto y en caso de que concuerden tanto el cliente como el servidor calculan el identificador de sesión (que será utilizado como clave de cifrado) y la MAC (HMAC utilizando SHA-1), a través de una nueva función hash conocida por ambos, en la que intervienen la clave simétrica inicial y el 'challenge'.

Una vez autenticado en el servidor, si el usuario (Alice) quiere iniciar una comunicación con uno de sus contactos (Bob) enviará una petición al servidor solicitando la clave pública de ese usuario (Bob), éste se la entregará y además enviará al usuario (Bob) la clave pública de Alice. Una vez que Alice tiene la clave pública de Bob, generará una clave de sesión aleatoria y se la enviará a Bob a través de una conexión P2P. Una vez que ambos tienen la clave de sesión, crearán la clave de cifrado y MAC correspondientes e iniciarán la comunicación segura.

Atendiendo a la seguridad del protocolo, cabe destacar que esta propuesta permite que, si la comunicación es interceptada en cualquiera de las fases de la misma (incluso en el intercambio de claves) el atacante no podrá descifrar la información por no disponer de la clave privada del cliente. Aun así, es sensible a ataques de denegación de servicio al poderse replicar los paquetes del cliente (p.e en la fase de intercambio de claves, no se podría continuar con el proceso pero si consumir los recursos del servidor enviando múltiples veces el mismo paquete cuyo contenido es válido y el servidor tiene que verificar). Además, dado que se producen conexiones P2P sin necesidad de enviar archivos, es posible acceder a la dirección IP de un contacto simplemente iniciando una sesión con él.

ECC IM IMPLEMENTATION

En Enero de 2008 C. H. Yang, T. Y. Kuo, T. Ahn y C. P. Lee propusieron un protocolo de mensajería instantánea basado en la utilización de criptografía de curva elíptica (ECC) en la creación de las claves públicas y las claves simétricas. El uso de ECC en el protocolo permite mejorar el rendimiento dado que el cifrado ECC con una longitud de clave de 160-bit es igual de seguro que el uso de RSA con longitudes de clave de 1024-bit.

XMPP

El protocolo XMPP (Extensible Messaging and Presence Protocol) es un protocolo abierto (al contrario que MSNP, OSCAR y YMSG), basado en XML y fácilmente extensible, que se utiliza principalmente en servicios de mensajería instantánea.

Originalmente fue desarrollado en 1999 bajo el nombre de Jabber. Como ya se ha comentado en la introducción, en el año 2000, Jeremie Miller presentó el protocolo en la IETF con el nombre IMPP y ésta lo acepto en el año 2002 renombrándolo a XMPP.

Este protocolo es utilizado en aplicaciones y servicios conocidos y ampliamente utilizados como Google Talk (cuyo soporte no se va a mantener en el nuevo servicio de Google, Hangouts), el chat de las redes sociales Tuenti, Facebook y Whatsapp (en algunos casos variaciones del mismo adaptadas al funcionamiento propio del servicio -como es el caso del WhatsApp-).

La red XMPP hace uso de un arquitectura cliente-servidor en la que no existen servidores centrales que gestionan el servicio sino que cualquier usuario puede crear su propio servidor XMPP (la comunicación se realiza directamente entre el nodo emisor y el receptor, sin saltos intermedios). Todos los usuarios en la red tienen asignado un identificador denominado JID ('Jabber ID'). Este identificador tiene una estructura parecida a la del email, tal que usuario@dominio. Para permitir accesos desde distintas localizaciones sin que éstos confluyan en una misma sesión, XMPP utiliza la figura del recurso (por ejemplo 'casa', 'trabajo', etc.) para especificar un cliente en concreto en el propio JID, quedando usuario@dominio/recurso.

Otra de las características a destacar del protocolo es que permite el uso de 'Connection Managers' para utilizar el protocolo a través de conexiones HTTP persistentes ('long-lived'). De esta forma,