Haciendo el cifrado más sencillo y accesible para todo el mundo

key transparency

Lo que podemos ver en la imagen que acompaña esta pieza es fiel analogía de lo ocurre continuamente en toda comunicación que hacemos digitalmente.

Como ya expliqué en su día, vivimos un momento apasionante en cuanto a cambio de paradigma comunicacional se refiere. En cuestión de apenas un par de años, hemos pasado de un entorno casi exclusivamente inseguro a otro donde la mayoría de plataformas de comunicación cifran por defecto los mensajes.

HTTPs era hasta hace nada un protocolo de comunicación entre servidores y clientes disponible casi solo para proyectos con peso. A día de hoy, se está volviendo el estándar de comunicación en la web y en el mundo app, y en cuestión de uno o dos años, será el único modelo de comunicación considerado “secure”. Es decir, que quien quiera seguir teniendo recursos disponibles en la red que sean accesibles por usuarios, tendrá que dar el paso sí o sí y cifrar sus comunicaciones.

Lo mismo ha pasado en los servicios de mensajería y redes sociales. A día de hoy, casi no hay ninguno de estos servicios que no cuente con algún tipo de cifrado, e incluso algunos plantean un entorno verdaderamente privado en el que únicamente los miembros envueltos en la comunicación (ni siquiera la propia compañía) son capaces de descifrar el contenido enviado. Protocolos de cifrado end-to-end como el habilitado en WhatsApp (cuyo protocolo, por cierto, y aún pese a todos los medios que se han hecho eco estos días del estudio de estos investigadores (EN), sigue siendo considerado robusto (EN)) o Telegram son ejemplos de cómo la industria se ha puesto las pilas en este sentido.

Hasta el punto que a día de hoy, conectarse a una red WIFI pública sigue entrañando su riesgo, pero no supone un peligro inmediato tan exagerado como ocurría apenas hace unos años, cuando todos los servicios compartían en texto plano los mensajes, exponiendo nuestros datos personales a cualquier interesado que estuviera conectado cerca.

Y pese a todo, aún hay camino que recorrer.

El cifrado genérico sigue siendo difícil de utilizar

Era algo que defendía recientemente en un artículo publicado en la revista corporativa ETC. HTTPs es un gran paso, como también lo son los cifrados de X o Y servicio de comunicación, pero seguimos teniendo problemas a la hora de habilitar cifrados de forma genérica.

El PGP es un claro ejemplo. Habilitado desde hace ya unos cuantos meses en la página de contacto de esta misma web, me permite ofrecer a cualquier interesado una manera de comunicarse conmigo de forma totalmente privada.

Pero para hacerlo, tiene que entender cómo funciona un cifrado asíncrono. No se trata simplemente de escribir un email a mi dirección de contacto y listo. Tendrá que escribirlo y luego cifrarlo con la siguiente clave pública (ES/TXT), un conjunto aparentemente caótico de letras y números.

Y para ello, tendrá que hacer uso de algún programa que cree la llave PGP en base a mi clave pública (una parte de la llave de mi casa) y la suya.

Para leerlo, un servidor tiene que hacer uso de otra herramienta que, en base a la llave que me envíe, descifre la parte que depende de mi llave para que el contenido enviado esté en un formato que yo, como humano, entiendo.

Y sí. El sistema es muy robusto, pero es profundamente ineficiente como aplicativo para el grueso de la sociedad. Cáspita, ¡es difícil de entender incluso para mi!

De ahí que viera con buenos ojos la decisión de un servicio de correo por habilitar un sistema PGP nativo (EN), que si bien no es la panacea, por lo menos acerca un pelín más este tipo de tecnologías al usuario de la calle. Y que eche de menos ver sistemas semejantes en servicios de correo ampliamente utilizados como puede ser GMail, Outlook y compañía.

¿Y si aplicamos el paradigma de la lista centralizada de identidades al cifrado?

En esto último debieron estar pensando los ingenieros de Google a la hora de desarrollar Key Transparency (EN/GitHub).

La esencia, como comentan en el blog de seguridad de la compañía (EN), pasaría por crear un espacio de trabajo accesible por cualquiera que permitiera a desarrolladores de producto ofrecer de forma sencilla al usuario maneras de compartir su clave pública con terceros. Básicamente, crear un directorio de verificación de comunicaciones que librara al usuario de tener que gestionar él su biblioteca de llaves. Una “especie” de páginas amarillas de contactos.

Este servicio funcionaría, al menos en teoría, con cualquier método genérico de cifrado (como PGP), habida cuenta de que se trataría de un servicio de descubrimiento de claves públicas open source no atado a un sistema específico.

La duda que me surge es qué novedad podría ofrecer Google a los servidores de clave que a día de hoy ya están en funcionamiento más allá de que sea la propia Google quien saca el suyo (con el buzz y el peso que tendría a nivel de implementación de posibles interesados).

Sin ir más lejos, Mailvelope (EN), que es la extensión que un servidor utiliza, hace uso de los servidores de clave de Ubuntu (OpenPGP Public Key Server (EN)).

Por lo poco que sabemos hasta ahora parece que Key Transparency sería una especie de servidores de clave pero no cerrados al uso único de PGP, sino con posibilidad de que quien quiera utilice su método de cifrado asíncrono preferido.

Pero de nuevo, es otro paso adelante. Si la cosa acaba en buen puerto, quizás veamos un GMail con cifrado end-to-end nativo. Algo que a priori rema en contra de los intereses de la compañía (no deberían poder entonces utilizar nuestros emails para conocernos mejor), pero que viendo cómo se está poniendo la cosa, quizás acabe por ser el estándar. Pasó lo mismo con HTTPs, y Google, que vive del profiling que sea capaz de realizar con nuestro rastro de navegación, ha sido el máximo defensor a la hora de implementar este cifrado en toda la web.

A fin de cuentas, en el mundo real llevamos tiempo manteniendo la privacidad de las cartas postales como un derecho ciudadano. Por lo menos, a no ser que haya indicios claros que incentiven a las autoridades a hacer lo contrario.

Y tendría todo el sentido del mundo que una situación así se acabe por democratizar también en el resto de comunicaciones digitales. Sea la navegación, sea la mensajería instantánea, sea cualquier tipo de relación/comunicación entre pares.