La incorporación de servicios de seguridad en las redes de datos da lugar a varias

54 

Loading....

Loading....

Loading....

Loading....

Loading....

Texto completo

(1)

Modelos de Seguridad  en Web

La incorporación de servicios de seguridad en las redes de datos da lugar a varias sol ciones concretas en Internet Estas sol ciones las llamamosM d l d id d soluciones concretas en Internet. Estas soluciones las llamamosModelos de seguridad en Web.

Estas diferentes soluciones de seguridad consisten en implementar los servicios de seguridaden niveles ya existentes de la arquitectura TCP/IP, o bien, crear un nuevo nivel para implementar estos servicios. Una última alternativa, es implementar los servicios directamente en nuestra aplicaciones.

(2)

Modelos de Seguridad  en Web

Los objetivos que vamos a seguir en esta presentación son, por un lado, conocer las diferencias entre los modelos prácticos de seg ridad e istente por otro presentar las diferencias entre los modelos prácticos de seguridad existente y, por otro, presentar las soluciones prácticas más utilizadas como son los túneles de cifradoen Internet, la capa de seguridadSSL (Secure Sockets Layer) ola implementación de servicios de seguridad directamente en nuestras aplicaciones. Un ejemplo de este último caso sería el correo electrónico seguro.

(3)

Modelos de Seguridad  en Web

El índice que vamos a utilizar comienza con la definición de los distintos modelos de id d continúa por la presentación de los l d Cif d I t t sig e con seguridad, continúa por la presentación de losTúneles de Cifrado en Internet,sigue con la descripción detallada de la capa SSL (una de las soluciones más utilizada en la práctica) y finaliza con la presentación del correo seguro S/MIME.

(4)

Modelos de Seguridad  en Web

Son posibles varios modelos para proporcionar seguridad en laWeb. Estos modelos son similares en c anto a los ser icios q e proporcionan en los mecanismos q e san similares en cuanto a los servicios que proporcionan y en los mecanismos que usan, aunque difieren respecto a su rango de aplicabilidad y su localización relativa dentro de la pilaTCP/IP.

Podemos clasificar los modelos de seguridad (soluciones de seguridad) existentes en Internet en tres grupos:

La primera solución proporciona seguridad en el mismo nivel IP de la arquitectura TCP/IP. Las aplicaciones de usuario estarán protegidas mediante servicios de seguridad que se implementa en el mismo nivelIPmediante cabecera adicionales del paqueteIPv4 que se implementa en el mismo nivelIPmediante cabecera adicionales del paqueteIPv4 o cabeceras opcionales de los paquetesIPV6. Ejemplo de amplio uso serían los túneles de cifrado utilizados a nivel corporativo para comunicar de forma segura dos sucursales de la misma organización remotamente distantes.

Una segunda solución de seguridad es utilizar una capa adicional dentro de la arquitecturaTCP/IPcomo es SSL (Secure Sockets Layer).Esta capa adicional permite a las aplicaciones de usuario obtener servicios de seguridad (canal confidencial, autenticación de usuario, integridad etc). Ejemplos claros son el acceso a servicios como autenticación de usuario, integridad etc). Ejemplos claros son el acceso a servicios como Banca electrónica ..

Una última solución es implementar los servicios de seguridad en las propias aplicaciones de usuario y no utilizar (aunque no es excluyente) los dos modelos anteriores. Este sería el caso de aplicaciones de correo electrónico seguro.

(5)

Modelos de Seguridad  en Web

IPSec es un conjunto de estándaresRFC´semitidos por elIETF (The Internet Engineering Task Force) que proporcionan servicios de seguridad a la capa IP y a todos los protocolos superiores basados enIP(TCPyUDP, entre otros). Es un estándar que aborda las

carencias en cuanto a seguridad del protocolo IP. Dichas carencias son graves y, tal como se ha constatado en los últimos años, afectan a la infraestructura misma de las redes IP. Todas las soluciones anteriores se basaban en soluciones propietarias que dificultaban la comunicación entre los distintos entornos empresariales al ser necesario que éstos dispusiesen de una misma plataforma La falta de comunicación entre los distintos entornos empresariales, al ser necesario que éstos dispusiesen de una misma plataforma. La falta de interoperabilidad ha sido el principal freno para el establecimiento de comunicaciones seguras, dado que no se ve factible la migración a una determinada plataforma en función de una colaboración empresarial puntual. Entre las ventajas deIPSecdestacan que está apoyado

en estándares del IETF y que proporciona un nivel de seguridad común y homogéneo para todas las aplicaciones, además de ser

independiente de la tecnología física empleada. IPSecse integra en la versión actual deIP (IP versión 4) y, lo que es todavía más

importante, se incluye por defecto en IPv6. IPSec proporciona confidencialidad, integridad y autenticidad de datagramas IP,

combinando tecnologías de clave pública (RSA), algoritmos de cifrado (DES, 3DES, IDEA, Blowfish), algoritmos dehash(MD5, SHA-1) y certificados digitalesX509v3.

La descripción de la arquitectura de seguridad que comprendeIPsecaparece descrita en elRFC 2401. EsteRFCes la actualización de

losRFC´s 1826 y 1827en los que se planteaba ya una solución de seguridad en Internet basada en el protocoloIP En elRFC 2401se

losRFC s 1826 y 1827en los que se planteaba ya una solución de seguridad en Internet basada en el protocoloIP. En elRFC 2401se

describe una arquitectura para proporcionar servicios de seguridad al tráfico de nivelIPtantoIPv4comoIPv6. Los aspectos claves son

siguientes:

