Seguridad en IMS

IMS (IP Multimedia Subsystem) es un conjunto de especificaciones para ofrecer servicios multimedia a través del protocolo IP. Esto hace posible incorporar todo tipo de servicios, como los de voz, multimedia y datos, en una plataforma accesible a través de cualquier medio con conexión a internet (fija o móvil).

Origen de IMS

En un principio definido por 3G.IP (conjunto de empresas pertenecientes al sector de las telecomunicaciones), fue 3GPP (3rd Generation Partnership Project) quien adoptó definitivamente la definición de IMS como parte de la estandarización de sistemas 3G^[1]^[2] en redes UMTS (Universal Mobile Telecommunications System), especificado en la Release 5 y 6.

Arquitectura

Se puede dividir en tres grupos de entidades:

Aplicación

Donde se encuentran los servidores de aplicación o AS y un HSS (Home Subscriber Server).

Los AS emplean el protocolo SIP (Session Initiation Protocol) para la señalización, empleado en el establecimiento de sesiones multimedia, como las llamadas de audio y video sobre internet. Los servicios ofrecidos por los operadores de telefonía se alojan y ejecutan en los AS.
Un HSS se trata de un dispositivo similar al HLR (Home Location Register) de la tecnología GSM (Global System for Mobile communications), donde se almacenan las credenciales de usuario.

Control

Formada por diferentes subsistemas (CSCF, MRF, etc) entre los que está el núcleo de IMS (IMS Core).

Otros dispositivos de gran importancia en esta capa son los CSCF (Call State Control Function), que integra tres subsistemas: P-CSCF (Proxy CSCF), S-CSCF (Serving CSCF) y I-CSCF (Interrogating CSCF). Estos subsistemas son los encargados, básicamente, de: procesar y enrutar la señalización; controlar los recursos del subsistema de transporte; realizar el registro y autenticación de los usuarios; provisionar los servicios IMS mediante el desvío de la señalización a los servidores de aplicación en cuestión y generar los registros de tarificación.

La MRF proporciona las funciones relacionadas con los medios de comunicación, tales como la manipulación de los medios de comunicación y la reproducción de tonos y anuncios. Cada MRF se divide en un controlador de función de recursos de medios (MRFC) y un procesador de función de recursos de medios (MRFP). El MRFC es un nodo del plano de señalización que interpreta la información proveniente de un AS y S-CSCF para controlar el MRFP. El MRFP es un nodo del plano de los medios de comunicación, se utiliza para mezclar la fuente o flujos de medios de proceso.

Transporte

Compuesta por el UE (User Equipment), la red de acceso (Access Network), el NASS (Network Attachment Subsystem) y el RACS (Resource Admission Control Subsytem). El transporte de red es realizado mediante IPv6, permitiendo la implementación de QoS (Quality of Service), seguridad integrada, autoconfiguración…

Seguridad

Tras haber visto un poco lo que es IMS y los dispositivos que actúan, entramos en las especificaciones de IMS relativas a la seguridad.

Desde el punto de vista de la estandarización, únicamente existe un mecanismo de autenticación y control de acceso, especificada en la TS 33.203 del 3GPP (Access Security for IP-Based Services) y que, comúnmente, se llama AKA (Authentication and Key Agreement). Sin embargo existen otras muchos mecanismos de autenticación y control de acceso, definidas para cubrir las necesidades de terminales heredados y permitir un despliegue más rápido. Los más comunes son:

Early IMS del 3GPP para el acceso móvil. Son aquellas implementaciones de IMS que por su antelación en el tiempo no son, enteramente, compatibles con las especificaciones de IMS, por lo que no son aplicables los mecanismos de seguridad. Algunos ejemplos pueden ser las implementaciones basadas en IPv4 como los dispositivos 2G.

Digest Authentication de TISPAN y PacketCable.

NASS-IMS. Autenticación inseparable de TISPAN para redes fijas. Es un método de autenticación en el que se pretende reutilizar la autenticación de la capa de red en IMS. Fue desarrollado por TISPAN para redes fijas en las que el terminal del usuario no dispone de una tarjeta ISIM. La seguridad de este mecanismo es prácticamente la misma que la de la red de acceso.

Digest Authentication con TLS (Transport Layer Security) de PacketCable.

La variedad existente de mecanismos de autenticación utilizados en IMS, causa problemas relacionados con la interoperabilidad, la existencia de redes con distintos niveles de seguridad, la selección del método más adecuado durante el registro del cliente, etc. En este sentido, el 3GPP ha desarrollado la recomendación TR 33.803 para guiar en la selección del método de autenticación más adecuado.

AKA (Authentication and Key Agreement)

La seguridad en IMS se basa en una clave secreta de larga duración compartida entre el ISIM (IP Multimedia Services Identity Module) y el centro de autenticación de la red local (AUC - Authentication Center).

