Universidad Nacional de Ingeniería Facultad de Ingeniería Eléctrica y Electrónica Curso Electivo

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.