La definición de nuevas cabeceras (también llamadas protocolos) a incluir en el paquete IP. La primera sería la llamada“Cabecera de Autenticación” ("Authentication Header”, AH).Esta cabecera está orientada a proporcionar servicios de autenticación a los paquetes IP.

La segunda cabecera es denominada “Cabecera de Encapsulados de Contenidos de Seguridad” ("Encapsulated Security Payload“, ESP).Esta última cabecera tiene una doble misión protege confidencialmente los datos incluidos en el paqueteIPy, además, puede

incluir el servicio de autenticación. La descripción completa de estas cabeceras aparece descripta en losRFC´s 2406 y 2402

Otros de los aspectos esenciales de IPSec es la definición del concepto de Asociación de Seguridad. Una asociación de seguridad (Security Association, SA) es una simple conexión que ofrece servicios de seguridad al trafico que soporta. UnaSAes identificada por una tripleta que consta de unSecurity Parameter Index (SPI), una dirección IP destino y un protocolo de seguridad (AH o ESP). Una

asociación de seguridad tiene una Base de datos asociadaSecurity Association Databasesen la que se contiene información relativa a la

asociación actual como algoritmos criptográficos y claves a aplicar. Se definen en laRFC 2401dos tipos de asociaciones de seguridad

(SAs): el modo transporte y el modo túnel. UnaSAmodo transporte es una asociación de seguridad entre dos máquinas. UnaSAmodo

túnel es esencialmente una asociación de seguridad aplicada a untúnel IP. Siempre que el elemento final de unaSAsea unapasarelala

SAdebe de ser modo túnel, como por ejemplo un SA entre un sistema y unapasarela. Dos sistemas pueden establecer unaSAmodo

túnel entre ellos.

Lascabeceras de Autenticación (AH)y la deEncapsulado de Contenidos de Seguridad (ESP)implementan mecanismos de cifrado y

f i h h i l i i d fid i lid d i i l i i l di h

funciones hash para proporcionar los servicios de confidencialidad y autenticación. Las claves necesarias para implementar dichos mecanismos pueden ser configuradas manualmente por el administrador de la red, o bien, ser distribuidas con un protocolo de seguridad. La arquitecturaIPsecha establecido en el protocolo de seguridadIKE “Internet Key Interchange” (RFC 2408) el estándar a utilizar.

(6)

Modelos de Seguridad  en Web

En la figura se aprecia el funcionamiento más conocido del protocoloIPsec: un túnel de cifrado a través de Internet En este ejemplo se ha establecido una Asociación de cifrado a través de Internet. En este ejemplo, se ha establecido una Asociación de Seguridad (SA, Seccurity Association)modo túnel. Una SAmodo túnel es esencialmente unaasociación de seguridadaplicada a un túnelIP. Siempre que un extremo de laSAsea unencaminador (router)laSA debe ser un túnel. Por lo tanto, una asociación entre dos encaminadoreses en modo túnel. El ejemplo de la figura sería un ejemplo clásico en el que una organización que dispone de dos sedes geográficamente separadas quiere interconectar el trafico entre ellas de forma segura utilizando la Internet abierta.

Supóngase que un sistema de una sede quiere mandar un paquete a un sistema de la otra Supóngase que un sistema de una sede quiere mandar un paquete a un sistema de la otra sede. En elmodo túnel se toma el paquete original generado por el sistema (incluida la cabecera IP original) y se le añade una cabecera de seguridad, normalmente laCabecera de Encapsulado de Contenidos de Seguridad (ESP, Encapsulated Security Payload). Luego se cifra todo el paquete resultante y se le añade una cabecera IP externa con las direcciones IP de losencaminadoresde las sedes de la organización.

El paquete IP resultante viaja por internet encaminándose hasta la otra sede de la organización en función de las direcciones IP de losencaminadores. Al llegar al destino, el encaminador que recibe el paquete descifra el paquete ESP y extrae el paquete IP interno que finalmente entrega al sistema final.

ElIANA (Internet Assigned Numbers Authority)ha asignado al protocoloESPel número decimal 50. Esto implica que el campoProtocolode la cabeceraIP externa contendrá el valor 50, mientras que dentro del mensajeESPse indica la naturaleza de los datos. Puesto que este campo, al igual que la carga útil, está cifrado, un hipotético atacante que intercepte el paquete no podrá saber si el contenido es TCP o UDP; esto es completamente normal ya que el objetivo que se persigue es precisamente ocultar la completamente normal ya que el objetivo que se persigue es, precisamente, ocultar la información.

(7)

Modelos de Seguridad  en Web

En la figura se observa el funcionamiento del protocolo IPsec en modo transporte para proporcionar servicio de confidencialidad En elmodo transporteel contenido transportado proporcionar servicio de confidencialidad. En elmodo transporteel contenido transportado dentro del paquete ESP son datos de la capa de transporte (por ejemplo, datos TCP o UDP). Por tanto, la cabecera IPSec se inserta inmediatamente a continuación de la cabeceraIPy antes de los datos de los niveles superiores que se desean proteger. El modo transporte tiene la ventaja de que asegura la comunicación extremo a extremo, pero requiere que ambos extremos entiendan el protocoloIPSec.

(8)

Modelos de Seguridad  en Web

Si se quiere únicamente garantizar la integridad y la autenticación de los paquetes IP se va a utilizar laCabecera de Autenticación (AH Authentication Header)

a utilizar laCabecera de Autenticación (AH, Authentication Header)

La cabeceraAHes el procedimiento previsto dentro deIPSecpara garantizar la integridad y autenticación de los datagramas IP. Esto es, proporciona un medio al receptor de los paquetesIPpara autenticar el origen de los datos y para verificar que dichos datos no han sido alterados en tránsito. Sin embargo no proporciona ninguna garantía de confidencialidad, es decir, los datos transmitidos pueden ser vistos por terceros. Tal como indica su nombre,AHes una cabecera de autenticación que se inserta entre la cabecera IP estándar (tanto IPv4 como IPv6) y los datos transportados, que pueden ser un mensaje estándar (tanto IPv4 como IPv6) y los datos transportados, que pueden ser un mensaje TCP, UDP.

Nótese que el campo añadido que incorpora el paquete IP es el resumen (hash)del paquete IP concatenado con una clave de autenticación que previamente se tendría que haber distribuido entre las entidades que se comunica.

Es importante destacar que AH asegura la integridad y autenticidad de los datos transportados y de la cabeceraIP, excepto los campos variables:TOS, TTL, flags, offsety checksum.

ElIANA(Internet Assigned Numbers Authority) le ha asignado el número decimal 51. Esto significa que el campo Protocolode la cabecera IPcontiene el valor 51, en lugar de los valores 6 ó 17 que se asocian aTCPyUDPrespectivamente. Es dentro de la cabeceraAH donde se indica la naturaleza de los datos de la capa superior.

(9)

Modelos de Seguridad  en Web

La autenticación se puede aplicar a un paqueteIPen un túnel IP. Esta es un situación recogida en el estándar aunque es muy poco utilizada. La autenticación se aplica al paquete interno entero (cabecera más carga útil) y a los campos inmutables de la cabecera IPexterna.

En un túnelIP la autenticación suele estar combinada con la confidencialidad y en ese caso se utiliza la cabecera ESP.

(10)

Modelos de Seguridad  en Web

Cuando la política de seguridad de la Organizaciónexige que las unidades de datos IP vayan protegidas con el servicio de confidencialidad y autenticación se va a utilizar la Cabecera de Encapsulado de Contenidos de Seguridad (ESP, Encapsulated Security Payload).

Esta nueva cabecera no sólo proporciona el servicio de confidencialidad sino también la autenticación. La autenticación y confidencialidad se puede aplicar a una Asociación de Seguridad modo transporte o modo túnel.

Como se aprecia en la figura la autenticación se evalúa sobre lo que se denomina paquete ESP. El paquete ESP es el conjunto de los datos de nivel superior y la cabecera ESP (modo transporte) o bien el paqueteIPoriginal y la cabeceraESP (modo túnel).

(11)

Modelos de Seguridad  en Web

El estándar RFC2402 recoge el comportamiento de la Cabecera de Autenticación (AH, Authentication Header)así como el formato En la figura se aprecia el formato de esta nueva Authentication Header)así como el formato. En la figura se aprecia el formato de esta nueva cabecera que comprende los siguientes campos:

El campo “próxima cabecera” indica el tipo del siguiente unidad de datos después de la cabecera de autenticación. Es un numero de protocolo IP. El campo “longitud” indica la longitud de la cabecera AH en palabras de 32 bits. El campo “SPI, security Parameters Index” es un valor arbitrario de 32 bits que en combinación con la dirección IP destino y la AH únicamente identifica la asociación de seguridad para este datagrama. El campo “número de secuencia” contiene un contador que se incrementa monótonamente. Es un campo obligatorio y siempre está presente. El procesado del campo número de secuencia es discrecional en el receptor

procesado del campo número de secuencia es discrecional en el receptor.

El campo datos contiene el hash del paqueteIPexceptuando los campos mutables concatenado con una clave de autenticación. Los algoritmos de autenticación pueden serMD5, SHA1.

Los campos inmutables en IPv4 son: versión, longitud de la cabecera, longitud total, identificación, protocolo, dirección origen y destino.

Los mutables enIPV4son tipo de servicio, flags, offset, tiempo de vida y suma de comprobación de la cabecera

Los campos inmutables en IPv6 son la versión, la longitud de la carga y la siguiente cabecera yp , g g y g y dirección origen y destino.

Los mutables en IPV6 son etiqueta de flujo, límite de saltos y clase de tráfico.

El identificador (número de protocolo) de la Cabecera de Autenticación (AH, Authentication Header)es el 51.

(12)

Modelos de Seguridad  en Web

En la figura se muestra un ejemplo de un paquete IP que incluye servicios de seguridad utilizando el modeloIPsec En concreto en la figura se muestra la implementación del utilizando el modeloIPsec. En concreto, en la figura se muestra la implementación del servicio de autenticación de un paqueteIPv4en modo transporte.

IPsec inserta el campo de autenticación inmediatamente después de la cabecera original IP, pero antes de la cabecera de transporte (TCP). El campo protocolo de la cabecera IP es cambiado alvalor 51para indicar la presencia de la cabecera AH.

En el campo parámetros de seguridad (SPI) de la cabecera AH define una serie de parámetros a aplicar a laasociación de seguridad(SA), estos son (entre otros): Algoritmo de autenticación claves tiempos de vida de las claves y parámetros relacionados que se de autenticación, claves, tiempos de vida de las claves y parámetros relacionados que se utilizan conAH.

En el campo de datos de esta cabecera se calcula elhashdel paquete IP concatenado con una clave de autenticación. Se excluyen para los cálculos del hash los valores de la cabecera IP que cambian al atravesar los distintosencaminadores. Los campos mutables en IPV4 son tipo de servicio,flags, offset, tiempo de vida y suma de comprobación de la cabecera

El receptor del datagrama IP usa la información de seguridad para verificar la El receptor del datagrama IP usa la información de seguridad para verificar la autenticación del datagrama y usa el campo siguiente cabecera para obtener el campo de datos del paqueteIP.

(13)

Modelos de Seguridad  en Web

En la figura se muestra la Cabecera de Encapsulado de Contenidos de Seguridad (ESP, Encapsulated Security Payload)

Encapsulated Security Payload).

