En Cloudflare, nos comprometemos a apoyar y desarrollar nuevas tecnologías de protección de la privacidad que beneficien a todos los usuarios de Internet. En noviembre de 2017, anunciamos un soporte por parte del servidor para el protocolo de Privacy Pass, un trabajo realizado con la colaboración de la comunidad académica. Privacy Pass, en pocas palabras, permite a los clientes ofrecer una prueba de confianza sin necesidad de revelar dónde y cuándo se brindó la confidencialidad. El objetivo del protocolo es permitir que toda persona demuestre que es de confianza para un servidor, sin que ese servidor pueda rastrear al usuario a través de la confidencialidad que se le asignó.

A nivel técnico, los clientes de Privacy Pass reciben tokens de autenticación de un servidor, que luego se pueden intercambiar en el futuro. Estos tokens se proporcionan cuando un servidor considera que el cliente es de confianza; por ejemplo, después de haber iniciado sesión en un servicio o si demuestran ciertas características. Los tokens intercambiados no se pueden asociar criptográficamente a la autenticación suministrada originariamente por el servidor, por lo tanto, no revelan nada sobre el cliente.

Para utilizar Privacy Pass, los clientes pueden instalar una extensión del navegador de código abierto disponible en Chrome y Firefox. Ha habido más de 150 000 descargas individuales de Privacy Pass en todo el mundo; aproximadamente 130 000 en Chrome y más de 20 000 en Firefox. La extensión es compatible con Cloudflare para que los sitios web sean más accesibles para los usuarios. Esto complementa el trabajo previo, incluso el lanzamiento de los servicios de onion de Cloudflare para mejorar la accesibilidad a los usuarios del navegador Tor.

El lanzamiento inicial se hizo hace casi dos años, y luego se realizó una publicación de investigación que se presentó en el Simposio de tecnologías para optimizar la privacidad en 2018 (donde obtuvo el premio Best Student Paper Award). Desde entonces, Cloudflare ha trabajado con la comunidad en general para desarrollar el diseño inicial y mejorar Privacy Pass. Hablaremos del trabajo que hemos realizado para desarrollar las aplicaciones actuales, junto con el protocolo en sí.

¿Cuáles son las novedades?

Soporte para extensión del navegador Privacy Pass v2.0:

• Configuración más sencilla del flujo de trabajo.

• Integración con el nuevo proveedor de servicios (hCaptcha).

• Cumplimiento con el proyecto de hash de curva.

• Es posible rotar las claves fuera de la versión de la extensión.

• Disponible en Chrome y Firefox (funciona mejor con versiones actualizadas del navegador).

Ampliación de un nuevo backend de servidor mediante la plataforma Cloudflare Workers:

• Las operaciones criptográficas se realizan mediante motor V8 interno.

• Proporciona una API de intercambio público para tokens v2.0 de Privacy Pass de Cloudflare.

• Disponible mediante solicitudes POST en https://privacypass.cloudflare.com/api/redeem. Consulta la documentación para ver ejemplos de uso.

• Sólo compatible con la extensión v2.0 (verifica que esté actualizada).

Estandarización:

• Desarrollo constante del proyecto de funciones pseudoaleatorias olvidadas (OPRF) en grupos de primer orden con CFRG@IRTF.

• Nuevo proyecto que especifica el protocolo de Privacy Pass.

Extensión v2.0

En el tiempo que transcurrió desde el lanzamiento, hemos trabajado en una serie de funciones nuevas. Hoy nos complace anunciar el soporte para la versión 2.0 de la extensión, la primera actualización desde la versión original. La extensión aún está disponible para Chrome y Firefox. Es posible que debas descargar v2.0 en forma manual desde la tienda si tienes las actualizaciones automáticas deshabilitadas en tu navegador.

La extensión aún se encuentra en etapa de desarrollo y consideramos que nuestro soporte está en la fase beta. Esto seguirá siendo así en la medida en que la especificación del proyecto del protocolo se siga escribiendo con la colaboración de la comunidad en general.

