Cifrado de comunicaciones

Retomamos nuestra campaña de prescriptores de ciberseguridad REALSEC con Luis Martin Liras, quien, en esta ocasión, nos habla acerca de un tema muy candente en el mundo de la seguridad: el  cifrado de la comunicaciones, dentro de los que nos desgrana interesantes contenidos acerca del cifrado asimétrico, infraestructura de clave pública, cifrado de comunicaciones web y casos prácticos.

Luis Martin es un profesional vinculado al mundo de la tecnología y de la seguridad informática desde hace más de 10 años y que actualmente desempeña su labor profesional para INCIBE (Instituto Nacional de Ciberseguridad)
Asimismo, ha trabajado en el desarrollo de aplicaciones y en lenguajes como C++, Java o PHP, ha administrado profesionalmente sistemas UNIX/Linux, y durante más de 4 años ha formado parte del equipo de INTECO-CERT, realizando contenidos web específicos del sector, cursos de concienciación, etc.
Además, es el autor del blog de ciberseguridad http://lirasenlared.blogspot.com
A continuación les compartimos este interesante artículo:

1-Cifrado de comunicaciones

La información sensible no se encuentra sólo en las unidades de disco de nuestros equipos y dispositivos. En el momento de enviar documentos a nuestros amigos y colaboradores, estamos dejando que información potencialmente sensible circule por un cable donde cualquier podría estar escuchando nuestra conversación y la información sensible enviada (O ni eso, en comunicaciones Wifi, la información viaja por las ondas, accesible a todo el mundo). Por esta razón es muy importante que todas las conversaciones de todo tipo (navegación web, correos electrónicos, mensajería instantánea, etc.) vayan cifrados.
En el caso del cifrado de comunicaciones, el algoritmo de cifrado utilizado suelen ser algoritmos de cifrado asimétrico como RSA o Diffie-Hellman, utilizados por protocolos de comunicación como PGP, GPG, SSL o TLS.

  • Cifrado asimétrico

Los algoritmos de cifrado asimétrico permiten realizar comunicaciones cifradas seguras entre actores que no se conocen entre sí a través de un medio inseguro.
En Internet un actor puede ser un servidor web, un cliente de correo, un navegador web, etc. Para conseguir esta comunicación segura, cada uno de estos actores debe tener una clave pública (que todo el mundo puede conocer) y una clave privada (que sólo el propio actor debe conocer).
Estas claves tienen la característica especial de que un mensaje cifrado con una de esas claves (ya sea la pública o la privada) puede ser descifrado por la otra. Es decir, si ciframos un mensaje con nuestra clave privada sólo podremos descifrarlo con nuestra clave pública. Y viceversa. Por eso se llama cifrado asimétrico.
El cifrado asimétrico permite garantizar la autenticidad de cada uno de los actores, la confidencialidad de la comunicación y el no repudio en el envío de un mensaje (ya sea texto, o una imagen o lo que sea, en adelante se le llamará “mensaje”). La autenticidad garantiza que cada actor es quien dice ser y no otro. La confidencialidad garantiza que si alguien intercepta el mensaje no podrá entender nada y el no repudio garantiza que si alguien envía un mensaje luego no puede negar que lo ha enviado.
Para conseguir estas tres características, el emisor cifrará el mensaje primero con su clave privada y el mensaje resultante a continuación lo cifrará de nuevo con la clave pública del receptor. Es decir, se cifrará dos veces.
Para descifrar el mensaje, el receptor (el legítimo receptor) deberá primero descifrar (es decir pasar el algoritmo de descifrado) usando su clave privada y al mensaje resultante (que aún será ilegible) se pasará de nuevo por el algoritmo de descifrado, esta vez usando la clave pública del emisor (que es conocida por todo el mundo).
Este proceso queda reflejado en este esquema. Andrés quiere mandarle un mensaje secreto a Bea. Primero lo cifrará con su clave privada y luego con la clave pública de Bea. Nótese que a partir del momento en que lo cifra con la clave pública de Bea, sólo Bea podrá descifrar el mensaje. Ni siquiera el propio Andrés podría descifrar su mensaje si se olvida de lo que ha puesto.
Para descifrar el mensaje que le llega a Bea, ésta primero los descifra con su clave privada y el contenido resultante (aún ilegible) los descifrará de nuevo con la clave pública de Andrés.
Por supuesto el algoritmo de cifrado y descifrado debe ser el mismo (ya sea Diffie-Hellman, RSA, etc.).
cifrado comunicaciones
Si alguien fuera capaz de interceptar el mensaje (por ejemplo cuando pasa por un servidor sobre el que no tenemos control en internet) nunca podrá descifrarlo. Lo que verá será una ristra de caracteres sin sentido (¿s4$’@”z…). Como no dispondrá de la clave privada de Bea, le será imposible descifrar lo que pone en ese mensaje. Con esto se consigue la confidencialidad.
Como Bea tiene la clave pública de Andrés, si consigue descifrar por completo el mensaje, puede estar segura de que ese mensaje lo ha escrito Andrés (Autenticidad) y es más, éste no puede rechazar su escritura (No repudio) porque nadie más que él tiene su clave privada por lo que ha tenido que escribirlo Andrés.
Lo cierto es que lo único que asegura este esquema es que el mensaje fue cifrado con la clave privada de Andrés, no que fuera él, libremente, quien lo escribió. Pudo ocurrir:

  • Andrés fue secuestrado y fue obligado a escribir el mensaje.
  • La clave privada de Andrés fue robada y alguien escribió el mensaje por Andrés.
  • Alguien se hizo pasar por Andrés y le mandó el mensaje a Bea.