En elcampo parámetros de seguridad (SPI, Security Parameters Index)se definen una serie de parámetros a aplicar a unaasociación de seguridad (SA),estos son (entre otros): Algoritmos de cifrado y autenticación, claves, valores de inicialización, tiempos de vida de las claves y parámetros relacionados que se utilizan con ESP. Al menos es obligatorio el algoritmo DES, modo del protocoloIPsec: túnel, o transporte.

La función de cifrado dentro del protocolo ESP es desempeñada por un algoritmo de cifrado de clave simétrica. Típicamente se usan algoritmos de cifrado bloque, de modo que la longitud de los

d t if ti últi l d l t ñ d bl (8 16 b t l í d l

datos a cifrar tiene que ser un múltiplo del tamaño de bloque (8 o 16 byte, en la mayoría de los casos). Por esta razón existe un campo de relleno, tal como se observa en la Figura el cual tiene una función adicional: es posible añadir caracteres de relleno al campo de datos para ocultar así su longitud real y, por tanto, las características del tráfico. Un atacante suficientemente hábil podría deducir cierta información a partir del análisis de ciertos parámetros de las comunicaciones, aunque estén cifradas, tales como el retardo entre paquetes y su longitud. La función de relleno está pensada para dificultar este tipo de ataques. El campo“número de secuencia”contiene un contador que se incrementa monótonamente. Es un campo obligatorio y siempre está presente. El procesado del campo número de secuencia es discrecional en el receptor.

procesado del campo número de secuencia es discrecional en el receptor.

El campo“carga de Datos”es conocido por las entidades de acuerdo a la asociación de seguridad junto con la clave y el algoritmo de cifrado. Nótese que el campo próxima cabecera va cifrado con lo cual un intruso no sabe el contenido del paqueteIP.

El campo “siguiente cabecera”identifica el tipo de datos contenidos en la“carga de datos” por ejemplo un nivel superior en IPV4 o un paquete IP entero. Si es un valor de “4” indica que tenemos encapsulado un paqueteIPV4, si tenemos un 6 Indica que tenemos un segmentoTCP. El “campo de autenticación” es un campo de longitud variable computado sobre el paquete ESP

l d d d i ió E i l i l id l i h

menos el campo de datos de autenticación. Este campo es opcional y es incluido solo si se ha seleccionado el servicio de Autenticación para laAsociación de Seguridadactual. La longitud de este campo debe de haber sido negociada en la SA. Los algoritmos especificados son SHA y MD5. La autenticación se aplica pues a el campoSPI, número de secuencia, carga útil, relleno, longitud de relleno y siguiente cabecera. Los cuatro últimos campos están cifrados, ya que el cifrado se aplica antes que la autenticación.

(14)

Modelos de Seguridad  en Web

En la figura se muestra un ejemplo práctico de la Cabecera de Encapsulado de C t id d S id d (ESP E l t d S it P l d) U l d 50 l Contenidos de Seguridad (ESP, Encapsulated Security Payload). Un valor de 50en el campo “protocolo” del datagrama IP informa al receptor de que tenemos un datagrama cifrado con ESP.

En este ejemplo el campo “siguiente cabecera” del paquete ESP debería indicar el protocolo TCP (6) si fuera UDP sería el 17. Y si tuviera dentro un paquete IP encapsulado el campo “siguiente cabecera” indicaría el valor 4 (encapsulado IPenIP). No obstante, este campo va cifrado y, por tanto, un intruso no podría determinar la naturaleza del tráfico.

naturaleza del tráfico.

En el ejemplo de la figura hay autenticación delpaquete ESPque se aplica después del cifrado de los datos.

El usuario receptor al ver elcódigo 50en el campo “siguiente protocolo”de la cabecera IPv4, interpreta que a continuación viene un paqueteESPy, por consiguiente, de acuerdo a su asociación de seguridad descifra la información y comprueba el campo de autenticación.

(15)

Modelos de Seguridad  en Web

En la figura se muestran todas las posibilidades recogidas en el modelo IPsec para proteger los paquetesIPen Internet

proteger los paquetesIPen Internet.

Una de las posibilidades más utilizada hoy en día es el modo túnel con la Cabecera de Encapsulado de Contenidos de Seguridad (ESP, Encapsulated Security Payload) utilizada para proporcionar confidencialidad y autenticación.

(16)

Modelos de Seguridad  en Web

IPv6la nueva especificación del protocolo IPv4que aumenta el espacio de direcciones IP de 32 a 128 bits (RFC 2460) ha incorporado desde su desarrollo la necesidad de IP de 32 a 128 bits (RFC 2460) ha incorporado desde su desarrollo la necesidad de incluir servicios de seguridad en el transporte de los paquetes IPv6 en la red.

El formato del paquete IPv6 tiene una cabecera fija de 40 octetos y varias cabeceras opcionales de ampliación en comparación con el formato del paqueteIPv4que es de 20 octetos y tiene un conjunto de cabeceras opcionales de longitud variable. En IPv6 algunos de los campos de la cabecera IPv4, como los relativos a fragmentación, se trasladan a las cabeceras de ampliación. Otros, como la suma de comprobación de la cabecera han sido eliminados. Una cabecera de tamaño fijo y las cabeceras opcionales cabecera han sido eliminados. Una cabecera de tamaño fijo y las cabeceras opcionales para funciones especiales reducen la necesidad de proceso en losencaminadores. Dos de las cabeceras opcionales de IPv6 coinciden exactamente con el modelo propuesto porIPsec. Es decir,Cabecera de Autenticación (AH, Authentication Header) y la Cabecera de Encapsulado de Contenidos de Seguridad (ESP, Encapsulated Security Payload) han sido incorporadas al protocolo IPv6 como mecanismo de seguridad para proporcionar los servicios de confidencialidad, integridad y autenticación.

(17)

Modelos de Seguridad  en Web

Otra solución para proporcionar seguridad a nuestras aplicaciones que utilizan la Internet abierta es incorporar un nuevo nivel o capa a la arquitectura TCP/IP Este nuevo nivel abierta es incorporar un nuevo nivel o capa a la arquitectura TCP/IP. Este nuevo nivel denominado SSL(“Secure Sockets Layer”)recogerá los datos de nuestras aplicaciones y mediante los mecanismos de seguridad conocidos basado en el modelo de clave pública incorporará servicios de seguridad.

Esta nueva capa es comúnmente encontrada embebida en los navegadores de Internet proporcionado el acceso seguro a los sitios Web. No obstante, el nivel SSL puede operar de forma independiente a los navegadores , como una capa más de la Arquitectura de comunicaciones de un sistema

comunicaciones de un sistema

El nivel de sockets seguro es (a semejanza con la familia TCP/IP) un conjunto de protocolos que tienen como objetivo el proporcionar servicios de seguridad: Protocolo de transporte (“Record Protocol”), Protocolo de Seguridad (“Handshake Protocol”), Protocolo de Alertas (“Alert Protocol”), Protocolo de Actualización de Cifradores (“Change Chiper Spec Protocol”).

De todos los protocolos que forman parte de la capa SSL será de especial interés para nosotros el protocolo de seguridad que será el encargado de distribuir las claves de sesiónp g q g y autenticación.

(18)

Modelos de Seguridad  en Web

El nivel o capaSSL (Secure Sockets Layer)fue desarrollado por Netscape (navegador de Internet) y ha sido universalmente aceptado por el WWW para autenticación y encriptación de las y ha sido universalmente aceptado por el WWW para autenticación y encriptación de las comunicaciones entre clientes y servidores. A partir del producto desarrollado por Netscape se desarrollo un estándarIETF (Internet Engineering Task Force) llamadoTransport Layer Security (TLS) basado enSSL.

El protocolo SSL corre por encima de TCP/IP y está situado por debajo de protocolos como HTTP. UtilizaTCP/IPen nombre de los protocolos de nivel superior y en el proceso permite que un servidor SSL se autentique a un cliente SSL, permite que el cliente se autentique al servidor y permite que ambas máquinas mantengan una conexión cifrada. Estas aspectos se orientan a lo que son aspectos fundamentales en las comunicaciones sobre Internet y otras redes TCP/IP:

son aspectos fundamentales en las comunicaciones sobre Internet y otras redes TCP/IP:

Autenticación del servidor SSL: Permite que un usuario confirme la identidad del servidor. El software del cliente SSL puede usar técnicas estándar de criptografía de clave pública para chequear que el certificado de un servidor y su ID son válidos y han sido emitidos por una Autoridad de Certificación (CA, Certification Authority)listada en la lista deCA´s consideradas fiables. Esta confirmación puede ser importante si el usuario, por ejemplo, envía un número de tarjeta de crédito sobre la red y quiere chequear la identidad del servidor que recibe la información.

Autenticación del cliente SSL: Permite que un servidor confirme la identidad de un usuario Autenticación del cliente SSL: Permite que un servidor confirme la identidad de un usuario. Usando las mismas técnicas usadas para el servidor de autenticación, el software del servidor SSL puede verificar si son válidos el certificado de un cliente y el ID público y que son emitidos por unaCAlistada de las consideradas fiables para el servidor. El servidor puede incluso exigir que el cliente firme alguna información con su clave privada. Esta confirmación puede ser importante si el servidor, por ejemplo, es un banco enviando información financiera confidencial a un cliente y quiere verificar la identidad del receptor.

Conexión cifrada SSL:Requiere que toda la información enviada entre un cliente y un servidor sea cifrada por el software de envío y descifrada por el software de recepción proporcionando sea cifrada por el software de envío y descifrada por el software de recepción, proporcionando por tanto un alto grado de confidencialidad. La confidencialidad es importante para ambas entidades para cualquier transacción privada. Además todos los datos enviados sobre una conexión cifradaSSLson protegidos para garantizar la integridad y el origen de la información.

(19)

Modelos de Seguridad  en Web

El protocolo SSL incluye dos subprotocolos básicos: el SSL Record Protocol y el SSL

H d h k P t l El i d fi l f t d t iti d t El

Handshake Protocol. El primero define el formato usado para transmitir datos. El segundo, el SSL Handshake Protocol, utiliza el primero para intercambiar una serie de mensajes entre un servidor SSL y un clienteSSL cuando ellos establecen una conexión SSL. Este intercambio de mensajes está diseñado para facilitar las siguientes acciones. Autenticación del servidor al cliente; Permitir que el cliente y el servidor seleccionen los algoritmos criptográficos, ocifradoresque ambos soporten; opcionalmente autentificar el cliente al servidor; establecer una conexión cifrada SSL.

(20)

Modelos de Seguridad  en Web

Dos importantes conceptos son lasesión SSLy laconexión SSL, los cuales son definidos como sigue:

como sigue:

Conexión: Una conexión es un transporte (conexión TCP segura) que proporciona un adecuado tipo de servicio. Para SSLtales conexiones son par a par Las conexiones son pasajeras. Cada conexión está asociada a una sesión.

Sesión: Una sesiónSSLes una asociación entre un cliente y un servidor. Las sesiones son creadas por elHandshake Protocol.Las sesiones definen un conjunto de parámetros de seguridad criptográficos, los cuales pueden ser compartidos entre múltiples conexiones. Las sesiones son usadas para evitar la costosa negociación de nuevos parámetros de Las sesiones son usadas para evitar la costosa negociación de nuevos parámetros de seguridad en cada conexión.

Entre cualquier par de entidades (aplicaciones tales como HTTP en cliente y servidor), hay múltiples conexiones seguras. En teoría, también puede haber múltiples sesiones simultáneas entre las entidades. No obstante las sesión podrían reutilizarse evitando negociar nuevamente los parámetros necesarios deSSL.

(21)

Modelos de Seguridad  en Web

El protocolo SSL Record Protocol proporciona dos tipos de servicios a las conexiones SSL

SSL:

Confidencialidad: ElHandshake Protocoldefine una clave de sesión compartida que es usada para el cifrado simétrico de los datos de nivel superior.

Integridad y Autenticación: El Handshake Protocol también define una clave compartida que es usada para generar unCódigo de Autenticaciónañadido a los datos que se envían.

(22)

Modelos de Seguridad  en Web

La figura indica el modo de operación del protocolo SSL Record Protocol: El Record

P t l t l d t d l li ió t itid l f t bl

Protocol toma los datos de la aplicación a ser transmitidos, los fragmenta en bloques manejables, opcionalmente comprime los datos, aplica unCAM (Código de Autenticación de Mensajes), los encripta, añade una cabecera, y transmite la unidad resultante a un segmentoTCP. Notar que elCAMes computado antes de que la encriptación tenga lugar y que el CAM es luego encriptado junto con el texto en claro o comprimido. Los siguientes algoritmos de encriptación son permitidos: IDEA, DES, Triple DES, FORTEZA, RC4-40, RC4 128. Los datos recibidos son descifrados, verificados, descomprimidos, y reemsamblados, para finalmente ser entregados a los niveles superiores.

(23)

Modelos de Seguridad  en Web

El paso final delSSL Record Protocoles añadir una cabecera con los siguientes campos:

Ti d t id (8 bit ) I di l t l d i l i d l

Tipo de contenido (8 bits): Indica el protocolo de nivel superior usado para procesar el fragmento incluido;

Mayor Versión (8 bits): Indica el número principal de la versión deSSLen uso. ParaSSLv3 el indicativo es el 3; Minor Versión (8bits): Indica en numero secundario de la versión de SSLen uso. Para SSLv3 el indicativo es el 0; (TLS1.0 es 3.1, TLS 1.1 es 3.2, TLS 1.2 es 3.3).

Longitud (16bits): la longitud en bytes del fragmento en claro (o comprimido si se usa compresión). El máximo valor es 2exp14=16K.

compresión). El máximo valor es 2exp14 16K.