ISIM: es una aplicación que se ejecuta en una tarjeta inteligente (UICC - Universal Integrated Circuit Card) y que contiene los parámetros de identificación y autenticación del usuario al IMS.
AUC: Asociado en este caso al HSS. Contiene la información necesaria para realizar los procesos de autenticación y cifrado de los servicios. Almacena los algoritmos de autenticación y cifrado y genera las claves necesarias para cada servicio.

El AKA se emplea para establecer tanto las claves de cifrado (3DES o AES-CBC) como las claves de integridad (HMAC-MD5 o HMAC-SHA-1).

ISIM ↔ HSS: Necesario para la autenticación mutua. Tanto el HSS como el ISIM tienen almacenada una clave secreta así como la identificación privada (IMPI) asociada a dicha clave.
UA ↔ P-CSCF: Garantiza un enlace seguro entre el UE y la red.
I/S-CSCF ↔ HSS: Establece una asociación de seguridad para la transferencia de información entre el I/S-CSCF y el HSS.
P-CSCF ↔ I/S-CSCF: Esta asociación de seguridad se aplica solo cuando el P-CSCF no se encuentra en el Home Network.
I-CSCF ↔ S-CSCF: Suministra la seguridad entre nodos SIP dentro de una misma red.

Proceso de registro de un UE IMS

Antes de que un usuario pueda conseguir el acceso a los servicios Multimedia IP, este debe registrar al menos una IMPU (IP Multimedia Public Identity), como por ejemplo, un número de teléfono. A continuación, la red debe autentificar la IMPI (IP Multimedia Private Identity) a nivel de aplicación.
El proceso de registro lo inicia el terminal IMS enviando un mensaje SIP REGISTER dirigido al P-CSCF con su IMPI e IMPU. Dicho mensaje llega al P-CSCF, y éste reenvía el mensaje al I-CSCF. El I-CSCF envía un mensaje DIAMETER de solicitud de autenticación del usuario que envió el mensaje REGISTER, DIAMETER UAR al HSS, quien responde con otro mensaje DIAMETER URR y paralelamente informa al I-CSCF la dirección del S-CSCF asignado al usuario. Luego el I-CSCF reenvía el mensaje de registro al S-CSCF, el cual a su vez envía el mensaje DIAMETER MAA que incluye el IMPI, que es empleado por el HSS para calcular el AV (authentication vector)) y genera la quíntupla <RAND, AUTN, XRES, CK, IK> y regresa la quíntupla al S-CSCF a través del mensaje DIAMETER MAA. Este mensaje es un indicativo de que la red está solicitando que el terminal emplee sus algoritmos de seguridad a fin de hacer la autenticación. A continuación, el S-CSCF envía el mensaje SIP 401 Unauthorized acompañado de cuatro de los cinco parámetros que formaban el AV al I-CSCF, quien retransmite el mensaje al P-CSCF. Nuevamente, el P-CSCF retransmite el mensaje al UE pero dejando solo dos parámetros en él, el RAND y el AUTN. Dado que el terminal tiene la misma clave secreta que tiene el HSS correspondiente, el usuario puede calcular el AUTN. Si éste coincide con el que recibió de la red, se considera que la red es legítima. El UE también calcula su respuesta RES, la cual se envía con otro mensaje SIP REGISTER junto con el IMPI e IMPU. Dicho mensaje llega al P-CSCF el cual lo reenvía al I-CSCF. Después el I-CSCF envía un mensaje DIAMETER UAR al HSS quien le responde con la dirección de S-CSCF a través de un mensaje DIAMETER UAA. Entonces el I-CSCF retransmite el mensaje de registro junto con el RES al S-CSCF. Este último envía el mensaje DIAMETER SAR al HSS quien responde con el mensaje DIAMETER SAA. Si el parámetro RES enviado por el usuario es igual al XRES que había calculado el HSS durante el primer intento de registro, entonces el HSS auténtica al usuario por medio del mensaje DIAMETER SAA. Finalmente el S-CSCF envía un mensaje SIP 200 OK al P-CSCF, que lo reenvía al usuario. Los procesos de seguridad siempre son ejecutados por la Home Network, incluso si el usuario está en roaming.

Intercambio de mensajes para el registro

Se proporciona soporte de la confidencialidad de mensajes SIP entre el UE y la P-CSCF gracias al empleo de IPsec.

Seguridad de acceso IMS para SIP

