Identidad e Internet. María Victoria Artigas Pedro Rincón

Transcripción

1 Identidad e Internet María Victoria Artigas Pedro Rincón

2 1 Motivación Seguridad vs Conveniencia Proveer al usuario contenido personalizado 2 Interacción Entre Usuarios y Páginas Web

3 Protocolos de autenticación web OpenID Es un estandar abierto para la autenticación de los usuarios de forma descentralizada Los usuarios crean su cuenta con cualquiera de los proveedores de identidad OpenID Utiliza Diffie-Hellman para establecer una clave de sesión La clave es compartida con un solo sitio web El identificador es un URL

4 Protocolos de autenticación web 1.El usuario es presentado con un login de OpenID por el consumidor (Consumer) 2.El usuario responde con el URL que representa su OpenID 3.El consumidor canoniza la dirección URL OpenID y utiliza la versión canoníca para solicitar mediante un GET un documento del Servidor de Identidad (Identity Server) 4.El Servidor de Identidad retorna el documento HTML solicitado por el URL OpenID

5 Protocolos de autenticación web 5.El consumidor inspecciona la cabecera del documento HTML por la etiqueta <link/> con el atributo rel colocado en openid.server y, opcional, ente, openid.delegate. El consumidor utiliza los valores en estos tags para construir un URL con el modo checkid_setup para el Servidor de Identidad y redirige al agente de usuario (User Agent). La dirección URL checkid_setup codifica, entre otras cosas, un URL de retorno en caso de éxito y uno en caso de fallar o de cancelación de la solicitud 6.El servidor OpenID retorna una página de login

6 Protocolos de autenticación web 7.El usuario envía mediante POST un ID de login y una clave al servidor OpenID 8.OpenID retorna un formulario trust solicitando si el usuario desea confiar en el consumidor (identificado por un URL) con su identidad 9.El usuario envía mediante POST la respuesta al servidor OpenID 10.El usuario es redirigido al URL de éxito o fracaso especificado en el paso 5 dependiendo de la respuesta del usuario 11.El Consumidor retorna la pagina apropiada de acuerdo a la acción codificada en el paso 10

7 Protocolos de autenticación web BrowserID Se basa en el uso de direcciones de correo como identificadores de los usuarios Basado en el protocolo verified , en el cual se garantiza que el usuario es el dueño de un correo mediante el uso de certificados Utiliza criptografía de llaves asimétricas y SSL Actualmente implementado como un JavaScript, pero espera ser integrado a los navegadores

8 Protocolos de autenticación web Certificate Provisioning 1.Algún evento ocurre mediante el cual el usuario indica que quisiera ingresar a una parte confiada (relying party) utilizando su cuenta de gmail, y el usuario es llevado a una página de gmail diseñada con el propósito de suministro de clave. 2.El usuario se autentica a gmail utilizando su usuario y clave. 3.Un java script alojado en el servidor de gmail llama a navigator.id.genkeypair(), una función que se encuentra del lado del clientes, implementada por el navegador, que causa que se generen un par de claves. Una vez completado, la clave pública es devuelta al llamador (java script de gmail), y el par de claves es almacenada en el navegador durante la sesión.

9 Protocolos de autenticación web Certificate Provisioning 4.Un java script de gmail en el lado del cliente envía una clave pública a un servidor de gmail vía SSL. 5.gmail firma la dirección de correo del usuario, la clave pública, y un intervalo de validez generando un signs the user's address, the public key, and a validity interval generating a JWT (que es sólo un medio de codificar un objeto JSON firmado). 6.Gmail vuelve este paquete para el cliente como una respuesta a la solicitud en el paso 3.

10 Protocolos de autenticación web Certificate Provisioning 7.El código de Java Script proporcionado por gmail invoca navigator.id.registerverified () en el cliente pasando el certificado. 8.El navegador ubica la clave privada generada en el paso 2 y la mueve junto al certificado de la sesión temporal al anillo de claves del usuario en BrowserID. El usuario ahora tiene un certificado válido de gmail guardado en su navegador permitiéndoles generar aseveraciones que acrediten su identidad.

11 Protocolos de autenticación web Assertion Generation 1.Durante el proceso de ingreso al website, el usuario hace click en un botón de sign in en el sitio de la parte confiable(relying parties) ocasionando que el RO invoque navigator.id.getverified (). 2.El usuario selecciona la dirección de correo de una lista mostrada por el navegador, con la cual quieren loggearse 3.El navegador combina el dominio que está solicitando la identidad, un período de validez y el certificado asociado con la identidad y los empaqueta (el certificado incluye una clave pública, y la dirección de correo electrónico a ser compartida). 4.El paquete es firmado utilizando la clave privada asociada con la identidad, codificada en un JWT, y devuelta a la página web.

12 Protocolos de autenticación web Assertion Verification 1.El Relying Party (de manera segura) envía la confirmación del cliente a los servidores 2.Los períodos de validez son revisados en ambas partes, el certificado y la confirmación. 3.El relying party extrae el host-name del correo electrónico en la confirmación; esta es la autoridad primaria de identidad para la dirección de correo electrónico. En el ejemplo gmail.com. 4.La llave o llaves públicas para gmail.com son obtenidas de una ubicación bien conocida en sus servidores.