Los tipos de contenidos que han sido definidos son o bien los mensajes del Protocolo de Seguridad (“Handshake Protocol”), o del Protocolo de Alertas (“Alert Protocol”), o del Protocolo de Actualización de Cifradores (“Change Chiper Spec Protocol”), o bien, datos de aplicación. Los tres primeros son protocolos específicos SSL. Notar que no hay distinción entre las varias aplicaciones (ej. HTTP) que pueden usarSSL. El contenido de los datos creados por tales aplicaciones es opaco aSSL.

(24)

Modelos de Seguridad  en Web

La parte más compleja de SSL es el Handshake Protocol, que en adelante le denominaremos protocolo de seguridad Este protocolo permite que el servidor y el denominaremos protocolo de seguridad. Este protocolo permite que el servidor y el cliente se autentifiquen y negocien un algoritmo de autenticación y de cifrado simétrico y las claves criptográficas que van a ser usadas para proteger los datos enviados en por elSSL Record Protocol. ElHandshake Protocoles usado antes de que cualquier dato de aplicación sea enviado.

ElHandshake Protocolconsta de una serie de mensajes intercambiados por un cliente y un servidor. Cada mensaje tiene tres campos:

Tipo (1byte): Indica uno de los 10 mensajes Tipo (1byte): Indica uno de los 10 mensajes

