SEGURIDAD EN WAP I

Por Juan Pagoaga Fernández

Contenidos:

Algunas definiciones
Precedentes en Internet: SSL
El medio aéreo: GSM
WTLS
Lo que hay en la actualidad en WTLS
The "White Spot"
El problema de la autenticación de usuario
Nuevos avances en WAP 1.2: WIM y WMLScript Crypto API
Avances previstos
Conclusiones
Referencias
  Artículo
  Generales
Comentarios adicionales.

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.

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 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].

Aunque WAP fue diseñado para utilizar cualquier tecnología móvil existente en la actualidad, 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, pero debe señalarse que durante el último año 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 protegidas (exclusivamente desde el terminal móvil a la BTS).

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) [WAP99a]. Sobre esa capa de transporte se sitúa una capa opcional de seguridad, denominada WTLS, Wireless Transport Layer Security.

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:

• WTLS debe soportar datagramas.
• Debe soportar portadoras de ancho de banda variopinto.
• Debe soportar periodos de latencia 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 coger 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:

Características	Clase 1	Clase 2	Clase 3
Intercambio de clave	Obligatorio	Obl.	Obl.
Certificados de servidor	Opcional	Obl.	Obl.
Certificados de cliente	Opc.	Opc.	Obl.
Compresión	-	Opc.	Opc.
Cifrado	Obl.	Obl.	Obl.
MAC	Obl.	Obl.	Obl.
Interfaz con tarjeta inteligente	-	Opc.	Opc.

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: DH 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.

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

• UP.Link de phone.com.
• La pasarela WAP de Ericsson.
• WAP Server de Nokia.
• 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.

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.

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.

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

• 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.
  
  
• 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 ningún acuerdo con el operador (el usuario accede al servicio introduciendo una URL en tras haber accedido a la conectividad 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 utilizando el protocolo HTTPS). Si 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.
  
  
• 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.
  
  

En la actualidad, existen varias especificaciones en discusión en el WAP Forum para solucionar este problema. La más significativa es la que permitirá la "tunelización" 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 Wireless Port Proxy.

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 al servidor web del proveedor de contenidos en forma de cabecera HTTP. La pasarela WAP de phone.com (UP.Link) lo hace mediante la cabecera X_UP_SUBNO, en tanto que la de Ericsson utiliza MSISDN (si bien este número va cifrado). El WAP Server de Nokia y Kannel envían la cabecera x-network-info.

Es preciso tener mucho cuidado con estas cabeceras puesto que su traspaso indiscriminado proporcionando el número de teléfono del usuario puede plantear ataques 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 de esta cabecera, a no ser que, como hace la pasarela de Ericsson, el número de teléfono se traspase cifrado. De este modo, sólo la aplicación del proveedor de contenidos que posea la clave para descifrar este número podrá conocerlo.

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

WAP 1.2 introduce nuevas posibilidades que aumentan la seguridad proporcionada por la familia de protocolos. Se trata de WIM (Wireless Identity Module) [WAP99c] y de una nueva biblioteca de funciones (la sexta) de WMLScript con propósitos criptográficos (Crypto) [WAP99d].

WIM 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 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). El acceso a las funciones de WIM se protege también mediante un PIN.

WMLScript Crypto API 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 especificació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.

A modo de curiosidad hay que señalar que no habrá "WAP 1.3". 1.2 será la última versión numerada de WAP. De ahora en adelante habrá versiones fechadas y todas las especificaciones que hayan pasado las pruebas de conformidad y las revisiones de seguridad serán incluidas en tal edición.

Entre los 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 (Wireless Port Proxy).
  
  
• 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 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.
  
  
• 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.
  
  

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.

Quizá la mejor evaluación que se puede hacer de la seguridad en el entorno móvil es que el acceso a Internet a través de dispositivos móviles se encuentra aún en un estado de inmadurez. El soporte masivo por parte de la industria es un esfuerzo de apenas un año que obtendrá su fruto a medida que GPRS y los sistemas de tercera generación (UMTS) vayan siendo implantados. 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.

• [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/
  
  
• [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
  
  
• [WAP99a] WAP Forum (05/11/99). "Wireless Application Protocol Architecture Specification". Disponible en http://www.wapforum.org/what/technical.htm
  
  
• [WAP99b] WAP Forum (05/11/99). "WAP Wireless Transport Layer Security Specification". Disponible en http://www.wapforum.org/what/technical.htm
  
  
• [WAP99c] WAP Forum (05/11/99). "WAP Identity Module Specification". Disponible en http://www.wapforum.org/what/technical.htm
  
  
• [WAP99d] WAP Forum (05/11/99). "WAP WMLScript Crypto API Library Specification". Disponible en http://www.wapforum.org/what/technical.htm
  
  

• [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.

COMENTARIOS ADICIONALES

Enhorabuena por el artículo. Lo mas completo que visto hasta ahora. Únicamente creo que peca de ingenuidad a la hora de pensar que el white spot es un problema sin importancia y difícil de abrir. Yo como desarrollador de un gateway comentaría, que lo primero que pide cualquier operador, banco, o quien quiera instalar un gateway, es un fichero de estadísticas, osea, quieren ver todos los accesos que se producen por su gateway. Un saludo. JIP

Juan Pagoaga Fernández

Envía el artículo a un amigo:

Tus comentarios y opiniones sobre el artículo: