Seguridad en WAP II
por Miguel Ángel Monjas Llorente
v. 2.0 - [15/01/2000]

CONTENIDOS

Introducción
Algunas definiciones
Precedentes en Internet: SSL
El medio aéreo: GSM
WTLS
  Conceptos
  Estado actual
El "White Spot"
  Conceptos
  Posibles soluciones a día de hoy
  Pasarelas subordinadas
El problema de la autenticación de usuario
Mejoras en la seguridad
  La evolución de las especificaciones
  WAP 1.2: WIM y WMLScript Crypto API
  Puesta a punto en WAP 1.2.1
  Nuevas especificaciones en WAP 1.3
Conclusiones
Referencias
  Artículo
  Generales

INTRODUCCIÓN

El presente artículo presenta una panorámica de las especificaciones y productos de seguridad para WAP existentes a día de hoy.

Se comienza definiendo el marco de discusión, presentando conceptos generales sobre seguridad. A continuación, se hace una revisión del protocolo SSL, ampliamente utilizado en Internet, y se señalan los riesgos en los que se incurre si no se utiliza el protocolo de seguridad de WAP, WTLS, del que se habla seguidamente.

El siguiente punto se centra en el problema de la existencia de información en claro en la pasarela cuando se utiliza WTLS, conocido como white spot. Seguidamente se examina la autenticación de los usuarios desde el punto de vista del proveedor de contenidos, para finalizar con las mejoras de seguridad previstas en las últimas especificaciones de WAP aprobadas por el WAP Forum.

Las variaciones introducidas desde la primera versión de este documento no son muy grandes:

• Se han añadido figuras para aumentar la comprensión de algunos puntos.
• Se han actualizado los nombres de productos y empresas, cuando éstos han cambiado desde la primera versión.
• Se han introducido nuevos productos (fundamentalmente centrados en el problema del white spot).
• Se ha pretendido arrojar nueva luz sobre las diferentes versiones de WAP.
• Se han introducido datos sobre el servicio ofrecido por los operadores españoles (aparecen en cursiva en el texto).
• Se introduce y explica la especificación de WAP Gateway Navigation.

ALGUNAS DEFINICIONES

Seguridad es un concepto que se usa a menudo con escaso rigor. Esto es así porque, en lenguaje natural, el concepto de seguridad es polisémico y, a menudo, equívoco. Cuando hablamos de seguridad en tecnologías de la información, estamos hablando de muchas cosas a la vez: que nadie nos robe o modifique los datos, que nadie nos suplante, que nadie acceda a donde no debe...

Para centrar la discusión en la que nos movemos, podemos acudir a los estándares de ISO donde, dentro del modelo de referencia OSI [ISO89b] se define una arquitectura de seguridad dentro de la que existe una serie de servicios de seguridad. Según esta especificación, para proteger las comunicaciones es necesario dotar a las mismas de dichos servicios. Se trata de los siguientes:

• Autenticación de la entidad par: mediante este servicio se verifica la fuente de los datos. La autenticación puede ser de la entidad origen, de la entidad destino o de ambas a la vez.
• Control de acceso: este servicio verifica que los recursos son utilizados sólo por quien tiene derecho a hacerlo.
• Confidencialidad de los datos: con este servicio se evita que se revelen, deliberada o accidentalmente, los datos de una comunicación.
• Integridad de los datos: este servicio verifica que los datos de una comunicación no se alteren, esto es, que los datos recibidos por el receptor coincidan por los enviados por el emisor.
• No repudio (barbarismo introducido desde el inglés que sería mejor traducido como irrenunciabilidad): proporciona la prueba, ante una tercera parte, de que cada una de las entidades ha participado, efectivamente, en la comunicación. Puede ser de dos tipos:
  • Con prueba de origen o emisor: el destinatario tiene garantía del quien es el emisor concreto de los datos.
  • Con prueba de entrega o receptor: el emisor tiene prueba de que los datos de la comunicación han llegado íntegramente al destinatario correcto en un instante dado.

Por tanto, cuando hablemos de seguridad, debemos especificar cuáles son los servicios de seguridad que requiere nuestro sistema y cómo vamos a garantizarlos.

PRECEDENTES EN INTERNET: SSL

En el mundo Internet, se utiliza habitualmente el protocolo SSL (Secure Sockets Layer, creado por Netscape Communications) [FRE96], que dispone un nivel seguro de transporte entre el servicio clásico de transporte en Internet (TCP) y las aplicaciones que se comunican a través de él, como garante de la seguridad en el acceso a servicios "delicados", como compra (comercio electrónico) o transacciones bancarias.

El modo de funcionamiento de SSL es bastante sencillo y se compone de dos partes diferenciadas:

1. Handshake Protocol (algo así como el apretón de manos): Se encarga de establecer la conexión, verificando la identidad de las partes (opcionalmente) y determinando los parámetros que se van a utilizar posteriormente (fundamentalmente se trata de acordar cual va a ser la clave simétrica que se utilizará para transmitir los datos durante esa conexión, para lo cual se utiliza criptografía de clave pública).
2. Record Protocol: Comprime, cifra, descifra y verifica la información que se transmite tras el inicio de la conexión (handshake).