De acuerdo con las especificaciones de 3GPP, la autenticación del usuario debe basarse en Digest AKA, algo análogo a la autenticación de acceso UMTS (Universal Mobile Telecommunications System) pero para SIP. La especificación 3GPP TS 33.203 exponía que la señalización entre el agente de usuario y el P-CSCF debía basarse en IPsec ESP (Encapsulating Security Payload) en modo transporte. Sin embargo, el uso de IPSec en este modo no era adecuado para su uso en redes fijas. El problema de IPsec estribaba en el cruce de NAT (Network Address Translation), por lo que TISPAN (Telecomunicaciones y convergencia a Internet de Servicios y Protocolos de Redes Avanzadas) seleccionó el modo de encapsulación UDP (User Datagram Protocol) de IPsec.

GAA (Generic Authentication Architecture)

Todos los mecanismos de seguridad que hemos visto son utilizados en redes de acceso y dominios IMS. Sin embargo, es posible extender los mecanismos de autenticación mencionados anteriormente a nivel de aplicación o servicio mediante lo que se conoce como GAA.

La GAA es la arquitectura de autenticación que hace posible extender los mecanismos de autenticación existentes en IMS a nivel de aplicación/servicio.

Protocolos empleados en las diferentes especificaciones de GAA

GAA emplea dos mecanismos de autenticación. Uno se basa en la posesión de un secreto compartido entre las entidades comunicantes (GBA - Generic Bootstrapping Architecture) derivada de las claves utilizadas en la autenticación AKA, y la otra basada en criptografía asimétrica (claves pública y privada) y certificados digitales o PKI (SSC - Support for Subscriber Certificates).

Autenticación usando un secreto compartido

De los dos tipos de implementación, el más utilizado es la basada en secretos compartidos. La gran ventaja de GAA/GBA es que permite la creación de asociaciones de seguridad entre el agente de usuario y las distintas aplicaciones. Estas asociaciones consisten, fundamentalmente, en compartir una clave (el secreto compartido), que permite la autenticación posterior del agente de usuario frente a la aplicación, y, si son necesarias, otras características de seguridad como la garantía de confidencialidad e integridad de la información (mediante cifrado y firma digital), no repudio (firma digital), etc. El problema de estos mecanismos es la manera de ponerse de acuerdo sobre este secreto compartido. Como he mencionado anteriormente, el secreto es derivado de las claves utilizadas en la autenticación AKA.

Se introduce un nuevo elemento de red, llamado BSF (Bootstrapping Server Function). Esta BSF tiene una interfaz con el HSS. El UE ejecuta AKA con el HSS a través de la BSF. Un servidor de aplicaciones llamado NAF (Network Application Function), puede recuperar esta clave de sesión de la BSF, junto con la información del perfil del suscriptor. De esta manera, el servidor de aplicaciones NAF y el UE comparten una clave secreta que posteriormente se puede utilizar, en particular, para autenticar el UE y la NAF en el inicio de la sesión de aplicación (posiblemente también para la integridad y/o la protección de la confidencialidad) . La comunicación entre la UE y la BSF, así como la que existe entre NAF y BSF y entre BSF y HSS, son independientes de la aplicación.

Autenticación basada en criptografía asimétrica y certificados

Una alternativa al uso de secretos compartidos para la autenticación, es el uso de la criptografía asimétrica. Esto supone que la entidad que quiere ser autenticado debe poseer un par de claves (pública y privada) y un certificado digital validando el par de claves. Una vez en posesión de dichas claves y del certificado, el UE los puede utilizar para producir firmas digitales. La principal desventaja de este tipo de autenticación es que se necesita una PKI y que las operaciones con claves asimétricas requieren un esfuerzo computacional mayor.

Si un cliente desea hacer uso de la tecnología de cifrado asimétrico, necesita un certificado digital, otorgado por una CA (Certification Authority). Dicho certificado vincula una clave pública con la identidad de su dueño legítimo. Si un abonado móvil quiere tener y hacer uso de un par de claves, el certificado debe estar preinstalado o el abonado debe tener los medios para generar u obtener un par de claves y, así mismo, obtener de forma dinámica el certificado digital correspondiente. Para obtener un certificado digital de forma dinámica un UE debe enviar una solicitud de certificado correspondiente a un portal PKI y este debe autenticar la solicitud de certificado. El par de claves y el certificado digital correspondiente también se pueden utilizar para la integridad y protección, pero éstos no son parte del alcance de la GAA.

Liberty Alliance y el SSO (Single Sing On)

El Liberty Alliance es un conjunto de empresas que se dedica a la creación de especificaciones relacionadas con la autenticación, privacidad y gestión de las identidades de usuarios de aplicaciones en línea. Uno de los conceptos manejados es el de SSO o Single Sign On, en el que un usuario solo necesita autenticarse una sola vez para acceder a diferentes aplicaciones o servicios.

