Protocolos seguros

El uso de los mecanismos de seguridad en las comunicaciones en Internet, sean o no transacciones económicas, debe estar regido por ciertas normas o estándares definidos a priori, de manera que el navegador del usuario y el servidor en el otro extremo puedan interactuar de forma automática. Estas normas son los protocolos.

Secure Sockets Layer (SSL) es actualmente el estándar de facto para las comunicaciones seguras en Internet. Proporciona privacidad e integridad a las comunicaciones web, autenticación del servidor y opcionalmente también autenticación del cliente, empleando HTTP. Cuando conectamos con un sitio empleando HTTPS lo que estamos haciendo realmente es emplear HTTP sobre SSL/TLS.

La sesión SSL se inicia con un protocolo de enlace, en el que se definen las caracerísticas técnicas y criptográficas que se van a emplear. En primer lugar el cliente envía al servidor una petición de conexión segura, en la que le comunica aspectos técnicos como la versión de SSL, los algoritmos de cifrado y los métodos de compresión de datos soportados por el cliente. El servidor responde comunicando sus propias restricciones técnicas y enviando su certificado, que incluye su clave pública. El navegador comprueba que el certificado ha sido emitido por una autoridad reconocida y que no ha sido revocado y, una vez definidos los detalles técnicos de la sesión, genera una una preclave que se cifra con la clave pública del servidor, y se envía a éste.

El servidor descifra la preclave empleando su clave privada y le aplica ciertas operaciones criptográficas; el navegador hace en paralelo estas mismas operaciones, de manera que ambos llegan a una misma clave de cifrado, simétrica, aleatoria y de un solo uso. Todas las comunicaciones entre cliente y servidor se van a cifrar con esta clave simétrica, hasta que la sesión finalice.

El uso de una clave simétrica responde al objetivo de agilizar las comunicaciones y reducir la carga de cómputo de los equipos; el empleo de cifrado de clave doble y de los certificados permite intercambiarla de forma segura; y su uso como clave única o de sesión minimiza el riesgo de que pueda ser rota por métodos de fuerza bruta.

En conjunto, el sistema permite:

• Autenticar al servidor
• Opcionalmente, autenticar también al cliente
• Proteger la confidencialidad de los datos intercambiados, incluyendo no solo el contenido de las páginas sino también contraseñas, URL, parámetros enviados, cookies, etc. ya que se cifra todo el tráfico HTTP. Un hacker solo podría saber el servidor al que estamos conectados, y el puerto empleado.

El funcionamiento de SSL depende críticamente de los certificados: si un certificado de una autoridad reconocida se viese comprometido, cualquiera podría crear sitios falsos que serían técnicamente indistinguibles de los reales, redirigir el tráfico HTTP y acceder al contenido íntegro de las comunicaciones, incluyendo contraseñas y datos personales.

Un protocolo para dar seguridad a las comunicaciones en redes abiertas, desarrollado a finales de los noventa por un consorcio de empresas financieras y de software, entre ellas Visa, MasterCard, IBM, Microsoft, RSA y Verisign, y en el que convergían SEPP (Mastercard), STT (Visa) y el esfuerzo de desarrollo de American Express.

Su finalidad principal era proteger las comunicaciones inherentes al comercio electrónico, y ofrecer además garantías de confidencialidad a las partes (de manera que cada agente tuviese acceso únicamente a la información que necesita para realizar su función en la transacción).

Su funcionamiento era relativamente sencillo:

1. El protocolo se inicia cuando el vendedor recibe un pedido de un cliente, y le asigna un identificador (ID)
2. El vendedor se pone en contacto con la pasarela de pago, y ambos intercambian sus certificados
3. El vendedor envía al usuario i) una versión firmada del ID de la transacción, su certificado, así como el certificado de la pasarela de pagos
4. El cliente verifica los certificados y genera dos mensajes: uno con la información del pedido, dirigido al comerciante, y otro con los datos de pago, dirigido a la pasarela de pagos. Ambos contienen el ID de la transacción, de manera que puedan relacionarse, pero su contenido no se cruza: los datos financieros, por ejemplo el número de tarjeta, nunca están en poder del comerciante; los datos de compra (producto, cantidades, precio) no son conocidos por las entidades financieras implicadas en la operación.
5. El comprador genera los resúmenes de estos mensajes y los une en un tercer mensaje; a continuación, firma este mensaje (esta es la llamada firma dual).
6. El comprador genera una clave aleatoria de sesión y cifra con ella el mensaje que contiene los datos financieros; cifra la clave y el mensaje de pago con la clave pública de la pasarela de pagos
7. El comprador envía al vendedor su certificado, la orden de pedido, el hash de la orden de pago, la versión cifrada de la información de pago (paso 6 anterior), y la firma dual.
8. El comerciante verifica el certificado del comprador y comprueba las firmas incorporadas a la orden de pedido y el hash de la orden de pago. Genera una confirmación de compra, la firma, y la envía al cliente
9. El comerciante genera una autorización de pago que incluye la cantidad y el ID de la operación; genera una clave de sesión con la que encripta este mensaje ya continuación cifra dicha clave con la clave pública de la pasarela de pago
10. El comerciante envía a la pasarela de pago la autorización y la clave cifrada (paso 9), junto con la información de pago, la clave de sesión cifrada generada por el cliente (paso 6) su certificado digital, y el certificado del cliente
11. La pasarela de pagos descifra la clave de sesión enviada por el comerciante con su clave privada y obtiene el texto en claro de la autorización de pago; verifica el certificado del vendedor.
12. Si todo es correcto, usa nuevamente su clave privada para recuperar la clave de sesión enviada por el cliente, y obtiene el texto en claro de la información de pago; verifica el certificado del cliente y las firmas digitales incorporadas a los mensajes de compra y pago; comprueba que el ID es el mismo que el de la autorización (paso 11).
13. Si todo es correcto, se generan las órdenes internas de transferencia de fondos, y se envía al comerciante una confirmación, cifrada como en los casos anteriores (una clave aleatoria de sesión, cifrada con la clave pública del comerciante)
14. El comerciante verifica la confirmación y emite una solicitud definitiva de pago a la pasarela: toma su importe, el ID de la operación y lo cifra con una clave aleatoria de sesión, y esta clave se cifra con la clave pública de la pasarela; todo esto se remite a la pasarela junto con el certificado del comerciante
15. La pasarela recupera la clave de sesión, verifica el certificado y la firma, y envía una confirmación de pago.

SET está diseñado para proporcionar altos niveles de seguridad a las partes implicadas en comercio electrónico; refuerza sustancialmente la seguridad de los pagos presenciales con tarjetas dotadas de chip criptográfico, que son mayoritarias en la actualidad. Pero tambien es extraordinariamente complejo, tanto en términos técnicos como de procedimiento, y requiere mucha más capacidad de cómputo que SSL, también un ancho de banda más amplio para las comunicaciones con los comerciantes. Los primeros estudios de desempeño técnico sugerían que la infraestructura de clave pública sería incapaz de soportar estas transacciones, y que sería necesario evolucionar hacia algoritmos de cifrado más eficientes, como los de curva elíptica. Esta es precisamente la filosofía de SET 2.0.