Longitud (3bytes): La longitud del mensaje en bytes

(25)

Modelos de Seguridad  en Web

El protocolo de seguridad consta de 4 fases:

Fase 1: Negociación de los parámetros de seguridad (algoritmos de cifrado y

autenticación, longitud de claves etc)

Fase 2: El servidor envía una acreditación (certificado del sitio Web) y,

opcionalmente, puede exigir una acreditación al cliente.

Fase 3: El cliente genera las claves de sesión y autenticación necesarias para la

comunicación y se las enviará al servidor cifradas con su clave pública. Si el

id

l

i ió

t ti

i á

tifi d

fi

á

d

servidor le exigió autenticarse enviará un certificado y firmará un resumen de

los mensajes anteriores.

Fase 4: Se intercambian mensajes con los algoritmos y claves generadas y

distribuidas entre las entidades.

(26)

Modelos de Seguridad  en Web

En la figura se muestran el nombre de los mensajes intercambiados en cada fase: Fase 1: “Cliente_Hola” y “Servidor_Hola”

Fase 2: Mensajes obligatorios“Certificado Servidor” y “Servidor_Hola_Fin”.Mensajes opcionales: “Intercambio Clave Servidor”y “Petición de Certificado”

Fase 3: Mensajes obligatorios“Intercambio_Clave_Cliente”. Mensajes opcionales, pero obligados si el servidor solicitó autenticación de cliente : “Certificado Cliente” y “Verificación de Certificado”

Fase 4: Mensajes obligatoriosj g “Mensaje Actualizacion Cifradores” y “Mensajej _ _ f y j de Fin”.

(27)