No obstante, de lo señalado anteriormente se deduce que SSL, como protocolo de seguridad de transporte, sólo proporciona algunos de los servicios de seguridad necesarios:

1. Confidencialidad: la información que circula entre el cliente (un navegador habitualmente) y el servidor que actúa de frontal del servicio se cifra utilizando criptografía de clave simétrica (con una clave de sesión acordada en el handshake).
2. Autenticación: las partes que mantienen la comunicación se autentican mediante certificados basados en criptografía de clave pública. Esto no es siempre así, siendo lo más habitual que sea únicamente el servidor el que se autentica mediante un certificado digital.
3. Integridad: la integridad de los datos transmitidos se asegura usando códigos de integridad (MAC) calculados mediante funciones de hash (SHA o MD5).

El uso de SSL como soporte de compras o transacciones seguras es muy habitual. En el caso de una compra en línea, es habitual facilitar los datos de tarjeta de crédito (número, fecha de caducidad, impresión...) sobre una conexión protegida con SSL para su procesado por parte de un TPV virtual proporcionado por un banco. Este modelo adolece de un grave problema. No protege al comercio contra el repudio de la transacción, puesto que no existe forma de demostrar que es el propietario de la tarjeta el que ha efectuado la compra. Como ejemplo se puede citar a la empresa española Weblisten, la cual, usando este modelo se enfrentó a un fraude durante el pasado año.

Para paliar este problema Visa y Mastercard crearon SET (Secure Electronic Transactions) [SET97] para garantizar la irrenunciabilidad en el pago electrónico utilizando tarjetas de crédito.

Otra forma de garantizar la irrenunciabilidad es utilizar SSL como capa de transporte seguro e implementar un protocolo a nivel de aplicación que, mediante firmas digitales, garantice la irrenunciabilidad de las operaciones. Por este camino es por donde van las recientes iniciativas de la Unión Europea y del gobierno español promoviendo la validez jurídica de las firmas digitales [ESP99].

EL MEDIO AÉREO: GSM

Aunque WAP fue diseñado para utilizar cualquier tecnología móvil existente actualmente, la más utilizada por WAP en nuestro entorno es GSM. GSM es una tecnología digital de acceso aéreo que incluye mecanismos de cifrado de la comunicación entre el terminal móvil y la BSC (estación base). No es misión del presente artículo describir el funcionamiento de GSM (puede consultarse el excelente artículo "Fundamentos de redes GSM" [WMLC00] publicado también en WMLClub), pero debe señalarse que durante los dos últimos años han surgido serias dudas sobre la fortaleza de los algoritmos utilizados [CEA99].

Se considera comúnmente que los mecanismos de cifrado de GSM no son suficientes para garantizar la seguridad de cualquier transacción conducida mediante WAP, debido no sólo a la debilidad de los algoritmos como a la porción de camino protegida (exclusivamente desde el terminal móvil a la BTS), como puede observarse en la siguiente figura:

Figura 1. Arquitectura de comunicaciones WAP

WTLS

Conceptos

Como ya es conocido, WAP se articula como una arquitectura en capas en la que la capa de transporte se denomina WDP (Wireless Datagram Protocol) [WAP00a]. Sobre esa capa de transporte se sitúa una capa opcional de seguridad, WTLS (Wireless Transport Layer Security).

Figura 2. Pila de protocolos WAP

Del mismo modo que en el mundo TCP/IP se ha consolidado un estándar de facto, el ya citado SSL (Secure Sockets Layer) o su evolución, TLS (Transport Layer Security) [DIE99], como capa de seguridad entre los protocolos de aplicación (HTTP, FTP, SMTP& ) y la capa de transporte, la especificación WAP ha definido WTLS. Este protocolo se ha diseñado siguiendo una serie de criterios:

• Debe soportar datagramas.
• Debe soportar portadoras de ancho de banda variopinto.
• Debe soportar periodos de latencia (retardos) potencialmente largos.
• La capacidad de memoria y procesamiento de los terminales puede ser pequeña.

En definitiva, TLS y WTLS son protocolos equivalentes (en múltiples partes de la especificación de WTLS se copia literalmente la de TLS), siendo patente que la intención de los autores del protocolo fue tomar TLS y añadir soporte a datagramas, optimizar el tamaño de los paquetes transmitidos y seleccionar algoritmos rápidos entre los permitidos.

En cuanto a su estructura, tanto SSL-TLS como WTLS incluyen una fase de handshake en la que se negocian los algoritmos utilizados, se intercambian claves y se verifican certificados, seguida de una fase de registro (en la que garantiza también la integridad de los mensajes intercambiados). Del mismo modo que con SSL-TLS, se han definido las siguientes características:

• Integridad de los datos. Se asegura que los datos intercambiados entre el terminal y la pasarela WAP no han sido modificados.
• Confidencialidad de los datos. Se asegura que la información intercambiada entre el terminal y la pasarela WAP no puede ser entendida por terceras partes que puedan interceptar el flujo de datos.

• Autenticación. El protocolo contiene servicios para autenticar el terminal y la pasarela WAP.

Las implementaciones de WTLS pueden soportar diferentes características, definiéndose las siguientes clases [CHR00]:

• Clase 1: clase básica en la que no existe autenticación ni de cliente (terminal WAP) ni de pasarela WAP.
• Clase 2: lo mismo que la clase 1, pero añadiendo autenticación de la pasarela WAP (este nivel es el equivalente al implementado usualmente con SSL en Internet). El único terminal WAP que lo soporta actualmente es el Nokia 7110.
• Clase 3: igual que la clase 2, pero añadiendo autenticación de terminal WAP. En la actualidad no existe ningún terminal WAP que soporte la clase 3.

El resumen de características es el siguiente:

Entre las diferencias que existen entre SSL-TLS y WTLS, las más significativas son:

• La negociación se hace sobre datagramas WDP (equivalentes a los datagramas de UDP), no sobre conexiones fiables TCP, puesto que no existe TCP en WAP.
• Se permite una autenticación basada en un secreto compartido. Esto permite que los terminales WAP puedan prescindir de hardware criptográfico.
• Existen mecanismos de negociación optimizados para mejorar el tiempo de transacción segura en los que el servidor busca el certificado del cliente por su cuenta (por ejemplo, consultando en un servicio de directorio) sin esperar que tal certificado viaje a través de la red móvil.

Criptográficamente las innovaciones son mínimas. La más significativa es que admite la utilización de algoritmos criptográficos basados en curvas elípticas, que ofrecen ventajas en cuanto a memoria y prestaciones. Por lo demás, sigue soportanto los algoritmos ya conocidos: Diffie-Hellman y RSA para intercambio de claves, RC5, DES, 3DES e IDEA para cifrado simétrico y MD5 y SHA para generación de MACs. Además, la especificación permite el uso de certificados X.509v3, pero también certificados WTLS (X.509 optimizados para reducir el tamaño) y X9.68 (certificados basados en algoritmos de curvas elípticas).

Podemos concluir que WTLS no es más que TLS (o SSL) modificado para permitir la utilización de terminales WAP como agentes de usuario. Si bien estas modificaciones lo hacen también más vulnerable (a tenor de los primeros análisis [SAA99] o [JOR99]), es de prever que posteriores versiones del protocolo lo hagan más fiable y una herramienta totalmente eficaz de seguridad de transporte en el tramo entre el terminal y la pasarela.

ESTADO ACTUAL

Las principales pasarelas WAP soportan WTLS, al menos de clase 2 (con autenticación de pasarela). Entre ellas se encuentran:

• UP.Link de Openwave (última reencarnación de phone.com, fundadora del WAP Forum con el nombre de Unwired Planet).
• El WAP Gateway Proxy de Ericsson.
• La pasarela/servidow WAP de Nokia, Nokia Activ Server (anteriormente Nokia WAP Server).
• La pasarela WAP de SAS.

Pasarelas WAP de código abierto como Kannel no implementan WTLS. Sin embargo, existe una implementación de WTLS para dicha pasarela por parte de 3ui.com a través de pila WAP Ophelia.

Por lo que a España se refiere, a día de hoy todos los operadores están utilizando la pasarela UP.Link de Openwave, por lo que puede utilizarse WTLS siempre que el terminal lo soporte.

Paralelamente, diversas empresas e instituciones están proporcionando certificados para las pasarelas WAP, pasarelas WTLS (que se encargan de añadir una capa WTLS a pasarelas WAP que no lo soporten nativamente) o SDKs para desarrollo de WTLS. Entre las más significativas están:

• Baltimore Technologies dentro de su solución Telepathy, proporciona certificados y una pasarela WTLS (WAP Security Gateway) que funciona con las pasarelas más populares, así como un SDK de desarrollo: WAP Security Toolkit.
• Verisign ofrece certificados de servidor: Wireless Server IDs.
• RSA Security tiene un SDK para WTLS: RSA BSAFE WTLS-C.
• Keyon, a través de su programa freecerts.com ofrece certificados de servidor gratuitos. También posee una pasarela WTLS.
• Certicom proporciona un SDK, WTLS Plus, que incorpora algoritmos basados en curvas elípticas.

En España, la empresa ipsCA ofrece certificados para pasarelas WAP.

EL "WHITE SPOT"

Conceptos

La primera debilidad que presenta el modelo de seguridad en WAP es la existencia de dos zonas de seguridad, fruto de la existencia de dos dominios tecnológicos diferentes (la zona TCP/IP y la zona WAP), conectados mediante la pasarela WAP (WAP Gateway). De lo descrito anteriormente, se deduce que mientras que en el dominio WAP existe seguridad en el transporte mediante WTLS, en el dominio TCP/IP esta protección en el transporte se consigue utilizando SSL.

La pasarela debe ser capaz de hablar WTLS con el dispositivo móvil (en la actualidad nivel 1 o nivel 2 mediante HMAC) y SSL con el proveedor de contenidos (con la posibilidad de añadir certificados de las autoridades de certificación que garantizan los servidores seguros de contenido).

Ahora bien, la conversión de protocolos no se hace en este nivel de transporte, sino que se realiza en un nivel más alto. Esto significa que es preciso un proceso de descifrado y recifrado en la pasarela WAP (descifrado WTLS y recifrado SSL cuando la comunicación se realiza desde el dispositivo móvil al servidor de contenido y viceversa cuando el camino es el inverso). Este proceso origina pérdida de las cualidades que ofrecía SSL en el dominio TCP/IP, puesto que el cifrado ya no es extremo a extremo, puesto que, en algún momento, en la pasarela WAP, los datos de la transacción segura se encontrarán en claro. Este es el fenómeno que se denomina white spot.

Aunque el proceso de descifrado y recifrado se realiza en la memoria de la pasarela WAP y no en disco, el fenómeno puede resultar inaceptable para el operador del servicio. ¿Por qué? Bueno, la posibilidad de que un intruso tenga acceso a datos confidenciales que están siendo manipulados en memoria es remota. Tendría que entrar de alguna manera en las instalaciones donde se encuentra la pasarela (suponiendo que las medidas de seguridad lógica son suficientes), poner fuera de combate a guardias y encargados, matar el proceso de descifrado-recifrado (o apagar la máquina) y examinar el fichero de swap o el de core. Complicado, ¿verdad?

Sin embargo los reparos del prestador del servicio no suelen estar asociados a la posibilidad de una intrusión externa, sino más bien a la pérdida del control de la seguridad y la aparición de una tercera parte, el propietario de la pasarela WAP (usualmente el operador móvil). Por muchas garantías que le dé el operador al prestador del servicio, éste queda de alguna forma desarmado ante sus clientes. ¿Qué ocurre si un cliente plantea dudas o quejas sobre la seguridad del servicio? El prestador del servicio, aún fiándose del operador (y no hay razones para no fiarse; todos nos fiamos de las facturas telefónicas que nos cobra el operador al final de cada mes), no sabe qué ha pasado. Incluso teniendo absoluta seguridad en la tecnología, no es capaz de garantizar que no existe un empleado desleal del operador que pueda irrumpir en la pasarela y extraer información confidencial.

Posibles soluciones a día de hoy

Existen varios enfoques a la hora de tratar de evitar el problema. Desde el punto de vista del proveedor de contenidos (o de servicios), las posibles soluciones dependen mucho del modelo de negocio utilizado. Básicamente, existen tres modelos de prestación de servicios WAP que describiremos someramente (una descripción detallada queda fuera del ámbito de este artículo):

• Modelo 1: El proveedor de contenidos integra su servicio en un portal móvil de un operador (e-moción, Conecta o amen@wap, por citar los españoles). En este caso, el propietario de la pasarela, el operador móvil, firma un contrato con el proveedor de contenidos por el que garantiza la seguridad de los datos que transitan por la pasarela (evidentemente sólo integridad y confidencialidad) y, opcionalmente, estableciendo la comunicación con el proveedor de contenidos mediante una VPN, consiguiendo así garantizar la seguridad de los datos en tránsito. La seguridad del tramo WAP se haya protegida explícitamente con WTLS y la del tramo Internet con SSL.
  
  

Figura 3. Modelo 1

• Modelo 2: El proveedor de contenidos utiliza la infraestructura de cualquier operador móvil para garantizar el acceso a su servicio o contenido, pero sin haber llegado a acuerdo alguno con el operador (el usuario accede al servicio introduciendo una URL tras haberse conectado a los servicios WAP del operador). En este caso, no se garantiza ningún servicio de seguridad, puesto que depende de la configuración de la pasarela del operador ofrecer SSL en el tramo Internet (incluso aunque se solicite una URL que use el protocolo HTTPS). La presencia de WTLS también depende de la configuración de la pasarela, puesto que aunque sea requerida por el usuario, generalmente no será implementada.

Figura 4. Modelo 2

• Modelo 3: El proveedor de contenidos decide garantizar él mismo la seguridad, ofreciendo los servicios de acceso al usuario. Para ello, el usuario tendrá que crear un nuevo perfil dentro de su teléfono WAP para asegurar la conexión al servicio (número de teléfono, pasarela WAP...) o indicar al proveedor de contenidos cual es su número de teléfono para que éste configure vía OTA el teléfono del usuario. En este caso, el proveedor de contenidos puede adquirir y configurar su propia pasarela WAP garantizando la existencia de WTLS en el tramo WAP de la comunicación. La existencia de SSL no es necesaria puesto que, o bien el servidor de origen se halla dentro de la intranet del proveedor o bien utiliza un servidor WAP en vez de una pasarela (como el servidor WAP de Nokia), integrando los contenidos con la infraestructura WAP.Este enfoque se centra en la arquitectura de comunicaciones situando la pasarela WAP en el lugar más conveniente para neutralizar el White Spot. Sin embargo, esta solución es muy difícil de implementar, puesto que requiere que el propio usuario reconfigure su conexión, haciéndole consciente de cual es la infraestructura subyacente, lo cual no es siempre posible. Además, no todos los terminales lo soportan.