13 Protocolos de autenticación web Assertion Verification 5.La firma del certificado es verificada; si es exitosa esta verificación se prueba que el RP que adjuntó la clave pública del usuario es válida. 6.La firma de la confirmación es verificada utilizando la clave pública del usuario que se encontraba adjuntada, después de este punto el RP sabe que la confirmación es válida y el usuario es poseedor de la dirección de correo especificada.

14 Protocolos de autenticación web OAuth Es un estandar abierto para la autorización de APIs Permite a los usuarios compartir recursos entre sitios web con controles de acceso, duración, especificidad, entre otros.

15 Protocolos de autenticación web 1.Obtiene un token de request 2.El usuario autoriza el token de request 3.Se intercambia el token de request por uno de acceso. 4.Se utiliza el token de acceso para obtener los recursos protegidos.

16 Manejadores de claves de acceso LastPass Funcionalidad con y sin conectividad Cifrado AES de 256 bits Utiliza JavaScript para su funcionamiento Utiliza SSL/HTTPS

17 Manejadores de claves de acceso

18 Manejadores de claves de acceso Clipperz Manejador On Line de Claves Basado en Zero-Knowledge Apps Cifrado Local antes de enviar información Garantiza seguridad de 128 bits Los pilares son: SRP, AES 256, Double SHA 256 Fortuna

19 Manejadores de claves de acceso

20 Seguridad con transacciones de Tarjetas de Crédito 3-D Secure Es un protocolo basado en XML para mejorar la seguridad de transacciones de Tarjetas de Crédito Implementado por Visa, MasterCard, JCB international y American Express como Verified by Visa, MasterCard SecureCode, J/Secure y SafeKey respectivamente.

21 Seguridad con transacciones de Tarjetas de Crédito

22 Seguridad con transacciones de Tarjetas de Crédito 1.El cliente quiere pagar y va a una planilla de pago donde el cliente coloca sus datos de dirección de domicilio 2.El software de la página que proporciona la planilla de pago emite una solicitud de transacción de Authorize o Sale con la información de la transacción y los tags return_url y cancel_url 3.El sistema CertoDirect de pago verifica si la tarjeta de crédito soporta la tecnología 3d Secure. Si es así el Gateway de pago envía de vuelta una respuesta XML con un tag forward_url 4.el software del pagina debe ahora enviar al navegador a la dirección de forward_url 5.el navegador del cliente va al forward_url

23 Seguridad con transacciones de Tarjetas de Crédito 6.El navegador del cliente redirige a una página de autenticación 3dsecure donde el cliente debe pasar la autenticación 3dsecure. 7.el browser del cliente redirige de nuevo al Gateway de pago Certodirect y el Gateway de pago basado en la respuesta de 3dsecure realiza el cargo en la tarjeta o no 8.el navegador del cliente redirige al return_url utilizando el método POST con la información del pedido que contiene la información de autenticación de 3dsecure (solamente si la transacción fue procesada exitosamente). si la return_url no fue provista entonces el navegador del cliente redirige al uro puesto en el sistema de pago CertoDirect. en caso de fallar el navegador redirige al cancel_url.

24 Seguridad con transacciones de Tarjetas de Crédito SET Desarrollado por Visa y MasterCard entre otros Fracasó debido a problemas como la necesidad de instalar software adicional por parte de los clientes, costos mayores de instalación y soporte, entre otros. Basado en certificados X.509

25 Seguridad con transacciones de Tarjetas de Crédito 1.El cliente recibe un certificado. luego de una verificación de la identidad apropiada, el cliente recibe un certificado digital X.509v3, el cual es firmado por el banco. El certificado verifica la llave pública RSA y su fecha de expiración. también establece la relación, garantizada por el banco, entre la llave del cliente y su tarjeta de crédito. 2.Los vendedores tienen sus propios certificados. un vendedor que acepta cierta marca de tarjeta de crédito debe poseer dos certificados para dos llaves públicas pertenecientes al vendedor: uno para firmar mensajes y otro para el intercambio de llaves. el vendedor también necesita una copia del certificado del Gateway de pago.

26 Seguridad con transacciones de Tarjetas de Crédito 3.El cliente coloca una orden. luego el cliente envía una lista de los ítems a comprar al vendedor, el cual retorna una planilla conteniendo la lista de ítems con su precio, el total y el numero de orden 4.El vendedor es verificado. además de la planilla de orden, el vendedor envía una copia de su certificado de forma tal que el cliente pueda verificar que está tratando con un vendedor legitimo

27 Seguridad con transacciones de Tarjetas de Crédito 5.Se envía la orden y el pago. el cliente envía tanto la orden como la información de pago al vendedor, junto al certificado del cliente. la orden confirma la compra de los ítems. el pago contiene la información nade la tarjeta de crédito. la información de pago es cifrada de tal forma que no puede ser leída por el vendedor. el certificado del cliente permite que le vendedor verifique al lienta. 6.El cliente solicita la autorización de pago. el vendedor envía la información de pago al Gateway de pago, solicitando una autorización de que el cliente posee suficientes fondos para la compra.

28 Seguridad con transacciones de Tarjetas de Crédito 7.El vendedor confirma la orden. el vendedor envía confirmación de la orden al cliente. 8.El vendedor provee los productos o servicios. el vendedor envía los productos al cliente. 9.El vendedor solicita el pago. esta solicitud es enviado al Gateway de pago, el cual maneja todo el procesamiento de pago.