Sistema transaccional de pagos y transferencias móviles

Texto completo

(1)SISTEMA TRANSACCIONAL DE PAGOS Y TRANSFERENCIAS MÓVILES. JUAN JOSÉ OTERO CLAROS. BOGOTÁ D.C. UNIVERSIDAD DE LOS ANDES DICIEMBRE DE 2005.

(2) SISTEMA TRANSACCIONAL DE PAGOS Y TRANSFERENCIAS MÓVILES. JUAN JOSÉ OTERO CLAROS CODIGO 200021927 CICLO TERMINAL 2 Tesis de grado presentada al profesor Harold Cruz. BOGOTÁ D.C. UNIVERSIDAD DE LOS ANDES DICIEMBRE DE 2005. 1.

(3) TABLA DE CONTENIDO. 1. INTRODUCCIÓN. 1.1.1. Estructura del documento 1.1.2. Enfoque del documento 1.1.3. Metodología 2. TIPOS DE TRANSACCIONES MÓVILES 2.1.1. Transacciones móviles remotas 2.1.2. Transacciones móviles locales 3. EJEMPLOS DE TRANSACCIONES MÓVILES 3.1.1. 3.1.2. 3.1.3. 3.1.4. 3.1.5.. Compras en sitios WEB o WAP Compra de artículos en comercios Máquinas de venta automática Pagos o transferencias de dinero entre personas Compra de tiquetes para el transporte público. 4. REQUERIMIENTOS FUNCIONALES GENERALES 4.1.1. Usuario 4.1.2. Comercio 5. REQUERIMIENTOS NO FUNCIONALES GENERALES 5.1.1. Usuario 5.1.2. Requerimientos del modelo de negocio 5.1.3. Requerimientos técnicos 6. ANALISIS DE TECNOLOGIAS 6.1.1. JAVA™ 2 PLATFORM, MICRO EDITION (J2ME) 6.1.1.1.1. 6.1.1.1.2. 6.1.1.1.3. 6.1.1.1.4. 6.1.1.1.5. 6.1.1.1.6. 6.1.1.1.7.. Ejemplo: realizar un pago Facilidad de uso Costo Seguridad Interoperabilidad Rendimiento Análisis. 2.

(4) 6.1.2. SMS (SHORT MESSAGE SERVICE) 6.1.2.1.1. 6.1.2.1.2. 6.1.2.1.3. 6.1.2.1.4. 6.1.2.1.5. 6.1.2.1.6. 6.1.2.1.7.. Ejemplo: realizar un pago Facilidad de uso Costo Seguridad Interoperabilidad Rendimiento Análisis. 6.1.3. SAT (SIM APPLICATION TOOLKIT) 6.1.3.1.1. 6.1.3.1.2. 6.1.3.1.3. 6.1.3.1.4. 6.1.3.1.5. 6.1.3.1.6. 6.1.3.1.7.. Ejemplo: realizar un pago Facilidad de uso Costo Seguridad Interoperabilidad Rendimiento Análisis. 6.1.4. VOICEXML E IVR 6.1.4.1.1. 6.1.4.1.2. 6.1.4.1.3. 6.1.4.1.4. 6.1.4.1.5. 6.1.4.1.6. 6.1.4.1.7.. Ejemplo: realizar un pago Facilidad de uso Costo Seguridad Interoperabilidad Rendimiento Análisis. 6.1.5. WAP (WIRELESS APPLICATION PROTOCOL) 6.1.5.1.1. 6.1.5.1.2. 6.1.5.1.3. 6.1.5.1.4. 6.1.5.1.5. 6.1.5.1.6. 6.1.5.1.7.. Ejemplo: realizar un pago Facilidad de uso Costo Seguridad Interoperabilidad Rendimiento Análisis. 7. SOLUCIONES EXISTENTES EN EL MUNDO 8. INFRAESTRUCTURA BANCARIA EN COLOMBIA 9. POSIBLE SOLUCION EN COLOMBIA – MOBILE BANKING 9.1.1. MODELO DE NEGOCIO 9.1.1.1.1. 9.1.1.1.2. 9.1.1.1.3.. Introducción Modelo actual con tarjetas de crédito y débito Modelo con sistema SMS. 3.

(5) 9.1.1.1.4. 9.1.1.1.5.. Enfoque del nicho de mercado Costos estimados. 9.1.1.1.5.1.1. 9.1.1.1.5.1.2. 9.1.1.1.6.. Costos para el establecimiento Costos para la persona natural (usuario final). Conclusiones. 9.1.2. ANALISIS Y DESCRIPCION DE CASOS DE USO 9.1.2.1.1.. Requerimientos funcionales. 9.1.2.1.1.1.1. 9.1.2.1.1.1.2. 9.1.2.1.1.1.3.. Establecimiento Persona Administrador transaccional. 9.1.3. DISEÑO DE LA APLICACIÓN 9.1.4. ASPECTOS CRITICOS 9.1.5. CONCLUSIONES DE LA APLICACION 10. CONCLUSIONES GENERALES 11. BIBLIOGRAFÍA. 4.

(6) Introducción Tarde o temprano el móvil se convertirá en un método de pago adicional a los sistemas electrónicos actuales independientemente de si se asocia a una cuenta bancaria o si se implementa como un servicio de billetera electrónica. El objetivo de esta tesis es describir detalladamente los requerimientos funcionales y no funcionales de una solución de transacciones móviles, analizar las tecnologías actualmente disponibles en el mercado móvil y proponer una posible arquitectura de implementación en el entorno colombiano. Esta tesis no solo contiene este documento que explica toda la teoría acerca de las transacciones móviles, sino que incluye un prototipo funcional (escrito en JAVA1, con interfaz Web en JSP’s diseñada para correr sobre un servidor JBOSS) basado en SMS capaz de realizar consultas, transferencias y pagos. Estructura del documento El documento se dividió en tres grandes partes: la primera inicia describiendo los tipos de transacciones móviles y algunos ejemplos interesantes. Más adelante, en el segundo capítulo se describen los requerimientos funcionales y no funcionales que debe soportar la solución. La segunda parte del documento es una de las más importantes e inicia en el tercer capítulo analizando J2ME2, SMS3, WAP4, VoiceXML 5y SAT 6como posibles tecnologías para el usuario final utilizando como punto de partida los requerimientos más importantes del segundo capítulo. Por último, la tercera parte del documento describe soluciones existentes en el mercado, la infraestructura bancaria en Colombia y propone una arquitectura para la implementación de la solución. En esta sección, se hará todo un proceso de análisis para el desarrollo del prototipo basado en SMS, que incluye el modelo de negocio, el análisis, el diseño y seguridad de la aplicación. Enfoque del documento Aunque las transacciones móviles se pueden categorizar utilizando múltiples criterios, para efectos prácticos de este documento se dividirá en 2 grandes grupos: micro/macropagos y remotas/locales. Los micropagos comprenden valores menores a $30.000 pesos (USD 13) mientras que los macropagos comprenden cualquier valor mayor a este. Por otro lado, la diferencia entre una transacción local 1. Java technology: Para más información, ver http://java.sun.com/ Java 2 Platform – Micro Edition: Para más información ver http://java.sun.com/j2me/ 3 Short Message Service: Servicio que prestan los operadores celulares mediante el cual es posible enviar mensajes de texto desde y hacia teléfonos móviles. 4 Wireless Application Protocol: Protocolo mediante el cual es posible acceder a Internet desde un teléfono móvil. Requiere del servicio del operador. 5 Tecnología que facilita una interfaz de voz donde el usuario puede interactuar con su voz o las teclas numéricas del teléfono. Para más información, ver http://www.voicexml.org/ 6 Sim Application Toolkit: Para más información, ver http://www.gemplus.com/techno/stk/ 2. 5.