Figura 5. Modelo 3

Existen enfoques alternativos. Uno de ellos consiste en aislar el proceso de cifrado-recifrado, utilizando versiones "seguras" del sistema operativo que impidan el acceso a dicho proceso. Este enfoque es el que utiliza Hewlett-Packard con Praesidium Virtualvault [HP00]. De acuerdo con la información proporcionada por la compañía, este producto ha sido integrado con éxito con las pasarelas WAP de Tantau y Nokia. De hecho, Nokia y Hewlett-Packard han llegado a acuerdo para la utilización de Virtualvault con su pasarela WAP, Nokia Activ Server.

Ericsson, en cambio, apuesta por proporcionar seguridad de extremo a extremo a nivel de aplicación con su producto WAP Guard. Este producto implementa un protocolo de cifrado de canal utilizando programas WMLScript que son enviados al terminal móvil para encargarse del cifrado de los datos sensibles. Previamente ha existido una fase de handshake (siguiendo la filosofía de SSL) en la que se ha acordado la clave simétrica de cifrado de canal utilizando técnicas asimétricas. Si bien la protección que ofrece no es comparable a la de SSL, combinado con WTLS ofrece una protección extra en el lugar más sensible, la pasarela WAP.

Pasarelas subordinadas

Actualmente existen varias especificaciones en discusión en el WAP Forum para solucionar este problema. La más significativa es la que permitirá el traspaso de conexiones a través de una pasarela, de forma que una conexión WAP sea atendida por la pasarela del operador y traspasada a la del proveedor de servicios, estableciéndose WTLS entre el terminal WAP del usuario y la pasarela WAP del proveedor de servicios. Esta especificación se denomina WAP Gateway Navigation [SIG00] y queda descrita en la siguiente figura:

Figura 6. Navegación entre pasarelas WAP

El diagrama de flujo de la figura consta de los siguientes pasos:

1. El usuario solicita un contenido a través del servicio WAP de su operador móvil.
2. La petición llega a la pasarela WAP del operador.
3. La pasarela efectúa la traducción de protocolos (WAP a TCP/IP y HTTP) y la envía al servidor de contenidos.
4. El servidor de contenidos detecta que la pasarela desde la que llega la petición no es su propia pasarela y envía un código de estatus HTTP 300 y un documento de navegación (Gateway Navigation Document). En este documento de navegación se proporciona, utilizando XML, el modo en el que conectarse a través de la pasarela del proveedor de contenidos (que puede conducir a la utilización incluso de un nuevo servidor de acceso), la validez del documento y las URLs que tendrán que ser servidas a través de la nueva pasarela.
5. La pasarela del operador intercepta el documento de navegación y lo valida, determinando si se permite la navegación entre pasarelas y que el proveedor de contenidos esté autorizado a enviar un documento de navegación.
6. Si el proceso de validación tiene éxito, se reenvía el documento al cliente, si no, se le envía un código de estado HTTP 403 (no autorizado).
7. El cliente recibe el documento de navegación, lo almacena y reconfigura la conexión, de forma que se utilice la pasarela correspondiente.
8. El cliente pide automáticamente de nuevo el contenido.
9. La pasarela del proveedor de contenidos traduce los protocolos y envía la petición al servidor de contenidos.
10. Se obtiene el contenido requerido.

El cliente seguirá utilizando la nueva configuración para las URLs citadas en el documento de navegación. Una vez que expira, el documento es eliminado de la caché del terminal.

El problema de la autenticación de usuario

La ausencia de cifrado extremo a extremo no es la única debilidad del modelo WAP (comparada con el modelo clásico en Internet). Se pierde también la autenticación de las partes (en SSL siempre se garantizaba, al menos, la del servidor). La existencia de dos dominios tecnológicos provoca la aparición de autenticaciones disjuntas, puesto que el terminal móvil se autentica frente a la pasarela WAP y no ante el servidor de contenidos, mientras que es la pasarela la que accede al servidor de contenidos y, eventualmente, se autentica.

En principio, la autenticación de los usuarios debe hacerse de modo similar a como se hace en el mundo Internet. El modo más obvio es la utilización de un par identificador/clave integrado o no con la propia autenticación del servidor web. Este mecanismo no ofrece ninguna novedad, con las mismas salvedades que el mundo Internet: Sólo es fiable si se utiliza un canal seguro (es decir, si se utiliza WTLS).

