6. Proposiciones comerciales

Miguel Ángel Monjas Llorente
Departamento de Ingeniería de Sistemas Telemáticos.

--------------------------------------------------------------

Los primeros pagos de servicios realizados sobre Internet fueron convencionales. Los usuarios del servicio transferían periódicamente el monto total desde su cuenta bancaria a la cuenta del proveedor. Estos pagos tomaban una gran cantidad de tiempo. Para el caso de la compra de productos, el modelo se comporta del mismo modo, transfiriendo el importe concreto a la cuenta bancaria del vendedor. No se usan los medios de transporte proporcionados por Internet. Este mecanismo no lo consideraremos propiamente como un pago en Internet.

Un poco más avanzado sería combinar las facilidades proporcionadas por las tarjetas de crédito, para evitar las transacciones externas. El cliente utiliza Internet para informar al comercio del número de cuenta, que el comercio utiliza para cargar el montante, de modo análogo a lo que sucedería fuera de Internet. La empresa que gestiona la tarjeta se encarga de todo lo demás. En este escenario empieza a circular información delicada por la red, atentando contra la privacidad del comprador (que puede ser monitorizado), y a la confidencialidad de los datos bancarios que pueden ser robados y utilizados fraudulentamente. Se imponen mecanismos de seguridad que garanticen la confidencialidad e integridad del contenido, así como la identidad de los presuntos cliente y vendedor.

La solución pareciría ser el uso de encriptación para enviar de forma segura el número de tarjeta. Pero aún así existen ciertos factores por considerar. Uno podría ser el coste de la transacción en sí mismo, el cual, si es elevado, podría hacer inviable la realización de microcompras.

El siguiente paso en la refinación del mecanismo consiste en introducir a una tercera parte para evitar que información delicada circule por Internet. Este esquema requiere el registro previo de los participantes, fase en la que se comprueba la identidad y solvencia de cada uno. A partir de este registro previo, las transacciones se hacen a partir de los datos almacenados por el intermediario, que periódicamente verifica que no ha habido problemas de suplantación de identidad, bancarrota u otras disfunciones que pudieran inhibir la capacidad de realizar transacciones.

Posibles limitaciones de este esquema son, de una parte la posibilidad de que se rehuse algún pago porque se haya alcanzado el límite de pago. De otra, la acumulación de datos sobre los participantes en manos de esta tercera parte puede atentar contra el derecho de las personas a la privacidad.

Un esquema diferente apunta a la reproducción de las características del dinero en metálico, en especial, del anonimato. La idea es que el usuario pueda disponer en su ordenador (o en una tarjeta inteligente) de dinero anónimo, que puede usar para realizar pagos. Siempre hay un banco detrás que respalda el valor de las "monedas". Aparecen problemas interesantes tanto para protegerse frente al robo del dinero, como para evitar el pago de más de un producto con el mismo dinero (copias).

Finalizamos con las propuestas de dos de las más importantes firmas de tarjetas de crédito: VISA y Mastercard, que han desarrollado sendos protocolos de ejecución de operaciones alrededor de sus tarjetas.

--------------------------------------------------------------

Checkfree

Se trata de un sistema integrado de comercio electrónico basado en protocolos propios, con clientes y servidores específicos. Trabaja sobre Windows 95 bajo el padrinazgo de Compuserve.

Las órdenes se transmiten a través de Internet, cifradas mediante el algoritmo RSA y utilizando claves públicas de 756 bits. El tamaño de esta clave se considera lo suficientemente seguro para usarla en transacciones comerciales.

Los comercios deben estar registrados en CheckFree. El comprador envía información para ejecutar el pago al comercio, que, a su vez, la remite a CheckFree. Una vez autorizado el pago, el cliente recibe un justificante, y el comercio recibe el identificador de esta autorización para que entregue el pedido. CheckFree se encarga de interactuar con los bancos para llevar a cabo la transferencia de fondos.

CyberCash

Cybercash establece un esquema de pago empleando sistemas propios de criptografía de clave pública (Secure Internet Payment Service). Se trata también de una empresa intermediaria entre el cliente y el banco. Ofrece un producto cliente-servidor propio para comunicar confidencialmente importes y números de tarjetas de crédito. Se encuentra disponible la especificación del CyberCash Credit Card Protocol Version 0.8.

First Virtual