La implementación del cliente utiliza la API WebRequest para buscar ciertos tipos de solicitudes HTTP. Cuando se detectan estas solicitudes, se reescriben para incluir algunos datos criptográficos necesarios para el protocolo de Privacy Pass. Esto permite que los proveedores de Privacy Pass que reciben estos datos autoricen el acceso al usuario.

Por ejemplo, un usuario puede recibir tokens de Privacy Pass para completar algunas comprobaciones de seguridad del servidor. La extensión del navegador almacena estos tokens, y las solicitudes futuras que necesiten una autorización de seguridad similar se pueden modificar para agregar un token almacenado como un encabezado HTTP adicional. A continuación, el servidor puede comprobar el token del cliente y verificar que este tiene la autorización correcta para continuar.

Si bien Cloudflare admite un tipo determinado de flujo de solicitudes, sería imposible esperar que diferentes proveedores de servicios cumplan exactamente con las mismas características de interacción. Uno de los principales cambios en la extensión v2.0 fue una reescritura técnica para en su lugar utilizar un archivo de configuración central. La configuración se especifica en el código fuente de la extensión y permite una modificación más sencilla de las características de navegación que inician las acciones de Privacy Pass. Esto permite agregar flujos de solicitudes nuevos y completamente diferentes, simplemente mediante la clonación y adaptación de la configuración para nuevos proveedores.

Pronto se implementará una nueva versión de la extensión, para demostrar que tales integraciones ahora son posibles con otros servicios además de Cloudflare. Esta nueva versión es compatible con el proveedor de CAPTCHA hCaptcha. Los usuarios que resuelvan desafíos efímeros provistos por hCaptcha recibirán tokens que protegen la confidencialidad y que serán intercambiados en otros sitios de clientes de hCaptcha.

“hCaptcha pone el acento en la privacidad del usuario, y el respaldo a Privacy Pass es una prolongación natural de nuestro trabajo en esta área. Esperamos trabajar con Cloudflare y otros, para que esta norma se adopte de manera amplia. Actualmente estamos investigando otras aplicaciones. La implementación de Privacy Pass en nuestro servicio a nivel global fue relativamente simple, y nos agradó trabajar con el equipo de Cloudflare para mejorar la extensión del navegador Chrome de código abierto con el fin de ofrecer la mejor experiencia a nuestros usuarios”.

— Eli-Shaoul Khedouri, fundador de hCaptcha

Esta integración de hCaptcha con la extensión del navegador Privacy Pass actúa como una validación del concepto al determinar la asistencia para nuevos servicios. Los nuevos proveedores que quieran integrarse con la extensión del navegador Privacy Pass pueden hacerlo simplemente mediante una pull request (solicitud de validación) al repositorio de código abierto.

Después del lanzamiento de la versión v1.0 de la extensión, quedaron algunas características sin implementar. Entre estas se encontraba la adecuada validación de prueba de conocimiento cero para comprobar que el servidor siempre utilizara la misma clave confirmada. En la versión v2.0 esta funcionalidad se completó, lo que impide que un servidor malintencionado intente desanonimizar a los usuarios mediante una clave diferente para cada solicitud.

Las operaciones criptográficas necesarias para Privacy Pass se realizan mediante el uso de criptografía de curva elíptica (ECC). La extensión actualmente utiliza la curva NIST P-256, por tal motivo, hemos incluido algunas optimizaciones. En primer lugar, esto permite almacenar puntos de curva elíptica en formatos de datos comprimidos y sin comprimir. Esto significa que el almacenamiento del navegador se puede reducir en un 50 % y que las respuestas del servidor también se pueden reducir.

En segundo lugar, se ha agregado soporte para el hash a la curva P-256 mediante el método "Simplified Shallue-van de Woestijne-Ulas" (SSWU) que se especifica en un proyecto en curso (https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-03) para estandarizar cifrados para hash con curvas elípticas. La implementación es compatible con la especificación del conjunto de cifrado (ciphersuite) “P256-SHA256-SSWU-” en este proyecto.

