I4S Tendencias en certificación digital

Actualmente, debido a la cantidad de aplicaciones y servicios proporcionados a través de Internet. Una de las mayores preocupaciones en torno a la #ciberseguridad es la capacidad de verificar la identidad de un individuo en Internet.   Es decir, probar que de alguna manera cierta persona es quien dice ser. La identificación es el primer problema a resolver cuando se trata de dar acceso a ciertos datos o permitir realizar operaciones como puede ser, por ejemplo, la compra online o el acceso al correo electrónico.

Para solventar la dificultad actual de verificar la identidad de los usuarios se usan certificados digitales y cadenas de confianza. Pero no es un problema ni mucho menos completamente resuelto. Por eso, los últimos años han surgido diversas tecnologías muy interesantes de tener en nuestro punto de mira, algunas de las cuales se recogen en este artículo.

candadoInternet Security Research Group: Let’s Encrypt

Es una Autoridad de Certificación, en adelante CA, que permite la expedición de certificados web gratuitos siempre que el host de la aplicación lo soporte. Para poder emitir el certificado es necesario demostrar el control sobre dominio donde se aloja la aplicación y para ello es necesario instalar en el host web un cliente software que emplee el protocolo ACME para la comunicación con Let’s Encrypt. Su objetivo es automatizar el proceso para configurar un servidor seguro.

¿Cómo funciona?

El funcionamiento de Let’s Encrypt es relativamente simple. Para certificar un dominio mediante este método sólo es necesario instalar en nuestro servidor un software agente. Este es distribuido en la web oficial de Let’s Encrypt. Después de la instalación de este software hay dos fases. En la primera debemos demostrar que somos los dueños del dominio para el cual queremos un certificado. Una vez hecho esto entramos en la segunda fase, en la que ya podemos gestionar el ciclo de vida de nuestros certificados.

1.   Validación del control del dominio

El software agente instalado en el host crea un par de claves público/privada. Tras esto, envía a Let’s Encrypt la clave pública y el dominio para el que se está solicitando el certificado. La CA de Let’s Encrypt responde a nuestro servidor con uno o más retos mediante los cuales se puede probar el control del dominio.

Un ejemplo típico es el de crear un fichero concreto en una de las rutas de nuestro dominio y firmarlo con la clave privada.

Una vez realizados los retos, la CA comprueba que estos sean correctos. En nuestro ejemplo, la CA buscará el fichero en la ruta de nuestro dominio, validará la firma con la clave pública y comprobará que concuerde con lo solicitado.

Si el reto se supera con éxito el servidor es autorizado para poder gestionar certificados para el dominio especificado.

2.   Solicitud, revocación y renovación de certificados

El software agente firma las peticiones de solicitud, renovación o revocación con la clave autorizada y el servidor contesta bien con el nuevo certificado o con la respuesta correspondiente a la revocación.

Let’s Encrypt proporciona una solución para simplificar el proceso de emisión de certificados de confianza siendo además gratuito para los usuarios. Sin embargo, existen soluciones más complejas, como es el caso de Lemur, que permiten simplificar el ciclo completo de gestión de un certificado, el cual no incluye únicamente su emisión sino también la distribución de las claves a los servidores finales y su correcta configuración.

netflixNetflix: Lemur

¿Por qué surge?

El sistema actual de gestión de certificados, Public Key Infrastructure (PKI) permite establecer una comunicación segura entre dos entidades mediante la creación de cadenas de confianza.

Las PKI están compuestas por diferentes elementos (CAs, certificados, claves privadas, etc) con los que los desarrolladores deben interaccionar si quieren establecer una comunicación segura para sus aplicaciones.

 

El proceso actual que debe de seguir un desarrollador para obtener una comunicación segura mediante HTTPS para una aplicación web es el siguiente:

  1. Es necesario crear un CSR (Certificate Signing Request), una petición para la firma del certificado que contiene datos de la compañía y localización entre otros parámetros.
  2. Envío del CSR a la CA para que sea validado y firmado.
  3. En algunos casos es necesario verificar el certificado emitido por la CA y aprobarlo.
  4. El último paso es el despliegue del certificado en el servidor así como el correcto almacenamiento de la clave privada en algún almacén de secretos previamente configurado.

Para desarrolladores sin experiencia en este flujo de trabajo, el proceso puede resultar complejo. Hay que tener en cuenta que los certificados tienen fecha de caducidad y es necesario gestionar su ciclo de vida para que no afecte a la disponibilidad de los sistemas. Además, durante el proceso es necesario mantener una correcta gestión de las claves privadas para mantener en todo momento la seguridad de la aplicación.