Mecanismos de one-time password [LAM81], que en el mundo Internet se implementan mediante calculadoras lógicas realizadas con JavaScript de cliente no son posibles con los terminales actuales, más por restricciones del tamaño de los paquetes transmitidos que por la limitación de potencia de proceso o memoria de dichos terminales.

El elemento novedoso que parece aportar la tecnología WAP es la posibilidad de utilizar los elementos de autenticación propios de la red GSM. Sin embargo, esto no es sencillo de conseguir de modo directo, utilizando las funciones de la tarjeta SIM, sino que hay que tomar un rodeo. Una vez autenticado el terminal en la red GSM, el operador telefónico puede traspasar el número de teléfono u otro identificador al servidor web del proveedor de contenidos en forma de cabecera HTTP. La pasarela WAP de Openwave (UP.Link) lo hace mediante la cabecera x_up_subno, en tanto que la de Ericsson utiliza MSISDN (mediante el que sí se envía el número de teléfono pero cifrado, de forma que sólo los proveedores de contenido a los que se permita conocer dicho número podrán extraerlo). La pasarela WAP de Nokia, Nokia Activ Server y Kannel envían la cabecera x-network-info.

En condiciones normales, sería preciso tener mucho cuidado con estas cabeceras puesto que su traspaso indiscriminado proporcionando el número de teléfono del usuario puede constituir un ataque a la intimidad de éste. De hecho el operador estadounidense Sprint tuvo problemas, utilizando UP.Link, puesto que proporcionaba en claro dicho número de teléfono. Por tanto, no puede confiarse demasiado en la presencia del número de teléfono en esta cabecera.

En España, a día de hoy, todos los operadores utilizan UP.Link. Aparentemente, todos ellos proporcionan un identificador único asignado a un numero de teléfono en la cabecera x_up_subno (independientemente del tipo de micronavegador utilizado). Este identificador consta de una cadena alfanumérica que identifica al número de teléfono y una indicación de la pasarela utilizada. Por ejemplo:

1. Telefónica MoviStar proporciona un valor del tipo 63449113652-1_wap.oleada.com como identificador.
2. Airtel nos da un identificador de la forma 329699622-39707_wap101.airtel.net.
3. En tanto que Amena incluye un identificador del tipo A4025650_wapgw.amena.es.

No obstante, algunos servidores web, como iPlanet, no son capaces de obtener esta cabecera. Se trata de un bug que está siendo resuelto.

Mejoras en la seguridad

La evolución de las especificaciones

Tras la creación del WAP Forum en 1997, la especificación 1.0 de WAP fue publicada en abril de 1998. Nunca fue implementada y hubo que esperar a la especificación 1.1, aprobada en junio de 1999, para que comenzara la andanza comercial de WAP, con la aparición de productos comerciales. Esta especificación ya incluía la capa de seguridad, WTLS.

WAP 1.2, aprobada en diciembre de 1999, introdujo nuevas posibilidades que aumentan la seguridad proporcionada por la familia de protocolos. Se trataba de WIM (Wireless Identity Module) y de una nueva biblioteca de funciones (la sexta) de WMLScript con propósitos criptográficos, denominada Crypto.

Tras la versión 1.2, el WAP Forum decidió no numerar oficialmente las versiones, de forma que las nuevas versiones estarían fechadas y todas las especificaciones que hubieran pasado las pruebas de conformidad y las revisiones serían incluidas en la edición correspondiente. No obstante, este criterio ha sido obviado informalmente y se sigue denominando a las versiones mediante notación numérica.

En junio de 2000 se publicó una nueva serie de especificaciones (June 2000 Conformance Specification), más conocida como 1.2.1, que venía a resolver problemas menores aparecidos en la versión 1.2. La versión 1.3 se prevé para junio de 2001.

WAP 1.2: WIM y WMLScript Crypto API

Aunque las especificaciones de WAP 1.2 llevan aprobadas desde diciembre del año 1999, la infraestructura y terminales disponibles en el mercado por el momento soportan exclusivamente las características esenciales de WAP 1.1, como WTLS.

Las nuevas especificaciones relacionadas con la seguridad son las siguientes:

• WIM (Wireless Identity Module)[WAP00c] es una especificación que trata de definir un equivalente en el ámbito de WAP del popular SIM (Subscriber Identity Module), implementado en las tarjetas de nuestros teléfonos GSM y que contenía la identidad del usuario en la red GSM. WIM es una aplicación para tarjetas inteligentes (la propia tarjeta SIM es una tarjeta inteligente) con varios propósitos:
  • Almacenar el par de claves del usuario, el certificado que avala dichas claves y cualquier certificado raíz.
  • Almacenar las claves simétricas de sesión.
  • Efectuar las operaciones criptográficas necesarias para ejecutar los procedimientos de la capa de seguridad (firmado, generación de claves...)

  Al tratarse WIM de una aplicación para tarjetas inteligentes, puede implementarse en una tarjeta aparte (válida para teléfonos dual slot, dual SIM o que se encuentren conectadas a un lector de tarjetas mediante infrarrojos o Bluetooth) o almacenada en una tarjeta multiaplicación que contenga otras aplicaciones como la SIM de GSM (este modelo, conocido como SWIM, pone el control de las claves del usuario en manos de su operador móvil, puesto que es éste el que le provee de tarjeta SIM). No se prevé la aparición de terminales que soporten WIM hasta mediados del 2001.

  El acceso a las funciones de WIM se protege también mediante un PIN.