Estos cambios tienen una doble ventaja, en primer lugar, aseguran que la especificación de la función hash de la curva P-256 cumpla con la especificación del proyecto. En segundo lugar, este conjunto de cifrado elimina la necesidad de usar métodos probabilísticos, como hash e incrementos. El método hash e incrementos tiene una probabilidad de error que no se puede pasar por alto y el tiempo de ejecución depende en gran medida de la entrada oculta del cliente. Si bien actualmente no está claro cómo abusar de los vectores de ataque de sincronización, el uso del método SSWU debería reducir el potencial de ataque a la implementación y conocer la entrada del cliente.

Como mencionamos anteriormente, un punto importante para garantizar la privacidad del cliente es verificar que el servidor siempre utilice la misma clave. Esto garantiza que el servidor no puede segregar la base de usuarios ni reducir la privacidad del cliente mediante el uso de diferentes claves secretas para cada cliente con el que interactúa. El servidor garantiza que siempre usa la misma clave al publicar una confirmación para su clave pública en algún lugar al que el cliente pueda acceder.

Cada vez que el servidor emite tokens Privacy Pass al cliente, también genera una prueba de conocimiento cero para demostrar que ha generado estos tokens con la clave correcta.

Antes de que la extensión almacene los tokens, primero verifica la prueba en relación con las confirmaciones que conoce. Anteriormente, estas confirmaciones se almacenaban directamente en el código fuente de la extensión. Esto significaba que si el servidor quería cambiar su clave, debía lanzar una nueva versión de la extensión, lo que resultaba complicado e innecesario. La extensión se ha modificado para que las confirmaciones se almacenen en una ubicación de confianza a la que el cliente pueda tener acceso cuando necesite verificar la respuesta del servidor. Actualmente, esta ubicación es unrepositorio en GitHub de Privacy Pass independiente. Para los que estén interesados, hemos brindado una descripción más detallada del nuevo formato de confirmación en el Anexo A al final de esta publicación.

Cómo implementar la asistencia del lado del servidor en Workers

Hasta ahora, nos hemos centrado en las actualizaciones del lado del cliente. Como parte de la compatibilidad de la extensión con v2.0, estamos implementando algunos cambios importantes en la asistencia del lado del servidor que utiliza Cloudflare. Para la versión 1.0, utilizamos una implementación de Go del servidor. En v2.0 estamos introduciendo una nueva implementación de servidor que se ejecuta en la plataforma Cloudflare Workers. Esta implementación de servidor solo es compatible con las versiones v2.0 de Privacy Pass, por lo tanto, es posible que debas actualizar la extensión si tienes las actualizaciones automáticas desactivadas en tu navegador.

Nuestro servidor se ejecutará en https://privacypass.cloudflare.comy todas las solicitudes de Privacy Pass enviadas al perímetro de Cloudflare se gestionan mediante scripts de Worker que se ejecutan en este dominio. Nuestra implementación se ha reescrito utilizando Javascript, con operaciones criptográficas que se ejecutan en el motor V8 que impulsa a Cloudflare Workers. Esto significa que podemos ejecutar operaciones criptográficas muy eficientes y en tiempo constante. Además de esto, nos beneficiamos con el rendimiento mejorado que se genera al ejecutar nuestro código en la plataforma Workers, lo más cerca posible del usuario.

En primer lugar, te puedes preguntar, ¿cómo logramos implementar operaciones criptográficas en Cloudflare Workers? Actualmente, el soporte para realizar operaciones criptográficas se brinda a través de la API de WebCrypto en la plataforma Workers. Esta API permite a los usuarios calcular funciones como el hash criptográfico, junto con operaciones más complicadas como las firmas ECDSA (algoritmo de firma digital de curva elíptica).

Como analizaremos más adelante, en el protocolo de Privacy Pass, las principales operaciones criptográficas se realizan mediante un protocolo conocido como función pseudoaleatoria olvidada verificable (VOPRF). Este protocolo permite a un cliente conocer las salidas de función calculadas por un servidor, sin revelar al servidor cuál fue su entrada real. El aspecto verificable significa que el servidor también debe probar (de una manera públicamente verificable) que la evaluación que pasan al usuario es correcta. Tal función es pseudoaleatoria, ya que la salida del servidor no se puede diferenciar de una secuencia aleatoria de bytes.