Ante la primera hipótesis poco puede proteger el cifrado asimétrico. La segunda y tercera hipótesis sólo serían posibles si no se utiliza “una infraestructura de clave pública” (PKI en inglés), que permite, por una parte revocar las claves públicas y privadas y por otra parte certificar que una persona con una clave pública es físicamente quien dice ser.

  • Infraestructura de clave pública

Cuando compramos en una tienda a través de internet realmente no conocemos a quién le estamos comprando. ¿Quién nos dice que al otro lado no hay un delincuente que simplemente se quedará con nuestro dinero a cambio de nada?
Para esto existe una infraestructura de autoridades de certificación, autoridades de registro, certificados, etc. A todo ello se le conoce como infraestructura de clave pública y nos permite certificar que una persona es quien dice ser, incluso si sufre el robo de sus claves. Toda la infraestructura de clave pública se basa en el uso los certificados digitales.
Un certificado es un fichero que aporta información sobre quién es el dueño de ese certificado. Es como el DNI con la excepción de que un certificado se puede aplicar casi a cualquier cosa, por ejemplo a una página web. Así, el certificado de una página web informará de cosas como, quien es el dueño de una página web, el algoritmo de cifrado preferido para sus comunicaciones, la clave pública de la web y el periodo de validez del certificado (entre otras muchas cosas).
Por ejemplo en la siguiente imagen podemos ver una conexión segura (en la que aparece el candado) y al hacer clic sobre el candado nos da información sobre la comunicación web:
conexion segura
Como vemos en la imagen anterior, el certificado (en este caso de la página web de Microsoft), nos indica que Microsoft está en Redmond, Washington, US, que la conexión utiliza el protocolo TLS 1.2, que para el cifrado se usa AES_256_CBC y que para la negociación ha utilizado una variante del algoritmo RSA (ECDHE_RSA).
Es más, en la parte de la derecha, nos permite conocer el tipo de clave pública del servicio web (que es una RSA de 2048 bits) y en la parte inferior nos la muestra (dado que es pública la puede conocer cualquiera). Ya veremos qué es cada una de estas cosas.
La entidad generadora de estos certificados es lo que se llama una Autoridad de Certificación (CA) y en certificados web algunos de los más conocidos son VeriSign o goDaddy. En el caso del ejemplo anterior la autoridad de Certificación el cometido de las autoridades de certificación es “certificar” que la información indicada en el certificado digital es cierta. También es responsable de emitir y revocar los certificados digitales.

¿Y cómo sabe esa «autoridad» de certificación que realmente esa web pertenece a esa persona?.

La CA (ella misma o a través de otra entidad llamada Autoridad de Registro) hace una serie de comprobaciones y si todo es correcto, genera el certificado y lo cifra con su clave privada. De esta manera el que reciba el certificado sabrá que los datos que aparecen en ese certificado los ha validado una CA (El dato de la CA certificadora es público).
Pero volvemos a lo mismo. ¿Y si esa CA no es quien dice ser? Para certificar su autenticidad las CAs también tiene un certificado digital donde dice quiénes son (es lo que se llama un certificado raíz) y para verificar la autenticidad de este certificado, éste va cifrado por una CA, pero no por la propia CA sino por otras CAs reconocidas del mercado. Se genera de esta manera lo que se llama “Web of trust”, es decir existe una red de CAs que se certifican las unas a las otras. Es difícil suplantar una CA, pero suplantar una red entera de CAs es algo prácticamente imposible.

