Trabajo Final de IMS (IP Multimedia Subsystem) - Enunciados
0 recomendaciones86 vistas
El documento describe los conceptos básicos de la criptografía de llaves simétricas y asimétricas, y cómo se usan protocolos como SSH y SSL para encriptar datos en tránsito. Explica que SSH encripta la negociación inicial de llaves y luego usa una llave simétrica compartida, mientras que SSL se usa comúnmente para encriptar el tráfico HTTP. Finalmente, compara una sesión Telnet de texto plano con una sesión SSH equivalente encriptada.
Más contenido relacionado
Similar a Trabajo Final de IMS (IP Multimedia Subsystem) - Enunciados (20)
![Stiveeeeeeeeeeen[1]](https://cdn.slidesharecdn.com/ss_thumbnails/stiveeeeeeeeeeen1-100205082950-phpapp01-thumbnail.jpg?width=560&fit=bounds)
Trabajo Final de IMS (IP Multimedia Subsystem) - Enunciados
- 1. UNIVERSIDAD NACIONAL DE INGENIERÍA FACULTAD DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA DEPARTAMENTOSACADÉMICOS CONCEPTOS TEORICOS DE ENCRIPTACIÓN TRABAJO COMPLEMENTARIO para EX – FINAL 2019-2 El ejercicio muestra una de las clases de información que individuos maliciosos pueden aprender “husmeando” el tráfico en una red local. Muchos protocolos envían passwords y datos privados en texto claro. Una de las mejores formas de proteger su privacidad y la seguridad de sus sistemas es reemplazar aplicaciones que usan protocolos de texto plano como el Telnet y FTP con aplicaciones que encriptan datos en tránsito. La encriptación toma un mensaje de texto plano (sin formato) y lo traduce a texto cifrado ilegible. El texto cifrado puede ser solamente descifrado o traducido de regreso en un mensaje de texto plano original con una llave secreta. Hay dos tipos principales de algoritmos criptográficos usados para encriptar datos: Criptografía de llave simétrica y criptografía de llave asimétrica. En criptografía de llave simétrica, ambas partes que se están comunicando deben compartir una llave secreta simple. Si ellos establecen esta llave compartida en privado, entonces ellos pueden usar este secreto compartido para transmitir en forma segura sobre la red. La parte que envía encripta los datos usando la llave acordada, y el receptor descifra los datos invirtiendo el proceso de encriptación. Si una tercera parte maliciosa fuera a aprender la llave compartida, entonces también podría descifrar los datos. Por lo tanto, es difícil acordar el secreto compartido cuando todas las comunicaciones incluyendo intercambio de llaves tome lugar sobre la red. En criptografía de llave asimétrica, las entidades comunicantes no comparten una simple llave secreta. En su lugar, cada parte genera un conjunto de dos llaves; una llave es llamada la llave privada y la otra la llave pública. La llave privada no es compartida con nadie, incluso cuando establecen un canal de datos seguro. La llave pública puede ser compartida con cualquiera, incluso atacantes. Estas llaves tienen la propiedad de que una llave cifra y la otra puede descifrar y viceversa. Para enviar un mensaje privado a A, cualquiera puede cifrar el mensaje usando la llave pública de A, y nadie más que A podrá descifrarlo. La criptografía de llaves asimétricas está basada en la dificultad de factorizar grandes números. En particular, el par de llaves pública y privada son calculadas tomando dos números primos muy grandes y multiplicándolos juntos. Multiplicando dos grandes números primos es una operación rápida, pero determinando los factores de un gran número es un proceso lento de intentar las posibles combinaciones. Aunque la factorización lleva un gran tiempo en una simple computadora, es fácil poner muchas computadoras a trabajar en el mismo problema; cada uno intentando un subconjunto de posibles factores. Con suficientes recursos de computo, es posible descifrar un mensaje incluso sin conocer
- 2. la llave privada. Sin embargo, el tiempo y dinero requerido desalienta a todos menos a los atacantes más dedicados y mejor financiados. Si alguien descubriera una forma para factorizar grandes números rápidamente, entonces la encriptación basada en esta técnica dejaría de ser efectiva. Además de cifrar, la criptografía de llave asimétrica puede también ser usado para firmar digitalmente documentos. Dado que la llave privada de un individuo es secreta, son los únicos que pueden cifrar un documento con su llave privada. Cualquier otra persona puede verificar que “firmó” el documento descifrándolo con la llave pública del firmante. En criptografía asimétrica, es seguro enviar la llave pública de uno sobre la red. Sin embargo, puede ser difícil determinar de manera segura que tiene la llave pública correcta para un individuo. Considere, por ejemplo, que un atacante podría pretender ser A y luego entregar su propia llave pública en lugar de la llave pública de A. Los mensajes cifrados con la llave pública del atacante pueden ser leídos por el atacante incluso si están destinados solamente a A. Los algoritmos de llave asimétrica son típicamente mucho más lentos que los algoritmos simétricos especialmente cuando cifran/descifran grandes cantidades de datos. Como resultado, muchos criptosistemas usan criptografía de llave asimétrica solamente para asegurar transferir una llave secreta compartida. Esta llave de secreto compartida llamada clave de sesión (session key) es luego usada para cifrar el resto de la conexión usando un algoritmo de llave simétrica. Los criptosistemas abordan el problema de forma segura determinando la llave publica adecuada para una entidad a través de la red en diferentes formas. Algunos mantienen un registro de llaves publicas conocidas. La primera vez que interactúas con una nueva persona o servidor, debe aceptar la llave pública que presentan. A partir de ese momento, el sistema le avisará si intentan presentar una clave pública diferente. Sin embargo, esto solo reduce la ventana de ataques para la primera conexión; no resuelve el problema. Otros sistemas requieren que los participantes presenten pruebas que su llave pública sea auténtica. Tal prueba típicamente toma de un certificado firmado digitalmente. Autoridades de certificación de confianza usarán sus llaves privadas para cifrar un documento que enumera la identidad de un individuo y su clave pública. Una vez más, no elimina completamente el problema. Para demostrar que la autoridad de certificación firmó el documento, debemos estar seguros de que tenemos la llave pública correcta para ellos. Además, debemos confiar que la autoridad de certificación hizo un buen trabajo validando cada identidad de persona antes de emitir un certificado. En este ejercicio se desarrollará una variedad de acciones usando protocolos de texto plano y luego desarrollar una acción equivalente usando un flujo de datos encriptados. Específicamente Secure Shell (SSH) y el Secure Socket Layer (SSL). SSH es un protocolo de capa de aplicación que provee inicio de sesión remota segura y transferencia de archivos. Este encripta y comprime datos transmitidos. SSH depende de criptografía asimétrica para intercambio de llaves y luego usa uno de diversos posibles algoritmos de llave simétrica para ocultación de los datos. Ha habido dos principales versiones de SSH, SSH1 y SSH2, los cuales son incompatibles una de otra. SSH1 es ampliamente desplegada, pero tiene algunos conocidos problemas. SSH2 fue primero presentado para evitar infringir la patente de RSA, un importante criptosistema de llaves publicas
- 3. desarrollado en el MIT. La infracción de patente ya no es una preocupación ya que la patente de RSA expiró en el 2000. Además, SSH2 también corrige fallas conocidas en SSH1. SSL trabaja en la capa de transporte en lugar de la capa de aplicación para encriptar datos. SSL puede ser usad en conjunto con protocolos de aplicación de texto plano sin modificar; cualquier cosa escrita en un socket seguro será encriptado. SSL fue inicialmente propuesto por Netscape y ha sido renombrado como Transport Layer Security o TLS. Después de la versión SSL 3.0 (1996) se publicó el TLS 1.0 (1999). En la versión de SSL 3.0 se detectó la Vulnerabilidad de Poodle. SSL o TLS se usan a menudo por web browser y servidores web para encriptar tráfico HTTP. Cuando accesa a una URL que empieza con https en lugar de http, es una buena indicación que los datos están siendo encriptados. Las conexiones HTTPS son a menudo usadas para compras en línea o accesar a información privada con un web browser. SSH es un protocolo de capa de aplicación. TLS es una capa entre la capa de aplicación y la capa de transporte. Puede ser utilizado por cualquier aplicación habilitada para SSL. CONFIGURACION. – Las huellas (traces) fueron tomadas en una máquina cliente conectada a la Internet por router cable modem. El cliente hace una serie de conexiones a un servidor remoto usando ambos protocolos de texto plano tal como Telnet y HTTP, y luego hace conexiones equivalentes usando protocolos encriptados tales como SSH y SSL. EXPERIMENTO. - Comparamos una sesión Telnet de texto plano a una conexión SSH encriptada. En ambas instancias, nos conectamos a un servidor remoto y ejecutamos la misma secuencia de comandos, Una huella (trace) de la sesión Telnet fue grabada en telnet.cap y una huella de sesión SSH fue grabada en ssh.cap. SESION TELNET DE TEXTO PLANO. - Primero, abra el archivo telnet.cap y use Follow TCP Stream del menú Analyze y examine el contenido del TCP stream. Telnet envía toda la data intercambiada en texto claro a través de la red.
- 4. Esto incluye todo lo que el usuario tipea o mira en su pantalla incluyendo el username y password, todos los comandos ejecutados e incluso el contenido de archivos y directorios vistos. FIG. Transcripción de sesión de telnet SESION SSH ENCRIPTADA. - Ahora abra el archivo ssh.cap y use Follow TCP Stream del menú Analyze y examine el contenido del TCP stream. Exactamente las mismas acciones fueron tomadas en esta huella (trace) es decir: Tipear en username y password, cd public, ls, cs public_html/networks/book, ls, exit. Sin embargo, con SSH, todas las interacciones son encriptadas. Solamente la data enviada en texto plano son cadenas handshakes en la cual el cliente y el servidor envía información acerca de la versión de SSH que esta siendo ejecutada. En el paquete 8, el cliente responde enviando una sesión de llave. Esta sesión de llave es de 148 bytes y es encriptada con llave pública del servidor. No sería seguro enviar la sesión de llaves en texto plano a través de la red porque los atacantes podrían descifrar la sesión si ellos conocen esta llave. Una vez encriptado con la llave pública del servidor, solamente la llave privada del servidor lo
- 5. descifrará. El cliente conoce la llave de sesión compartida porque generó la llave y el servidor conoce la llave una vez que lo descifra. FIG. Transcripción de sesión SSH
- 6. FIG. Negociación de llaves SSH El paquete 8 completa la negociación de llaves entre el cliente y el servidor. Después de este punto, todos los datos son encriptados en la sesión de llaves compartida que es conocido solamente para el cliente y el servidor. Esto tiene diversas ventajas. Primero, los algoritmos de encriptación de llaves simétrica son más rápidos que los logaritmos de llave asimétrico. Segundo, las sesiones de llaves cambian con cada nueva sesión y esto limita la cantidad de datos encriptados con una llave dada disponible para un atacante. Si la misma llave fue usada para cada conexión, un atacante podría notar patrones en la data encriptada que podría ayudarlo a descifrar transmisiones. Esto es especialmente cierto porque un atacante a menudo puede predecir que dato fue enviado durante ciertas porciones de una conexión. (Ejemplo: el prompt del login enviado por el servidor). Dado suficiente texto cifrado y traducciones de texto plano conocido, un atacante podría descifrar datos más fácilmente. ATAQUES EN CONTRA DE SSH. - Ahora, vamos a examinar en más detalle que el cliente SSH y el servidor SSH intercambian para permitir a ellos descifrar este flujo encriptado (encrypted stream). En los paquetes 4 y 5, el servidor y el cliente intercambian mensajes handshake en texto plano identificando la versión de SSH que ellos están usando. En este ejemplo, ellos están usando SSH1. El servidor esta usando SSH-1.99 y el cliente está usando SSH-1.5.
- 7. En el paquete 7, el servidor envía su llave pública a través de la red. La llave es de 267 bytes de longitud. Recuerde que, en la criptografía de llave asimétrica, la llave pública de una entidad puede divulgarse a cualquier persona, incluso a un atacante. Entonces desde la perspectiva del servidor anunciando su llave pública a través de la red es seguro. El cliente SSH típicamente comparará la llave pública con una copia localmente almacenada y acepta la llave si es la misma. Si no coinciden, el cliente SSH advertirá al usuario porque esto puede indicar que un atacante esta intentando hacerse pasar como el servidor real. Si el cliente SSH no tiene una copia de esta llave del servidor en su base de datos local, entonces no hay forma de verificar si la llave presentada por el servidor es legítima. La mayoría de los clientes SSH abordan este problema preguntando al usuario si ellos desean aceptar la llave pública ofrecida por el servidor. Una vez aceptada, la llave es almacenada en la base de datos local. Esto disminuye la ventana de oportunidad para un posible ataque a una primera conexión de usuario, pero no elimina la posibilidad. Un atacante puede conseguir que un usuario acepte inicialmente su llave pública. Sin embargo, puede ser difícil para el atacante hacerse pasar como el servidor legítimo por mucho tiempo. Por ejemplo, si un usuario inicia sesión en la máquina de un atacante que se hace pasar por el servidor real, esta máquina necesitaría tener una copia de toda la data de usuario para continuar la ilusión. Un atacante podría ganar los passwords de esta forma, pero necesitaría desconectar al usuario inmediatamente para evitar detección. Otro más sutil ataque es llamado ataque de “hombre en el medio” (Man In The Middle”). En este caso, un atacante se coloca entre un usuario legítimo y un servidor. El primero nota la llave pública del servidor, y ellos proveen al usuario con su propia llave pública. Cuando el usuario encripta paquetes con la llave pública del atacante, el atacante puede descifrarlos y ver toda la información. Ellos podrían incluso modificarlo, encriptar con la llave publica real del servidor, y enviarlos al servidor. En esta forma, el atacante no necesita poseer todos los recursos del servidor para hacerse pasar por el servidor. Aunque tales ataques son posibles, aún hacen que el trabajo del atacante sea mucho más difícil. Así como asegurar con llave las puertas de una casa no evita que ladrones rompan una ventana. SSH no evita toda clase de ataques, pero desalienta ataques casuales. Esto a menudo es suficiente para todos, excepto para los recursos más valiosos. COMPARANDO HTTP Y HTTPS. - Seguido, comparemos una sesión HTTP de texto plano con una sesión HTTPS encriptada usando TLS. En ambas instancias, buscamos la misma pagina web. Una huella de la sesión HTTP fue salvado en http.cap y la huella de la sesión encriptada HTTPS fue salvada en https.cap. Primero, abra el archivo http.cap y use Follow TCP Stream del menú Analyze y examine el contenido de TCP stream. Toda la información enviada por el web browser o servidor web se muestra en texto plano. En este caso, estamos simplemente recogiendo una pagina web estática. Sin embargo, en un
- 8. ejemplo de compra en línea, podemos ver información de tarjetas de crédito, usernames, passwords u otra información sensible. Ahora abra el archivo https.cap y use Follown TCP stream del menú analyze y examine el contenido de TCP stream. En este caso, todos los datos intercambiados en forma cifrada. No hay ninguna pista de las URLs solicitadas o datos actuales devuelto. El stream (secuencia) encriptada en https.cap usa el Protocolo de Seguridad de Capa de Transporte (Transport Layer Security Protocol – TLS). TLS es un framework extensible que permite al cliente y al servidor a negociar cual protocolo criptográfico usar para intercambio de llaves y otra información necesaria para apoyar el protocolo elegido. En el más bajo nivel, TLS consiste en una serie de registros. El TLS Record Protocol toma los mensajes de texto plano a ser transferidos, los quiebra en pequeñas piezas si es necesario, los comprime si se desea, calcula y añade un checksum, encripta el registro resultante y finalmente transmite. Por encima de este protocolo de registro de capa inferior, varios otros protocolos TLS son implementados incluyendo un protocolo handshaking, un protocolo para cambiar los cifrados utilizados y un protocolo de datos de aplicación. FIG. Secure Socket Layer Client Hello El cliente inicia la conexión encriptada con un registro client hello en el paquete 4. El cliente y el servidor deben negociar los algoritmos criptográficos específicos a ser usados. En este mensaje client hello, el cliente enumera las opciones que admite en orden de preferencia. La primera opción
- 9. del cliente es SSL_RC4_128_WITH_MD5 – Secure Socket Layer versión 2, el cifrado de flujo RC4 con una llave de 128 bit, y un checksum MD5. En el paquete 6, el servidor responde con registros TLS – un server hello, un certificado, un server key Exchange (intercambio de llave de servidor), y un server hello done. En el registro server hello, el servidor indica que ha escogido usar una de las opciones enumeradas por el cliente: TLS_DHE_RSA_WITH_AES_256_CBC_SHA. Note que esta no fue la primera opción del cliente. El registro certificado en el paquete 6 contiene el certificado X.509 del servidor. Este certificado contiene la llave pública del servidor, información acerca del propietario y localización del servidor (subject), y la autoridad de certificación quien concedió el certificado (issuer - emisor). Wireshark no resalta estas porciones individuales, pero algunos de ellos (ejemplo: issuer y subject name) están en texto ASCII. El certificado también contiene una firma digital. El emisor crea dicha firma encriptando un hash o checksum de la información del certificado con su llave privada. Si la firma puede ser descifrada con la llave pública de emisor, entonces solamente alguien con acceso a la llave privada del emisor podría haber “firmado” el documento. En el paquete 7, el cliente responde con 3 registros TLS: un client key Exchange, un change cipher spec, y un encrypted handshake message. En client key Exchange, el cliente especifica una llave conocida como la “premaster secret”. El significado preciso de este secreto depende del algoritmo de encriptación que esta siendo usado. Por ejemplo, para RSA, este puede ser un secreto encriptado con la llave pública del servidor. Tal como en el ejemplo de SSH, este permite al cliente y al servidor usar una llave de sesión compartida para encriptar datos en lugar de algoritmos de llave asimétrica más caros. El registro change cipher spec (registro de especificación de cambio de cifrado) se establece para señalar una transición en el algoritmo de cifrado que se utiliza. El registro change cipher spec propone un nuevo algoritmo de encriptación, pero está encriptado (así mismo) con el algoritmo actual. Después el cliente escribe este registro, y todos los registros subsecuentes serán encriptados en el nuevo algoritmo. Este incluye el cuarto registro en el paquete 7, el encrypted handshake message. En el paquete 9, el servidor también responde con un change cipher spec message (mensaje de cambio de especificaciones de cifrado) propio, seguido por un encrypted handshake message. Esto completa la negociación de los atributos de este canal encriptado. Todo los datos que siguen son encriptados de acuerdo con los parámetros acordados.