Modelos de Seguridad  en Web

La Fase 1 es usada para iniciar la conexión lógica y negociar los parámetros de seguridad entre el cliente y el servidor El intercambio es iniciado por el cliente que envía un mensaje cliente y el servidor. El intercambio es iniciado por el cliente, que envía un mensaje “Cliente_Hello”con los siguientes parámetros:

Versión: La versión más alta que utiliza el cliente.

Número aleatorio: Una estructura aleatoria generada por el cliente que consta de un sello de tiempo de 32 bits y 28 bytes generados por un generador de números aleatorio. Estos valores sirven como identificadores de uso único y son usados durante el intercambio de claves para evitar ataques por retransmisión de mensajes.

Identificador de sesión: Este campo es utilizado para identificar una sesión. Un cliente puede recuperar una sesión anterior. Recuperar una sesión anterior puede ser útil debido a que crear una nueva sesión requiere operaciones criptográficas que introducen un retardo en la conexión. La información de sesiones anteriores identificada porun identificador de Sesión es almacenada en la cache del cliente y el servidor. Si el valor de este campo es cero indica que el cliente desea establecer una nueva sesión en esta conexión.

Familia de Cifradores (CipherSuite):Es una lista que contiene las combinaciones de algoritmos criptográficos soportados por el cliente, en decremento el orden de preferencia. Cada elemento de la lista (cada familia de cifradores) define un algoritmo de intercambio de clave y autenticación. Métodos de compresión:Esta es una lista de métodos de compresión que el cliente soporta. Después de enviar el mensaje “Client_Hello”, el cliente espera el mensaje “Server_Hello” el cual contiene los mismos parámetros que el mensaje “Client_Hello”. Para el mensaje “Server_Hello” se aplican las siguientes convenciones. El campoversióncontiene la más baja versión de las sugeridas por el cliente y la más alta soportada por el servidor. El camponúmero aleatorioes generado por el servidor y es independiente del camponúmero aleatoriodel cliente. Con el número aleatorio generado por el cliente y el número aleatorio generado por el servidor se genera luego las claves de sesión y autenticación. Si el campoIdentificador de sesióndel cliente

g g y p f

fuera distinto de cero (recuperación de una sesión anterior), este mismo valor es usado por el servidor. En el caso que el identificador de sesión fuera cero el del servidor es un valor que ahora se asociará a la actual sesión. El campoFamilia de Cifradorescontiene la familia más simple de cifradores seleccionados por el servidor de aquellos propuestos por el cliente.

(28)

Modelos de Seguridad  en Web

En la figura se describen los distintos algoritmos de cifrado simétrico y autenticación, así como los procedimientos de distribución de claves utilizados

(29)

Modelos de Seguridad  en Web

El servidor empieza esta fase enviando su certificado: mensaje “Certificate”. De forma

i l l id d d l j “S K I t h

opcional el servidor puede mandar el mensaje“Server_Key_Interchange”

En este mensaje opcional el servidor envía una clave temporal al cliente. Esta clave puede ser usada por el cliente para cifrar en un intercambio posterior la clave de sesión. Este mensaje soóo es creado cuando el certificado del servidor no contiene una clave adecuada para el cifrado de laclave de sesióno cuando la familia decifradoresobliga al uso de una clave efímera para la operación de intercambio de claves.

(30)

Modelos de Seguridad  en Web

A continuación un servidor puede solicitar un certificado del cliente. El mensaje “Certificate RequestCertificate_Request” incluye dos parámetros: tipo de certificado y autoridadesincluye dos parámetros: tipo de certificado y autoridades aceptables de certificación.

El mensaje final de la fase 2 es el mensaje “Server_Done_Message”. Este mensaje, el cual es obligatorio, es enviado por el servidor para indicar el fin de los mensajes asociados del servidor. Después de enviar este mensaje, el servidor esperará una respuesta del cliente. Este mensaje no tiene parámetros.

(31)

Modelos de Seguridad  en Web

Después de que el cliente recibe el mensaje “Server_Done_Message”, debería verificar que el servidor proporciona un certificado válido y compruobar que los parámetros del que el servidor proporciona un certificado válido y compruobar que los parámetros del mensaje ”Server_Hello” son aceptables. Si todo es satisfactorio, el cliente envía uno o más mensajes de vuelta al servidor.

Si el servidor había solicitado un certificado, el cliente empieza esta fase enviando el mensaje “Certificate”, conteniendo un certificado de acuerdo a los requisitos del servidor.

A continuación, el cliente construye el mensaje más importante del protocolo. Es el mensaje“Client Key Exchange”:

mensaje Client_Key_Exchange :

El cliente genera un bloque de 48 bytes denominado “pre-master secret” que contiene las claves de sesión y autenticación. Este bloque se genera a partir de funciones hash aplicadas a los números aleatorios y mensajes intercambiados hasta ahora. El bloque “pre-master secret” se cifra con la clave pública del certificado del servidor y se incorpora en el mensaje “Client_Key_Exchange”.

(32)

Modelos de Seguridad  en Web

Finalmente, en esta fase, el cliente puede enviar un mensaje “Certificate_Verify”. Este

j á bli t i i l id l f t i i ió tifi d l li t

mensaje será obligatorio si el servidor en la fase anterior exigió un certificado al cliente. Este mensaje contiene un hash de todos los mensajes anteriores del protocolo de seguridad enviados y recibidos cifrado (firmado) con la clave privada del cliente.

El servidor podrá con la clave pública del cliente verificar el resumen, y por consiguiente, autenticar la identidad del cliente.

(33)

Modelos de Seguridad  en Web

En esta fase se completa el protocolo de seguridad. El cliente envía un mensaje “Change Cipher SpecChange_Cipher_Spec” después de haber actualizado la familia de cifradores a utilizar, después de haber actualizado la familia de cifradores a utilizar. Notar que este mensaje no es considerado parte del Handshake Protocol, sino que es enviado usando elChange Cipher Spec Protocol.

El cliente inmediatamente envía el mensaje “Finished” utilizando los nuevos algoritmos negociados, y las claves distribuidas. El mensaje “Finished” verifica que la distribución de claves y el proceso de autenticación tuvo éxito.

El mensaje “Finished” es el primero protegido con los algoritmos y claves recién negociadas No se requiere asentimiento para este mensaje Las partes pueden empezar a negociadas. No se requiere asentimiento para este mensaje. Las partes pueden empezar a enviar información confidencial y autenticada inmediatamente después de enviar el mensaje“Finished” Los receptores del mensaje deben verificar que los contenidos son correctos

En respuesta a estos dos mensajes, el servidor envía su propio mensaje “Change_Cipher_Spec”, actualizado su familia de cifradores y enviando mensaje “Finished”. En este punto el protocolo de seguridad esta completado y el cliente y el servidor pueden empezar a intercambiar datos de nivel de aplicación.p p p

