Pago electrónico

ESTÁNDARES DE PAGO:
SSL&SET
RESUMEN
FO II 2001−2002
SSL (SECURE SOCKETS LAYER)
DEFINICIÓN
Este protocolo fue desarrollado por Netscape, y se sitúa en una capa entre los protocolos de aplicación (HTTP,
FTP, Telnet, etc.) y TCP/IP, proporcionando las siguientes ventajas:
• La conexión es privada. El cifrado es usado después de un acuerdo inicial en el que se define una
clave secreta. Para este cifrado se usa criptografía simétrica. (DES, RC4).
• La identidad de los participantes en la comunicación puede ser autentificada usando criptografía de
clave pública. (RSA, DSS, etc.)
• La conexión es fiable. El transporte del mensaje incluye una verificación de la integridad de éste
usando un Código de Autentificación del Mensaje (MAC). Para los cálculos de las MAC se usarán
funciones hash seguras. (SHA, MD5, etc.).
ARQUITECTURA DEL PROTOCOLO SSL.
El protocolo SSL está compuesto por dos capas o niveles. En el nivel inferior se encuentra el `SSL Record
Layer', usado para encapsular diversos protocolos de mas alto nivel.
• SSL Handshake Protocol: para la realización del establecimiento de la conexión entre cliente y
servidor.
1
• SSL Change Cipher Spec Protocol: utilizado a la hora de acordar los parámetros de cifrado a usar.
• SSL Alert Protocol: comunica mensajes de error de SSL.
Una ventaja de SSL es su independencia con respecto al protocolo de aplicación usado. Un protocolo de nivel
más alto puede situarse transparentemente sobre SSL.
EL HANDSHAKE.
La fase más importante de una conexión SSL es la negociación o `handshake'. En ella, el cliente y el servidor
intentan consensuar los parámetros básicos de la sesión y la conexión. Si ambos interlocutores no se ponen de
acuerdo en lo que se refiere al cifrado y a la autentificación, no se producirá ninguna transferencia de
información.
APLICACIÓN EN EL COMERCIO ELECTRÓNICO
SSL fue creado como un protocolo de comunicaciones seguro de uso genérico. Como no fue pensado
explícitamente para el comercio electrónico presenta usa serie de deficiencias que deben tenerse en cuenta:
• Confidencialidad:
SSL garantiza la confidencialidad extremo a extremo pero una vez finalizada la conexión, el vendedor posee
todos los datos del comprador, así como su número de tarjeta de crédito. El vendedor podría almacenar esos
datos y el cliente estaría expuesto a cualquier tipo de fraude.
• Integridad:
2
SSL no garantiza la integridad de la información una vez finalizada la conexión, por lo que el vendedor podría
modificar esos datos, por ejemplo, cobrando de más al cliente.
• Autenticación:
El cliente no necesita autenticarse, por lo que una persona con acceso a números de tarjeta de crédito robados
podría realizar cualquier tipo de compra por Internet. Éste es precisamente el tipo de fraude más común y que
causa mayores perdidas a las compañías de crédito.
• No repudio:
Una vez finalizada la compra no existe ningún tipo de comprobante de compra por lo que cualquier protesta
posterior carecerá de medios para su confirmación. Tampoco existe ningún documento firmado por lo que
tanto el cliente como el vendedor o el banco podrían negar su participación en la compra sin que existiera la
posibilidad de probar lo contrario.
• Lentitud:
El hecho de que en una comunicación segura SSL todos los datos intercambiados entre cliente y vendedor
vayan encriptados hace que se ralentice la transferencia. Así, la simple presentación de productos por parte del
vendedor en el web se hace lenta.
CONCLUSIÓN
Con SSL, toda la seguridad recae en la confianza que el cliente tenga en el vendedor, ya que potencialmente el
vendedor puede realizar cualquier tipo de fraude con total impunidad. Sólo las empresas con muy buena
reputación podrían, a priori, contar con esta confianza del consumidor.
El más que posible fraude con números de tarjetas robados hace que las entidades de crédito añadan una
comisión en las compras bastante elevada (un 5% aproximadamente) para compensar este tipo de fraude. Esto
hace que el precio de la compra se incremente considerablemente, lo que anula el atractivo inicial de comprar
por Internet: los precios bajos.
Estandarizar la comunicación con el banco es una de los puntos importantes que hay que solucionar para
conseguir una mayor transparencia y poder abrirse a la competencia.
SSL utiliza certificados digitales siguiendo el estándar X.509, es decir, certificados de propósito general. Sería
más interesante que existieran Autoridades Certificadoras creadas especialmente para emitir certificados de
este tipo y que dichas autoridades estuvieran avaladas por la banca de tal modo que los certificados digitales
expedidos tuvieran conexión con cuentas bancarias concretas.
SET (SECURE ELECTRONIC TRANSACTIONS)
Este protocolo esta especialmente diseñado para asegurar las transacciones por Internet que se pagan con
tarjeta de crédito. Esto es debido a que una gran cantidad de transacciones de compra por Internet son
efectuadas con tarjeta de crédito, por otro lado SSL deja descubierto alguna información sensible cuando se
usa para lo mismo. La principal característica de SET es que cubre estos huecos en la seguridad que deja SSL.
Por ejemplo con SSL sólo protege el número de tarjeta cuando se envía del cliente al comerciante, sin
embargo no hace nada para la validación del número de tarjeta, para chequear si el cliente está autorizado a
usar ese número de tarjeta, para ver la autorización de la transacción del banco del comerciante etc., Además
que el comerciante puede fácilmente guardar el número de tarjeta del cliente. SET permite dar seguridad tanto
3
al cliente, al comerciante como al banco emisor de la tarjeta y al banco del comerciante.
En el protocolo SET se especifican unas normas que deben cumplir todas las partes involucradas en la
transacción (comprador, comerciante, entidad financiera y autoridad certificadora), que garantizan las tres
condiciones básicas de la operación:
1.− Autentificación:
La autentificación sirve para comprobar que los participantes en la operación comercial sean quienes dicen
ser, es decir: que el consumidor sepa en qué comercio está comprando, y el comercio esté seguro de que quien
compre sea realmente el titular del instrumento de pago.
La autentificación se realiza a través de certificados digitales que tanto el comerciante como el comprador
poseen, y que les son proporcionados por una tercera parte, la entidad financiera, como por ejemplo VISA.
Principalmente, el certificado digital asegura la validez de una clave pública, e incluye los siguientes campos
de información:
• Un identificador del propietario del certificado. Otro identificador de quién asegura su validez (que
será una Autoridad Certificadora). Las fechas de inicio y caducidad del certificado.
• Un identificador del certificado (o número de serie).
• La clave pública del propietario del certificado.
• La firma digital de la Autoridad Certificadora, que asegura la autenticidad de todos los campos del
certificado.
2.− Privacidad:
Toda la información que viaja por la Red, durante el intercambio de identidades y datos, está protegida con
métodos criptográficos, que cifran toda la información que se transmite entre las partes involucradas. Los
datos son encriptados a través de algoritmos dotados de dos claves asimétricas, una clave pública destinada a
ser distribuida libremente para que los remitentes puedan cifrar sus datos. La otra clave, la clave privada, sólo
conocida por su legítimo propietario y custodiada con el máximo celo, sirve para descifrar los datos recibidos.
SET sin embargo también hace uso de criptografía simétrica para el cifrado de la información.
3.−Integridad:
En SET, la integridad garantiza que los datos no han sido alterados de forma fraudulenta. La integridad, junto
con la autenticidad, se basa en la generación de firmas digitales. La firma digital se crea a partir de las
relaciones matemáticas entre las claves pública y privada. Así, los datos cifrados con una de las claves sólo
pueden ser descifrados con la otra. Pero en el caso de la firma digital, se invierten los papeles de las claves.
Usando una función irreversible (MD5) se "destilan" los datos de la transacción, que luego son cifrados con la
clave privada del remitente. El resultado se añade al final del original que se envía, constituyendo así la firma
digital del mismo. El destinatario de los datos descifra el "destilado" a través de la clave pública del remitente.
Si el resultado del destilado es idéntico al original la integridad y la autenticidad de los datos es correcta. Si no
son idénticos significa que ha habido una manipulación no autorizada de los datos.
Proceso de SET
Inicio.− El cliente inicializa la compra. Decisión de compra del cliente. El cliente está navegando por el sitio
web del comerciante y decide comprar un artículo. Para ello rellenará algún formulario al efecto y
posiblemente hará uso de alguna aplicación tipo carrito de la compra, para ir almacenando diversos artículos y
pagarlos todos al final. El protocolo SET se inicia cuando el comprador pulsa el botón de Pagar o equivalente.
4
1.− Arranque de la cartera. El servidor del comerciante envía una descripción del pedido que despierta a la
aplicación cartera del cliente.
2.− Transmisión cifrada de la orden de pago. El cliente comprueba el pedido y transmite una orden de pago
de vuelta al comerciante. La aplicación cartera crea dos mensajes que envía al comerciante. El primero, la
información del pedido, contiene los datos del pedido, mientras que el segundo contiene las instrucciones de
pago del cliente (número de tarjeta de crédito, banco emisor, etc.) para el banco adquiriente. En este momento,
el software cartera del cliente genera un firma dual, que permite juntar en un solo mensaje la información del
pedido y las instrucciones de pago, de manera que el comerciante puede acceder a la información del pedido,
pero no a las instrucciones de pago, mientras que el banco puede acceder a las instrucciones de pago, pero no
a la información del pedido. Este mecanismo reduce el riesgo de fraude y abuso, ya que ni el comerciante
llega a conocer el número de tarjeta de crédito empleado por el comprador, ni el banco se entera de los hábitos
de compra de su cliente.
3.− Envío de la petición de pago al banco del comerciante. El software SET en el servidor del comerciante
crea una petición de autorización que envía a la pasarela de pagos, incluyendo el importe a ser autorizado, el
identificador de la transacción y otra información relevante acerca de la misma, todo ello convenientemente
cifrado y firmado. Entonces se envían al banco adquiriente la petición de autorización junto con las
instrucciones de pago (que el comerciante no puede examinar, ya que van cifradas con la clave pública del
adquiriente).
4.− Validación del cliente y del comerciante por el banco adquiriente. El banco del comerciante descifra y
verifica la petición de autorización. Si el proceso tiene éxito, obtiene a continuación las instrucciones de pago
del cliente, que verifica a su vez, para asegurarse de la identidad del titular de la tarjeta y de la integridad de
los datos. Se comprueban los identificadores de la transacción en curso (el enviado por el comerciante y el
codificado en las instrucciones de pago) y, si todo es correcto, se formatea y envía una petición de
autorización al banco emisor del cliente a través de la red de medios de pago convencional.
5.− El emisor de la tarjeta autoriza la transacción. Consiste en la autorización del pago por el banco emisor
del cliente. El banco emisor verifica todos los datos de la petición y si todo está en orden y el titular de la
tarjeta posee crédito, autoriza la transacción.
6.− Envío al comerciante de un testigo de transferencia de fondos. En cuanto el banco del comerciante
recibe una respuesta de autorización del banco emisor, genera y firma digitalmente un mensaje de respuesta
de autorización que envía a la pasarela de pagos, convenientemente cifrada, la cual se la hace llegar al
comerciante.
7.− El servidor del comerciante completa la transacción. Se trata del envío de un recibo a la cartera del
cliente. Cuando el comerciante recibe la respuesta de autorización de su banco, verifica las firmas digitales y
la información para asegurarse de que todo está en orden. El software del servidor almacena la autorización y
el testigo de transferencia de fondos. A continuación completa el procesamiento del pedido del titular de la
tarjeta, enviando la mercancía o suministrando los servicios pagados. Además, se le entrega a la aplicación
cartera del cliente un recibo de la compra para su propio control de gastos y como justificante de compra.
8.− Entrega del testigo de transferencia de fondos para cobrar el importe de la transacción. Después de
haber completado el procesamiento del pedido del titular de la tarjeta, el software del comerciante genera una
petición de transferencia a su banco, confirmando la realización con éxito de la venta. Como consecuencia, se
produce el abono en la cuenta del comerciante.
9.− El banco emisor de la tarjeta de pago envía el aviso de crédito al cliente. Dicho de otra forma, se
produce el cargo en la cuenta del cliente. A su debido tiempo, la transacción se hace efectiva sobre la cuenta
corriente del cliente.
5
CONCLUSIÓN
SET no resulta fácil de implantar, por lo que su despliegue está siendo muy lento. SET exige software
especial, tanto para el comprador (aplicación de cartera electrónica) como para el comerciante (aplicación
POST o TPV), y los bancos (software de autoridad de certificación, pasarela de pagos, etc.). Además no existe
suficiente información al respecto y en general la situación es cuando menos confusa.
Aunque los productos anteriores cumplan con el estándar SET, esto no implica necesariamente que sean
compatibles. Este es un problema que exige mayores esfuerzos de coordinación y más pruebas a escala
mundial para asegurar la interoperabilidad.
SET seguirá coexistiendo con SSL durante mucho tiempo, hasta que se alcance una masa crítica de usuarios
que propicien su utilización a gran escala, o caiga en el olvido superado por otra nueva iniciativa más ágil y
mejor adaptada.
Estándares de pago : SSL & SET. (Resumen) 3
FO II . 2001−2002
6