Seguridad en Internet. Resumen Cuando se realizan pagos en Internet y acceso a sitios Web que requieren certificado, intervienen dos protocolos seguros SSL y SET, ofreciendo confidencialidad, identificación, integridad e identificar tanto al cliente como al servidor. Palabras clave Protocolo, SSL, SET, cifrado, autenticación, integridad, cliente, servidor, pago. 1 Introducción Hay ocasiones en las que se hace necesario recibir/enviar información sensible desde/a un servidor de Web, ya sea información confidencial, datos de personal, nóminas, etc. No vale con restringir el acceso mediante claves de acceso o procedimientos similares, además la información que viaja desde/a un servidor de Web debe ir cifrada, para evitar escuchas se pone de manifiesto la necesidad de asegurar mediante algún mecanismo la intimidad y la integridad en las sesiones con el Servidor Web.[ALVe] Para ello surgen dos protocolos que se comentan a continuación. 2 Protocolo SSL SSL (Secure Sockets Layer) fue diseñado y propuesto en 1994 por Netscape Communications Corporation junto con su primera versión del Navigator como un protocolo para dotar de seguridad a las sesiones de navegación a través de Internet. Sin embargo, no fue hasta su tercera versión, conocida como SSL v3.0 que alcanzó su madurez, superando los problemas de seguridad y las limitaciones de sus predecesores. En su estado actual proporciona los siguientes servicios: Cifrado de datos: la información transferida, aunque caiga en manos de un atacante, será indescifrable (confidencialidad). 1
Autenticación de servidores: el usuario puede asegurarse de la identidad del servidor al que se conecta. Integridad de mensajes: se impide que modificaciones intencionadas o accidentales en la información mientras viaja por Internet pasen inadvertidas. Autenticación de cliente: permite al servidor conocer la identidad del usuario, con el fin de decidir si puede acceder a ciertas áreas protegidas. 2.1 Cómo funciona SSL? Cuando un navegador solicita una página a un servidor seguro, ambos intercambian una serie de mensajes para negociar las mejoras de seguridad. Este protocolo sigue las siguientes fases (de manera muy resumida): La fase Hola, usada para ponerse de acuerdo sobre el conjunto de algoritmos para garantizar la confidencialidad e integridad y para la autenticación mutua. El navegador le informa al servidor de los algoritmos que posee disponibles. La fase de autenticación, en la que el servidor envía al navegador su certificado x.509v3 que contiene su clave pública y solicita a su vez al cliente su certificado X.509v3 (sólo si la aplicación exige la autenticación de cliente). La fase de producción de clave de sesión, en la que el cliente envía al servidor una clave maestra a partir de la cual se generará la clave de sesión para cifrar los datos intercambiados posteriormente mediante el algoritmo de cifrado simétrico acordado en la fase 1. El navegador envía cifrada esta clave maestra usando la clave pública del servidor que extrajo de su certificado en la fase 2. La fase Fin, en la que se verifica mutuamente la autenticidad de las partes implicadas y que el canal seguro ha sido correctamente establecido. Una vez finalizada, ya se puede comenzar la sesión segura. De ahí en adelante, durante la sesión segura abierta, SSL proporciona un canal de comunicaciones seguro entre los servidores Web y los clientes (los navegadores) a través del cual se intercambiará cifrada la información (URL, formularios, cookies,...). 2.2 Ventajas de SSL SSL v3.0 goza de gran popularidad y se encuentra ampliamente extendido en Internet, ya que viene soportado por los dos principales navegadores del mercado, Netscape Navigator 3.0 ó superior así como por Internet Explorer 3.0 ó superior. SSL proporciona un canal de comunicaciones seguro entre los servidores web y los clientes (los navegadores), pero su uso no se limita a la transmisión de páginas web. Al encontrarse entre los niveles de transporte y de aplicación, potencialmente SSL puede servir para dar seguridad a otros servicios, como FTP, correo, telnet, etc. El usuario no necesita realizar ninguna acción especial para invocar el protocolo SSL, basta con seguir un enlace o abrir una página cuya dirección empieza por HTTPs://. El navegador se encarga del resto. 2
2.3 Limitaciones y Problemas Debido a la limitación de exportación del gobierno de los Estados Unidos sobre los productos criptográficos, las versiones de los navegadores distribuidas legalmente más allá de sus fronteras operan con nada más que 40 bits de longitud de clave. Claves tan cortas facilitan los ataques de fuerza bruta. Es importante recalcar que SSL sólo garantiza la confidencialidad e integridad de los datos en tránsito, ni antes ni después. Por lo tanto, si se envían datos personales al servidor, entre ellos el número de tarjeta de crédito, número de la seguridad social, DNI, etc., SSL solamente asegura que mientras viajan desde el navegador hasta el servidor no serán modificados ni espiados. SSL solamente se utiliza para comunicaciones seguras en WWW. El protocolo SSL se trata de un sistema de seguridad ideado para acceder a un servidor, garantizando la confidencialidad de los datos mediante técnicas de cifrado modernas. El protocolo SSL sólo afecta a la comunicación cliente vendedor; la comunicación vendedor-banco se realiza mediante protocolos privados. SSL no garantiza los requerimientos de seguridad en su totalidad pero aporta las siguientes características: Confidencialidad. Mediante el uso de la encriptación. Integridad. Se garantiza que los datos recibidos son exactamente iguales a los datos enviados Autenticación. El vendedor se autentifica utilizando un certificado digital emitido por una empresa llamada autoridad certificadora No Repudio. Este requisito no esta garantizado 3 Protocolo SET (Secure Electronic Transaction) Como se puede observar de las características anteriores, el protocolo SSL garantiza la seguridad siempre que exista una confianza mutua entre comprador y vendedor. Con el objetivo de aumentar la seguridad, Visa y Mastercard crearon en mayo de 1997 el protocolo SET. Las principales diferencias entre SSL y SET estriban en que en este protocolo se definen tres entidades (cliente, vendedor y banco) y un protocolo de comunicaciones estándar entre vendedor y banco. En SET cada una de las entidades debe certificarse antes de realizar cualquier transacción y todos los mensajes quedan firmados digitalmente de manera que no puedan ser modificados posteriormente, eliminado la posibilidad de repudio. 3.1 El protocolo SET En relación a los requerimientos de seguridad tenemos: 3
Confidencialidad. Igual que en SSL, los datos van encriptados y no pueden ser interpretados por cualquier persona ajena a la transacción. SET aumenta la privacidad de la comunicación al impedir que el vendedor tenga acceso a los datos bancarios del cliente y que el banco no pueda acceder a los datos de la compra. Integridad. Los datos enviados no pueden ser alterados ni durante la comunicación ni después ya que han sido firmados digitalmente. Autenticación. Tanto el banco, como el vendedor y el cliente deben estar certificados. En SSL únicamente se certifica al vendedor. No Repudio. La firma digital puede servir como prueba de la transacción, por lo que ninguna de las partes puede negar haber participado en ella. Aunque técnicamente se pueda demostrar que la compra se produjo, legalmente el cliente siempre tendrá el derecho a negar su participación en la compra. 3.2 Cómo funciona SET El proceso subyacente en una transacción SET típica funciona de forma muy parecida a una transacción convencional con tarjeta de crédito: Decisión de compra del cliente. El protocolo SET se inicia cuando el comprador pulsa el botón de Pagar o equivalente. Arranque de la cartera. El servidor del comerciante envía una descripción del pedido que despierta a la aplicación cartera del cliente. Transmisión cifrada de la orden de pago. Se crean dos mensajes y se envían al comerciante. El primero, la información del pedido, mientras que el segundo contiene las instrucciones de pago del cliente para el banco adquiriente. 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. Envío de la petición de pago al banco del comerciante. 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). Validación del cliente y del comerciante por el banco adquiriente. 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. 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, convenientemente cifrada, la cual se la hace llegar al comerciante. 4
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 entrega al cliente un recibo de la compra, como justificante de compra. Entrega del testigo de transferencia de fondos para cobrar el importe de la transacción. El 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. Cargo en la cuenta del cliente. A su debido tiempo, la transacción se hace efectiva sobre la cuenta corriente del cliente. El protocolo definido por SET especifica el formato de los mensajes, las codificaciones y las operaciones criptográficas que deben usarse. No requiere un método particular de transporte, de manera que los mensajes SET pueden transportarse sobre HTTP en aplicaciones Web, sobre correo electrónico o cualquier otro método. En su estado actual SET solamente soporta transacciones con tarjeta de crédito/débito, y no con tarjetas monedero. Se está trabajando en esta línea para extender el estándar de manera que acepte nuevas formas de pago. Al mismo tiempo se están desarrollando proyectos para incluir los certificados SET en las tarjetas inteligentes, de tal forma que el futuro cambio de tarjetas de crédito a tarjetas inteligentes pueda incorporar el estándar SET. Cómo puede saber el cliente que está realizando una compra segura? En las compras con SSL, el cliente accederá a un centro comercial virtual mediante un navegador Internet y seleccionará los productos que desea adquirir. Posteriormente, entrará en una página donde se le pedirán sus datos personales y bancarios, el más importante de ellos es el PIN de la tarjeta de crédito. Antes de enviar los datos hay que fijarse si estamos conectando con un servidor seguro; esto se puede comprobar mirando el icono del candado que aparece en la parte superior del navegador. Si está cerrado significa que la comunicación se realizará mediante las técnicas de encriptación SSL y que el servidor esta certificado por Verisign. En caso contrario el navegador mostrará un mensaje avisando que la comunicación no es segura. 4 Conclusiones Las claves para saber si una persona o cliente hace una compra segura, es saber si se trabaja con un protocolo seguro, entre ellos SSL o SET, para ello el cliente accederá a un centro comercial virtual mediante el navegador seleccionando productos. Cuando en la página se solicita los datos personales, bancarios y pide el pin de la tarjeta de crédito, se debe observar si se está conectando a un servidor seguro, comprobando si el icono del candado que aparece en la parte superior del candado sino es mejor no realizar esa compra. Si está cerrado ese candado significa que la comunicación se está aplicando mediante técnicas de encriptación SSL y que el servidor está certificado, en caso contrario avisará si la comunicación no es segura. 5
Bibliografía Marañón, Álvarez. Seguridad SLL,(2010), extraído el 2 de Abril desde http://www.idg.es/iworld/articlo.asp?id=68235&sec=iworld Set en Internet, (2010), extraído el 2 de Abril desde http://www.setco.org The SSL protocol, (2010), extraído el 7 de Abril desde http://www.netscape.com/eng/ssl3/ssl-toc.html Verisign Secre Site Services, extraído el 7 de Abril desde http://www.verisign.com 6