(34)

Modelos de Seguridad  en Web

El protocolo de Notificación de Alertas es un protocolo adicional de la capa SSL. Este

t l d t t l l t itid SSL l tid d C d

protocolo es usado para transportar las alertas remitidas por SSL a la entidad pares. Cada mensaje del protocolo consta de dos bytes. El primer byte toma para indicar la severidad del mensaje. Si el nivel es fatal SSL inmediatamente termina la conexión. Otras conexiones en la misma sesión pueden continuar, pero no se pueden establecer nuevas conexiones en esta sesión. El segundo byte contiene un código que índica una alerta específica. Algunas alertas son las siguientes:

Mensaje inesperado: Recepción de un mensaje inapropiado; Bad_record_mac: Fué recibido un MAC incorrecto; Descompresion failure: La función de descompresión recibido un MAC incorrecto; Descompresion_failure: La función de descompresión recibida tiene una entrada inadecuada (por ejemplo no poder descomprimir o descomprimir a un valor mayor que la longitud permitida);Handshake_failure: El emisor no puede negociar un conjunto aceptable de parámetros de seguridad dados por las opciones disponibles; Ilegal_parameter: Un campo en un mensaje de handshake queda fuera del rango o es inconsistente con otros campos;

Otras alertas son las siguientes:

Close notify: Notifica al receptor que el emisor no enviará más mensajes en esta Close_notify: Notifica al receptor que el emisor no enviará más mensajes en esta conexión. A cada entidad se la requiere a que envíe una alertaclose_notifyantes de cerrar el lado de escritura de la conexión;No_certificate: Puede ser enviado en respuesta a una petición de certificado si no hay certificado apropiado disponible; Bad_certificate: Un certificado recibido fue corrupto (por ejemplo conteniendo una firma no verificada); Unsupported certificate: El tipo de certificado recibido no está soportado; Certificado revocado: Un certificado ha sido revocado; Certificate_expired: Un certificado que ha expirado;Certificate_unknown:Algunos otros problemas en procesar el mensaje lo hacen

i t bl

(35)

Modelos de Seguridad  en Web

El Protocolo de Actualización de Cifradores (“

Change Chiper Spec Protocol

”) es

d l

l

ífi

l

SSL R

d P

l

l á

uno de los tres protocolos específicos

que usan el

SSL Record Protocol

y es el más

simple. Este protocolo consta de un solo mensaje que consta

de

un solo byte con

el valor “1”. El único propósito de este mensaje es causar que se actualicen la

familia de cifradores usados en esta conexión.

(36)

Modelos de Seguridad  en Web

El protocoloSSLno es exclusivo de losNavegadores Web, sin embargo, es ampliamente

tili d t t t D h h l i d t t l tá l i l t ió

utilizado en este contexto. De hecho el origen de este protocolo está en la implementación del código del navegador Netscape. Hoy en día sin embargo el código fuente del protocolo SSL esta en infinidad de aplicaciones distribuidas diferentes de una aplicación Web.

Un cliente desde unnavegador Webaccede a este protocolo cuando este cliente accede al puerto 443 del servidor Web. A este puerto se accede cuando la petición URL comienza con “https” en vez de “http”. Es en este momento cuando empieza la implementación del protocolo SSL. Si la ejecución del protocolo ha tenido éxito se habrá distribuido las protocolo SSL. Si la ejecución del protocolo ha tenido éxito se habrá distribuido las claves de sesión y las claves de autenticación de modo que la información que viaja entre el cliente y el servidor va a ir protegida (cifrada) y autenticada.

(37)

Modelos de Seguridad  en Web

Por motivos históricos se reproduce en la figura la interfaz del navegador Netscape, que

i b l i i d l t l SSL

(38)

Modelos de Seguridad  en Web

En la figura se reproducen las familias de cifradores soportadas inicialmente por el

t l SSLi t d l N d N t

(39)

Modelos de Seguridad  en Web

En la figura se reproduce el contenedor de certificados fiables soportados. Es decir,

ll t id d d tifi ió id fi bl C l i tifi d

aquellas autoridades de certificación que se que consideran fiables. Cualquier certificado recibido firmado por esta CA se considerará fiable siempre y cuando no esté caducado y no haya sido revocado.

(40)

Modelos de Seguridad  en Web

En la figura se especifica el uso para el cual se va a utilizar esta CA. En el ejemplo

tifi iti b

(41)

Modelos de Seguridad  en Web

A continuación vamos a presentar la captura del protocolo SSLcon el monitor de red “whireshark”. En la figura se muestra el mensaje inicial “Client Hello” del protocoloSSLy los campos incorporados como son la versión, número aleatorio, número de sesión o la familia decifradoressoportados.

(42)

Modelos de Seguridad  en Web

En la figura se muestra los mensajes que envía el servidor al cliente en contestación al mensaje “Client Hello”. En primer lugar se muestra la captura del mensaje”Server Hello”del protocoloSSL.En este mensaje el servidor selecciona una familia de cifradores de entre las habilitadas y las solicitadas por el cliente. Después de este selecciona una familia de cifradores de entre las habilitadas y las solicitadas por el cliente. Después de este mensaje finalizaría laFase 1del protocolo.

También se muestra la captura del mensaje “Certificate” emitido por el servidor conteniendo el certificado de servidor. Finalmente, se muestra la captura del mensaje “Server Hello Done”. Despues de estos dos mensajes finalizaría laFase 2del protocolo.

(43)

Modelos de Seguridad  en Web

En la figura se muestra el detalle del mensaje “Certificate” enviado por el servidor. Este certificado como sabemos debe de contener un certificado del servidor que proteja el sitio web del servidor y que esté firmado por unaAutoridad de Certificaciónque sea considerada fiable por el cliente.

(44)

Modelos de Seguridad  en Web

En la figura se muestra el detalle del mensaje “Server Hello Done” enviado por el servidor. Con este mensaje finalizarían los mensajes enviados por el servidor de laFase 2del protocolo.

(45)

Modelos de Seguridad  en Web

En la figura se muestra la captura del mensaje de laFase 3 del protocolo emitido por el cliente “Client Key Exchange”y de los mensajes “Change Cipher Spec” y “Encripted Handshake Message” (llamado mensaje ”finished”) de la Fase 4.

Recordemos que el mensaje “Client Key Exchange”contiene las claves de sesión y autenticación cifradas por la clave publica del servidor. El mensaje “Change Cipher Spec” se utiliza para indicar a la otra entidad que ya se han actualizado loscifradoresa utilizar en la sesión. Finalmente, el mesajeEncripted Handshake Message” es enviado por cada una de las entidades para comprobar que los algoritmos de cifrado y autenticación funcionan correctamente.