La función VOPRF requiere que un servidor realice operaciones ECC de bajo nivel que no están expuestas actualmente en la API de WebCrypto. Hemos compensado las posibles formas de evitar este requisito. En primer lugar, intentamos usar la API de WebCrypto de una manera no estándar, mediante el uso del intercambio de claves EC Diffie-Hellman como método para realizar la multiplicación escalar que necesitábamos. También intentamos implementar todas las operaciones usando JavaScript puro. Lamentablemente, ninguno de los métodos dio resultado, en el sentido de que no se integrarían con grandes bibliotecas criptográficas externas, o serían demasiado lentos para utilizar en una configuración de Internet eficiente.

Al final, brindamos una solución que agrega las funciones necesarias para Privacy Pass a la interfaz interna de WebCrypto en el motor Javascript V8 de Cloudflare. Este algoritmo imita la firma/verifica la interfaz que brindan los algoritmos de la firma como ECDSA. En resumen, usamos la función sign() para emitir tokens de Privacy Pass al cliente. Mientras que el servidor puede utilizar verify() para verificar los datos que canjea el cliente. Estas funciones se implementan directamente en el nivel V8, por lo tanto, son mucho más eficientes y seguras (se ejecutan en tiempo constante, por ejemplo) que las alternativas de JS (JavaScript) puro.

La interfaz WebCrypto de Privacy Pass no está disponible actualmente para uso público. Si existe el suficiente interés en usar este algoritmo adicional en la plataforma Workers, consideraremos la posibilidad de hacerlo público.

Últimamente, las VOPRF han demostrado que son funciones elementales muy útiles para crear varias herramientas criptográficas. Además de Privacy Pass, también son esenciales para desarrollar protocolos de intercambio de claves autenticadas por contraseña como OPAQUE. También se han utilizado en diseños de intersección de conjuntos privados, protocolos de intercambio de secretos protegidos por contraseña y de control de acceso con resguardo de la privacidad para el almacenamiento de datos privados.

Escribir el servidor en Cloudflare Workers significa que brindaremos asistencia del lado del servidor para Privacy Pass en un dominio público. Si bien solo emitimos tokens a los clientes después de estar seguros de que podemos confiar en ellos, cualquiera podrá intercambiar los tokens a través de nuestra API de intercambio público en https://privacypass.cloudflare.com/api/redeem. A medida que implementamos el componente del lado del servidor en todo el mundo, podrás interactuar con esta API y verificar los tokens de Privacy Pass de Cloudflareindependientemente de la extensión del navegador.

Esto significa que cualquier servicio puede aceptar los tokens de Privacy Pass de un cliente que fueron emitidos por Cloudflare y, a continuación, verificarlos con la API de intercambio de Cloudflare. Con el resultado proporcionado por la API, los servicios externos pueden comprobar si Cloudflare ha autorizado al usuario en el pasado.

Creemos que esto beneficiará a otros proveedores de servicios, ya que pueden utilizar el certificado de autorización de Cloudflare en sus propios procesos de toma de decisiones, sin sacrificar la privacidad del cliente en ningún momento del proceso. Esperamos que este ecosistema pueda crecer aún más, y que tenga más servicios que ofrezcan API de intercambio público propias. Estos certificados serán más útiles si existe un mayor y más diverso grupo de emisores.

Al ejecutar nuestro servidor en un dominio público, somos efectivamente, un cliente del producto Cloudflare Workers. Esto significa que también podemos hacer uso de Workers KV para protegernos contra clientes maliciosos. En particular, los servidores deben verificar que los clientes no estén reutilizando tokens durante la etapa de canje. El rendimiento de Workers KV en el análisis de lecturas hace que esta sea una opción obvia para brindar protección de duplicación del gasto a nivel mundial.

Si deseas utilizar la API de intercambio público, brindamos la documentación para usarla en https://privacypass.github.io/api-redeem. También brindamos algunas solicitudes y respuestas de ejemplo en el Anexo B al final de la publicación.