El 3GPP ha introducido una recomendación para la combinación de GAA/GBA y los mecanismos de autenticación y SSO definidos por Liberty Alliance y SAML v2.0. De esta forma, es posible beneficiarse de una autenticación fuerte, basada en AKA, con los mecanismos definidos por SAML v2.0 y Liberty Alliance para proporcionar SSO. No obstante, la mayor desventaja de GAA/GBA es que ha sido diseñada para agentes de usuario que cuenten con soporte de algún tipo de tarjeta. OMA ha especificado soluciones de autenticación, por ejemplo basadas en HTTP Digest con credenciales de usuario, para terminales que no dispongan de tarjeta ISIM.

Ataques en IMS

Network snoop

Rompe la confidencialidad. Sin la protección con SSL/TLS o IPSec, sería fácil para un atacante capturar la señalización SIP y el tráfico RTP (Real-time Transport Protocol) usando herramientas como Wireshark. Otro ataque contra la confidencialidad puede realizarse mediante el uso de herramientas de análisis para reunir información sensible y valiosa acerca de componentes, sistemas operativos y topología de la red.

Session hijacking

Dirigido hacia la integridad. El atacante puede insertar paquetes maliciosos en una sesión e incluso sustituir una parte del tráfico. Por ejemplo, el atacante puede enviar mensajes SIP Re-Invite para modificar los parámetros de la sesión.

DoS (Denial of Service)

Ataque contra la disponibilidad. El atacante envía un gran número de datagramas en un corto periodo de tiempo, causando una degradación de servicio o llegando incluso a detenerlo por completo. Algunos ejemplos son las inundaciones TCP SYN, inundaciones UDP…

P-CSCF Discovery

Orientado a la integridad y disponibilidad. El P-CSCF es el punto de entrada para el UE. DHCP (Dynamic Host Configuration Protocol) y DNS (Domain Name System) son comúnmente utilizados para descubrir el P-CSCF. Un atacante puede romper el proceso de descubrimiento de P-CSCF envenenando la caché del DNS para que el nombre de un dominio o IP falso sea devuelto al UE. El resultado es que el UE no puede ser registrado en la red o es registrado en un servidor falso.

Service Abuse

Impacta sobre la disponibilidad e integridad de IMS. Los usuarios autorizados pueden utilizar los servicios más de lo esperado o ganar acceso a servicios que no son permitidos para ellos.

Toll Fraud

Ataque contra el accounting. Un atacante puede falsificar un UE y enviar un BYE request a CSCF. El CSCF, pensando que la sesión ha finalizado, para de contabilizar al mismo tiempo que los UE no liberan los flujos de medios. Esto significa que los UE siguen intercambiándose flujos sin ser contabilizados. Se debe a la falta de control de flujos de medios.

Permission Acquistion

Ataque contra la autenticación. Un atacante puede obtener la contraseña de autenticación debido a una grieta u otros métodos. Básicamente, un UE que no dispone de una tarjeta ISIM emplea, como hemos mencionado anteriormente, HTTP Digest. Este método se basa en un nombre de usuario y una contraseña, que por lo general, no es de alto nivel de seguridad. HTTP Digest enumera varios ataques, como un ataque de fuerza bruta o un ataque de repetición.

Mitigado

Para mitigar todos estos ataques a la red se deben tener en cuenta los siguientes factores:

El proceso de autenticación por parte del abonado a la red tiene que ser muy fuerte.
El flujo intercambiado entre el cliente y los servidores de aplicaciones debe de ser seguro.
Los sistemas y aplicaciones deben de ser seguras.

Véase también

Referencias

↑ Referencia vacía (ayuda)
↑ «Wikipedia». Google Chrome. Google. Consultado el 16 de noviembre de 2017.

G.Camarillo, M.A. García‐Martín, “The 3G IP multimedia subsystem (IMS: merging the Internet and the cellular worlds”, 3rd Ed., Wiley 2008.
http://www.etsi.org/deliver/etsi_tr/133900_133999/133919/06.02.00_60/tr_133919v060200p.pdf
http://www.3gpp.org/
http://edadmovil.wordpress.com/casos-de-desarrollo/implementacion-ims/funcionamiento-ims/
https://web.archive.org/web/20131213060910/http://departamento.pucp.edu.pe/ingenieria/images/documentos/seccion_telecomunicaciones/IMS/Capitulo%207%20QoS%20y%20Seguridad.pdf
https://web.archive.org/web/20131218095643/http://blog.s21sec.com/2008/12/ims-introduccin.html
http://www.jatit.org/volumes/Vol51No1/12Vol51No1.pdf
https://web.archive.org/web/20131211004844/http://www.sersc.org/journals/JSE/vol8_no3_2011/5.pdf
http://www.efort.com/media_pdf/IMS_ESP.pdf

Datos: Q17080288

[1] Referencia vacía (ayuda)

[2] «Wikipedia». Google Chrome. Google. Consultado el 16 de noviembre de 2017.

[1]

[2]