(7) y remota es que la primera requiere contacto entre las partes mientras que la segunda no. El siguiente diagrama explica la relación entre los tipos de de transacciones móviles.. Micropagos. Macropagos. Remotos. Locales. -Bajo volumen, gran potencial. -Billeteras basadas en servidor. -Autenticación WIM o PIN. -Emergente con gran potencial. -Tecnología bluetooth o RFID.. -Existente pero aún con potencial. -Autenticación MSISDN. -Premium SMS / WAP Push. -Emergente, con gran potencial -Tecnología RFID.. Figura 1. Relación entre los tipos de transacciones móviles.. Existe un gran campo de investigación en las transacciones que comprenden micropagos, especialmente en el de transacciones locales. Sin embargo, esta tesis se enfocará en analizar las posibles tecnologías que aplican para los macropagos utilizando la actual infraestructura bancaria en Colombia. La solución se puede implementar asociando el móvil a una cuenta bancaria, desarrollando un servicio de billetera electrónica, utilizando un sistema prepago, etc. Aunque en este documento analizaremos superficialmente algunas de estas soluciones en el entorno colombiano, se requiere un mayor estudio en esta área y se deja como inquietud para futuras investigaciones. Para el caso del prototipo que se desarrollará, más adelante se vera el porque se decidió hacerlo a manera de sistema prepago, donde la entidad financiera es la responsable de manejar dichas cuentas prepagadas. Metodología El proceso inició con la recolección de importante información tomada de Internet y personas que se encuentran en constante contacto con el medio. La información se analizó y se filtró utilizando como criterio de selección únicamente las lecturas que aplicaban para nuestro enfoque. Después se procedió a realizar el documento que se complementó con nueva documentación y entrevistas con personas del sector financiero y de los operadores celulares.. 6.

(8) Las entrevistas con las personas del sector financiero, más específicamente con las personas encargadas del área de tarjetas de crédito serán fundamentales para darle el enfoque correcto al prototipo, que de en adelante en este documento, será referido como “Mobile Banking”. Se espera que este documento se vuelva esencial en la implementación de soluciones móviles en el sector financiero y que promueva el uso de este servicio. Con el prototipo, se espera ilustrar el mecanismo de funcionamiento de una de las posibles formas de implementar micro o macropagos.. Tipos de transacciones móviles Aunque las transacciones móviles se pueden categorizar utilizando múltiples criterios, para efectos prácticos de este documento las dividiremos en 2 grandes grupos: micro/macropagos y remotas/locales. Los micropagos comprenden valores menores a $30.000 pesos (USD 13) mientras que los macropagos comprenden cualquier valor mayor a este. La diferencia entre una transacción local y remota es que la primera requiere contacto entre las partes mientras que la segunda no. A continuación se describe con más detalle las transacciones locales/remotas. Para el caso del prototipo incluido en esta tesis, éste manejara tanto transacciones móviles remotas como locales. Transacciones móviles remotas Se definen como la capacidad de realizar transferencias de dinero entre personas y/o negocios utilizando el móvil sin necesidad de que las partes se encuentren en el mismo lugar en el momento de la transacción. El rango de posibilidades para esta tecnología es muy amplio, desde la compra de tonos y logos que se envían al móvil hasta la adquisición de bienes, servicios y contenido. SMS constituye la mayoría de transacciones móviles actuales para la adquisición de contenido. El cobro lo realiza directamente el operador y traslada el porcentaje correspondiente al proveedor del contenido una vez hecho el recaudo. La aceptación de WAP y otras tecnologías emergentes han permitido independizar el cobro de los operadores y trasladarlo a las entidades financieras pertinentes. Sin embargo, se necesita un sistema realista y flexible para el pago con tarjetas crédito o un sistema similar. Transacciones móviles locales Se definen como la capacidad de realizar transferencias de dinero entre personas y/o negocios utilizando dispositivos móviles. La restricción es que las partes se deben. 7.

(9) encontrar en el mismo lugar en el momento de la transacción. Es muy posible que el móvil termine por convertirse en la próxima billetera digital. Se han desarrollado módulos RFID 7independientes que se adhieren al móvil sin una conexión al sistema electrónico del mismo. Este tipo de implementaciones se ha probado en prototipos y en algunos casos comerciales. Se espera que los próximos módulos tengan acceso a los recursos del teléfono mejorando la interacción del usuario y expandiendo las posibles aplicaciones. Bluetooth tiene el potencial de ser usado en transacciones locales que requieran grandes transferencias de información en ambas direcciones. Sin embargo, transacciones críticas en tiempo no pueden ser implementadas ya que la configuración y la conexión inicial entre los dispositivos es muy lenta para los requerimientos no funcionales de la solución. En el área de los pagos móviles basados en tarjetas de pago expedidas por bancos internacionales, EVM móvil8 (especificación actual para tarjetas de crédito aplicado a los móviles) se ve como un posible concepto a futuro, especialmente en el área de pagos móviles locales. Una serie de requerimientos fundamentales se necesitan cumplir en el EMV móvil para que las implementaciones tengan sentido. Específicamente: • La necesidad por el concepto a nivel global. • La especificación actual de EMV se debe desarrollar para que tenga en cuenta requerimientos especiales para dispositivos móviles. o El rol de los sistemas móviles se debe aclarar. o Los requerimientos en seguridad para los dispositivos móviles se deben evaluar detalladamente. • La certificación de los móviles debe ser expedida por las mismas industrias que crean los móviles. Ejemplos de transacciones móviles Existen innumerables ejemplos que aplican para los sistemas de transacciones móviles tanto remotas como locales. Los ejemplos que describiremos son los siguientes: • • • • •. Compras en sitios WEB o WAP. Compra de una artículo en una tienda. Maquinas de venta automática. Pagos o transferencias de dinero entre personas. Tiquetes para transporte público.. 7 RFID (siglas de Radio Frequency IDentification, en español Identificación por radiofrecuencia) es un método de almacenamiento y recuperación de datos remoto que usa dispositivos denominados etiquetas o tags RFID. Una etiqueta RFID es un dispositivo pequeño, como una pegatina, que puede ser adherida o incorporada a un producto, animal o persona . Las etiquetas RFID contienen antenas para permitirles recibir y responder a peticiones por radiofrecuencia desde un emisor-receptor RFID. Las etiquetas pasivas no necesitan alimentación eléctrica interna, mientras que las activas sí lo requieren. Recuperado el 19 de Junio de 2005, de http://es.wikipedia.org/wiki/RFID 8 Para más información acerca de EMV, ver http://www.fnmt.es/es/html/tage/lc_ta_pr.asp. 8.

(10) Compras en sitios WEB o WAP Este escenario describe la situación el la cual una persona ha ingresado a un portal WEB o WAP, decide realizar una compra y va a utilizar su dispositivo móvil como medio de pago. La secuencia de eventos, según la arquitectura que se utilice, puede variar ampliamente. Por ejemplo, al realizar el pago en el sitio WEB/WAP utilizando el móvil como medio de pago, el usuario podría ingresar en el portal su MSISDN 9(número de móvil) o automáticamente el mismo móvil reconocería la compra (en el caso de un portal WAP). Se inicia inmediatamente una sesión inalámbrica con el portal donde el usuario deberá autenticarse (manual o automáticamente) en el móvil y la transacción termina con un mensaje de confirmación en el móvil del usuario. Las ventajas sobre los pagos que actualmente se hacen con tarjeta de crédito en portales son evidentes. La transacción es mucho más segura ya que la autenticación y la confirmación se hace directamente en el móvil. La única forma de fraude sería si otra persona toma el móvil, confirma la transacción y conoce el PIN. Compra de artículos en comercios Este caso aplica para tiendas, restaurantes, etc. y cualquier pago que se haga cara a cara utilizando el móvil en comercios establecidos. El comercio inicia la transacción desde un POS o un sistema WEB ingresando o reconociendo el dispositivo del móvil (vía RFID, Bluetooth10, etc.) e ingresa el valor a pagar. Se inicia una sesión inalámbrica entre el sistema del comercio y el móvil. El usuario se autentica en el móvil y la transacción termina con un mensaje de confirmación para ambas partes. Maquinas de venta automática Este escenario describe cómo se podría utilizar el móvil como medio de pago para una maquina de venta automática. Existen diferentes implementaciones para iniciar la transacción: el usuario podría ingresar en su móvil el código de la maquina y el artículo deseado, podría ingresar a un pequeño portal de la maquina y seleccionar el artículo o ingresar su móvil en la máquina y el artículo deseado. Una vez se ha iniciado la transacción se establece una sesión inalámbrica entre la máquina y el móvil, el usuario se autentica y la transacción termina con la entrega del producto o un mensaje de error (el usuario puede no tener fondos o la maquina no tiene disponible el producto seleccionado). 9. Formato usado Internacionalmente para referirse al número del teléfono móvil.. 10. Bluetooth es la norma que define un estándar global de comunicación inalámbrica, que posibilita la transmisión de voz y datos entre diferentes equipos mediante un enlace por radiofrecuencia. Los principales objetivos que se pretende conseguir con esta norma son: - Facilitar las comunicaciones entre equipos móviles y fijos - Eliminar cables y conectores entre éstos - Ofrecer la posibilidad de crear pequeñas redes inalámbricas y facilitar la sincronización de datos entre nuestros equipos personales. Recuperado el 20 de Junio de 2005, de http://es.wikipedia.org/wiki/Bluetooth. 9.

