eSIM permite leer mensajes ajenos e interceptar llamadas. Y esto ya ha sido demostrado

El laboratorio de investigación Security Explorations presentó los resultados de varios meses de trabajo, revelando vulnerabilidades en el núcleo de la tecnología eSIM. El objeto de estudio fue una tarjeta eUICC de la empresa Kigen, certificada según los estándares de GSMA y que utiliza una implementación propia de la máquina virtual Java Card.

A pesar de los mecanismos de seguridad declarados, incluidos la certificación EAL4+, medidas integradas de aislamiento de memoria y protección contra ataques externos, el producto fue vulnerable a un ataque exitoso que permitió tomar el control total de la eSIM y demostró el colapso del modelo de seguridad confiable de todo el ecosistema eUICC.

La investigación mostró que las vulnerabilidades advertidas por Security Explorations ya en 2019 —pero ignoradas en su momento— no solo eran reales, sino también potencialmente devastadoras. En ese entonces, la empresa Oracle calificó estos hallazgos como "preocupaciones" y se negó a reconocer su criticidad. Hoy queda claro que errores en la implementación de los bytecodes de Java Card, como la confusión de tipos entre objetos y matrices, no se corrigieron ni en la implementación de referencia de Oracle ni en productos independientes como la eUICC de Kigen.

Security Explorations logró comprometer la tarjeta eUICC de Kigen, incluso en el perfil de prueba TS.48, simulando la instalación de una aplicación Java maliciosa mediante el canal SMS-PP. Como resultado del ataque, extrajeron la clave privada ECC que identifica a la tarjeta GSMA, lo que permitió descargar y descifrar sin restricciones perfiles eSIM de numerosos operadores, incluidos AT&T, Vodafone, Orange, T-Mobile y otros. Estos perfiles contenían no solo configuraciones de red, sino también claves OTA confidenciales, identificadores de suscriptores, aplicaciones Java y parámetros de servicio. En algunos casos, las aplicaciones extraídas podían ser modificadas e instaladas nuevamente sin que el operador lo detectara.

Uno de los experimentos más reveladores fue un ataque a la red de Orange. Los investigadores demostraron la posibilidad de clonar una eSIM: el perfil duplicado, instalado en otro dispositivo, permitió interceptar llamadas entrantes y SMS. Mientras el dispositivo malicioso estuviera encendido, el usuario legítimo no recibía ningún mensaje, y la red los marcaba como entregados. Este comportamiento amenaza tanto la privacidad como la confiabilidad de los servicios de autenticación de dos factores usados por bancos, correos electrónicos y otros sistemas críticos.

Kigen reconoció la vulnerabilidad y comenzó a colaborar con los investigadores. La empresa pagó $30,000 por el informe técnico detallado y aceptó un período de confidencialidad de 90 días antes de la publicación. Tras el análisis, se intentó mitigar la vulnerabilidad implementando verificación de tipos en todos los bytecodes de Java Card. Sin embargo, Security Explorations señaló que la medida fue simbólica e ineficaz: el sistema solo verificaba la parte superior del stack sin rastrear el flujo de control, dejando decenas de escenarios vulnerables. En otras palabras, la "verificación universal" introducida no funcionaba, dejando más de 100 posibles vectores de ataque.

En respuesta a las vulnerabilidades, GSMA revisó la especificación TS.48, deshabilitando la instalación de aplicaciones Java en perfiles de prueba. También se emitió un documento especial con recomendaciones para la industria, subrayando la necesidad de controlar las claves de gestión remota de aplicaciones (Remote Application Management). No obstante, los investigadores consideran que estas medidas son parciales y no abordan la raíz del problema: la debilidad arquitectónica de la máquina virtual Java Card, sobre la cual se basa todo el ecosistema eSIM.

Curiosamente, Kigen, a pesar de declararse independiente de Oracle, desarrolló su propia máquina virtual en la que se replicaron los mismos errores conceptuales encontrados en la implementación de referencia de Oracle. Afirmaron no estar al tanto de las vulnerabilidades señaladas por Security Explorations en 2019. Sin embargo, según los investigadores, se intentó contactar a Kigen ya en noviembre de 2020 mediante un formulario de contacto, tras un seminario web conjunto con Orange.

Además de Kigen, el estudio abarcó a otros proveedores de eUICC. Usando el servicio de Comprion, se probó un chip de Giesecke+Devrient, que mostró mayor resistencia: a pesar de permitir conversiones arbitrarias de tipos, la zona crítica de memoria estaba aislada y el campo de tamaño del arreglo no se superponía con los datos de los objetos. Esto confirma que no todas las implementaciones de Java Card son igual de vulnerables. Sin embargo, los investigadores no tuvieron acceso a chips de otros fabricantes como Thales y NXP, debido a políticas de distribución cerradas y condiciones de confidencialidad.

Uno de los hallazgos más preocupantes fue que los servidores de aprovisionamiento remoto de SIM (Remote SIM Provisioning), incluidos los de IDEMIA y Thales, no detectaban certificados eUICC comprometidos. Esto indica una falta sistémica de validación y monitoreo, lo que permite ataques a gran escala sin ser detectados. Además, el análisis mostró que muchas eSIM no implementan una verificación completa del bytecode de Java Card, a pesar de las recomendaciones de la especificación SGP.25.

Las herramientas utilizadas por los especialistas no solo permitían hackear tarjetas y extraer su contenido, sino también examinar Java Card en busca de problemas de seguridad comunes. Estas herramientas podían analizar memoria, stack, variables locales y ejecutar análisis de bytecode automáticamente. Se usaron tanto para el análisis de la eUICC de Kigen como en pruebas en redes reales.

Una conclusión importante de los investigadores fue el reconocimiento del fracaso de los mecanismos de certificación existentes. A pesar de las certificaciones EAL4/5 y declaraciones de protección a nivel de hardware, la arquitectura permite que un atacante eluda todas las capas de defensa mediante vulnerabilidades en la implementación de software. Además, los estándares actuales no exigen verificación obligatoria de aplicaciones Java durante la carga, lo que crea condiciones ideales para insertar "troyanos" durante el aprovisionamiento.

Security Explorations subraya la necesidad de revisar el modelo de confianza de la industria de las telecomunicaciones. Los operadores no deberían confiar ciegamente en los certificados GSMA como garantía absoluta de seguridad. Una eUICC comprometida permite comprometer a los suscriptores de cualquier operador móvil. Las aplicaciones instaladas en una eSIM no son accesibles para el análisis del usuario, lo que las convierte en un posible vector de ataque para entidades gubernamentales o el crimen organizado.

A pesar de la magnitud de la amenaza, Oracle no mostró interés en las propuestas técnicas gratuitas para corregir las vulnerabilidades ofrecidas por los investigadores. Kigen, en cambio, reconoció el problema y coordinó su mitigación a través de GSMA, notificando directamente a más de 100 organizaciones y a cientos más a través del programa CVD.

Los autores del estudio enfatizan que su trabajo fue financiado de forma independiente, sin apoyo externo, y que, con el respaldo adecuado, estarían dispuestos a compartir sus resultados gratuitamente con todos los participantes de GSMA. El objetivo del estudio es demostrar el valor del análisis de seguridad independiente y la importancia de prestar atención a los detalles que la industria ha ignorado sistemáticamente durante años.