First Virtual patrocina un sistema conocido como Green Commerce Model, actuando como una especie de agencia bancaria que da un servicio de intermediario entre clientes y comerciantes. Se basa en el establecimiento de acuerdos entre las partes y el banco. Establecido el acuerdo, cada parte recibe un identificativo propio que queda ligado a una cuenta bancaria y a una dirección de correo electrónico.

Cuando un cliente quiere realizar una compra, le envía una orden al vendedor, el cual, a su vez la envía a First Virtual junto con el identificador del comprador en First Virtual. Éste se encarga de contactar al cliente por correo electrónico para confirmar que acepta el cargo.

La principal característica novedosa es la política de "satisfacción garantizada", que protege a los consumidores de los vendedores deshonestos permitiéndoles el derecho incondicional para rehusar el pago de artículos individuales. Un mecanismo estadístico se usa para identificar a aquellos que hacen un uso frecuente de este derecho y cancelar su cuenta.

Si se detecta un intento fraudulento de utilización (el cliente asegura no haber hecho el pedido que se le intenta cargar), la cuenta se cancela automáticamente, y se le abre una cuenta nueva.

Aceptada la transacción, su importe se le carga al cliente y se abona al vendedor, que ya puede hacer la entrega. El vendedor abona un porcentaje a First Virtual en concepto de comisión. Por otra parte, el vendedor no recibe el dinero hasta pasados 91 días, lo que da margen suficiente a detectar irregularidades.

El sistema no utiliza sistemas criptográficos, alegando por una parte que la información financiera nunca viaja por Internet (sólo los identificativos en First Virtual) y, por otra, que sus cautelas son suficientes y preferibles a la seguridad (siempre relativa) de la criptografía. La especificación (en Postscript) se encuentra disponible.

NetBill

NetBill es un proyecto desarrollado en la Universidad Carnegie-Mellon. NetBill es un pequeño banco en el que tanto clientes como comerciantes mantienen cuentas privadas. Los clientes pueden poner dinero en su cuenta para ejecutar pagos, y los comercios pueden retirarlo.

Se basa en protocolos propios, con clientes y servidores específicos que pueden empotrarse en navegadores WWW u otro tipo de interfaces de usuario. Todas las transferencias por Internet van adecuadamente cifradas y firmadas por medio de claves públicas, con autentificación basada en Kerberos.

El sistema es muy adecuado para la venta de información a través de la red. Un cliente hace un pedido, y recibe el producto (la información) cifrado. Cuando lo recibe, ordena el pago que, una vez ejecutado, hace que el comerciante le entregue al comprador la clave necesaria para desencriptar la información. De esta forma se consigue ligar a ambas partes para evitar fraudes por desaparición súbita, o por pérdidas derivadas de fallos de la red o de los equipos terminales.

DigiCash

Se trata de dinero digital en metálico que usa un sofisticado sistema de utilización de claves y huellas digitales para ofrecer monederos electrónicas con dinero anónimo. El cliente recibe un programa específico que le permite comunicarse con un banco para retirar dinero, con otros individuos para intercambiarlo, y con comercios para realizar pagos.

Para retirar dinero del banco se utiliza una elaborada técnica criptográfica que se denomina "firma ciega". El cliente se inventa números de serie para las monedas que desea, los "ensobra" con una clave digital aleatoria que impide ver el número de serie, y los envía al banco para su autorización. El banco dispone de una serie de firmas, una por cada valor monetario (por ejemplo, hay una firma que vale 1000 pesetas). El banco firma la moneda ensobrada del cliente y se la devuelve a éste. El cliente es capaz de eliminar la clave digital que ocultaba el número de serie sin alterar la firma del banco. En este momento dispone de una moneda validada por el banco cuyo número de serie sólo conoce el cliente. El banco detrae la cantidad de la cuenta; pero como ignora el número de serie de las monedas electrónicas, le será imposible asociar un pago observado a un cliente concreto.

El cliente puede enviar sus monedas a un comercio, que negociará con el banco su cobro. El banco sólo tiene que saber que la moneda es válida y que no se utiliza más de una vez. Para ello basta que lleve una base de datos de números de serie consumidos.

El cliente y el comercio reciben programas específicos que se comunican entre ellos o con un banco previamente acordado para utilizar unos protocolos de propietario. Se trata de un sistema cerrado. Lo que reciben las partes se asemeja enormemente a un monedero electrónico que debe ser cuidadosamente protegido frente a robos o intrusos telemáticos. Pero nótese que ante un robo el cliente puede informar inmediatamente al banco de los números de serie robados y anularlos.

Una aplicación real es el Mark Twain Bank, que usa dólares USA. También puedes echarle un vistazo a HACKING Digicash.