Estandarización y nuevas aplicaciones

Junto con el reciente trabajo de ingeniería que hemos hecho en el soporte de Privacy Pass, hemos colaborado con la comunidad en general para estandarizar la funcionalidad subyacente de VOPRF y el protocolo en sí. Si bien el proceso de estandarización de las funciones pseudoaleatorias olvidadas (OPRF) se ejecuta desde hace más de un año, las iniciativas recientes para estandarizar el protocolo de Privacy Pass han sido impulsadas por aplicaciones muy recientes que se han desarrollado en los últimos meses.

La estandarización de protocolos y funciones es una manera de ofrecer interfaces interoperables, seguras y eficientes para ejecutar protocolos en Internet. Esto facilita a los desarrolladores la escritura de sus propias implementaciones en esta funcionalidad compleja. El proceso también ofrece revisiones útiles de colegas expertos de la comunidad, lo que permite detectar mejor los riesgos de seguridad potenciales que deben mitigarse en cualquier implementación. Otro beneficio es que permite llegar a un consenso con respecto a los diseños de protocolo más confiables, escalables y eficientes para todas las aplicaciones posibles.

Las funciones pseudoaleatorias olvidadas (OPRF) son una generalización de las VOPRF que no requieren que el servidor demuestre que ha evaluado la funcionalidad correctamente. Desde julio de 2019, colaboramos en un proyecto con el Grupo de Investigación del Foro de Criptografía (CFRG) en la Fuerza de Tareas de Investigaciones de Internet (IRTF) para estandarizar un protocolo de OPRF que opera en grupos de orden prioritario. Esta es una generalización de la configuración provista por curvas elípticas. Es la misma construcción VOPRF que fue especificada originalmente por el protocolo de Privacy Pass y se basa en gran medida en el diseño del protocolo original del trabajo de Jarecki, Kiayias y Krawczyk.

Uno de los cambios recientes que hemos hecho en el proyecto es aumentar el tamaño de la clave para las operaciones OPRF en el lado del servidor. Las investigaciones actuales sugieren que es posible crear consultas específicas que pueden permitir que se filtre parte de la clave. Para las claves que brindan solo 128 bits de seguridad esto puede resultar un problema, ya que la filtración de demasiados bits reduciría la seguridad más allá de los niveles que se aceptan actualmente. Para contrarrestar esto, hemos aumentado el tamaño mínimo de la clave a 192 bits. Esto evita que esta filtración se convierta en un vector de ataque mediante la utilización de cualquier método práctico. Luego analizaremos estos ataques de manera más detallada cuando hablemos de nuestros planes futuros para el desarrollo de VOPRF.

La aplicación que presentamos cuando originalmente se admitía Privacy Pass siempre fue pensada como una prueba de concepto para el protocolo. En los últimos meses, han surgido una serie de nuevas posibilidades en ámbitos que van mucho más allá de lo previsto anteriormente.

Por ejemplo, la API del token de confianza, desarrollada por el Grupo de la Comunidad de Web Incubator, se ha propuesto como interfaz para el uso de Privacy Pass. Esta aplicación permite a terceros proveedores verificar si un usuario ha recibido una certificación de confianza de un conjunto de emisores centrales. Esto permite que el proveedor tome decisiones con respecto a la honestidad de un cliente sin tener que asociar un perfil de conducta con la identidad del usuario. El objetivo es evitar la actividad fraudulenta de los usuarios en quienes el conjunto de emisores centrales no confía. Resultaría posible verificar las certificaciones de confianza con los emisores centrales mediante API de canje similares a las que hemos presentado.

Un trabajo independiente de Facebook describe una aplicación similar para prevenir comportamientos fraudulentos que también pueden ser compatibles con el protocolo de Privacy Pass. Por último, han surgido otras aplicaciones en las áreas que brindan acceso a almacenamiento privado y establecen modelos de seguridad y privacidad en confirmaciones de publicidad.