• WMLScript Crypto API [WAP99a] no es más que una nueva biblioteca estándar de WMLScript. De momento, sólo contiene una función (Crypto.signText), similar a la ya disponible en JavaScript desde la versión 1.3 [NET98]. Su finalidad, como puede deducirse fácilmente, es generar una firma digital de un texto que es enviado al terminal WAP dentro de una deck.

  Utilizando esta función para generar una firma digital sobre un contrato digital o un resguardo de una transacción, se consigue la irrenunciabilidad con prueba de origen.

Puesta a punto en WAP 1.2.1

La revisión de junio de 2000 ha añadido algunos cambios en las especificaciones de WTLS:

• Se han eliminado algunas combinaciones de algoritmos ya señaladas como poco seguras [SAA99].
• Se ha prohibido la posibilidad de no efectuar intercambio de clave.
• Se ha hecho obligatorio que el soporte mínimo de WTLS sea la clase 2.

Nuevas especificaciones en WAP 1.3

Una de los principales cambios que se introducirá en WAP 1.3 es que WTLS se hará obligatorio. Nadie podrá proclamar un soporte WAP 1.3 sin haberlo implementado en su infraestructura o en sus terminales. El resto de características introducidas en WAP 1.2 (WIM y Crypto.signText), aún no está claro si serán obligatorias o no.

Entre los nuevos avances que se están estudiando en materia de seguridad, algunos ya han sido citados:

• La posibilidad de traspasar conexiones WAP entre pasarelas de forma que el white spot se produzca en la infraestructura del proveedor de contenidos (WAP Gateway Navigation).
• La posibilidad de almacenar los certificados de cliente en un servicio de directorio (como LDAP) y referenciarlos mediante una URL.

Otros de los planteados son los siguientes:

• En futuras versiones de WMLScript Crypto API, se añadirán funciones de cifrado y descifrado (Crypto.encryptText y Crypto.decryptText)así como generación de MACs basados en clave simétrica y funciones de firma digital para Mobile SET.
• La posibilidad de integrar WAP y SIM Toolkit, de modo que se pueda acceder desde WAP a aplicaciones desarrolladas según este último estándar, lo que permitiría acceder al SIM y utilizar funciones criptográficas y de seguridad.
• Interfaces de acceso a funciones externas (External Function Interface, EFI), que definirán como acceder a procesos externos, como por ejemplo:
• Un lector de tarjetas conectado al teléfono mediante Bluetooth, como Wireless Wallet.
• Una tarjeta inteligente insertada en una segunda ranura (teléfono dual slot).
• Una aplicación SIM Toolkit almacenada en el SIM de la tarjeta.
• La creación de un estándar WPKI (Wireless PKI) que permita integrar la infraestructura criptográfica que define WTLS en infraestructuras de clave pública como las ya existentes en el dominio TCP/IP [MAÑ99]. Los fabricantes de PKIs más importantes ya han puesto en el mercado diferentes productos de WPKI. Sin embargo, hasta que no se defina el estándar y los fabricantes de infraestructuras integren estos productos, su utilidad es bastante limitada. Entre los más destacados están los siguientes:
  • Baltimore Technologies con Telepathy, la cual proporciona certificados de servidor, como ya se ha citado previamente.
  • Certicom, propietaria de los algoritmos criptográficos basados en curvas elípticas ha presentado recientemente MobileTrust.
  • Entrust ofrece Secure Wireless e-Business Solutions.

CONCLUSIONES

Durante los últimos meses se han multiplicado las voces en contra de WAP. A juicio de muchos, se trata de una familia de especificaciones cerrada, propietaria, sujeta a patentes y con problemas de diseño [BAN00]. Esos problemas de diseño, se proclama, afectan significativamente a la capa de seguridad de WAP, WTLS.

La postura más realista a la hora de abordar el tema de la seguridad consiste en reconocer que el acceso a Internet a través de dispositivos móviles se encuentra aún en un estado incipiente. El soporte masivo por parte de la industria es un esfuerzo de apenas año y medio que obtendrá su fruto a medida que se vaya implantando GPRS y, más adelante, los sistemas de tercera generación (UMTS).La madurez de la tecnología, mediante estándares ampliamente aceptados y soportados, llevará a la consecución de los niveles de seguridad necesarios para hacer del acceso móvil a Internet la herramienta idónea para el comercio electrónico, el ocio y la prestación de servicios personalizados.

REFERENCIAS

Artículo

