- Introducción
El tema del pago en redes abiertas ha adquirido una gran relevancia en los últimos años debido al creciente desarrollo del comercio electrónico. Los sistemas de pago electrónicos deben proporcionar la infraestructura necesaria para facilitar el pago en las transacciones realizadas a través de la red Internet. Son tan importantes y necesarios que, de no llegar a soluciones satisfactorias, el desarrollo del comercio electrónico se podría ver seriamente frenado.
Los sistemas convencionales de pago utilizados en el mundo basado en papel no se adaptan perfectamente al mundo electrónico. Este problema debe ser abordado y solucionado desde una perspectiva pluridisciplinar (jurídica, técnica, económica, etc.). A priori puede parecer chocante el hecho de que esquemas de pago que per se son electrónicos, no encajen perfectamente y de forma inmediata como esquemas de pago para las transacciones realizadas en Internet. Nos estamos refiriendo, concretamente, a los sistemas de pago basados en tarjeta. Y es que no podemos olvidar, que el hecho de que los intercambios sean cara a cara en el comercio presencial tradicional, junto con el justificante escrito en soporte papel y con firma manuscrita, suponen elementos de seguridad que deben tener su traducción o equivalente en el mundo electrónico.
De todas formas, algunos de los sistemas de pago del mundo real (por contraposición al mundo virtual) son más o menos aceptados como métodos de pago en Internet (como es el caso de las tarjetas de crédito). No obstante, su uso se ve frenado por las reticencias de los usuarios clientes, que no acaban de confiar en la seguridad de las transacciones realizadas exclusivamente por medios electrónicos. Para los vendedores tampoco son la solución ideal. Por ejemplo, en el caso concreto de las tarjetas de crédito, hasta fechas muy recientes, los costes por transacción eran muy elevados, hecho que las entidades financieras justificaban por el alto riesgo que suponían este tipo de operaciones. Desde el punto de vista del vendedor existe el problema de que no tiene garantía de la identidad del usuario de la tarjeta, que puede no ser su titular legítimo. Este riesgo es un motivo adicional para que los potenciales vendedores sean reacios a aceptar estos nuevos medios de pago. Las reticencias de los clientes conducen a un ritmo de ventas inferior al esperado, lo que supone un fracaso para el empresario que decide utilizar las nuevas tecnologías para desarrollar plataformas de comercio electrónico.
La criptografía es un elemento indispensable para proporcionar seguridad a las transacciones electrónicas, y más concretamente al pago electrónico basado en tarjeta de crédito. En los siguientes apartados se describirán dos protocolos concretos (SSL y SET) que deberían servir para aumentar la confianza de los usuarios en los nuevos medios de contratación electrónicos. - SSL
Algunas implementaciones del pago con tarjeta de crédito relacionadas con transacciones electrónicas a través de Internet, obligan al comprador a enviar los datos de la tarjeta por un canal diferente a la propia red de redes (transmisión por fax o comunicación telefónica). Una alternativa a estas soluciones sería enviar los datos de la tarjeta de crédito por medio de una comunicación segura a través de Internet, y tratar la transacción en su parte de validación por medios convencionales o ligeramente modificados (el llamado TPV -Terminal Punto de Venta- virtual).
Para que efectivamente la transferencia sea segura son necesarios dos servicios de seguridad. Por una parte deben cifrarse las comunicaciones entre comprador y vendedor para evitar que posibles atacantes puedan interceptar los detalles de la tarjeta de crédito. Por otra parte, el vendedor debe autenticarse de tal manera que no sea posible que un atacante pueda suplantarle, con el objetivo de obtener los datos de la tarjeta del cliente. También sería deseable que el comprador se autenticase, pero ni en las ventas a distancia (en el mundo real) ni en los pedidos por vía telefónica, se exige este requisito. Generalmente la autenticación del cliente suele dejarse para la etapa de entrega del producto. Este sistema sólo es útil para el comercio de bienes materiales, pues en el caso de bienes o servicios digitales no se produce la deseada personación que permita autenticar al comprador. De esta manera ya estamos estableciendo un primer límite al posible uso de un sistema sin autenticación previa del comprador, a no ser que el vendedor quiera asumir el consiguiente riesgo.
En la red Internet, los anteriores servicios de seguridad (confidencialidad de la comunicación y autenticación del servidor) se proporcionan habitualmente con el uso del protocolo SSL (Secure Socket Layer). SSL es un protocolo de propósito genérico que permite el establecimiento de conexiones seguras entre entidades correspondientes a protocolos de nivel de aplicación (login remoto, correo electrónico, transferencia de ficheros, etc.), aunque seguramente el protocolo de aplicación que más viene utilizando SSL es el protocolo http (hypertext transfer protocol) utilizado en el web. El protocolo SSL fue desarrollado por la compañía Netscape en el año 1994, habiendo evolucionado hasta una última versión que recibe el nombre de TLS (Transport Layer Security), aunque la más utilizada en este momento es la versión 3.0 de SSL.
En SSL antes de proteger la información que ha de ser intercambiada (entre la que se puede encontrar los datos de la tarjeta de crédito) se produce una negociación entre el programa que utiliza el comprador (típicamente un navegador) y el servidor de comercio electrónico del vendedor. La secuencia, de forma resumida, es como sigue:
En el primer paso el navegador del comprador envía un valor aleatorio, uno de los elementos que se utilizará para generar el material criptográfico necesario, y un identificador de la sesión, que podrá ser útil para evitar renegociaciones en transacciones cercanas en el tiempo entre las mismas entidades. El último argumento es una lista ordenada, por orden de preferencia del usuario, de algoritmos criptográficos. Deben negociarse: un algoritmo de clave simétrica para conseguir el servicio de confidencialidad (por ejemplo DES, 3DES, IDEA, RC2, RC4, etc.), un algoritmo para el servicio de autenticación y de intercambio de claves (por ejemplo RSA o Diffie-Hellman), y finalmente un algoritmo para garantizar la integridad de los datos intercambiados (por ejemplo, MD5 o SHA).
En el segundo paso el servidor del vendedor también envía un valor aleatorio, que se utilizará para generar el material criptográfico necesario, y el identificador de la sesión que envió el navegador. El último argumento es el conjunto de algoritmos criptográficos que ha escogido el servidor, de entre los propuestos por el cliente. Si entre los algoritmos propuestos por el cliente no hubiera uno de cada servicio válido para el servidor, debería abortarse la sesión.
A continuación el servidor envía al navegador un certificado de clave pública. Se trata de un documento electrónico que vincula la clave pública del vendedor, con la identidad del mismo. De esta manera el comprador puede tener la garantía de que está dialogando con una máquina bajo el control del vendedor que posee el nombre de dominio al que se ha conectado.
En el tercer paso, el navegador genera un parámetro secreto que deberá ser conocido por el servidor, pero sólo por el servidor. Para que así sea, cifra este valor con la clave pública del servidor, pues de esta manera sólo él, con su clave privada, podrá tener conocimiento de ese parámetro secreto. A partir de este parámetro secreto (y los valores aleatorios de los primeros pasos) ambas entidades generan claves secretas de sesión (una para cada sentido) y claves secretas de integridad (también una para cada sentido de la comunicación). Una vez que se han generado estas claves, ya puede empezar la fase de intercambio de datos. El uso de la criptografía simétrica y de las funciones de integridad con parámetro secreto, permitirá que la comunicación de los datos sea confidencial, con el servicio de integridad, y con autenticidad (aunque generalmente sólo del servidor). - SET
El ámbito del protocolo SET se ciñe a la fase de pago de las transacciones electrónicas. Las especificaciones de este protocolo aclaran que las funciones para la fase de compra, negociación del precio, selección del método de pago, etc., deben ser desarrolladas por otros protocolos. SET sólo interviene una vez que el comprador ha decidido qué va a comprar, a qué precio, y que va a utilizar una tarjeta para realizar el pago.
En una transacción por vía telefónica, el comprador proporciona los datos de su tarjeta al comerciante, el cual contacta con su entidad financiera con el objetivo de obtener la autorización del pago. Esta entidad financiera, a su vez, puede obtener la autorización de entidad que emitió la tarjeta a través de las redes financieras operadas por la asociación de tarjetas (por ejemplo, Visa o MaterCard). Estas redes privadas hace tiempo que existen y utilizan protocolos propietarios que operan sobre enlaces dedicados con mecanismos de seguridad adecuados en operación. Por tanto, existe una infraestructura de enlaces y ordenadores para procesar las transacciones. De hecho, SET asume la existencia de estas redes y sólo especifica las reglas de diálogo entre el comprador y el vendedor, y entre el vendedor y una entidad denominada pasarela de pago. El modelo previsto en SET, con sus participantes, es el siguiente:
El protocolo SET consiste en un conjunto de pares de mensajes petición / respuesta, como puede verse a continuación:
Uno de los objetivos de SET es que el vendedor no tenga acceso a los datos financieros del comprador, y que la entidad financiera no tenga acceso a los datos relativos al producto o servicio adquirido, proporcionando además el servicio de no repudio de las partes implicadas en la transacción. Para conseguir los anteriores objetivos es preciso utilizar técnicas de criptografía clásica y de criptografía asimétrica.
El proceso de SET se inicia tras la presentación al comprador de un formulario de orden de compra rellenado, cuyo contenido haya sido aceptado. Cómo se han seleccionado los productos y cómo se presenta la orden de compra al usuario queda fuera del ámbito de SET. El mensaje PInitReq sirve para indicar al vendedor que el comprador está preparado para pagar los bienes o servicios acordados, y contiene la siguiente información:
idioma: idioma que utiliza el comprador
- ID_TC: un identificador local de la transacción
- retoC: un valor numérico que será utilizado en la respuesta del vendedor para garantizar que la transmisión es "en tiempo real"
- IDmarca: la marca de la tarjeta que se utilizará para realizar el pago (por ejemplo, Visa o MasterCard)
- IDbanco: número de identificación del banco del comprador
- Tras la recepción del anterior mensaje. el vendedor envía el mensaje PInitRes, que contiene los siguientes datos:
- ID_T: el vendedor genera un identificador global de la transacción que combinado con el identificador del comprador sirve par formar un identificador de transacción único, que identificará una compra específica respecto de los demás posibles mensajes de compra recibidos
- fecha: el día y hora en el que se realiza la transacción
- retoC: el valor numérico que envió el comprador
- retoV: un valor numérico generado por el vendedor
- CertF: el certificado de clave pública de la entidad financiera del vendedor
- CertV: el certificado de clave pública del vendedor
Los mensajes de orden de compra ejecutan el pedido efectivo que el comprador realiza al vendedor. Es el par de mensajes más complejo del protocolo de pago. El comprador envía dos elementos, la información del pedido (OI por Order Information) y las instrucciones de pago (PI por Payment Instructions). El elemento OI contiene los datos que identifican la descripción del pedido. El elemento PI contiene los datos de la tarjeta de crédito del comprador, y los identificadores de pedido y transacción. Este último elemento se cifra con la clave pública de la entidad financiera del vendedor, de tal manera que el vendedor no tendrá acceso a su contenido. Posteriormente se reenviará a la entidad financiera en la fase de autorización.
El elemento OI contiene la siguiente información (mucha de ella de la fase de inicialización):
OI = ID_T, retoC, retoV, IDbanco, IDmarca, H(pedido)
El uso del reto generado por el vendedor sirve para garantizar que se trata de un mensaje vinculado a la transacción en curso. El último elemento es un resumen de la información relativa al pedido:
pedido = descripción, cantidad, salt
El valor aleatorio salt es generado por el comprador para prevenir posibles ataques por fuerza bruta (o basados en diccionario). El parámetro cantidad indica el valor económico de la transacción.
Para construir el elemento PI son necesarios dos elementos. El primero son los datos de la tarjeta:
datos_tarjeta = núm_tarjeta, fecha_expiración, núm_secreto, nonce
donde núm_secreto es un número compartido entre el comprador, la pasarela de pagos y la entidad financiera del comprador; nonce es un valor aleatorio para evitar ataques de repetición y de fuerza bruta. El segundo elemento necesario es el resumen de la información relativa al pedido. Entonces, el elemento PI es de la siguiente forma:
PI = ID_T, H(pedido), cantidad, IDV, PUF(datos_tarjeta)
Obsérvese que para proporcionar mayor seguridad al intercambio, los datos correspondientes a la tarjeta han sido cifrados con la clave pública de la entidad financiera. Posteriormente también son cifrados con un algoritmo de criptografía simétrica (junto con otra información). También puede verse que en las instrucciones de pago no se encuentra directamente información del pedido, sino tan sólo un resumen del mismo, H(pedido).
En el mensaje PReq se utiliza un tipo de firma especialmente importante en el protocolo SET: la firma dual. Para generar esta firma debe procederse de la siguiente manera:
- obtener el resumen (aplicar una función hash) por separado de OI y PI
- concatenar los dos resúmenes y aplicar la función hash al resultado
- aplicar el cifrado de clave pública al anterior resumen ("firmar")
- adjuntar los resúmenes, H(OI) y H(PI), para que los destinatarios puedan verificar la firma dual sin necesidad de tener acceso al contenido de la parte del mensaje que no les corresponde
El proceso de autorización permite al vendedor verificar que el comprador tiene crédito para el pedido que ha realizado, y para obtener el permiso de cargo de la transacción a la tarjeta del comprador. En la petición de autorización el vendedor envía a su entidad financiera información relativa al pedido, firmada y cifrada. Las instrucciones de pago (PI) del comprador también se envían en esta petición. Más concretamente encontramos la siguiente información:
Info_auth = ID_T, fecha, cantidad, PI, H(pedido), H(OI), datos_vendedor, datos_comprador, firma_dual
Obsérvese que en la anterior información encontramos un resumen del pedido. La entidad financiera verificará que coincida con el contenido en las instrucciones de pago (PI). Si es así, la entidad financiera sabrá que el comprador y el vendedor están de acuerdo sobre los bienes o servicios y la cantidad a ser cargada. La firma dual sobre PI permite verificar que esta orden procede del comprador. El resumen de OI en la petición del vendedor demuestra el conocimiento de los datos del OI que va firmado en la firma dual, permitiendo demostrar el acuerdo en los datos del pedido sin necesidad de revelar estos datos a la entidad financiera. También se envían datos relativos al comprador, como la dirección de remisión de la factura (obtenidos por vías externas al protocolo SET), y otros relativos al vendedor.
Tras haber recibido la petición de autorización, la entidad financiera descifra las distintas partes del mensaje, verifica las firmas, y comprueba la consistencia entre los detalles del pedido enviado por el vendedor y los que se encuentran en las instrucciones de pago, PI. A continuación la entidad financiera obtiene la autorización a través de la red bancaria existente. Si recibe una autorización positiva de la entidad emisora del comprador, la entidad financiera del vendedor prepara el mensaje de respuesta de autorización para el vendedor, que incluye el código de autorización del emisor. La información contenida en la respuesta es:
Info_auth_res = ID_T, cantidad, código, datos_captura
Tras recibir una autorización correcta, el vendedor puede enviar los bienes al comprador. Una autorización correcta indica que el emisor de la tarjeta ha verificado los detalles de la tarjeta y el límite del crédito, y por tanto el pedido puede ser cursado.
La respuesta que envía el vendedor al comprador contiene el status de la transacción y los códigos de respuesta disponibles. El código indica si se han completado los pasos de autorización o captura. El campo resultado contiene los códigos de autorización o captura, si es que se han producido estos pasos. Estos códigos se generan en la red bancaria para autorizar y compensar la transacción, y pueden aparecer en el cargo mensual de la tarjeta del comprador. - SET y SSLAlgunos autores han visto SSL y SET como competidores que comparten un mismo objetivo. De hecho no tiene porqué ser así, pudiendo llegar a ser complementarios. SSL, tal como se ha visto, puede servir para proteger información en tránsito, y para dar autenticidad del servidor al cliente. Los servicios de seguridad que proporciona SSL son limitados. Por su parte, SET se centra exclusivamente en la fase de pago, y por tanto quedan fuera de su ámbito las fases de negociación y de entrega (esta última especialmente a ser considerada en el caso de bienes y servicios digitales). Por tanto, parece claro que podría utilizarse SSL para las fase previas y posteriores a la fase de pago, y utilizar el protocolo SET para esta fase concreta.
SSL no proporciona no repudio en origen, y por tanto esto significa que comprador y vendedor pueden negar a posteriori haber intervenido en una determinada transacción electrónica. En estas primeras etapas del comercio electrónico, y en las transacciones de bajo coste (por ejemplo, la compra de un libro por medios electrónicos), el vendedor estará dispuesto a asumir que el comprador niegue a posteriori haber realizado el pedido, con los consiguientes costes que le pueda suponer. También a la inversa, el comprador está dispuesto a asumir que el vendedor no envíe el producto supuestamente encargado (siempre asumiendo que su entidad financiera deberá devolverle el importe de la transacción de la operación no realizada). Pero pensemos en transacciones de un nivel más elevado, y llegaremos al convencimiento de que el modelo basado exclusivamente en SSL no es estrictamente adecuado.
También hay que indicar que el hecho de comunicar los datos de la tarjeta al vendedor, supone asumir un riesgo no siempre deseado. Esto no es estrictamente nuevo, y de hecho este riesgo se asume también en las transacciones presenciales. Nos estamos refiriendo al uso fraudulento de esos datos en poder del vendedor, por parte del propio vendedor o de terceros. Periódicamente pueden leerse noticias de desarticulaciones de redes que se dedican a obtener esos datos, a través de terminales legítimos o no (restaurantes, tiendas, terminales bancarios falsos, etc.). La única novedad que introduce la no presencialidad es el hecho de no saber realmente con quién se está dialogando.
La conclusión es que SSL no es la vía más adecuada para realizar pagos con tarjeta de crédito a través de Internet, siendo recomendable el uso del protocolo SET. La siguiente cuestión sería por qué SET, que corrige esas deficiencias, no es más utilizado. La respuesta más clara la encontramos en la complejidad de la especificación. El esfuerzo para desarrollar y verificar los programas asociados a SET es considerable.
Otro motivo que explica el retraso en la implantación efectiva de SET la encontramos en la incorporación de la firma electrónica. En SET, y ese es precisamente uno de sus puntos fuertes, comprador y vendedor deben disponer de su firma digital, y de sus correspondientes certificados digitales. En el caso de SSL, es opcional que el cliente disponga de un certificado de clave pública. Obviamente el hecho de que sea más restrictivo SET, es decir, que obligue a los compradores a disponer de un certificado de clave pública, frena su implantación. En un futuro cercano cuando todos los usuarios dispongan de esa posibilidad, será más viable el uso de SET. - Conclusiones
Las tarjetas de crédito son un medio de pago que está demostrando con su relativo éxito su adecuación para los pagos en las transacciones de comercio electrónico de Internet. Por una parte disponemos de una amplia base de usuarios a lo largo del mundo que disponen y utilizan tarjetas de crédito en el comercio convencional, y que desean (con reticencias por la falta de seguridad apreciada) utilizarlas en los pedidos electrónicos. Por otra parte tenemos un colectivo de marcas de tarjeta de crédito, que prácticamente son aceptadas en todo el mundo, y que de forma inherente proporcionan la posibilidad de utilizar múltiples divisas en las operaciones.
Como parte negativa hay que reconocer que las transacciones no presenciales, que es el caso de Internet, son inseguras y susceptibles de padecer cierto nivel de fraude (como de hecho así sucede). Esto es debido, en general, a que no hay identificación del usuario de la tarjeta, ni justificante escrito y firmado de la operación y ni, en última instancia, utilización de la tarjeta en sentido estricto, que puede seguir en poder del titular legítimo. Por tanto hay que protegerse frente a los posibles ataques que pueden padecerse.
En esta ponencia se ha revisado el protocolo SSL, que proporciona dos funciones básicas de seguridad. En primer lugar, permite tener la seguridad de que el vendedor con el que se está tratando es efectivamente quien dice ser. En segundo lugar, se produce un cifrado del enlace, de tal manera que los detalles de la tarjeta de crédito no pueden ser interceptados en tránsito. Así se resuelven dos problemas, que aunque se pueda alegar que no son los que provocan mayores problemas en las transacciones electrónicas, pueden servir para dar mayor confianza a los compradores, y por tanto mayor posibilidad de negocio a los empresarios.
SET aparece como un protocolo que puede resolver todos los problemas de seguridad ligados a los pagos con tarjeta de crédito en Internet. Por desgracia su aceptación no ha sido la deseada, pero en un futuro no muy lejano debe aparecer alguna alternativa que sí tenga la aceptación del mercado.
[1] D. Abrazhevich: "Classification and Characteristics of Electronic Payment Systems"; EC-Web 2001, LNCS 2115, pp. 81-90, Springer Verlag, 2001.
[2] N. Asokan, P.A. Janson, M. Steiner y M. Waidner: "The State of the Art in Electronic Payment Systems"; IEEE Computer, pp. 28-35, 1997.
[3] G. Drew: "Using SET for Secure Electronic Commerce"; ed. Prentice-Hall, 1998.
[4] A. Freier, P. Karlton y P. Kocher: "The SSL Protocol: Version 3.0"; Netscape Communication Corp., noviembre de 1996.
http://home.netscape.com/eng/ssl3/index.html
[5] MasterCard y Visa: "Secure Electronic Transaction (SET) Specification - Book 1: Business Description Version 1.0"; mayo de 1997.
http://www.setco.org
[6] MasterCard y Visa: "Secure Electronic Transaction (SET) Specification - Book 2: Programmer's Guide Version 1.0"; mayo de 1997.
http://www.setco.org
[7] MasterCard y Visa: "Secure Electronic Transaction (SET) Specification - Book 3: Formal Protocol Definition Version 1.0"; mayo de 1997.
http://www.setco.org
[8] D. O'Mahony, M. Pierce y H. Tewari: "Electronic Payment Systems for E-Commerce"; ed. Artech House, segunda edición, 2001.
[9] E. Rescorla: "SSL and TLS: Designing and Building Secure Systems"; ed. Addison-Wesley, 2001.
I am really enjoying reading your well written articles. It looks like you spend a lot of effort and time on your blog.I will support this,and expresses my point of view completely.
ResponderEliminar