(11) Pagos o transferencias de dinero entre personas Este ejemplo describe como hacer transferencias entre personas utilizando el móvil, de forma segura y sin necesidad de revelar información personal o de cuentas bancarias. El usuario se autentica en su móvil, ingresa el móvil u otra forma de identificación de la otra parte y el monto a transferir. Un mensaje de confirmación llega a al móvil del usuario que recibe la transacción para que se autentique y la transacción termina con un mensaje de confirmación en ambas partes. Compra de tiquetes para el transporte público Este escenario describe una forma de compra y autenticación en las entradas en sistemas como el Transmilenio y otros sistemas de transporte públicos que se organizarán en el país. También puede aplicar para tiquetes aéreos, en tren, etc. Las implementaciones para la compra del tiquete pueden variar ampliamente. Lo importante es que el tiquete permanece en el teléfono virtualmente evitando otra tarjeta o comprobante en el momento del ingreso. La compra del tiquete puede ser cara a cara utilizando el móvil como medio de pago o a través de un portal donde se utilice el teléfono como medio de pago. Al momento de ingresar al sistema de transporte, el usuario podría acercar su teléfono al sistema de recolección de tiquetes, oprimir un botón para activar la función de tiquetes o seleccionar un sistema que generaría un PIN para el ingreso.. Describiremos los requerimientos funcionales y no funcionales que debe soportar la solución y analizaremos la aplicabilidad de estos requerimientos en cada una de las tecnologías móviles. Por último analizaremos una posible implementación aplicado al entorno colombiano.. Requerimientos funcionales generales Usuario Para efectos prácticos de este documento, los requerimientos funcionales para el usuario excluyen el inicio del proceso que condujo hasta la transacción. Se enfocan en el momento en el que el usuario va a hacer el pago o la transferencia de dinero independientemente del motivo (pago en un restaurante, transferencia de dinero entre personas, compra de un artículo en una tienda virtual, etc.).. 10.

(12) Autenticación El usuario debe poder autenticarse contra el sistema de transacciones móviles. La forma de autenticación puede variar, puede ser por hardware o por software, ingresando un PIN o automáticamente utilizando el MSISDN del móvil o un certificado emitido por la entidad financiera. Realizar transferencia Este caso de uso lo utiliza el usuario cuando va a hacer un pago o va a hacer una transferencia entre cuentas. Debe seleccionar la cuenta origen, la cuenta destino y la cantidad. Confirmar transferencia Cuando el usuario realiza el pago de algún bien, servicio o contenido, el comercio es el encargado de iniciar la transacción. El usuario únicamente recibirá una confirmación que deberá aceptar o rechazar. Por otro lado, si es un usuario que está recibiendo una transferencia (por ejemplo, otra persona está transfiriéndole dinero) también recibirá una confirmación que deberá aceptar o rechazar. Comercio. Autenticación El comercio debe poder autenticarse con el sistema de transacciones móviles. La forma de autenticación puede variar, puede ser por hardware o por software,. 11.

(13) ingresando un nombre de usuario y contraseña o por un certificado emitido por la entidad financiera. Iniciar transacción El comercio debe tener la capacidad de iniciar una transacción. El inicio de la transacción puede variar ampliamente, puede ser utilizando un POS, un sistema WEB o cualquier otra forma que permita iniciar la transacción. Deberá ingresar la cantidad y la identificación del usuario. Para la identificación se han utilizado sistemas RFID en los celulares, códigos de barra, el MSISDN, bluetooth o tarjetas inteligentes. Confirmar transacción Una vez se ha ingresado la información el comercio podrá aceptar o cancelar la transacción. Requerimientos no funcionales generales Usuario Rapidez Según el Mobey Forum11, las transacciones no deben tomar más de 30 segundos excluyendo los ingresos que deba hacer el usuario. Por ejemplo, en una transacción remota, cuando el usuario selecciona “comprar”, no deben pasar más de 5 segundos para que reciba las posibles formas de pago. Una vez se ha seleccionado la forma de pago y los detalles de autenticación validados (esto no debe demorar más de 10 segundos), un mensaje de transacción exitosa no debe demorar más de 15 segundos después de ingresar el PIN. Las transacciones locales deben estar sujetas a tiempos parecidos. Facilidad para el usuario Es el requerimiento más importante ya que define la aceptación que pueda tener la solución. Debe ser fácil de utilizar (en comparación con los sistemas actuales) y se debe reducir el impacto cultural demostrando la facilidad para hacer las transacciones y motivar su uso con descuentos y promociones. Precio Si el precio de cada transacción es muy alto respecto al beneficio que brinda la solución, no se cambiaran los sistemas actuales de pago. Se deben dar incentivos a los comercios y a los consumidores para crear hábito. Independencia bancaria, de operador celular y de móvil Los usuarios deben tener la posibilidad de cambiar operador celular o su móvil sin tener que hacer cambios en los servicios de pago. Alta aceptación en comercios Si los comercios no aceptan la solución los usuarios tampoco lo harán. Es importante motivar a los comercios con bajos porcentajes de comisión y la posibilidad de financiarles cualquier sistema adicional que deban adquirir. 11. Mobey Forum: Recuperado el 6 de Mayo de 2005, de http://www.mobeyforum.org. 12.

(14) Bajo impacto en la tecnología Se debe comenzar utilizando tecnología existente como SMS y WAP ya que son tecnologías conocidas y aceptadas por los usuarios. A medida que los usuarios encuentren valor en la solución se puede implementar en tecnologías emergentes que ofrezcan mayor valor. Seguridad La solución debe ser segura. Deben existir mecanismos contra fraudes e intento de intrusión en los sistemas y las comunicaciones. Los usuarios deben saber y estar seguros que el destino de la transacción es el que ellos esperan. La información debe estar lo suficientemente cifrada para garantizar que no habrá acceso de terceros a la información. Privacidad La información del usuario se debe mantener con la mayor confidencialidad y no debe ser distribuida a terceros. Requerimientos del modelo del negocio Autenticación flexible Dependiendo del monto y tipo de la transacción se deben poder utilizar diferentes niveles de autenticación. Para pagos de bienes y servicios se puede utilizar autenticación basada en certificados y PKI móvil. Para micro-pagos, autenticación basada en MSISDN y PIN. Seguridad La transición de la información entre el móvil y los participantes debe estar lo suficientemente cifrada para evitar el acceso de terceros a esta información. Por otro lado, los negocios deben estar protegidos contra fraudes garantizando el correcto pago por el bien, servicio o contenido que prestaron. La autenticación debe ser lo suficientemente robusta para evitar que la identidad de las personas o los negocios pueda ser imitada. Valor para todos los participantes Todos los participantes en el modelo de negocio deben percibir valor: entidades financieras, operadores móviles, proveedores de tecnología, comercios y usuarios. Se ha encontrado gran valor para cada uno de los participantes exceptuando los comercios. Estos son vitales para la aceptación de la solución y se debe minimizar el impacto que exista en la infraestructura existente (muchos comercios cuentan actualmente con por lo menos un POS). Mantener procesos independientes Los procesos de cada participante se deben mantener independientes. Las entidades financieras y los comercios no deben realizar acuerdos con los operadores ni depender de ellos para prestar el servicio. Escalabilidad Se deben poder implementar otros servicios financieros y la solución debe permitir diferentes métodos de pago. Por otro lado, debe soportar diferentes. 13.

(15) modelos de negocio como interoperabilidad entre bancos o intermediarios privados. Promoción de marcas Las marcas deben ser visibles para el usuario permitiendo que exista la competencia natural en el negocio y que los diferentes participantes puedan presentar la solución como valor agregado para sus usuarios. Requerimientos técnicos Tecnologías abiertas y estándares Se deben utilizar tecnologías abiertas para evitar la inversión de grandes sumas de dinero y la interoperabilidad entre bancos, operadores y móviles. Por otro lado se debe intentar utilizar y/o adaptar los servicios electrónicos y tecnologías existentes como EMV, ISO-858312, etc. para las entidades bancarias y SMS, WAP, etc. para los usuarios. Independencia tecnológica Las soluciones en tecnología deben ser independientes entre bancos, operadores, móviles y comercios aunque todas deben estar soportadas bajo los mismos protocolos. Seguridad Comprende la autenticación del usuario, del comercio, la autorización del usuario para realizar la transacción y la integridad de la información. La solución debe garantizar los tres conceptos y debe proponer diferentes alternativas en cada uno de ellos. ANALISIS DE TECNOLOGIAS Java™ 2 Platform, Micro Edition (J2ME) J2ME provee un ambiente de desarrollo robusto y flexible para aplicaciones que se ejecutan en dispositivos de consumo como móviles, PDA´s, teléfonos, etc. Igual que J2EE13, J2SE y JavaCard, J2ME cuenta con su propia máquina virtual y una serie de API´s estándar definidos en el Java Community Process14 (JPC). Aunque J2ME comprende un gran rango de configuraciones y perfiles según las capacidades de los dispositivos, esta sección asume que se utilizarán móviles con la configuración CLDC y el perfil MIDP15. El objetivo es analizar las ventajas de desventajas de utilizar J2ME como aplicación cliente en la solución de transacciones móviles. Iniciaremos con un ejemplo de cómo 12. Para más información, ver http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=15871 13 Java 2 Platform, Enterprise Edition. Para más información, ver http://java.sun.com/j2ee/index.jsp 14 Para más información, ver http://jcp.org/en/home/index 15 CLDC: Connected Limited Device Configuration. MIDP: Mobile Information Device Profile. Para más información, consultar http://searchmobilecomputing.techtarget.com/sDefinition/0,290660,sid40_gci511735,00.html. Recuperado el 5 de Febrero de 2005.. 14.

(16) se realizaría una transacción utilizando J2ME y analizaremos los requerimientos más importantes. Ejemplo: realizar un pago Este ejemplo enumera la secuencia de eventos que suceden en el escenario donde un usuario va a pagar por un bien, servicio o contenido remota o localmente con su móvil utilizando J2ME. 1. El usuario inicia la aplicación J2ME. 2. Se inicia una sesión inalámbrica entre las partes. Puede ser iniciada por el usuario (en caso de transferencias y pagos) o por el comercio (en caso de pagos). 3. El usuario selecciona el método de pago (tarjeta de crédito, billetera virtual, etc.). 4. La aplicación solicita la autenticación del usuario que puede ser a través de una identificación y un PIN o un certificado en la aplicación o SIM. 5. La aplicación solicita la confirmación del usuario y la transacción es realizada. Independientemente de quien inicie la sesión, el usuario debe ejecutar la aplicación J2ME y seleccionar el pago a realizar o esperar un mensaje (SMS/WAP Push16) que inicia la transacción. Esto se debe a que la especificación no soporta un método de ejecución automático de la aplicación. Ahora analizaremos los requerimientos más importantes aplicados a J2ME. Facilidad de uso Este requerimiento comprende la facilidad en la descarga de la aplicación y la ejecución de la transacción. Existen diferentes formas para instalar la aplicación aunque la más conveniente es enviar un mensaje (SMS/WAP Push) al móvil del usuario para que descargue e instale la aplicación. El mensaje puede contener parámetros específicos de modo que el servidor personalice el JAD e incluya información adicional del usuario y la llave privada o el certificado digital. La facilidad de uso en el momento de la transacción es el factor más importante para el usuario. Los MIDlets17, a diferencia de SMS, proveen una avanzada interfaz gráfica que brinda una ventaja evidente siempre y cuando la navegación sea sencilla, rápida e intuitiva. Sin embargo, J2ME presenta un problema: independientemente de quién inicie la transacción, el usuario deberá ejecutar la aplicación manualmente. La especificación no soporta la ejecución automática de las aplicaciones. Adicionalmente, MIDP 1.0 no soporta WMA y no es viable incluir la librería ya que su funcionamiento depende del móvil. Con MIDP 2.0 esta limitante no existe.. 16 Consiste de un mensaje SMS que contiene un URL para acceder directamente a ella. Para más información, ver http://www.ihub.com/WAP%20Push.htm 17 Aplicaciones diseñadas para correr en dispositivos móviles como celulares o PDA’s.. 15.

(17) Costo El único costo adicional en el que incurriría el usuario sería el tiempo al aire al descargar la aplicación y al realizar la transacción. Este tiempo es mucho menor que en WAP y en muchos casos puede llegar a ser más económico que SMS dependiendo del número de mensajes que se deban intercambiar. Por otro lado, los precios en los planes de datos de los operadores cada vez son menores y se espera que continúen bajando. Seguridad La solución debe proveer comunicación segura desde el móvil al servidor transaccional para toda información confidencial que se deba transmitir. Debe implementar mecanismos de autenticación o verificación para identificar al usuario. Criptografía MIDP 1.0 no provee librerías oficiales de criptografía, sin embargo existe el JSR 177 (Java Specification Request 177) – Security and Trusted Services for J2ME (SATSA) que fue incluido en MIDP 2.0 aunque se puede incluir opcionalmente en MIDP 1.0. El objetivo de SATSA es incluir una serie de librerías que proveen servicios de seguridad y confianza integrando un elemento de seguridad (ES) en el móvil. Un ES es un componente en el dispositivo J2ME que provee los siguientes beneficios: − Almacenamiento seguro para proteger información sensible como la llave privada del usuario, llave pública, certificados digitales, información personal, información de autenticación, etc. − Operaciones criptográficas para soportar protocolos de pagos, integridad y confidencialidad de la información. − Un ambiente de ejecución seguro para implementar características de seguridad adicionales. Las aplicaciones J2ME se pueden utilizar estas características para implementar servicios de valor: autenticación y autorización, servicios bancarios, pagos, etc. Por otro lado, Sun Microsystems adicionó soporte no oficial para HTTPS 18(kssl) como parte de la RI (Reference Implementation) de MIDP 1.0.3. Esto no es obligatorio en los dispositivos pero si los manufacturadores lo implementan, en teoría debería funcionar. En MIDP 2.0 el soporte para HTTPS es obligatorio utilizando alguna de las siguientes especificaciones: HTTP sobre TLS, SSL v3, WTLS o TLS.. 18 Versión segura del protocolo HTTP. El sistema HTTPS utiliza un cifrado basado en las Secure Socket Layers (SSL) para crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP.. Es utilizado principalmente por entidades bancarias, tiendas en línea, y cualquier tipo de servicio que requiera el envío de datos personales o contraseñas. El puerto estándar para este protocolo es el 443. Recuperado el 5 de Febrero de 2005, de http://es.wikipedia.org/wiki/HTTPS. 16.

(18) Existe una iniciativa llamada Bouncy Castle que provee una librería de criptografía para dispositivos J2ME. Es una adaptación de JCA (Java Cryptography Architechture) y JCE (Java Cryptography Extenssion) para configuraciones CDC y CLDC de J2ME. Provee las siguientes herramientas: - Los motores de criptografía más aceptados (DES, TripleDES; RSA, etc). - Los motores de generación de valores de HASH (MD5 y SHA-1). - Soporte para generación de MAC (Message Authentication Code). - Soporte para la generación e intercambio de llaves (RSA, Diffie-Helman, etc). - Soporte para la escritura y lectura de certificados digitales (x509, X.9.62, PKCS#12, etc). Autenticación Existen diversas formas de autenticación que se pueden implementar en J2ME. La más recomendable es la utilización del PIN, La información adicional del usuario que se requiera para la autenticación puede estar contenida en la aplicación que se descarga. Otra forma de lograr la autenticación es utilizando verificación y las facilidades de almacenamiento de J2ME. Se mantiene la llave privada para firmar digitalmente cualquier información que se envíe. Por otro lado, el MIDlet también podría proveer servicios de verificación utilizando la llave pública de la entidad. Interoperabilidad Debido a la diversidad de móviles que existen en el mercado, la interoperabilidad es un requerimiento fundamental para el sistema de transacciones móviles. J2ME tiene la ventaja que cuenta con una máquina virtual que, independientemente del sistema operativo del móvil, garantiza la ejecución de la aplicación. Sin embargo, si el móvil no soporta J2ME evidentemente la aplicación no funcionará. Desafortunadamente, muy pocos móviles soportan J2ME (cerca del 15%), aunque esta cifra va en ascenso. En cuanto a la comunicación, MIDP soporta conexiones HTTP 1.1 sobre TCP/IP o cualquier pila de protocolos como WAP, i-Mode, etc. MIDP 2.0 soporta la librería de mensajería llamada Wireless Messaging API (WMA) que permite enviar y recibir mensajes utilizando SMS o Cell Broadcast Service (CBS) en redes GSM. La librería se puede incluir en móviles que soportan MIDP 1.0 aunque su funcionamiento depende de las capacidades del móvil. Existen liberías para Bluetooth, Infrarrojo y Wifi aunque su funcionamiento depende de las capacidades del móvil y las características de la librería. Ninguna es requerida en la especificación. Rendimiento J2ME, en comparación con WAP, presenta un alto rendimiento ya que las aplicaciones se ejecutan en el móvil evitando el acceso continuo e ineficiente con el. 17.

(19) servidor y reduciendo las necesidades de ancho de banda ya que la única información que se transmite son los datos. Los procesos que requieren criptografía podrían deteriorar el rendimiento aunque se han realizado pruebas que demuestran que el tiempo necesario es imperceptible para el usuario. Análisis Las ventajas más importantes de J2ME son: − La interfaz gráfica que facilita la interacción con el usuario. − Alto rendimiento a nivel de comunicación y procesamiento ya que reduce el intercambio de información con el servidor. − La capacidad propia de almacenamiento permite implementar sistemas de seguridad y criptografía avanzados. − Las aplicaciones funcionan en cualquier móvil que soporte J2ME. − Java es una tecnología altamente aceptada. Las desventajas son: − La aplicación y sus actualizaciones se deben descargar al móvil. Este proceso puede ser engorroso para el usuario. − El inicio de la transacción y el establecimiento de la sesión con el comercio o la contraparte no es sencillo ya que no existe un método eficiente para enviar información al móvil. Se debe complementar con otras tecnologías como SMS. − La aceptación de la tecnología aun no es total, de hecho, la mayoría de móviles no soportan J2ME. SMS (Short Message Service) SMS es un servicio prestado por todos los operadores de telefonía móvil que permite la transmisión de mensajes de texto simples compuestos de máximo 160 caracteres sobre una plataforma de ancho de banda reducido desde y hacia dispositivos inalámbricos. Utiliza un SMSC (Short Message Service Center) que actúa como un sistema de almacenamiento y enrutamiento de los mensajes para garantizar la entrega de los mismos a través de la red móvil del operador. Al igual que con otras tecnologías que estamos analizando, iniciaremos con un ejemplo de cómo se realizaría una transacción utilizando SMS y después analizaremos los requerimientos más importantes sobre la tecnología. Ejemplo: realizar un pago Este ejemplo describe el escenario en el cual una persona va a pagar en un comercio por un bien, servicio o contenido con su móvil utilizando SMS. 1. El comercio inicia la transacción identificando al móvil e ingresando el valor que el usuario debe pagar. La identificación del móvil puede variar ampliamente. Se puede utilizar código de barras, el MSISDN, etc.. 18.

(20) 2. El usuario recibe un mensaje en su móvil con las características del pago: establecimiento, valor a pagar, etc. Adicionalmente en el mensaje se le pide devolver el PIN. 3. El usuario responde el mensaje ingresando su PIN para confirmar la transacción. 4. La transacción es realizada y tanto el comercio como el usuario reciben una confirmación. Para facilidad en el sistema, el usuario deberá seleccionar previamente el método de pago que desea utilizar cuando haga transacciones con su móvil. Esto se puede hacer directamente en la entidad bancaria o a través de una interfaz WEB. Facilidad de uso Como se puede ver en el ejemplo, realizar un pago es un proceso muy simple para el usuario. Sin embargo este proceso se hace más complicado cuando el usuario inicia alguna operación transaccional debido a los comandos que debe ingresar en el mensaje para que el servidor transaccional entienda la operación. Por ejemplo, cuando el usuario desee transferir dinero a otra persona deberá ingresar la identificación del tercero (por ejemplo su MSISDN) y el monto a transferir. Esta operación se podría ver reflejada en el siguiente comando: 3158546598 15000 3158546598 Æ MSISDN del tercero. 15000 Æ valor a transferir. Este tipo de comandos podría ser dificultar la aceptación por parte de los usuarios aunque su impacto se puede reducir con campañas que muestren como realizar cada transacción. Costo El único costo adicional en el que incurriría el usuario utilizando SMS son los mensajes que se intercambien que podrían ser de 3 a 6 dependiendo del tipo de la transacción. Sin embargo, también existe la opción de que la entidad financiera asuma los costos de los mensajes ya que muy probablemente se los cobre al usuario en su cuota de manejo. Seguridad La seguridad en SMS comprende la transmisión segura de la información entre el móvil y el servidor transaccional, la autenticación y el ocultamiento de la información confidencial del usuario en el móvil y el operador. Criptografía SMS utiliza las redes GSM o CMDA como medio de transporte entre los móviles y el SMSC. El riesgo de que la información sea interceptada por terceros es mínima debido a la dificultad de decodificar la información en este tipo de redes.. 19.

(21) Adicionalmente, la comunicación entre el operador y el servidor transaccional se puede hacer utilizando un canal seguro o VPN. Autenticación Cuando un usuario conduce una transacción a través de SMS deberá autenticarse para completarla. Aunque la autenticación se podría hacer utilizando un certificado digital o alguna otra forma de verificación, lo más común será utilizar un PIN, que en conjunto con el MSISDN proporcionarán las credenciales necesarias para autenticar al usuario. El problema de este método es que el mensaje puede quedar guardado en el móvil y en caso de que sea robado, esta información podría estar disponible a terceros que únicamente podrían realizar las transacciones desde el móvil del verdadero usuario ya que simular ser otro móvil no es soportado por SMS. Por otro lado existe un riesgo asociado a los operadores ya que los mensajes quedan guardados en los registros del SMSC19. Existen varios métodos para solucionar estos problemas que pueden ser utilizados conjuntamente. Adicionalmente, la plataforma transaccional deberá restringir la cantidad de dinero que se puede gastar en un determinado lapso de tiempo para evitar grandes fraudes. PIN parcial La idea es que la plataforma transaccional solicite al usuario en el mensaje parte de su PIN indicando el ingreso de ciertos dígitos de forma aleatoria. Por ejemplo, “por favor ingrese los dígitos 1, 3 y 5”. Cada vez los dígitos requeridos cambiarían. Esto ocultaría parte del PIN y haría más difícil su descubrimiento a terceros. Sobrescribiendo el “mensaje de solicitud” Una vez que el usuario ingresa su PIN recibirá una confirmación de la plataforma transaccional notificándolo del éxito o fracaso de la transacción. Este mensaje de notificación se puede configurar para que sobrescriba el mensaje de solicitud del PIN que se envío anteriormente ocultando los dígitos que se solicitaron al ingreso. Nota: esta característica es opcional del móvil / SIM y no siempre está disponible. Sin embargo, se encuentra en la mayoría de móviles modernos. En caso de que el móvil sea robado será mucho más difícil para el tercero descubrir la combinación correcta del PIN y adicionalmente, la plataforma transaccional podría deshabilitar la cuenta después de un número determinado de ingresos incorrectos.. 19 SMS Center: Nodo de los operadores encargado del envío y recepción de todos los mensajes de textos que pasan por su red. 20.

(22) USSD Una solución muy efectiva es el uso de GSM USSD como método de interacción con el usuario. USSD 20(Unstructured Supplementary Service Data) es un canal de datos disponible en las redes de los operadores que permite iniciar sesiones con un servidor USSD y provee un mecanismo de “request - response” basado en mensajes que es mucho más efectivo que SMS ya que efectivamente establece una sesión con el usuario. La desventaja potencial de esta solución es que el operador de telefonía móvil deberá soportar la tecnología. Aplicaciones USSD se han implementando con gran éxito en países como Japón pero en Colombia esta tecnología no está aun disponible. WAP Push / SMS WAP Push se puede emplear como mecanismo de autenticación. El usuario interactuaría con el sistema por medio de SMS pero en el momento de la autenticación se establecería una sesión WAP Push para solicitar el PIN. La ventaja de este método es que no se deja rastro en el móvil ya que se utiliza WAP como método de comunicación. Sin embargo, existe la desventaja que el servicio estaría limitado a móviles que soporten WAP Push y no sería tan interoperable como SMS. Interoperabilidad Debido a la diversidad de móviles que existen actualmente en el mercado, la interoperabilidad es un requerimiento fundamental para el sistema de transacciones móviles. SMS tiene la ventaja que es soportado por todos los operadores y por el 99% de los móviles actualmente en el mercado. Rendimiento SMS es un sistema de comunicación muy eficiente aunque depende del SMSC y del servidor transaccional. A diferencia de J2ME, donde parte del procesamiento se puede hacer en el móvil, SMS es únicamente un canal de comunicación y todo el procesamiento se debe hacer en el servidor aumentando la carga del mismo. Hasta hace poco en Colombia los operadores no mantenían una buena calidad del servicio en sus SMSC ya que estaban totalmente concentrados en los servicios de voz. Sin embargo, con la llegada de los servicios interactivos a través de SMS, los operadores se han visto obligados a mejorar sus servidores y prestar un mejor servicio. Análisis Las ventajas más importantes de SMS son: - Todos los operadores lo soportan. 20 Tecnología similar a SMS. Usado en Mobipay (Ver soluciones existentes en el mundo de este documento para más información).. 21.

(23) -. El 99% de los móviles lo soportan. El impacto de la tecnología es muy bajo ya que SMS es un servicio altamente aceptado. El establecimiento de la sesión entre las partes (usuarios y comercios) es muy sencillo ya que SMS es un medio eficaz de comunicación con los móviles.. Las desventajas son: - Existe un mayor riesgo en la seguridad a menos de que se utilicen medios alternativos que limitan la utilización del servicio. - La interfaz no es fácil de manejar en ciertos escenarios como transferencias de fondos. - El valor de cada mensaje es alto aunque los precios tienden a bajar. SAT (Sim Application Toolkit) Cualquier móvil GSM o UMTS funciona utilizando una tarjeta inteligente llamada SIM con las siguientes características: • • • • • •. Provee un ambiente seguro para almacenar información confidencial. Administra la información necesaria para identificarse y autenticarse con el operador. Almacena números celulares y mensajes de texto. Facilita los servicios de “roaming”. Habilita servicios de valor agregado y comercio móvil. La interfaz entre la SIM y los móviles está estandarizada.. SAT es un estándar que permite implementar servicios de valor agregado y financieros en móviles GSM extendiendo la funcionalidad de la SIM. Es una tecnología emergente aunque con gran potencial. Su arquitectura incorpora servicios de seguridad que brindan una excelente plataforma para servicios transaccionales. Desafortunadamente las implementaciones de SAT no están estandarizadas entre los proveedores de tarjetas y las aplicaciones no son portables. Adicionalmente, la tarjeta tiene memoria limitada que normalmente oscila entre 16k y 32k. Al igual que con otras tecnologías que estamos analizando, iniciaremos con un ejemplo de cómo se realizaría una transacción utilizando SAT y después analizaremos los requerimientos más importantes para esta tecnología. Ejemplo: realizar un pago Este ejemplo describe el escenario en el cual una persona va a pagar en un comercio por un bien, servicio o contenido con su móvil utilizando SAT. 1. El comercio inicia la transacción identificando el móvil e ingresando el valor que el usuario debe pagar. La identificación del móvil puede variar ampliamente. Se puede utilizar código de barras, el MSISDN, etc. 2. La aplicación SAT se inicia automáticamente y le muestra al usuario las características de pago: establecimiento, valor a pagar, etc. Adicionalmente le solicita al usuario el método de pago.. 22.

(24) 3. El usuario ingresa el método de pago y su PIN. 4. La transacción es finalizada y un mensaje de confirmación es enviado tanto al usuario como al establecimiento. SMS se utiliza como método de transmisión de la información entre los móviles y el servidor transaccional. La ventaja de SAT respecto a SMS es la seguridad que implementa y la facilidad de uso para el usuario en el momento de la transacción. Facilidad de uso Teniendo en cuenta que SAT es una aplicación que se instala en el móvil, este requerimiento se debe dividir en dos aspectos fundamentales: la descarga de la aplicación (o actualizaciones) y la ejecución de la transacción. Existen diferentes alternativas para instalar SAT en los móviles aunque la más conveniente y la única que se puede implementar de forma remota es a través de SMS o CBS. Adicionalmente, la aplicación podría estar instalada cuando el usuario compra el móvil aunque esto requiere de un acuerdo entre el proveedor de la solución y los operadores celulares. La facilidad de uso en el momento de realizar la transacción es uno de los aspectos más importantes para el usuario. Entre todas las tecnologías analizadas, SAT tiene la mayor ventaja ya que utiliza SMS como medio de transmisión pero mejora la interacción del usuario con el servidor transaccional utilizando una interfaz gráfica con características similares a WAP. A diferencia de J2ME, donde el usuario debe iniciar la aplicación manualmente, la aplicación SAT se inicia automáticamente con la llegada del mensaje. Costo El único costo adicional en el que incurriría el usuario utilizando SAT son los mensajes SMS que se intercambien. Podrían ser de 3 a 6 dependiendo del tipo de la transacción. Sin embargo, también existe la opción de que la entidad financiera asuma los costos de los mensajes ya que muy probablemente se los cobre al usuario en su cuota de manejo. Seguridad SAT soluciona algunos problemas de seguridad que puede existir en WAP utilizando la tarjeta SIM. La información en la tarjeta está protegida de accesos no autorizados y de posibles cambios permitiendo que las aplicaciones se ejecuten en un ambiente seguro. Por otro lado, el estándar SAT provee mecanismos para garantizar la confiabilidad y la integridad de la información por medio del PIN y algoritmos criptográficos. Criptografía SAT soporta diferentes estándares criptográficos incluyendo triple DES. El proveedor del servicio instala la llave criptográfica antes de entregar el móvil al. 23.

(25) usuario garantizando que la llave nunca se transmitirá por la red. La integridad de la información se hace utilizando SHA o MDS 521.. Security. Security. Cada mensaje que viaja por la red es dividido en paquetes individualmente codificados utilizando encabezados de seguridad. La especificación de seguridad está a cargo de la organización 3GPP en el documento TS 03.48 y queda fuera del alcance de este documento. Existen variaciones en la implementación de cada proveedor de tarjetas y las aplicaciones también pueden adicionar elementos de seguridad adicionales no estandarizados. La siguiente figura tomada de la especificación muestra el sistema de seguridad utilizado en SAT.. Sending Application. Sending Entity. Transport Mech.. Receiving Entity. Receiving Application. Information flow. (e.g. a bank). (e.g. SMS-SC). (e.g. SIM resident application). (e.g. SIM). (e.g. USSD, SMS). (e.g. SIM). (e.g. SIM resident application). (e.g. SMS-SC). (e.g. a bank resident application) 22. Autenticación Existen diversas formas de autenticación que se pueden implementar en SAT. La más recomendable es la utilización del PIN que junto al MSISDN o certificado digital proporcionarán las credenciales necesarias para autenticar al usuario. Interoperabilidad Hasta el momento SAT provee las mayores ventajas respecto a otras tecnologías analizadas. Sin embargo, SAT es una tecnología emergente y por lo tanto no está completamente estandarizada entre los proveedores de tarjetas. Esto implica que la aplicación que se escriba para un proveedor no será compatible en las tarjetas de otro proveedor. 21. Algoritmos de cifrado que generan una llave para verificar integridad. Diagrama recuperado el 20 de Agosto de 2005, de http://www.langamers.it/ttt/ing/avvenuti/mcommerceSecurity.pdf 22. 24.

(26) Por otro lado, SAT depende de las redes GSM y actualmente en Colombia también contamos con una red CMDA 2000 proveída por Movistar aunque es muy probable que esta compañía migre su plataforma a GSM. Rendimiento SAT, así como J2ME, provee un alto rendimiento ya que las aplicaciones se ejecutan en el móvil evitando el acceso continuo e ineficiente con el servidor. Sin embargo, la transmisión de información entre los móviles y el servidor transaccional se hace utilizando SMS que aunque es un método muy eficiente depende de el SMSC y el servidor transaccional. Análisis Las ventajas más importantes de SAT son: • • • •. El diseño de SAT provee un gran componente de seguridad ideal para las operaciones transaccionales. Provee una interfaz gráfica que facilita la interacción con el usuario. Se utiliza SMS como método de transmisión de datos. A diferencia de J2ME, las aplicaciones se pueden ejecutar con la llegada de un mensaje lo que facilita el inicio de la sesión entre el móvil y el servidor transaccional.. Las desventajas son: • • • • •. Es una tecnología emergente y las aplicaciones no son portables entre tarjetas de diferentes proveedores. La utilización del PIN del celular y el PIN que deberá ingresar en el sistema transaccional puede ser confuso para el usuario. Únicamente existe soporte para redes GSM. Existe una estrecha relación entre el proveedor de la solución y los operadores. La memoria de la SIM es limitada y normalmente oscila entre 16k y 32k.. VoiceXML e IVR VoiceXML permite que personas comunes y corrientes accedan a Internet desde cualquier teléfono, solo marcando un número. La interacción del usuario con la aplicación web es por medio del habla, la cual no esta limitada para reconocer determinadas frases sino que el usuario puede hablar normalmente. IVR funciona de manera similar a VXML solo que es mucho mas limitado. Con IVR, el usuario esta limitado a interactuar únicamente con los botones numéricos del teléfono. Cabe notar, que todo lo que se pueda hacer con IVR, también se puede hacer con VXML.. 25.

(27) Para que una aplicación VXML sea puesta en producción, es necesario montarla en una plataforma especializada. Existen varios proveedores de esta plataforma, como lo son VOXEO23, INTERVOICE, VOICEGENIE, VOXPILOT, etc. El objetivo es analizar las ventajas y desventajas de utilizar VXML como tecnología en la solución de transacciones móviles. Iniciaremos con un ejemplo de cómo se realizaría una transacción utilizando VXML y analizaremos los requerimientos más importantes. Ejemplo: realizar un pago Este ejemplo enumera la secuencia de eventos que suceden en el escenario donde un usuario va a pagar por un bien, servicio o contenido remota o localmente con su móvil utilizando VXML. 1. El usuario decide realizar la compra 2. El establecimiento inicia la transacción con el número del móvil del usuario. 3. El usuario recibe una llamada telefónica a su móvil de la aplicación. 4. La aplicación solicita la autenticación del usuario que puede ser a través de una contraseña hablada o un PIN numérico. 5. La aplicación valida la información del usuario y se realiza la transacción. En este ejemplo, también sería válido que el usuario iniciara la transacción haciendo la llamada directamente él, pero sería necesario entonces introducir algún código o identificación del establecimiento. Tal como esta en el ejemplo, la transacción tendría un costo adicional que sería la llamada echa al móvil. Ahora analizaremos los requerimientos más importantes aplicados a VXML. Facilidad de uso Este requerimiento comprende la facilidad del uso de la aplicación una vez iniciada la transacción. Este requerimiento es muy importante ya que el usuario no cuenta con ningún tipo de interfaz visual para guiarse mejor. La facilidad de uso de esta tecnología depende de que tan clara es la explicación dada al usuario y la duración de la llamada, entre mas corta y menos tenga que hacer el usuario, mejor. Tiene una gran ventaja sobre SMS, J2ME, WAP, etc. y es que debido a que el IVR existe hace mucho tiempo, es mucho más natural para las personas interactuar de esta forma con su teléfono. Sin embargo, VXML presenta un problema. Es posible que hayan personas a las que se les dificulte más la pronunciación correcta de las palabras para que estas puedan ser reconocidas por el traductor. 23. Para más información acerca de esta plataforma, ver http://www.voxeo.com/. 26.

(28) Costo Es evidente que esta es la solución más barata posible ya que el único gasto en el que incurriría el usuario (Si es que es él quien inicia la transacción), sería una llamada telefónica que duraría muy pocos minutos. El valor de esta llamada dependería de las entidades bancarias y del integrador. Si comparamos este costo con el costo de una solución echa en WAP por ejemplo, la diferencia es enorme. Seguridad PLATAFORMA Este aspecto de seguridad es un poco delicado ya que depende básicamente de la plataforma donde este puesta la aplicación. Entonces a continuación se analizará la seguridad de una plataforma específica. Se tomará como ejemplo la plataforma de VOXEO. Primero que todo, hay que tener en cuenta que la plataforma VOXEO provee una interfaz al cliente por medio de una llamada telefónica. Cada llamada representa una instancia única (similar al comportamiento de un browser web). Para cada instancia, se pueden configurar “cookies” o manejar sesiones agregándole parámetros al URL. Además, la plataforma VOXEO asigna un único ID de sesión a cada llamada. A continuación, un ejemplo de cómo seria el manejo de sesiones de una manera segura: http://www.myphoneapp.com/app.jsp? session.callerid=14075551212&session.calledid=18005558888&session.sessio nid=a7b4f6g3d912de9ba0c9d6a3b...24 Una vez el manejo de sesiones este listo, es posible añadir otra seguridad adicional, por medio de un PIN, para controlar el acceso a la aplicación. Lo más aconsejable, es manejar ambas seguridades, la de manejo de sesiones y la autenticación por PIN. En VoiceXML y CallXML, cada sesión SSL es también única a la instancia del browser del que fue iniciada. Lo mismo ocurre en CCXML. Adicionalmente a SSL, VOXEO también soporta conectividad a través de IPSEC VPN. En esta capa, la información no maneja seguridad por medio de sesiones, por lo cual es recomendable combinarla con cifrado de sesiones para un mayor grado de seguridad.. Interoperabilidad. 24. Recuperado el 3 de Septiembre de 2005, de http://www.vxml.org/frame.jsp?page=security.htm. 27.

(29) Debido a la diversidad de móviles que existen en el mercado, la interoperabilidad es un requerimiento fundamental para el sistema de transacciones móviles. VXML tiene la ventaja que es compatible con el 100% de los teléfonos móviles. Esta es la ventaja más grande que tiene VXML. Rendimiento El rendimiento depende de la plataforma en la que se monte la aplicación. En teoría, si la plataforma es robusta, la solución debería funcionar muy bien. Un problema es que como los comandos del usuario son hablados, es posible que a veces el sistema no reconozca el comando de voz del usuario y a este le toque repetirlo al menos unas 2 veces. Además, la información que recibe el usuario de la aplicación es hablada, lo que hace que sea un poco demorado el proceso. En términos generales, el rendimiento es bueno siempre y cuando se tenga una plataforma robusta. Con VOXEO por ejemplo, no habría problema. Análisis Las ventajas más importantes de VXML son: − Alto rendimiento a nivel de comunicación y procesamiento de la información que viaja entre cliente y servidor. El tráfico de VOZ es muy liviano. − Provee alto nivel de seguridad. − Las aplicaciones funcionan en cualquier móvil. − Es muy sencillo de usar. − Para la mayoría de la gente, es una tecnología mucho más natural que SMS, J2ME y WAP. − El inicio de la transacción es muy simple. Sólo consiste en una llamada telefónica.. Las desventajas son: − No existe interfaz gráfica. − El reconocimiento de voz puede fallar y volverse tedioso para el usuario final. Wireless Application Protocol (WAP) WAP es una especificación de un conjunto de protocolos de comunicación con el fin de estandarizar la forma en que dispositivos móviles se conecten a Internet. En el pasado, el acceso a Internet se limitaba a los computadores, pero con este nuevo protocolo (WAP), es posible acceder a Internet desde un teléfono celular. Los operadores celulares brindan esta posibilidad de acceso a Internet desde sus redes hace algunos años en Colombia. Las redes GPRS y CDMA de datos brindan velocidades cercanas a los 140 kbps lo cual es bastante rápido. Si lo comparamos con el acceso telefónico, este vendría siendo unas 4 veces más rápido.. 28.

(30) WAP nació gracias a las siguientes compañías: Ericsson, Motorola, Nokia, y Unwired Planet (ahora Phone.com). El Wireless Markup Language (WML) es usado para crear páginas que pueden ser vistas a través de WAP. El objetivo es analizar las ventajas y desventajas de utilizar WAP como interfaz en la solución de transacciones móviles. Iniciaremos con un ejemplo de cómo se realizaría una transacción utilizando WAP y analizaremos los requerimientos más importantes. Ejemplo: Consulta de saldo Este ejemplo enumera la secuencia de eventos que suceden en el escenario donde un usuario va a consultar el saldo de su cuenta bancaria de cualquier entidad. Para este ejemplo, asumiremos que el usuario tiene contratado un plan de datos con su operador celular. 1. El usuario inicia sesión WAP en su teléfono celular. 2. El usuario debe ingresar al portal WAP donde realizará la consulta. 3. El usuario ingresa su nombre de usuario y contraseña con el fin de autenticarse. 4. Ya el usuario tiene acceso a su información bancaria. 5. Ahora el usuario solo debe seleccionar la cuenta para que le despliegue su saldo. También se puede tener acceso a otros servicios tales como transferencias bancarias, eso depende de la aplicación. En este ejemplo, el cliente es responsable de iniciar la consulta ya que es un requerimiento que él esta solicitando. Ahora analizaremos los requerimientos más importantes aplicados a WAP. Facilidad de uso Este requerimiento comprende la facilidad en el uso del teléfono celular mediante el cual se esta accediendo a la página a través de WAP. La facilidad de uso en el momento de la transacción es el factor más importante para el usuario. Las paginas WML, a diferencia de SMS, proveen una avanzada interfaz gráfica que brinda una ventaja evidente siempre y cuando la navegación sea sencilla, rápida e intuitiva. WAP provee una ventaja sobre J2ME, y es que sin que el usuario inicie una sesión, esta se puede iniciar automáticamente usando WAP PUSH. WAP PUSH es básicamente el envío de un mensaje SMS con una dirección de Internet para que el usuario ingrese. Esta ventaja se hace evidente al momento de hacer una compra, donde el usuario no tiene que ingresar a ningún portal sino que por medio de WAP PUSH se le indica que debe hacer y todo se hace más simple. El problema con este requerimiento es que solo el 5% de los teléfonos celulares en Colombia tienen acceso a WAP entonces la mayoría de la gente desconoce como funciona este servicio.. 29.

(31) Costo El costo de esta implementación a través de WAP puede llegar a ser costoso ya que a diferencia de J2ME, con WAP no existe nada corriendo en el celular y todo debe ser traído a través de Internet. El precio promedio de los operadores en Colombia, por KB transmitido es de 15 pesos. Por otro lado, los operadores brindan planes de datos donde el KB sale más económico. La parte buena de esto es que los precios de datos son cada vez más baratos y se espera que continúen bajando. Seguridad La solución debe proveer comunicación segura desde el móvil al servidor transaccional para toda información confidencial que se deba transmitir. Debe implementar mecanismos de autenticación o verificación para identificar al usuario. SSL Y WTLS Secure Sockets Layer (SSL) es usado en Internet masivamente y también puede aplicarse al ambiente WAP. SSL es usado únicamente entre el servidor web y el “Gateway” WAP. Entre el “Gateway” WAP y el dispositivo móvil se usa otro protocolo llamado Wireless Transaction Layer Security (WTLS). WTLS es especializado para ambientes inalámbricos. SSL no es compatible directamente con WTLS, entonces el “Gateway” debe descifrar la información que viene en SSl para luego volverla a cifrar usando WTLS y así podérsela pasar al dispositivo móvil. Por lo tanto, al interior del “Gateway”, la información queda desprotegida. El siguiente diagrama muestra el modelo antes mencionado: | | [WAP device]------------[WAP gateway]-----------[Content server] <---WTLS--->{unprotected}<---SLL---> | | (Firewall) | | (Firewall)25 Con base al modelo anterior, se puede ver que la información es segura en todo momento menos en el Gateway WAP. Los operadores celulares son los dueños de este Gateway y por ende ellos serian los responsables de cualquier manipulación de la información que pase por su Gateway. Por otro lado, los operadores celulares pueden ser victimas a ataques que podrían comprometer la información dentro del Gateway. A continuación, se ve un modelo que brinda seguridad desde ambos extremos de la transacción (Movil – Servidor):. 25. Recuperado el 4 de Septiembre de 2005, de http://www.123wapinfo.com/faqs/security/Default.asp?4. 30.

(32) | | [WAP device]-----------------------------------["WAP server" (acting as WAP gateway)] <---------------WTLS---------------> | | (Firewall) | | (Firewall)26 El problema con este modelo es que el Gateway ya no hace parte del operador celular y si el usuario requiere de algún otro servicio que no sea simulado por el servidor, seria necesario una reconfiguracion en su teléfono celular. En algunos modelos de teléfonos esta configuración es sencilla, pero en otros es muy complicada. El problema ya esta resuelto pero sería mejor si se pudiera hacer de otra forma. Una solucion alternativa seria la siguiente: "Passthrough mode" | | [WAP device]------------[WAP gateway]-----------["WAP server"] <---------------WTLS---------------> | | (Firewall) | | (Firewall)27 Con este modelo, el Gateway solo tendría que pasar la información de un lado al otro sin modificarla. Esto NO esta implementado todavía pero sería la solución óptima. Autenticación La forma más simple de autenticación en WAP es con un nombre de usuario y contraseña. Con el modelo anterior esta forma de autenticación no tendría problema ya que la información viajaría siempre cifrada. Interoperabilidad Debido a la diversidad de móviles que existen en el mercado, la interoperabilidad es un requerimiento fundamental para el sistema de transacciones móviles. WAP tiene la ventaja de que funciona independientemente del sistema operativo del dispositivo móvil. Sin embargo, si el móvil no soporta WAP o el cliente no tiene servicio de datos activado, evidentemente tendrá acceso a la aplicación transaccional. Desafortunadamente, sólo el 5% de los móviles en el mercado soportan WAP y muy pocos usuarios lo saben utilizar.. 26. Recuperado el 4 de Septiembre de 2005, de http://www.123wapinfo.com/faqs/security/Default.asp?4. 27. Recuperado el 4 de Septiembre de 2005, de http://www.123wapinfo.com/faqs/security/Default.asp?4. 31.

(33) En cuanto al contenido de las páginas WML, es necesario que sean soportadas por el 100% de los teléfonos celulares con WAP. Por experiencias vividas, sabemos que esto es complicado de lograr porque los simuladores WAP son muy distintos al comportamiento real de un teléfono celular. Rendimiento El rendimiento depende básicamente de la velocidad de navegación que ofrezca el operador celular. En Colombia, Comcel acaba de montar la tecnología EDGE la cual brinda un ancho de banda de 140 kbps, Movistar cuenta con CDMA que brinda un ancho de banda de 153 kbps y OLA tiene GPRS que brinda un ancho de banda de 54 kbps. Con estas velocidades se puede trabajar sin problema para realizar transacciones pero sigue siendo mucho mas lento que a través de SMS o usando J2ME. El problema de usar WAP reside en que toda la información debe viajar y se hace muy pesado, lo cual afecta directamente al rendimiento de la solución. Los procesos que requieren criptografía podrían deteriorar el rendimiento auque esta es la forma en la que se debe hacer y no se puede modificar. Análisis Las ventajas más importantes de WAP son: − La interfaz gráfica que facilita la interacción con el usuario. − WAP PUSH facilita el inicio de una transacción automáticamente. − Las aplicaciones funcionan en cualquier móvil que soporte WAP. Las desventajas son: − Todo el contenido viaja a través de Internet y compromete el rendimiento. − El inicio de la transacción y el establecimiento de la sesión con el comercio o la contraparte no es sencillo ya que no existe un método eficiente para enviar información al móvil. Se debe complementar con otras tecnologías como SMS. − La aceptación de la tecnología aun no es total, de hecho, la mayoría de móviles no soportan WAP. − La cultura colombiana no esta adaptada al uso de WAP. SOLUCIONES YA EXISTENTES EN EL MUNDO A continuación, se expondrá un caso exitoso de la implementación de una solución de pagos móviles en España. El sistema se llama Mobipay 28y es la solución pionera a nivel mundial de este tipo de transacciones. Su inicio fue a mediados del año 2002. Mobipay es un sistema de pagos a través del móvil promovido de forma conjunta por la mayor parte de las entidades financieras españolas, las tres compañías de. 28. Sistema implementado en España. Para más información, ver http://www.mobipay.es. 32.