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.

• “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:

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

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.

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