En este ejemplo suponemos que el servidor no exige al cliente su autenticación, es decir, es una implementación del protocolo SSL sin autenticación de Cliente. En caso contrario serían necesarios más mensajes en la Fase 2 y 3 del protocolo SSL.

(46)

Modelos de Seguridad  en Web

En la figura se muestra el detalle de los mensajes “Change Cipher Spec” y “Encripted Handshake Message” (llamado mensaje ”finished”) de la Fase 4.

(47)

Modelos de Seguridad  en Web

En la figura se muestra la captura de los datos de aplicación de usuario comprobando efectivamente que van cifrados y, por consiguiente, no son accesibles a un intruso.

(48)

Modelos de Seguridad  en Web

En la figura se muestra lo que ocurriría si, por ejemplo, un usuario del servicio de correo electrónico accediera a su buzón para obtener los mensajes y no utiliza un protocolo de seguridad como SSL. El resultados sería que fácilmente podría capturarse sus claves de acceso.

(49)

Modelos de Seguridad  en Web

El protocolo SSL fue originalmente desarrollado por la empresa Netscape, al que se le

d b l i SSL 1 SSL 2 SSL 3 t últi lib d 1996

deben las versiones SSLv1, SSLv2 y SSLv3, esta última liberada en 1996.

TLS (Transport Layer Security)fue especificado en el RFC 2246 como una actualización de SSLv3. Las diferencias entre SSLv3 y TLS1.0 son pequeñas pero son significativamente suficientes para que no pueda establecerse una sesión entre un cliente SSLv3 y un servidor TLSv1 (y viceversa).

Algunas diferencias entre SSLV3 y TLS1.0 son las siguientes:

En SSL v3 en el mensaje “Certificate_verify” se hace un hash de todos los mensajes anteriores incluyendo la pre-master secret. En TLS no se incluye lapre-master secret . El cálculo de la pre-master secretse hace de forma diferente en SSL v3 y en TLS. TLS v1 incluye una numeración en las unidades del Record Protocol e incluyen este número de secuencia en el MAC. El mensaje “Finished” incluye un hash de todos los mensajes anteriores. En el protocolo TLS comprueba si la URL actual coincide con el certificado recibido del servidor lo cual permite garantizar la autenticación del servidor.

Se han desarrollado nuevas versiones de TLS v1.1 (abril 2006) y TLSv1.2 (agosto 2008) . En esta última se incluye ya el protocolo de cifrado simétrico AES

(50)

Modelos de Seguridad  en Web

Un tercera alternativa para incorporar servicios de seguridad a nuestras

li

i

i

l

di h

i i

l

i

li

i

E

aplicaciones es implementar dichos servicios en las mismas aplicaciones. Estas

aplicaciones pueden ser aplicaciones estándar como el correo electrónico o

aplicaciones de comercio electrónico como SET, o bien, pueden ser aplicaciones

propietarias de uso especifico de una Organización.

La ventaja de este modelo es que el servicio puede ser confeccionado a las

necesidades específicas de una aplicación dada.

El implementar los mecanismos de seguridad dentro de las aplicaciones no excluye

El implementar los mecanismos de seguridad dentro de las aplicaciones no excluye

la posibilidad de utilizar conjuntamente la capa de seguridad SSL o bien los

servicios de seguridad de IPsec.

(51)

Modelos de Seguridad  en Web

El correo electrónico es un ejemplo claro en el cual la propia naturaleza de la

j

p

p p

aplicación determina la forma de implementar los servicios de seguridad. Es

común utilizar el modelo de clave pública para proporcionar los servicios de

confidencialidad y no repudio.

Al tratarse de una comunicación unidireccional la forma de proporcionar

confidencialidad utilizando el modelo de clave pública consiste en lo siguiente: Se

cifra un mensaje con una clave de sesión y se envía a la otra entidad el mensaje

cifrado y la clave de sesión cifrada con la clave pública de la otra entidad Para ello

cifrado y la clave de sesión cifrada con la clave pública de la otra entidad. Para ello

es necesario conocer el certificado de clave pública de la entidad a la que

queremos mandar un mensaje cifrado.

Si queremos mandar un mensaje firmado se hace un resumen del mensaje y se

cifra con la clave privada del emisor. Al destinatario del mensaje se le hace llegar

el mensaje, el bloque criptográfico de firma y el certificado del emisor. El receptor

del mensaje comprueba con el certificado recibido del emisor la validez de la

fi

A i i

l

b á

l

ifi d d l

i

á

firma. Asimismo, el receptor comprobará que el certificado del emisor está

firmado por una autoridad de confianza.

Si queremos mandar un mensaje cifrado y firmado se repiten los dos mecanismos

en el mismo mensaje.

(52)

Modelos de Seguridad  en Web

MIME es una extensión de RFC 822 para solucionar los problemas y limitaciones del uso

d SMTP t t l d t f i d t t d d

de SMTP y otros protocolos de transferencia de correo entre otros no poder mandar ficheros ejecutable, ni binarios, limitados a 7bit ASCCI etc…

S/MIME (Secure/Multipurpose Internet Mail Extension) es una mejora de seguridad al formato estándar de correo MIME basado en la tecnología de criptografía simétrica y en los certificados X.509.

Aunque tanto PGP como S/MIME son estándares, parece que S/MIME emerge como estándar para uso comercial, mientras que PGP queda para uso personal.

El correo PGP no utiliza certificados X.509. Las claves públicas utilizadas por PGP no están firmadas por una autoridad de Certificación sino por usuarios del sistema. La confianza de las claves publicas manejadas descansa en la confianza directa entre usuarios.

(53)

Modelos de Seguridad  en Web

Cuando se implementan aplicaciones de seguridad en Java utilizando el protocolo SSL p ede oc rrir q e la propia á i i t l j tenga restricciones de seg ridad q e puede ocurrir que la propia máquina virtual java tenga restricciones de seguridad que limiten las familias decifradoressoportadas.

A modo de ejemplo se listan en la figura el conjunto de familias soportadas por la maquina virtual java 1.06.14 con restricciones de política de seguridad. Es decir, es el conjunto de familias soportadas por defecto al instalar la maquina virtual java que incluye por defecto ciertas restricciones, por ejemplo, la longitud de la clave simétrica que no puede ser superior a 128 bits.

(54)

Modelos de Seguridad  en Web

Las restricciones de la maquina virtual java se puede cambiar modificando los ficheros contenidos en la carpeta de instalación j \j *\lib\ it \”

contenidos en la carpeta de instalación …..java\jre*\lib\security\ .

Al levantar las restricciones de la política de seguridad se incrementa el número de familias de cifradores soportadas en el protocolo SSLy aparecen familias que manejas longitudes de clave de 256 bits como se muestra en la figura.

Figure

Actualización...

Referencias

Actualización...

Related subjects :