Teniendo en cuenta las aplicaciones anteriores, hemos comenzado recientemente un trabajo colaborativo en un nuevo proyecto de IETF, que establece específicamente la funcionalidad requerida que proporciona el protocolo de Privacy Pass en su totalidad. Nuestro objetivo es desarrollar, junto con más socios industriales y la comunidad académica, una especificación del funcionamiento del protocolo de Privacy Pass. Esperamos que con esto podamos diseñar un protocolo de la capa base, que luego se pueda utilizar como unidad criptográfica básica en aplicaciones más generales que requieren algún tipo de autorización menos estricta. Nuestro plan es presentar la primera versión de este proyecto en la próxima reunión 106 de IETF en Singapur el mes próximo.

El proyecto aún está en las primeras etapas de desarrollo y estamos buscando personas interesadas en ayudar a conformar la especificación del protocolo. Agradeceremos toda ayuda que contribuya a este proceso. Consulta el repositorio de GitHub para obtener la versión actual del documento.

Posibilidades futuras

Por último, mientras trabajamos activamente para abrir diversos caminos en el presente, las direcciones futuras para el proyecto siguen abiertas. Creemos que hay muchas aplicaciones que aún no hemos considerado y nos llena de entusiasmo pensar dónde se utilizará el protocolo en el futuro. Estas son algunas otras ideas que tenemos para aplicaciones y propiedades de seguridad novedosas que creemos que vale la pena considerar en el futuro.

Una de las desventajas del uso de VOPRF es que los tokens de canje solo pueden ser verificados por el servidor emisor original. Si usamos una unidad básica subyacente que permitía la verificación pública de tokens de canje, cualquiera podría verificar que el servidor emisor había emitido un token en particular. Este protocolo podría construirse sobre esquemas de firma ciega, tales como Blind RSA. Lamentablemente, hay problemas de rendimiento y de seguridad que surgen a partir del uso de esquemas de firma ciega en el entorno de un navegador. Los esquemas actuales (especialmente las variantes basadas en RSA) requieren cálculos criptográficos que son mucho más pesados que la construcción utilizada en nuestro protocolo de VOPRF.

Las únicas construcciones de VOPRF existen en entornos precuánticos, generalmente, en función de la dificultad de problemas conocidos en configuraciones de grupo como la suposición de registro discreto. Las construcciones de VOPRF no brindan seguridad contra adversarios que puedan ejecutaralgoritmos computacionales cuánticos. Esto significa que el protocolo de Privacy Pass solo es seguro contra los adversarios que se ejecutan en hardware clásico.

Los desarrollos recientes sugieren que la informática cuántica puede llegar antes de lo que se pensaba. Por lo tanto, creemos que investigar la posibilidad de construir alternativas prácticas postcuánticas para nuestro kit de herramientas criptográficas actual es una tarea de suma importancia para nosotros y para la comunidad en general. En este caso, el diseño de alternativas postcuánticas efectivas para construcciones VOPRF sería un avance teórico importante. Finalmente, esto permitiría lograr un protocolo de Privacy Pass que brinda autorización y a la vez preserva la privacidad en un mundo postcuántico.

Hemos mencionado anteriormente que las VOPRF (o simplemente OPRF) pueden permitir que se filtre parte de la clave. Aquí ofreceremos una breve descripción de los ataques reales, junto con más detalles sobre nuestros planes para implementar conjuntos de cifrado de mayor seguridad para mitigar la filtración.

Concretamente, los clientes con malas intenciones pueden interactuar con una VOPRF para crear algo que se conoce como una muestra de q-Strong-Diffie-Hellman (q-sDH). Estas muestras se crean en grupos matemáticos (por lo general, en la configuración de la curva elíptica). Para cualquier grupo, hay un elemento g público que resulta central para todas las operaciones de tipo Diffie-Hellman, junto con la clave de servidor K, que normalmente se interpreta como un número generado de manera aleatoria desde este grupo. Una muestra A q-sDH tiene la siguiente forma:

( g, g^K, g^(K^2), … , g^(K^q) )

( g, g^K, g^(K^2), … , g^(K^q) )

y solicita al adversario con malas intenciones que cree un par de elementos satisfactorios (g^(1/(s+K)),s). Es posible que un cliente cree una muestra q-SDH en el protocolo de VOPFR con solo enviar el resultado de la evaluación VOPRF anterior nuevamente al servidor.

Si bien se cree que este problema es difícil de resolver, hay una serie de trabajos realizados que muestran que el problema es bastante más fácil que lo que sugiere el tamaño del grupo (por ejemplo, consultar aquí y aquí). En concreto, la seguridad de bits que sugiere el grupo se puede ver reducida hasta un registro2de (q) bits. Si bien esto no resulta fatal de manera inmediata, incluso para grupos que deben proporcionar 128 bits de seguridad, puede ocasionar una pérdida de seguridad que significa que la configuración ya no estaría preparada para el futuro. Como consecuencia, todo grupo que brinde la funcionalidad VOPRF que se instancie mediante una curva elíptica como P-256 o Curva25519 ofrece garantías de seguridad más débiles que las aconsejadas.

Teniendo en cuenta esto, recientemente hemos tomado la decisión de actualizar los conjuntos de cifrado que recomendamos para el uso de OPRF a solo aquellos que brindan > 128 bits de seguridad, de manera estándar. Por ejemplo, la Curva448 brinda 192 bits de seguridad. Para lanzar un ataque que redujera la seguridad a una cantidad inferior a 128 bits se necesitarían hacer consultas OPRF del cliente de 2˄ (68). Esta es una barrera significativa para la entrada de cualquier atacante, por lo que consideramos estos conjuntos de cifrado como algo seguro para instanciar la funcionalidad OPRF.

En un futuro próximo, será necesario actualizar los conjuntos de cifrado que se utilizan en nuestro soporte de la extensión del navegador de Privacy Pass según las recomendaciones en el proyecto de VOPRF actual. En general, con un proceso de la versión más iterativo, esperamos que la implementación de Privacy Pass pueda seguir más de cerca el estándar del proyecto actual a medida que evoluciona durante el proceso de estandarización.

Ahora puedes instalar v2.0 de la extensión de Privacy Pass en Chrome o Firefox.

Si deseas colaborar con el desarrollo de esta extensión, puedes hacerlo en GitHub. ¿Eres un proveedor de servicios que desea integrar el soporte del lado del servidor para la extensión? Si es así, nos interesaría mucho que te comuniques con nosotros.

Seguiremos trabajando con la comunidad en general en el desarrollo de la estandarización del protocolo; motivados por las aplicaciones disponibles que hemos desarrollado. Siempre buscamos aplicaciones nuevas que permitan ampliar el ecosistema de Privacy Pass más allá de los límites actuales.

Anexo

Aquí presentamos algunos detalles adicionales relacionados con los temas que tratamos anteriormente.

Las confirmaciones de clave son necesarias para que el servidor demuestre que está actuando honestamente durante el protocolo de Privacy Pass. Las confirmaciones que utiliza Privacy Pass para la versión v2.0 tienen un formato ligeramente diferente al de la versión anterior.

"2.00": {
  "H": "BPivZ+bqrAZzBHZtROY72/E4UGVKAanNoHL1Oteg25oTPRUkrYeVcYGfkOr425NzWOTLRfmB8cgnlUfAeN2Ikmg=",
  "expiry": "2020-01-11T10:29:10.658286752Z",
  "sig": "MEUCIQDu9xeF1q89bQuIMtGm0g8KS2srOPv+4hHjMWNVzJ92kAIgYrDKNkg3GRs9Jq5bkE/4mM7/QZInAVvwmIyg6lQZGE0="
}

En primer lugar, la versión de la clave de servidor es 2.00, el servidor debe informar al cliente qué versión piensa utilizar en la respuesta a un cliente que contiene tokens emitidos. Esto se hace para que el cliente siempre pueda usar las confirmaciones correctas al verificar la prueba de conocimiento cero que envía el servidor.