VISA

En colaboración con Microsoft, ha desarrollado una especificación completa, la Secure Transactions Technology (STT), basada en el uso de claves públicas, respondiendo a los siguientes requisitos comerciales:

STT utiliza el concepto de "doble firma", que se usa para ligar los datos del pedido (que sólo interesan al comercio) con los datos financieros (que sólo interesan al banco). El cliente, que dispone de ambas informaciones, calcula sus huellas digitales, las concatena y firma digitalmente. El comercio recibe el pedido (del que él mismo puede extraer la huella) y la huella de lo que se envía al banco (difícilmente falsificable). El banco recibe, de forma similar, los datos bancarios y la huella del pedido. Así, cada receptor puede comprobar la firma del conjunto, respetándose al tiempo la confidencialidad de los datos, su integridad y la coherencia entre el pedido y el pago.

Respecto de los credenciales que autentican las claves públicas, STT propone una jerarquía de autorizaciones. En el primer nivel existe una autoridad del sector, A, debidamente acreditada. A acredita al banco del comprador, BE, y al banco del vendedor, BC. Cada banco acredita a sus respectivos clientes. Con esta delegación en cascada, cualquiera de las partes puede asegurarse la identidad de las demás. El esquema de jerarquía de delegaciones aún no parece maduro y requerirá probablemente más elaboración.

La autoridad A emite certificados al público, ligando una clave pública a un número de tarjeta y a una cuenta en un banco. Cuidadosamente se evita introducir el nombre del usuario para mantener su anonimato, quedando solamente ligada la huella digital de la cuenta de cargo.

MasterCard

MasterCard patrocina protocolos de pago basados en los protocolos iKP de IBM. Estos protocolos se plasman en una especificación conocida como Secure Electronic Payment Protocol (SEPP), y ha sido desarrollados en asociacion con IBM, Netscape, CyberCash y GTE Corp. El mecanismo se basa en el uso de claves públicas.

Cabe destacar de esta propuesta el cuidadoso tratamiento de la emisión de certificados para autentificar claves públicas. La autoridad de certificación (CA) es única, y es la propia MasterCard. Esta autoridad emite certificados para los clientes, haciéndoselo saber al banco emisor. Los bancos que tratan con comercios reciben sus certificados directamente de la misma CA. Los comercios deben solicitar sus certificados al banco en el que poseen sus cuentas, el cual traslada la petición (junto con su asunción de responsabilidad) a MasterCard para que emita el certificado al comercio.

MasterCard entra en la red interbancaria, que se utilizará internamente para requerir y difundir certificados, además de su uso tradicional como vehículo de compensación.

SEPP prevé transacciones en línea con autorización inmediata del cargo, y transacciones diferidas (off-line) en las que utiliza correo electrónico. Además, el cliente puede recabar posteriormente el estado de su orden de compra.
--------------------------------------------------------------

En todos los modelos citados se puede observar que los actores son los clásicos: compradores, vendedores e instituciones financieras que materializan las transacciones y garantizan la solvencia del sistema. La mayor parte de los sistemas se limitan a introducir agencias especializadas capaces de realizar las labores tradicionales sobre medios inseguros y sin presencia física de los interesados. Por ello, los requisitos funcionales apuntan sistemáticamente a la confidencialidad, integridad y autentificación de los objetos y las partes. Y para éllo parece denominador común el uso de técnicas criptográficas.

Sólo la propuesta de DigiCash con su dinero en metálico rompe la uniformidad y se lanza al anonimato tradicional del dinero en metálico, con algunas características muy interesantes de seguridad (pagos anónimos, imposibilidad de extraer perfiles de uso por terceras partes, recuperación del efectivo en caso de robo, etc.) que lo hacen muy atractivo; pero hasta la fecha se ha venido considerando excesivamente complejo como para una implementación generalizada.

Como no podía ser menos tratándose de dinero, los sistemas actuales son muy conservadores. Todas las empresas en el negocio adoptan numerosas cautelas frente a fraudes y fallos técnicos. Si el número de incidencias fuera elevado, las comisiones se dispararían y los costes asociados al comercio electrónico no serían tolerables.

--------------------------------------------------------------

[PAGINA INICIAL | PAGINA ANTERIOR | PAGINA SIGUIENTE]

--------------------------------------------------------------

Page maintained by Miguel Ángel Monjas Llorente (mmonjas@dit.etsit.upm.es)
Last modified: Mon Feb 19 18:00:00 1996