Como continuación del anuncio de la 4º Cumbre de Correo electrónico OpenPGP, este artículo ofrecerá un breve resumen de nuestra experiencia en el evento. Interactuamos con gran cantidad de personas que llevan adelante diversos proyectos basados en OpenPGP, académicos y otros individuos con gran conciencia acerca de la seguridad y privacidad el correo electrónico. De acuerdo a lo programado, la 4º Cumbre de Correo electrónico OpenPGP tuvo conferencias plenarias, sesiones abiertas (también llamadas grupos de trabajo), una fiesta de firma de claves, comida y bebida, y por supuesto, mucha diversión.
A continuación presentamos un resumen de los diversos puntos que se trataron durante las conferencias plenarias y sesiones abiertas. La mayor parte del contenido es de naturaleza extremadamente técnica, y por tanto lo más probable es que solo sea de interés para aquellos que desarrollan software relacionado con el correo electrónico OpenPGP.
Conferencias plenarias y sesiones abiertas de la 4º Cumbre de Correo electrónico OpenPGP (20-10-2018) – Día 1
OpenPGP: Conferencia plenaria
de Phil Zimmermann
– OpenPGP necesita de muchas mejoras. Hagámoslas realidad.
– Es necesario deshacerse de las primitivas criptográficas antiguas/obsoletas, y en su lugar emplear diseños/algoritmos modernos, bien escrutados y libres de patentes en futuras versiones del protocolo (TLS 1.3 puede servir de ejemplo).
– Chacha20, Poly1305 y AES son solo algunos buenos algoritmos (sin embargo, no me gustan mucho las modalidades Galois/Counter).
– Verificación de claves: el modelo de confianza de OpenPGP es difícil de explicar a los usuarios no técnicos. Hacemos la verificación de huellas digitales de claves públicas usando diversos canales alternativos, que en su mayoría no son convenientes. Las huellas digitales de claves públicas podrían transferirse empleando otros medios seguros (p.ej. WhatsApp/Signal/…) o ZRTP y el protocolo Signal (es decir, el Silent phone). La idea sería emplear otros medios o sistemas además de OpenPGP para aprovechar (reforzar) la confianza, en lugar de usar el modelo de confianza actual de PGP.
– Falta de efecto de red en OpenPGP: en su mayor parte debido a su complejidad operativa, no hemos sido capaz de llegar a más usuarios. Superemos esto tomando buena nota de lo ocurrido en sistemas que ya han aprovechado exitosamente el efecto de red
– Esperamos conocer a personas interesadas en mejorar/modernizar el estándar OpenPGP.
Reflexiones acerca de la integración de la criptografía postcuántica
– También deberíamos comenzar a enfocarnos en el uso de criptografía postcuántica en OpenPGP. El momento ha llegado.
– Las claves postcuánticas pueden ser enormes; no transportemos las claves sino más bien las huellas digitales, y descarguemos las claves de algún tipo de servidor de claves de nueva generación.
A futuro
– Estándar actual RFC4880; Borrador del nuevo estándar RFC4880bis; Grupo de trabajo: https://tools.ietf.org/wg/openpgp/
– Descontinuar las primitivas criptográficas antiguas/obsoletas: cifras, algoritmos de compresión, etc. y otras elecciones de diseño (p. ej. reemplazar MDC con AEAD).
– Deshacerse de cosas antiguas, recortar todo lo posible y al mismo tiempo ajustar los puntos de mejora al marco sintáctico existente.
– Usar primitivas criptográficas modernas (p. ej. solamente pares de claves basados en ECC-curve25519 para nuevos usuarios, …). No suministrar más soporte para los métodos tradicionales (p. ej., eliminar la opción para generar claves basadas en la cifra anterior, etc.) y comenzar a avanzar en la dirección correcta.
– Pedir a los proveedores de software OpenPGP que mantengan actualizadas sus implementaciones para dispositivos de usuario (p. ej., emplear algún tipo de actualización automática) y obligar a los usuarios a actualizar su par de claves repudiando el anterior (si hace falta).
– El universo de OpenPGP es un polvorín, es necesario modernizarlo. Hará falta gran cantidad de voluntad política.
Los propietarios y miembros de proyectos en AutoCrypt, DeltaChat y NextLeap (para evitar los MITM) también ofrecieron conferencias plenarias e informativas.
Sesión de OpenPGP: servidores de claves SKS
Moderador de la discusión: Kristian Fiskerstrand
– Conjuntos de servidores de claves: https://sks-keyservers.net/overview-of-pools.php
– Temas abordados: nuevos requisitos de los conjuntos, remoción de las ID de los usuarios por motivos de privacidad, mejora del desempeño de los servidores de claves.
– El conjunto de servidores actual cuenta con 5 servidores ejecutados por 2 operadores.
– Qué datos debe contener el servidor de claves: ¿debemos almacenar las ID de usuario? ¿Deberíamos no permitir firmas de confianza externas en los servidores de claves y usar un servicio diferente para eso? ¿Deberían los SKS responder exclusivamente a las huellas digitales?
¿O deberíamos hacer que todo esto fuese opcional?
– También existen otros problemas de equilibrio.
– Para que los servidores de claves no fuesen voluntariamente ignorantes al proporcionar la clave correcta. ¿deberíamos ejecutar las operaciones criptográficas (p.ej. verificar las firmas de confiabilidad y tomar decisiones razonable)? ¿o deberíamos sacar esa función del servidor de claves y asignarla a algún servicio externo?
– También son bienvenidas las implementaciones alternativas (no-OCaml), preferiblemente con requisitos mínimos.
– Otros mecanismos claves para descubrimiento: WKD (https://wiki.gnupg.org/WKD), Mailvelope key server, etc.
– Se desea conocer las opiniones de la comunidad acerca de esto.
Para hacer seguimiento: lista de correos openpgp@ietf.org (https://www.ietf.org/mailman/listinfo/openpgp)
Sesión de OpenPGP: Autocrypt nivel 2
Moderador de la discusión: Patrick Brunschwig
– Discusión acerca de qué sincronizar (Clave privada: mensaje de configuración de Autocrypt, estado de Autocrypt, libreta de direcciones, direccionamiento alternativo, preferencias generales de MUA: firma/HTML/etc., política de establecimiento de reglas, anillo de claves públicas, reglas de filtrado, etiquetas, etc.).
– Propiedades: fáciles de usar, autenticadas y confidenciales, continuas, automáticas, más de dos dispositivos, etc.
– Opciones para lograr la sincronización: protocolo Kolab, mecanismo de emparejamiento, MLS: protocolo de mensajes grupales, cubrir la pérdida de mensajes.
– Riesgos/efectos colaterales: sincronización de finalización a un dispositivo con el que se desea sincronizar (evitando el espionaje en el canal), eliminación, duplicación, fallas en la sincronización (eliminación de claves, etc.), movimiento lateral posterior a un compromiso.
– Separación en múltiples capas: definir mecanismo de emparejamiento y sincronización (cómo establecer una autenticación, canal en lugar de la sintaxis a sincronizar), almacenamiento (IMAP, NextClout, Gdrive, etc.), ¿qué hay para sincronizar?
– Contrarrestar los MITM: verificaciones de claves en persona basándose en el código QR de la clave pública (automatizada con tokens de autenticación), límites de tiempo para el proceso de verificación (aún sin planificar, en discusión), separar claves almacenadas para diferentes contextos (grupos vs 1:1), cambio total de la clave si existen cambios en cualquier bit de la clave.
– Autocrypt y webmail: integrar Autocrypt (p. ej.- Mailfence, Mailvelope). Autocrypt no define técnicas para su implementación, y en su mayoría deja la elección de las mejores opciones dentro de la arquitectura de implementación en manos del implementador.
– Si bien Autocrypt no lo exige, los proveedores de webmail firman los encabezados de Autocrypt usando DKIM para garantizar su integridad.
Sesión de OpenPGP: múltiples métodos para descubrimiento de claves
Moderador de la discusión lead: Daniel Kahn Gillmor
– Compatibilidad de MUA con múltiples métodos de descubrimiento de claves: cómo manejarlos y cómo usar diversas respuestas de descubrimiento de claves desde diferentes ubicaciones para tomar una decisión lógica/razonable para el uso de la clave adecuada.
– Métodos existentes para descubrimiento de claves: Autocrypt (por correo electrónico), WKD (por correo electrónico), conjunto SKS (por correo electrónico/keyid/fpr), servidor de claves de Mailvelope (por correo electrónico/keyid/fpr), LDAP (por correo electrónico/keyid/fpr), DNS (por correo electrónico), Garbage pile de Kai & PEP (por correo electrónico/keyid/fpr), keybase.io (por nombre de usuario/canales de redes sociales/fpr), anulación manual (p.ej. firmas locales en claves importadas manualmente o la libreta de direcciones).
– La confianza en métodos clave de descubrimiento (mediante direcciones de correo electrónico): WKD está siendo usado por GpgOL, Enigmail, etc., y cifra automáticamente los mensajes entre dos usuarios cuya clave pública sea conocida para WKD.
– Ordenamiento/clasificación y manejo de colisiones: ¿en qué ocasiones los servicios emplean múltiples métodos de descubrimiento de claves y obtienen múltiples respuestas con diferentes claves públicas? Enigmail y GnuPG tienen una lista con un cierto orden en el cual buscan las claves y toman decisiones razonadas acerca de qué clave utilizar. Tanto el servidor de claves Mailvelope como garbage pile devuelven un solo resultado.
– ¿Acciones posibles a emprender al descubrir múltiples claves?
> Clasificación – por validez u otros criterios, como última subclave creada.
> Cifrarlas todas: tiene la ventaja de que representa el menor riesgo posible de que el destinatario sea incapaz de descifrar el mensaje.
> Escalar el problema al usuario.
…
– Problemas de filtración de metadatos, cada fuente clave de descubrimiento tiene diferentes filtraciones de metadatos. P.ej., DNS es particularmente problemático, WKD solamente filtra el dominio, etc. Para la búsqueda, comenzar con cero filtraciones de datos y poca latencia.
Sesión de OpenPGP: representación del mensaje de validación de la firma digital conforme
Moderador de la discusión: Daniel Kahn Gillmor
– El significado de la firma digital conforme avanza el tiempo no está claro, con un protocolo de almacenamiento y reenvío como el correo electrónico. Preguntas planteadas: ¿de qué maneras afecta a mi MUA una firma válida/inválida? Estoy viendo mensajes antiguos, y ahora el estado es diferente. ¿Afecta eso a lo que mi MUA hará?
– Parece que no tenemos una representación unificada del mensaje de validación de la firma conforme avanza el tiempo, en los casos donde la clave del firmante ha caducado o ha sido revocada después de la firma.
– OpenPGP.js: La caducidad y la revocación se tratan de forma diferente. Cuando se verifica una firma, la validez de la clave se deriva de la hora de la firma.
– GnuPG: usa un registro de fecha en la firma en sí. Si la clave no había caducado, entonces se considera válida. De lo contrario, se considera inválida.
– Los diversos MUA presentan sus mensajes de validación de firmas de forma diferente: requieren más testing para facilidad de uso y feedback en general.
– Uso de diversos puntos de datos relacionados con el tiempo, que pueden ser tomados en cuenta al evaluar la validez de la firma (¿almacenar los resultados de la validación en memoria cache), y así mostrar al usuario el mensaje de validación de la firma adecuado.
– Las firmas y fechas se están usando de formas muy diferentes en diversas aplicaciones de correo electrónico, y esto deja espacio para más conversaciones y para aprender entre sí.
Sesión de OpenPGP: Encabezados protegidos/Hueco en la memoria
Moderador de la discusión: Dr.-Ing. Dominik Schürmann
– Las especificaciones técnicas se crearon en el 2016, pero desde entonces no han evolucionado. El borrador de internet de la IETF se emitirá en los próximos meses. Una nueva fuente con información centralizada sería una gran adición (p.ej., una página web).
– Algunos clientes lo implementan, pero aun sí quedan problemas de implementación (p. ej. problemas de hilo conversacional con el asunto, etc.) y de compatibilidad (p. ej. el modo de contingencia [“fall back mode”] produce mensajes distorsionados, el MUA no descifra estos mensajes, etc.).
– Como las especificaciones aún están evolucionando, es necesaria la coordinación para simplificar las especificaciones hasta el nivel mínimo posible (p. ej., comenzar por cifrar el asunto sin hacer referencias, etc., cosa que representaría una excelente base para iteraciones consiguientes).
– Reducir la capacidad de búsqueda: no es posible buscar dentro del asunto del mensaje
– Brindar asesoría a los MUA también sería necesario en diversos aspectos, p. ej. usar solamente la primera parte de MIME dentro del mensaje cifrado; indicar un “Asunto cifrado” como nombre del asunto también serviría como indicador de seguridad: usar “Sin asunto” / “Asunto no disponible” o “Asunto integrado”, para que el asunto no fuese rechazado por las medidas de detección de spam.
– Consideración de privacidad: no localizar la cadena de asunto reemplazada elegida, cosa que podría revelar el lenguaje del mensaje en sí mismo.
¡El día terminó con una fiesta de firma de claves!
Sesiones de la 4º Cumbre de Correo electrónico OpenPGP (21-10-2018) – Día 2
Sesión de OpenPGP: Servidores de claves públicas y preocupaciones relativas al RGPD
Moderadores de la discusión: Patrick Brunschwig & Vincent Breitmoser
– La clave de OpenPGP PII. El cargar las claves automáticamente sin consentimiento del usuario en un lenguage claro y fácil de entender (las casillas de verificación no sirven para esto, puesto que no son tan indicativas) está haciendo que las aplicaciones no cumplan con el RGPD.
– Hasta el momento, ningún servidores de claves públicas ha recibido queja de un DPA. Pero es necesario avanzar en la dirección adecuada.
– Las personas usan direcciones de correo electrónico para encontrar las claves públicas, y funciona en la mayoría de los casos, como el servidor de claves de Mailvelope (pero eso deja de lado la federación y otros requisitos que tenemos en el conjunto).
– Idea: hace falta una identidad de marca neutral en el servidor de claves, no usar el servidor de claves Mailvelope en OpenKeyChain. Keys.openpgp.org podría servir de alojamiento a este nuevo servidor. Sería gestionado por un grupo pequeño pero estable. Las claves deberían ser verificables y eliminables.
– Puntos de discusión: dirección de correo electrónico, firma de entes externos, ¿Cuan inmediata se desea que sea la solución? ¿Búsquedas solamente de ID completos (+ huellas digitales) en vez de subcadenas por motivos de desempeño?
– Interfaz: HKP? Dejar a la implementación de servidor de claves (o a un reemplazo inmediato) la decisión de qué datos devolver (p. ej. todos los ID de la clave). Gobernanza: ¿pedir a organizaciones sin ánimo de lucro que lo operen? (¿P. ej. la EFF?).
– Gmail y otros proveedores emplean ciertos algoritmos para limpiar (eliminar los puntos, etc.) la parte local de una dirección de correo electrónico, lo que inhabilita la estrategia de la coincidencia exacta. ¿Sería posible implementar esto en tablas de consulta, o normalizar la representación del correo electrónico mediante algún intermediario?
– ¿El hacer búsquedas usando ID de clave largos (64 bits) puede causar colisiones? Más adelante, abandonar los ID de clave largos, cuando las huellas digitales estén presentes en las firmas.
Sesión de OpenPGP: Indicadores de seguridad (spoofing de HTML)
Moderador de la discusión: Daniel Kahn Gillmor
– La visualización de HTML conlleva varios riesgos: ¿canales de exfiltración? ¿Deshabilitarlos completamente? ¿O permitir una visualización limitada de contenidos externos?
– Indicadores en la lista de mensaje? ¿Rellenar la línea del remitente u otras partes que no pueden ser manipuladas por el cuerpo? ¿Cargar los correos electrónicos como “solo texto”, con un botón que permita verlos como HTML?
– Varios clientes tuvieron problemas con el estado de firma única, el PGP inline es problemático, particularmente para los casos de firmado irregular. Tal vez tener solamente un estado de firma por mensaje (pero esto tendría un impacto inmediato en las firmas de la lista de correos).
– Limitar el estado criptográfico a “envoltura criptográfica” vs. “carga criptográfica” — usar solamente el conjunto de capas de criptografía MIME en la parte más exterior del mensaje. https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html
– Si hubiese una “mancha” con criptografía inline en un mensaje de texto simple, ¿permitir al usuario descifrarlo manualmente?.
– La Universidad Ruhr de Bochum envió un correo a muchos MUA acerca de indicadores de IU susceptibles de spoofing. Debemos estar preparados para hacer enlaces con ese trabajo cuando lleguen las quejas acerca de visualizaciones simplificadas: https://www.golem.de/news/openpgp-gnupg-signaturen-faelschen-mit-html-und-bildern-1809-136738.html
– El espacio para los encabezados de seguridad a nivel de la interfaz se gestiona de manera diferente según la implementación. Es posible hacer muchas mejoras ilustrando al usuario de la manera más comprensible (por ejemplo, mostrando un indicador detallado de forma predeterminada, pero permitiéndole minimizar el indicador y al mismo tiempo aprovechar la oportunidad para ilustrarlo acerca de indicadores minoritarios, etc.).
Sesión de OpenPGP: marca de tiempo para validación de firmas
Moderador de la discusión: Danny De Cock
– Planteamiento del problema: la validación de firmas digitales en OpenPGP (en la mayoría de las implementaciones) toma en cuenta el estado actual de la clave del firmante (revocada/caducada), y muestra un mensaje de validación de firma que es confuso o inexacto si la clave del firmante está revocada o caducada.
– Dependiendo del estado del par de claves del firmante (válido/inválido) al momento de hacer la firma (fecha y hora): si es válida, entonces la firma digital también lo será, y viceversa en caso contrario.
– Conservar estados: emplear un ente externo para mantener las marcas de hora y brindar información para validación de firmas en caso de conflictos.
– O usar árboles de Merkle para combinar diversos valores de hash (usando el orden de los nodos) para la verificación. P. ej. el destinatario del mensaje puede aplicar un hash a todas las firmas obtenidas y llevar un registro de estas (p. ej. en una base de datos basada en un árbol de Merkle) que puede ser usada como un medio verificable que se puede presentar ante un tribunal.
– En el caso de la revocación de la clave de un firmante, siempre hay un período entre el momento en que la clave resultó comprometida (que podría ser desconocida para el usuario) y el momento en que fue revocada por el usuario. Cualquier firma realizada durante este período podría considerarse malintencionada. En caso de tener una autoridad de confianza, el retroceso podría hacerse hasta la última firma verificada (hecha por el usuario cuando la clave no estaba comprometida).
– Para profundizar en el punto anterior, en lugar de tener una autoridad de confianza, se le podría pedir al firmante del mensaje que publique el más reciente estado de verificación de la clave en un canal público (p. ej. servidores de claves públicas, etc.) que servirían como puntos de datos para el último estado verificado (que puede usarse para tomar una decisión razonable, p.ej. hora de la firma VS último estado verificado).
Diapositivas de la sesión: : https://homes.esat.kuleuven.be/~decockd/slides/20181021.signature.validation.pdf
OpenPGP: visualización de la validación de la firma
Moderador de la discusión: Andre Heinecke
– El mensaje de visualización de validación de firma es diferente para varias implementaciones.
– El mensaje de validación de la firma también tendría que informar al usuario de que una firma válida no implica que la clave del firmante usada para firmar el mensaje pertenezca al legítimo propietario. Podría haber un segundo parámetro que establezca la condición de confiabilidad de la clave del firmante.
– Algunas implementaciones también ofrecen información de verificación de la dirección del remitente, más allá de la firma digital en sí.
– Las firmas se hacen sin contexto, las implementaciones pueden suministrar opciones, p.ej. siempre firmar para este destinatario con esta huella digital, etc.
– Una presentación general del mensaje de validación de firma digital podría ser un estado binario, si un mensaje es válido o no.
Sesión de OpenPGP: correo electrónico eliminable
Moderador de la discusión: Daniel Kahn Gillmor
– Establecer una definición para correo electrónico eliminable: controlar el período durante el cual un correo pueda ser leído.
– Un intento de replantear el “secreto adelante” y adoptarlo para un formato archivable de mensaje, como el correo electrónico.
– OpenPGP podría emplear una rotación frecuente de subclaves para lograr lo mismo (en un período mayor). Pero lograr que las personas cambien de clave a menudo es complicado, especialmente en los casos en que no se puedan leer correos electrónicos antiguos, cosa que no es deseable.
– ¿Deberían los correos electrónicos almacenarse en absoluto? Esto representaría una contradicción al “Secreto adelante” Sin embargo, muchos argumentan que la capacidad de archivar correos electrónicos es una funcionalidad tanto para casos empresariales (p. ej. por motivos de conformidad con reglamentos) como para casos personales (p. ej., los usuarios conservan los correos electrónicos por decisión propia).
– Algunas implementaciones (p. ej., NotMuch) almacenan la clave de la sesión (con cifrado simétrico) y al mismo tiempo permiten a los usuarios eliminar/rotar las claves (asimétricas) habilitando así a los usuarios para leer antiguos mensajes cifrados. Otro enfoque podría ser cifrar nuevamente todos los mensajes hacia una clave local.
– No hay una política de autoeliminación en los clientes de correo electrónico. Si bien algunas mensajerías (instantáneas) permiten eso. También se pueden explorar otras opciones en este aspecto para establecer una política personal de autoeliminación (p. ej. en los encabezados de los correos electrónicos, notas de las subclaves, etc.). Sin embargo, hacer cumplir esta política para los correos electrónicos podría necesitar acuerdos bilaterales vinculantes.
– Eliminar localmente un correo electrónico no es suficiente, dado que siempre hay más personas que podrían tener una copia de ese mensaje, que podría obtenerse. Los usuarios pueden sencillamente hacer una captura de pantalla o emplear cualquier canal secundario para conservar una copia de ese correo electrónico.
– Algunas investigaciones en esta área proponen usar una subclave diferente para cada mensaje. Sin embargo, esto lleva a problemas comunes (p.ej., entornos multidispositivo, etc.).
– ¿Representaría una ventaja eliminar los correos electrónicos después de una pequeña ventana de tiempo (p. ej. una semana) contra guardarlos indefinidamente?.
– Idea: generar previamente y publicar claves para “alta rotación” que permita a las partes que se comunican usar una clave específica durante un período corto, y entonces usar una clave diferente. Sin embargo, una rotación frecuente podría llevar a la gente a consultar frecuentemente los servidores de claves, lo cual puede permitir la identificación de metadatos (IP, qué destinatario). El exigir un canal fuera de banda para acceder a las claves rotadas requiere de un medio online bien conectado.
– Y hablando de una ventana pequeña, los correos electrónicos pueden tardar hasta un día entero en ser entregados. Es necesario determinar qué período de tiempo sería el adecuado, y para quién.
Justus explora dos enfoques hacia cómo traer el Secreto Adelante a OpenPGP: https://sequoia-pgp.org/talks/2018-08-moving-forward/moving-forward.pdf https://www.youtube.com/watch?v=an6oYjikAPY
A los grupos de trabajo les siguió una sesión de conclusión, y el día terminó con una sesión de colaboración/hacking entre diferentes proyectos de OpenPGP, con muchas conferencias secundarias de gran valor. Una versión incluso más detallada de las sesiones con preguntas y respuestas puede encontrarse aquí.
Estamos encantados de haber tenido la oportunidad de organizar la 4º Cumbre de Correo electrónico OpenPGP y de haber obtenido, intercambiado y compartido experiencias acerca de esos importantes temas, que contribuirán a moldear el futuro del OpenPGP. Esto también nos ha permitido interactuar con otros proyectos basados en OpenPGP, que comparten nuestra visión común de fortalecer la seguridad y privacidad de los datos en nuestro mundo cada vez más conectado. Quedamos a la expectativa de los próximos acontecimientos en todos los temas discutidos en las muchas conferencias plenarias/sesiones abiertas/conferencias secundarias, y continuaremos brindando apoyo a cualquier otra iniciativa que contribuya a hacer que la internet sea un lugar más seguro y abierto.
Muchas gracias a:
- Patrick Brunschwig de Enigmail por reunir a toda esta gente excelente para esta cumbre
- La Renewable Freedom Foundation por financiar las cenas
- El increíble público de la 4º Cumbre de Correo electrónico OpenPGP
Mailfence es un paquete de webmail seguro y privado que ofrece a los usuarios un control total sobre sus datos.
Síganos en twitter/reddit y manténgase actualizado en todo momento.