¿Qué es y cómo funciona?

Lemur es un framework que permite facilitar las tareas de los desarrolladores en la gestión y creación de certificados. Se sitúa como elemento intermedio entre desarrolladores y CAs simplificando y centralizando el proceso para obtener, gestionar, monitorizar y desplegar certificados.

En la nueva infraestructura, el desarrollador solicita mediante interfaz web el certificado a Lemur, quien se encarga internamente de generar el CSR y comunicarse con la CA correspondiente para su validación y firma.

Lemur además cuenta con diversos plugins que permiten el despliegue del certificado en distintos entornos y servidores de forma transparente al desarrollador. Esta gestión automática evita que la información sensible se distribuya de forma indeseada.

figura1-2

 

figura1-1

Figura 1: Comparación entre PKI convencional y Lemur [Fuente: Medium]

Google: Certificate Transparency

¿Por qué surge?

Con el sistema de certificación actual, los navegadores pueden detectar la autenticidad de una página web mediante el uso de certificados. Esto se consigue haciendo uso de un intermediario en quien confiamos y que valida la autenticidad de un certificado de forma comprobable mediante técnicas criptográficas.

Sin embargo, el sistema actual tiene un problema en cuanto a la confianza depositada en ese intermediario. Como cualquier sistema, en el ámbito de la seguridad sabemos que el tiempo pasa y con ello surgen nuevas formas de vulnerar sistemas aparentemente seguros. Estos intermediarios, llamados autoridades certificadoras (CA), son empresas cuyos sistemas de seguridad, por desgracia, no escapan de esta máxima. Sin olvidar, que una empresa está sujeta a la legalidad del país en el que reside, que puede obligarla a actuar acorde a dicha legalidad. Por otro lado también es posible que un empleado cometa un error y cree un certificado con datos que no son correctos. O como en el siguiente ejemplo, en el que un delincuente consigue entrar en el sistema.

Esto es equivalente a si un criminal consigue entrar en una comisaría de policía y con las impresoras especiales que allí disponen imprime un DNI a tu nombre.

A primera vista no se ve cómo este hecho puede afectar a nuestras vidas. Sin embargo, resulta crítico para nosotros el que esto pueda suceder. ¿Pero por qué?

Imaginemos que un ciberdelincuente consigue entrar en los sistemas de la empresa que valida la identidad de las páginas web de la organización X. En ese momento, el cibercriminal podrá crear certificados que suplanten la identidad de la organización X. Y si hasta ese momento lo ha hecho bien, nadie sabrá que esos certificados han sido hechos sin permiso de la organización X.

Para cualquier navegador el certificado será veraz y probará que la página web pertenece en efecto a la organización X. Sin embargo quien está detrás no será (…) un ciberdelincuente preparado para obtener nuestros datos. 

Por poner un ejemplo del día a día, esto es equivalente a si un criminal consigue entrar en una comisaría de policía y con las impresoras especiales que allí disponen imprime un DNI a tu nombre pero con la imagen de su cara. Si nadie ve al delincuente mientras comete la falsificación, ese DNI no se puede saber que es falso ya que se ha hecho mediante métodos reglamentarios. Entonces, ese criminal podrá hacerse pasar por otra persona. Por supuesto, en la vida real no es tan fácil hacer esto con un DNI, ya que el criminal necesitaría las credenciales de acceso de un funcionario público para poder usar dichas máquinas. Sin embargo, ejemplifica bien lo que puede hacerse con un certificado falsificado.

Volviendo al ámbito digital, una vez que el ciberdelincuente falsifica ese certificado, lo único que tiene que hacer a continuación es poner “la imagen de su cara” en vez de la imagen original. Para ello, por ejemplo, puede crear una página web idéntica a la de la organización X. El certificado que ha creado el ciberdelincuente se ha creado por los métodos oficiales y para cualquier navegador el certificado será veraz y probará que la página web pertenece en efecto a la organización X. Sin embargo quien está detrás no será una organización en la que podemos confiar, sino un ciberdelincuente preparado para obtener nuestros datos.

En este ejemplo, hay un problema muy grave. Nosotros confiamos en que el intermediario que valida nuestra identidad es seguro y no dejará que esto pase. Pero, como se ha dicho, si el criminal ha hecho bien su trabajo, nadie sabrá que esto ha pasado. ¿Entonces cómo sabremos que esto ha pasado?

La respuesta, es concisa, no se puede saber. En algún momento alguien resultará estafado, hará una denuncia y tras investigar el suceso, se descubrirá ese certificado falso y se invalidará.

Sin embargo, hasta ese punto el mal ya ha sucedido. Es por eso que con Certificate Transparency, se pretende eliminar de raíz la posibilidad de que esto pase.

¿Cómo funciona?

Certificate Transparency es un elemento que se añade como un nivel extra de seguridad a la cadena de confianza ya existente, en la cual están envueltas las CA, las VA, los certificados y los servidores web.

Certificate Transparency se compone de tres piezas que trataremos a continuación. La interacción entre estas piezas es la que aporta un nuevo nivel de seguridad a la cadena de confianza. En resumen, lo que se consigue con esta interacción es obligar a que todos los certificados aparezcan públicamente en al menos tres servidores de log. Si no aparecen en estos servidores serán considerados como no válidos. Esto se cumple tanto para certificados lícitos como para certificados que no lo son. Gracias a esto, cualquier dueño de dominio que haga uso de un monitor podrá enterarse rápidamente de certificados robados y firmados a su nombre, impidiendo de esta forma el phising con su identidad. Y a su vez, cuando un usuario que haga uso de un auditor en su navegador intente entrar a este tipo de webs maliciosas, será informado por su navegador de que el sitio web no es seguro.

Actualmente, muchas empresas están lanzando sus propios monitores y servicios de monitorización.


Servidor de logs:
Es el encargado de almacenar los certificados. Para almacenar los certificados se utiliza una estructura predefinida: Un árbol binario de Merkle que puede verse como una estructura de hashes encadenados, de forma que si la información de un nodo (certificado en este caso) es modificada, es necesario rehacer el árbol entero para obtener un hash raíz consistente.

figura2Figura 2: Esquema de un árbol de Merkle.

 

Para poder almacenar el certificado en el log es necesario realizar primero el hash del mismo y es este hash es el que se añade al árbol existente.

Esta estructura de hashes encadenados permite fácilmente comprobar cuándo la información de un certificado ha sido modificada ya que el hash raíz del árbol de Merkle tras la alteración no se corresponde con el hash raíz del árbol original provocando una inconsistencia y detectando por tanto que la información ha sido alterada.

Auditor: Se encarga de comprobar que los certificados están en un servidor de log válido así como que el árbol es consistente o lo que es lo mismo, que no haya habido ninguna alteración en ningún nodo. Un auditor puede ser el propio navegador web.

Actualmente, sólo Chrome está preparado para implementar esta tecnología pese a que se prevé que otros navegadores como Firefox comiencen a incorporarla en futuras actualizaciones.

Monitor: Permite centralizar la información de los servidores de log de forma gráfica e intuitiva de modo que cualquier usuario pueda comprobar qué certificados tiene un servidor y pueda operar con ellos (búsquedas, descargas…).

Es necesario que un certificado se encuentre en al menos tres logs para darlo por válido, si no, el certificado es descartado y por tanto el navegador mostrará al usuario final un aviso de seguridad.

Actualmente, muchas empresas están lanzando sus propios monitores y servicios de monitorización. Uno de los ejemplos más relevantes es la red social Facebook.

Facebook: Monitor de Logs

La aparición de la tecnología Certificate Transparency descrita en el punto anterior ha hecho que muchas compañías importantes quieran beneficiarse de sus capacidades. Este es el caso concreto de Facebook. Que ha desarrollado un monitor que se encarga de consultar a los diversos servidores de logs por sus certificados y además los muestra de forma intuitiva y accesible en un portal web.

En esta web, Facebook, ha añadido la capacidad de realizar búsquedas por dominio y descargar los certificados. Gracias a estas funcionalidades tan sencillas, su monitor se convierte en una herramienta muy útil que permite centralizar la información y visualizarla de forma sencilla.

figura3Figura 3: Apariencia del monitor web de Facebook [Fuente: Facebook]

Conclusiones

Gracias a la aparición de diferentes frameworks y tecnologías como las comentadas anteriormente, la gestión de certificados se simplifica. Además, el objetivo final de las tecnologías emergentes es incrementar la seguridad evitando que se distribuyan de forma insegura las claves privadas y proponiendo alternativas para la detección de certificados comprometidos.

Con todo ello, la seguridad del individuo en internet y la protección de los datos que se intercambia es un aspecto clave y por lo tanto seguirá experimentando evoluciones y nuevas aportaciones.


Fuentes: I4S(Innovation4Security)

Autores:

Ruth González Novillo
– Linkedin: www.linkedin.com/in/ruthgonzaleznovillo

Jorge Cuadrado Saez
– Twitter: @Coke727
– Linkedin: https://www.linkedin.com/in/jorgecuadradosaez/

Alberto Díaz Adorna
– Linkedin: www.linkedin.com/in/albertodiazadorna