• [BAN00] Banan, M. (26/05/2000). "The WAP Trap". Disponible en http://www.freeprotocols.org/wapTrap/one/main.html
• [CEA99] Cea, J. (26 de diciembre de 1999). "Cifrado GSM. ¿Desarrollo cerrado o desarrollo intencionado?". Hispasec, una-al-día. Disponible en http://www.hispasec.com/unaaldia.asp?id=425
• [CHR00] Christinat, M. and Isler, M (2000) "WTLS -The security layer in the WAP stack", Colloquium on Information Security, June 22, 2000. Disponible en http://www.keyon.ch/en/publications/infosec_wtls_keyon.pdf
• [DIE99] Dierks, T. y Allen, C. (January 1999). "The TLS Protocol. RFC 2246". Disponible en ftp://ftp.isi.edu/in-notes/rfc2246.txt
• [ESP99] Reino de España (17 de diciembre de 1999). "Real Decreto-Ley 14/1999, de 17 de diciembre de 1999, sobre firma electrónica". Disponible en http://www.sgc.mfom.es/legisla/internet/rdley14_99.htm
• [FRE96] Freier, A. O., Karlton, P. y Kocher, P. C. (1996). "The SSL Protocol Specification 3.0". Disponible en http://home.netscape.com/eng/ssl3/
• [HP00] Hewlett-Packard Co. (2000). VirtualVault Home Page. Accesible en http://www.hp.com/security/products/virtualvault/
• [ISO89a] ISO (1989) "Information Processing Systems - OSI - Basic Reference Model - The Basic Model", ISO/IEC IS 7498-1.
• [ISO89b] ISO (1989). "Information Processing Systems - OSI - Basic Reference Model - Part 2: Security Arquitecture", ISO/IEC IS 7498-2.
• [JOR99] Jormalainen, S. y Laine, J. (30/11/99). "Security in the WTLS". Disponible en http://www.tcm.hut.fi/Opinnot/Tik-110.501/1999/papers/wtls/wtls.html
• [LAM81] Lamport L. (1981). "Password Authentication with Insecure Communication", Communications of the ACM, v. 24, n. 11, Nov. 1981, pp. 770-772.
• [MAÑ99] Mañas, J.A. y Heras, M. (1999). "Qué es una PKI y a qué problemas pretende dar solución". Ponencia en Securmática 99, 28 de abril de 1999.
• [NET98] Netscape Communications Co. (07/09/98). "Signing text from JavaScript". Disponible en http://developer.netscape.com:80/docs/manuals/security/sgntxt/contents.htm
• [SAA99] Saarinen, M. J. (September 1, 1999). "Attacks against the WAP WTLS Protocol". Disponible en http://www.jyu.fi/~mjos/wtls.pdf
• [SET97] SETCo. (1997). "SET Secure Electronic Transaction Specification. Book 3: Formal Protocol Definition. Version 1.0". Disponible en http://www.setco.org/download/set_bk3.pdf
• [SIG00] Signhal, S. (November 2000). "WAP Gateway Navigation. Helping operators deliver end-to-end security over WAP". Ponencia en WAP Congress. Sevilla, 28 y 29 de noviembre de 2000.
• [WAP99a] WAP Forum (05/11/1999). "WAP WMLScript Crypto API Library Specification (June 2000 Conformance Specification)". Disponible en http://www.wapforum.org/what/technical.htm
• [WAP00a] WAP Forum (29/03/2000). "Wireless Application Protocol Architecture Specification (June 2000 Conformance Specification)". Disponible en http://www.wapforum.org/what/technical.htm
• [WAP00b] WAP Forum (18/02/2000). "WAP Wireless Transport Layer Security Specification (June 2000 Conformance Specification)". Disponible en http://www.wapforum.org/what/technical.htm
• [WAP00c] WAP Forum (18/02/2000). "WAP Identity Module Specification (June 2000 Conformance Specification)". Disponible en http://www.wapforum.org/what/technical.htm
• [WMLC00] Márquez Solís, S. (30 de noviembre de 2000). "Fundamentos de las redes GSM". Disponible en la sección de artículos de WMLClub, http://www.wmlclub.com/articulos/fundamentosgsm.htm

Generales

• [HTTP11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and Berners-Lee, T. (January 97). "Hypertext Transfer Protocol -- HTTP/1.1. ". Disponible en ftp://ftp.isi.edu/in-notes/rfc2068.txt
• [PHO99] Phone.com (January, 2000). "Understanding Security on the Wireless Internet". Disponible en http://www.phone.com/pub/Security_WP.pdf
• [ROD00] Rodríguez Berzosa, Luis (febrero de 2000). "La Seguridad en XML y WAP". Revista SiC, nº 38, febrero 2000, pp. 64-66.
• [SCH96] Schneier, B. (1996). "Applied Cryptography", 2nd Ed., J. Wiley & Sons, Inc..

Envía el artículo a un amigo:

Tus comentarios y opiniones sobre el artículo: