Google apuesta por centralizar la verificación de claves para su extensión End-to-End
Hasta el momento quienes usan servidores de correo online (webmail) como Gmail o Yahoo y quieren añadir una capa adicional de protección a sus comunicaciones tienen que recurrir a plugins externos como Mailvelope que permiten cifrar el contenido de los correos electrónicos con el servicio PGP de criptografía con clave pública o incluso aventurarse en el uso de herramientas que en un principio pueden parecer complejas de instalar y usar –como Tails. Estos dos grandes del correo electrónico web llevan ya meses trabajando en sus propias extensiones de cifrado de extremo-a-extremo.
El deseo de Google es hacer el cifrado de extremo-a-extremo “más fácil de usar”, tal y como señalaba Stephan Somogyi, jefe de producto, seguridad y privacidad de la corporación estadounidense en el blog corporativo del equipo con motivo de la migración del código fuente de la versión alpha del plugin a la plataforma de verificación de código software GitHub. Casi un año más tarde coincidimos con él durante el transcurso de Re:publica 2015 –la mayor conferencia europea de Internet y Sociedad en red celebrada en Berlín– y puntualiza: “nuestra prioridad es primero hacer un servicio seguro y en segundo lugar algo fácil de usar, pero no al revés”.
"Si no eres una persona con perfil técnico ni siquiera vas a saber la diferencia entre una clave pública y una privada, por eso debemos ser capaces de hacer la criptografía fácil y lista para ser utilizada por el usuario, pero cuidando de la seguridad".
Esa solución se llama End-to-End, la futura extensión de Chrome construida sobre una criptolibrería de nuevo diseño basada en JavaScript, que ayudará a cifrar, descifrar, usar firmas digitales, y verificar mensajes dentro del propio navegador usando OpenPGP –el estándar abierto para cifrado más extendido y que a su vez derivó originalmente del PGP creado por Phil Zimmermann en 1991—.
Como formato estándar, este lleva funcionando desde hace más de dos décadas, si bien “a lo largo de los años se han ido encontrando muchos errores, errores que ahora sabemos son clave, como por ejemplo: la gestión de llaves, su distribución, etcétera”, apunta el ingeniero de sistemas. Motivos que identifica como factores responsables de la baja adopción de este sistema por parte de los usuarios.
Un 'key server' propio que rompe con el modelo 'web-of-trust'
En el sistema PGP, para que el intercambio de mensajes cifrados sea posible, es decir, que emisor y destinatario puedan cifrar y descifrar respectivamente el mensaje, es necesario que hayan intercambiado previamente sus claves públicas. Para facilitar este intercambio, existen servidores de claves PGP externos, que funcionan como almacenes de estas particulares 'llaves', que a su vez están ligadas a las claves privadas de sus respectivos usuarios y que permiten abrir el correo cifrado.
Según Somogyi, contar con un servidor de claves propio “permitiría a nuestros clientes hacer backups de claves, encontrar claves de otros usuarios y hacer las claves disponibles al 'mundo exterior' –como ya anunciamos estamos colaborando con Yahoo para que sus usuarios y los usuarios Gmail puedan intercambiar claves”.
El responsable de Seguridad y Privacidad de Google se refiere a la alianza a la que han llegado ambas compañías con un fin común: incrementar el uso y la usabilidad de la criptografía. Como adelantaba el pasado año Alex Stamos, Jefe de Seguridad de Información de Yahoo, con motivo del anuncio de los planes de la compañía de seguir los pasos de su competidor en lo que respecta a cifrado de extremo-a-extremo: “esto significa que no sólo los usuarios de Yahoo Mail podrán comunicarse de forma cifrada con otros usuarios de Yahoo Mail, sino también con usuarios de Gmail y en un futuro con otros sistemas de correo electrónico que adopten metodologías similares”.
Pero no sólo eso, Google está optando por un “novedoso enfoque” con este prototipo de key server, ya que “rompe” con el actual modelo web-of-trust de confianza distribuida, apostando ahora por un sistema centralizado para autentificar las identidades entre usuarios –apunta Bill Budington, ingeniero de sistemas de la Electronic Frontier Foundation.
Actualmente, lo normal es que un usuario se descargue la clave de otro usuario a través de uno de los múltiples servidores de claves que existen, y luego compruebe si esa clave es la correcta leyendo una larga cadena de cifras y letras, la cual es una representación de sus claves en formato extraído. Si la clave es correcta, les asegura que cuando se manden mensajes cifrados, nadie más podrá descifrarlos. Esta comprobación manual y descentralizada es un proceso bastante laborioso, por lo que desde hace tiempo la comunidad de desarrolladores web investiga la forma de facilitar el proceso.
“Esto es una victoria en términos de usabilidad, ya que todo ese proceso sucede entre bambalinas sin que el usuario intervenga. Aunque todavía no está claro cuán comparable es la seguridad de este sistema con respecto a la del tradicional, la verificación de claves manual, ya que aún no ha sido ampliamente implementado ni auditado”, subraya Budington.
Liberación del código fuente en GitHub
Tal vez por ello, y tras varios varios meses sin novedades, sigue siendo una incógnita cuándo estará lista la versión no-alpha del plug-in. En el post del blog de Google mencionado anteriormente expresaban su deseo de “tener una End-to-End mucho más desarrollada para 2015”, sin embargo, fuentes corporativas consultadas para la publicación de este artículo, insisten en que éste sigue siendo un “proyecto pequeño, que en el futuro será una extensión de Chrome pero que todavía no existe”.
Por su parte, Yahoo, que también anunció el pasado año que empezaría a ofrecer a sus usuarios la opción de cifrado extremo-a-extremos en 2015, difundía el pasado mes de marzo un vídeo demo –que recogía en el propio Stamos en una entrada del blog – mostrando cómo será el funcionamiento del cifrado de correos electrónicos de Yahoo Mail con la extensión Chrome e2e, en comparación con la Pretty Good Privacy a través de la herramienta GPGtools.
Durante la conversación en Berlín, Somogyi mantiene la hermeticidad habitual de la casa y no se aventura a adelantar aún una fecha concreta de lanzamiento para la versión oficial. “Poner artificialmente una fecha no sería bueno en términos de calidad. No podemos permitirnos ofrecer un servicio destinado a gente que realmente lo necesita por cuestiones de seguridad, como periodistas o defensores de los derechos humanos, sin tener todas las garantías de que será seguro”.
“Inicialmente teníamos el código en nuestro propio repositorio, en el mes de diciembre lo migramos a GitHub, precisamente porque queríamos contar con la participación de la comunidad, para asegurarnos que revisaría el código y sí, se encontraron algunos bugs de seguridad que se han resuelto”.
Por sorprendente que pueda resultar que una gran corporación como ésta comparta el código fuente de uno de sus futuros productos, lo cierto es que no es tan inusual, de hecho, el emporio que dirige Larry Page cuenta con un Programa Recompensa para Vulnerabilidades que ofrece compensaciones económicas por descubrir fallos de seguridad en el código de los servicios de Google web, Youtube y Blogger.
“Nada garantiza que si se abre un código vaya a mejorarse –matiza el que fuera anteriormente Director de productos de PGP Corporation—, el open source permite que sea haga auditable pero no garantiza la seguridad, si eso fuera así no habrían existido Heartbleed, Poodle y otras tantas vulnerabilidades; de modo que el código abierto es necesario pero no suficiente en lo que respecta a ciertos aspectos críticos de la seguridad”.
“En Google confiamos plenamente en nuestra capacitación como ingenieros, por eso hay cosas que no hacemos open source, y para las que contamos con procesos internos que son de sobra suficientes para garantizar la seguridad”, aclara Somogyi.
“El hecho de que End-to-End sea un proyecto de código abierto y que su proceso de desarrollo sea transparente debería reconfortar a aquellos usuarios preocupados por la seguridad y fiabilidad del software, pero el hecho de que se desarrolle en abierto no es en sí mismo suficiente” coincide el ingeniero de EFF. “Las auditorías por parte de terceros y revisiones por pares son vitales para cerciorarse de que se encuentran y resuelven posibles vulnerabilidades del software lo antes posible. Afortunadamente, Google cuenta con su programa de recompensa para quienes encuentran errores de seguridad”.
¿Es el cifrado in-browser realmente fiable?
¿Es el cifrado in-browser realmente fiable?Para algunos sectores de la comunidad tech, la denominada criptografía in-browser (dentro del navegador) sigue despertando ciertas suspicacias, aunque “muchas cosas han cambiado en los últimos años”, según apunta el ingeniero de la EFF.
“En el pasado la criptografía in-browser no era posible. La reconocida firma de seguridad, Matasano, publicó en 2011 su famoso post enumerando todas las razones por las que realizar el cifrado en el navegador era dañino, desaconsejable e incluso peligroso. Entre ellas destacaban el hecho de que no hubiese en Javascript un generador de números aleatorios lo suficientemente bueno para criptografía, no hubiese mecanismos para firmar el código que se entrega para asegurar que se comporta correctamente, ni se dispusiese de ninguno de los elementos básicos para una buena criptografía –los llamadas 'primitivas criptográficas'—. Pero ahora, ”todos los navegadores de escritorio y la mayoría de los navegadores móviles son compatibles con fuertes generadores de números aleatorios a nivel de sistema operativo“.
Tal y como explica Budington, el grupo de trabajo de Criptografía del Consorcio de la World Wide Web (W3C) –comunidad internacional, liderada por el inventor de la web, Tim Berners-Lee, cuyo fin es desarrollar estándares web— ha ideado una API que los fabricantes de navegadores están implementando para asegurar la disponibilidad de primitivas criptográficas de bajo nivel. “End-to-End estará disponible como una extensión de navegador en la tienda web de Chrome, por lo que cada versión irá firmada por Google antes de ser entregada y ejecutada por los usuarios finales”.
De hecho, otras extensiones para navegador tan extendidas como CryptoCat también utilizan este mecanismo de entrega de código a sus usuarios. “Todo esto significa que si los desarrolladores siguen ciertas buenas prácticas establecidas, pueden desarrollar aplicaciones de cifrado para navegadores seguras”, por ello, desde la EFF aplauden la iniciativa de Gmail.
"Tener múltiples implementaciones de cifrado seguro y autentificación de correo electrónico es, en general, positivo para el ecosistema de la privacidad".
Especialmente, en un momento como el actual en el que, tras desvelarse que el programa PRISM de la NSA interceptaba información de corporaciones como Yahoo, Google, Facebook o Apple, la concienciación de los internautas con respecto a su privacidad y la seguridad de sus comunicaciones va en paulatino aumento. De un tiempo a esta parte, la labor de la comunidad tech está contribuyendo a lo que puede considerarse una democratización de unas herramientas antes manejadas en su mayoría por personas con un perfil informático elevado, por lo que esta alianza entre los dos gigantes del webmail pone de manifiesto, cuanto menos, que la criptografía es una prioridad cada vez mayor para la industria y la sociedad post-Snowden.
Foto: Yuri Samoilov