Revocación de certificados

Si ocurriera que nuestra web se ve comprometida y descubre la clave privada del servidor, o si, por descuido alguien accede a nuestro correo y descubre nuestra clave privada, la infraestructura de clave pública ya no sería válida. Cualquiera podría hacerse pasar por nosotros, o por nuestro servidor, ya que es conocedor tanto de nuestra clave pública (que era ya conocida por todos), como de nuestra clave privada.
En esa situación es necesario revocar los certificados. Esto se consigue realizando una solicitud a la Autoridad de Certificación que nos los hubiera firmado en su momento. Tras la solicitud en apenas un rato podemos tener los certificados revocados. Si a partir de ese momento alguien monta una web haciéndose pasar por nosotros, el navegador al comprobar la validez del certificado, podrá ver que se encuentra en la lista de revocación de certificados de la autoridad de certificación y nos mostrará un aviso por pantalla:
revocacion certificados
Un certificado puede estar revocado por diferentes causas. Por ejemplo porque su plazo de validez haya expirado o porque se haya realizado una solicitud de revocación de certificado.

  • Cifrando comunicaciones web

Cuando hacemos una compra a través de Internet estamos enviando cierta información confidencial como los dígitos de la tarjeta de crédito, el usuario, la fecha de caducidad y el código CCV de la tarjeta. Con esta información, cualquier podría realizar una compra a través de internet, suplantando nuestra identidad, por lo que este tipo de datos sólo deben ser conocidos por el usuario y la tienda.
Sin embargo hay un problema. Esa conexión está pasando por los servidores de nuestro proveedor de Internet, por servidores de comunicaciones alojados (generalmente) en USA, probablemente por otros sistemas de salto alojados en Inglaterra u Holanda hasta llegar a los servidores del hosting de la tienda donde esté alojada la página web donde estamos comprando. Es un largo camino y un montón de sistemas de los cuales no sabemos nada ni si han sido comprometidos o cuál es su configuración de seguridad.
mapa comunicaciones
 Camino que sigue una consulta a twitter desde algún lugar de Francia
Por esta razón es necesario proteger la comunicación de manera que viaje cifrada desde nuestro ordenador al servidor web de la tienda. Para conseguir esta comunicación cifrada, el primer requisito es que el servidor web este configurado para admitir conexiones HTTPS y que disponga de una certificado SSL que nos informe de quién es, cuál es su dueño y cuál es su clave pública.
Una conexión segura contra un servidor web que admitan conexiones HTTPS tiene 3 fases:

  • En una primera fase el navegador web y el servidor negocian el algoritmo de cifrado de la comunicación y otros parámetros que permitan realizar la conexión de una forma segura. Este proceso se llama Handshake. El cifrado de la conexión se hace utilizando un algoritmo de cifrado simétrico, con una clave compartida que ambos extremos conocen. Sin embargo, para el intercambio de esta clave conocida por ambos, se utiliza un algoritmo de cifrado asimétrico. Todo esto se negocia en la fase de Handshake.
  • Una vez terminada la negociación, la conexión segura es establecida. En ese momento, el servidor web le envía su certificado, que almacena el nombre de la entidad certificadora (CA) del servidor web, el periodo de validez de ese certificado y la clave pública del servicio web. Ese certificado irá firmado (con la clave privada de la Autoridad de Certificacion-CA), por lo que el navegador deberá descifrarlo usando la clave pública de ésta, que como vimos antes, tiene almacenado en una base de datos. Una vez descifrada podrá leer toda la información albergada en el certificado, continuando con la conexión.
  • Si el navegador detecta que o bien el periodo de validez o la CA son inválidos, nos mostrará un mensaje de error indicándolo, pero nos dejará continuar bajo nuestra responsabilidad:

verificacion conexion

  • A continuación el navegador generará una clave maestra de cifrado y se la enviará al servidor web usando la clave pública de éste, y a partir de este momento la comunicación irá cifrada usando la clave compartida (que solo el servidor y el navegador conocen puesto que el intercambio se ha producido de forma cifrada).

El resto de la conexión va cifrada utilizando el algoritmo de cifrado simétrico (cifrado y descifrado con la misma clave) que ha sido negociado en la primera fase de la conexión. El cifrado asimétrico se usa únicamente para la fase de negociación entre el navegador y el servidor.

  • Casos prácticos

Hasta aquí vale, pero, si yo soy un navegador y al visitar una web recibo un certificado que esté cifrado… ¿cómo lo descifro? Los navegadores vienen por defecto con las claves públicas de las autoridades de certificación más reconocidas. De hecho, lo que almacenan no son las claves, si no los propios certificados de las CAs.
Podemos consultar estos certificados en nuestro navegador preferido. Asi, por ejemplo en Internet Explorer si vamos a a ajustes, opciones de internet –> contenido –> certificados –> Entidades de certificación Raíz de Confianza (O en Google Chrome en Ajustes→Configuración→HTTPS/SSL →Administrar certificados), veremos un listado de unas 200 CAs que acepta nuestro navegador.
Para demostrar que una página web utiliza un certificado firmado por una entidad reconocida, los navegadores suelen mostrar un candado verde en la barra de direcciones del navegador (en la siguiente imagen, un ejemplo con los tres navegadores principales):
urls
Puede ocurrir que el certificado utilizado para firmar no sea reconocido por el navegador (porque no ha sido instalado por defecto). Esto ocurre por ejemplo en la Sede Electrónica de la Administración Española, como podemos ver en la siguiente imagen.
No se trata de que el sitio no sea de confianza (pocas cosas considero que sean más confiables que una administración gubernamental). El problema en estos casos es que el navegador no lleva incorporado el certificado de la entidad que está firmando la página web.
https
En la imagen anterior (es la página de la sede electrónica del MEC), la CA resulta ser “AC Administración Pública” pero como el navegador (en este caso Google Chrome) es de origen americano y se pretende que sea de uso universal, no incluyen por defecto a la administración española como CA. Esta es la razón por la que cada vez que tenemos que realizar trámites con la administración, nos pide que instalemos los certificados que la avalan.
En otros navegadores es más aparente. Por ejemplo en Firefox o Internet Explorer en vez de tachar el candado lo dibujan en gris:
urls-educacion
Existe por último la casuística en que al acceder a un sitio web, el certificado es auto firmado. Esto quiere decir que no lo avala una autoridad de certificación. En esos casos los navegadores nos informan mediante un aviso muy explicativo:
confianza conexion
conexion fallida
Esto no tiene por qué significar error alguno. En estos casos la navegación será segura (los datos irán cifrados), pero simplemente nadie nos puede garantizar que este sitio es legítimo de la tienda que estamos visitando.
Los posibles errores que nos encontramos son muchísimos. Por eso es importante leerse el mensaje de error para entender lo que está pasando. En el siguiente ejemplo el mensaje nos avisa de que el certificado no es para el sitio web que se visita (en concreto se quiere visitar ixxxxc.com y el certificado es para lxxxxs.com). En este caso la explicación es que se ha contratado el desarrollo de la web ixxxxc.com a la empresa lxxxxs.com y ésta, para ahorrar costes ha subido su propio certificado en vez de contratar uno nuevo. La conexión irá cifrada, sí, pero el mensaje (un poco exagerado) nos advierte de que posiblemente la web no pertenezca a ixxxc.com.
conexion no privada

Resumen

Cuando visitamos una página web segura y nos aparece un aviso de error es importante leer el mensaje que nos aparece. Básicamente podemos resumir los errores en tres:

  • El certificado no es de confianza (no ha sido firmado por una CA)
  • El certificado no es para quien dice ser
  • El certificado ha sido revocado

En los tres casos podemos decirle al navegador que continuamos con la navegación. La conexión irá cifrada por lo que nadie podrá ver lo que se transmite, pero podría ocurrir que la web no es de quien dice ser y podríamos estar enviándoles información sensible pensando que se trata de una web legítima.
Cuando al visitar una web segura no nos salta el aviso, el cifrado asimétrico y la infraestructura de clave pública nos están asegurando de que la web es legítima, la persona que está detrás es quien dice ser y comunicación va cifrada y nadie puede escucharla.

Sin comentarios

Envia un comentario

Comment
Nombre
Email
Sitio Web