El valor del miembro H es la confirmación de la clave pública para la clave secreta que utiliza el servidor. Se trata del punto de curva elíptica codificado en base64 de la forma H=kG donde G es el generador fijo de la curva, y k es la clave secreta del servidor. Como se cree que el problema del registro discreto es difícil de resolver, se cree que derivar k de H es difícil. El valor de vencimiento del miembro es una fecha de vencimiento para la confirmación que se utiliza. El valor de la firma del miembro es una firma ECDSA evaluada mediante una clave de firma a largo plazo asociada con el servidor y los valores de H y expiración.

Cuando un cliente recupera la confirmación, verifica que no haya vencido y que se compruebe la firma mediante la clave de verificación correspondiente que está integrada en la configuración de la extensión. Si estas comprobaciones se aprueban, recupera H y verifica la respuesta de emisión enviada por el servidor. Las versiones anteriores de estas confirmaciones no incluían firmas, pero estas firmas se validarán a partir de v2.0.

Cuando un servidor desea rotar la clave, simplemente genera una nueva clave k2 y agrega una nueva confirmación a k2 con un nuevo identificador como 2.01. Luego puede usar k2 como secreto para las operaciones VOPRF que necesita calcular.

La API de intercambio está disponible a través de HTTPS mediante el envío de solicitudes POST a https://privacypass.cloudflare.com/api/redeem. Las solicitudes a este punto de conexión deben especificar los datos de Privacy Pass mediante el uso de la sintaxis JSON-RPC 2.0 en el cuerpo de la solicitud. Analicemos una solicitud de ejemplo:

{
  "jsonrpc": "2.0",
  "method": "redeem",
  "params": {
    "data": [
      "lB2ZEtHOK/2auhOySKoxqiHWXYaFlAIbuoHQnlFz57A=",
      "EoSetsN0eVt6ztbLcqp4Gt634aV73SDPzezpku6ky5w=",
      "eyJjdXJ2ZSI6InAyNTYiLCJoYXNoIjoic2hhMjU2IiwibWV0aG9kIjoic3d1In0="
    ],
    "bindings": [
      "string1",
      "string2"
    ],
    "compressed":"false"
  },
  "id": 1
}

En lo que se muestra arriba: params.data[0] son los datos de entrada del cliente que se utilizan para generar un token en la etapa de emisión; params.data[1] es la etiqueta HMAC que el servidor utiliza para verificar un intercambio; y params.data[2] es un objeto JSON con codificación base64 convertido a representación textual que especifica los parámetros hash a curva que utiliza el cliente. Por ejemplo, el último elemento de la matriz corresponde al objeto:

{
    curve: "p256",
    hash: "sha256",
    method: "swu",
}

Lo que especifica que el cliente ha utilizado la curva P-256, con la función hash SHA-256, y el método SSWU para aplicar la función hash a la curva. Esto permite que el servidor verifique la transacción con el conjunto de cifrado correcto. El cliente debe vincular la solicitud de intercambio con cierta información fija, que almacena como secuencias múltiples en la matriz params.bindings. Por ejemplo, podría enviar el encabezado Host de la solicitud HTTP, y la ruta HTTP que se utilizó (esto es lo que se usa en la extensión del navegador Privacy Pass). Por último, params.compressed es un valor booleano opcional (predeterminado como falso) que indica si la etiqueta HMAC se calculó con codificaciones de puntos comprimidos o sin comprimir.

Actualmente, los únicos conjuntos de cifrado admitidos son el ejemplo anterior, o el mismo excepto con el método igual al incremento para el método hash-e-incremento de función hash a una curva. Este es el método original que se utiliza en v1.0 de Privacy Pass y solo es compatible con versiones anteriores. Consulta la documentación provista para obtener más detalles.

Si se envía una solicitud a la API de intercambio y se verifica correctamente, se obtendría la siguiente respuesta.

{
  "jsonrpc": "2.0",
  "result": "success",
  "id": 1
}

Cuando se produce un error se obtiene algo similar a lo siguiente.

{
  "jsonrpc": "2.0",
  "error": {
    "message": <error-message>,
    "code": <error-code>,
  },
  "id": 1
}

Los códigos de error que proporcionamos se especifican como códigos JSON-RPC 2.0, documentamos los tipos de errores que proporcionamos en la documentación de la API.