Escrito por: Noemí Glaeser, cripto a16z

Escrito por: Chris, Noticias Techub

En la criptografía de clave pública, siempre ha habido un problema difícil: cómo asociar correctamente una clave de cifrado (como una clave pública) con una identidad específica (como una persona u organización). La clave de este problema es tener una forma pública y consistente de mostrar la relación entre identidades y claves públicas para que todos puedan usar con confianza esas claves públicas para cifrar información.

Sin una relación tan clara, es posible que otros no puedan determinar a quién pertenece una determinada clave pública y pueden enviar información cifrada a la persona equivocada, lo que provocará una fuga de información u otras consecuencias graves. En Web3, este problema todavía existe.

Actualmente existen tres soluciones a los problemas anteriores: directorio de claves públicas, cifrado basado en identidad (IBE) y cifrado basado en registro (RBE). Cada uno de estos tres métodos tiene sus propias ventajas en cuanto a anonimato, interactividad y eficiencia. Por ejemplo, la EBI requiere una base sólida de confianza, pero en algunos casos funciona mejor en términos de anonimato y eficiencia. Este artículo tiene como objetivo explorar la aplicación de estos tres métodos en blockchain y comparar sus ventajas y desventajas.

tres métodos

En términos generales, la forma común de asociar claves de cifrado con información de identidad es utilizar una infraestructura de clave pública (PKI), cuya parte principal es un directorio de claves públicas. En este método, la persona que envía el mensaje necesita interactuar con un tercero de confianza (es decir, la autoridad que mantiene este directorio, normalmente una autoridad certificadora) para poder enviar el mensaje cifrado.

Sin embargo, en un entorno Web2, mantener este directorio de clave pública requiere altos costos y operaciones engorrosas. Además, los usuarios están expuestos al riesgo de posibles abusos por parte de las autoridades certificadoras.

Algunas alternativas propuestas por los criptógrafos para solucionar problemas con la infraestructura de clave pública (PKI). En 1984, Adi Shamir propuso el cifrado basado en identidad (IBE), en el que la identidad de una parte (como un número de teléfono, correo electrónico o nombre de dominio ENS) se puede utilizar directamente como clave pública. Este enfoque elimina la necesidad de mantener un directorio de claves públicas, pero introduce un nuevo problema: tener que depender de un tercero confiable (el generador de claves) para generar la clave privada.

En 2001, Dan Boneh y Matthew Franklin propusieron la primera construcción práctica de IBE, pero esta tecnología no ha sido ampliamente adoptada y se utiliza principalmente en algunos ecosistemas cerrados, como entornos de implementación empresarial o gubernamental. Una de las razones por las que IBE no se utiliza ampliamente puede ser que se basa en un fuerte supuesto de confianza, es decir, confiar en las claves generadas por un tercero.

Sin embargo, como se analizará más adelante en este artículo, este problema de confianza se puede resolver confiando en una única parte confiable (es decir, un quórum de un grupo de participantes), lo que la tecnología blockchain puede lograr fácilmente.

Ventajas y desventajas

Hay muchos factores diferentes a considerar al comparar estos esquemas de cifrado, y haré dos suposiciones al respecto:

Los usuarios no actualizan ni revocan sus claves: esto significa que la discusión asume que la clave de cada usuario es fija y no puede cambiar.

El contrato inteligente no utiliza ningún servicio de disponibilidad de datos (DAS) fuera de la cadena ni datos de blobs: es decir, se supone que el contrato inteligente se basa completamente en datos dentro de la cadena y no implica servicios de datos fuera de la cadena ni almacenamiento de datos adicional. .

Directorio de claves públicas

Cualquiera puede transferir una identificación que no esté ocupada por otros llamando al contrato inteligente.

(DNI, orden de compra)

Las entradas se agregan al directorio en cadena.

PKI descentralizada se refiere al mantenimiento de un directorio de identidades (ID) y sus correspondientes claves públicas a través de contratos inteligentes. Este directorio es público y no depende de terceros centralizados. Por ejemplo, tomando ENS como ejemplo, mantiene una relación de mapeo entre un nombre de dominio (es decir, identidad) y metadatos relacionados, incluidas las direcciones resueltas por el nombre de dominio (las claves públicas se pueden derivar de transacciones en estas direcciones). ENS es un sistema más complejo que no sólo registra claves públicas sino que también almacena otros metadatos. La función de la PKI descentralizada es relativamente simple: el contrato inteligente solo necesita mantener una lista y registrar la clave pública correspondiente a cada identidad.

Cuando un usuario desea registrar una identidad, primero necesita generar un par de claves (clave pública y clave privada), o usar el par de claves ya generado para enviar su ID de identidad y clave pública al contrato inteligente (posiblemente también pagando A). cierta tarifa), el contrato inteligente verificará si esta identificación ha sido registrada por otra persona. Si no está ocupado, el contrato inteligente agregará la ID y la clave pública al directorio. Una vez que se completa el registro, cualquiera puede obtener la clave pública correspondiente a una identificación solicitando al contrato inteligente que envíe un mensaje cifrado al usuario si el remitente ha cifrado el mensaje al usuario antes y ya tiene la clave pública del usuario. , no es necesario volver a solicitar la clave pública del contrato inteligente. Después de tener la clave pública, el remitente puede usarla para cifrar el mensaje como de costumbre y luego enviar el mensaje cifrado al receptor. El receptor usa la clave privada correspondiente para descifrar el mensaje y restaurar el texto original.

Veamos los pros y los contras de este enfoque:

Ventajas Desventajas Descifrado no interactivo: el proceso de descifrado no requiere interacción con otras partes y el descifrador puede completar el descifrado de forma independiente. No es conciso: es posible que el sistema no sea lo suficientemente simple en algunos aspectos, lo que puede significar una mayor complejidad, un mayor volumen de datos o requerir más recursos. Transparencia: un sistema puede ser transparente en algunos aspectos, lo que significa que las operaciones son públicas y pueden ser examinadas. Cifrado interactivo: el proceso de cifrado puede requerir cierta interacción con otras partes, lo que añade complejidad. Cualquier ID: los usuarios son libres de elegir o utilizar cualquier ID de identidad sin estar restringidos por formatos o reglas específicos. El remitente no es anónimo: es posible que la identidad del remitente no permanezca completamente anónima dentro del sistema.

Cifrado basado en identidad (IBE)

La identidad de un usuario está representada por su clave pública, lo que significa que la clave pública no sólo se utiliza para el cifrado sino que también sirve como identificador único para el usuario. Pero este enfoque depende de uno o más terceros de confianza que son responsables de generar y emitir claves. Además, estos terceros deben mantener una clave maestra durante toda la vida útil del sistema, que en algunos casos puede usarse para descifrado u otras operaciones importantes.

En el sistema IBE, los usuarios no generan ellos mismos un par de claves públicas y privadas como en los sistemas de cifrado tradicionales. En cambio, los usuarios deben registrarse en un generador de claves confiable. El generador de claves contiene un par de claves maestras (incluida la clave privada maestra msk y la clave pública maestra mpk). Cuando un usuario proporciona su ID, el generador de claves utiliza la clave privada maestra msk y la ID del usuario para calcular una clave privada única para ese usuario. La clave privada generada debe entregarse al usuario a través de un canal seguro. En términos generales, se utiliza un protocolo de intercambio de claves para establecer este canal seguro.

Para el remitente, el sistema IBE simplifica el proceso de cifrado. El remitente solo necesita descargar la clave pública maestra (mpk) del generador de claves una vez y luego puede usar la identificación para cifrar el mensaje. El descifrado también es sencillo para el destinatario. Los usuarios registrados pueden descifrar el texto cifrado recibido utilizando la clave privada que les proporciona el generador de claves.

La clave privada maestra (msk) del generador de claves debe conservarse a largo plazo porque necesita generar continuamente nuevas claves privadas de usuario mientras el sistema está en ejecución. Esto es diferente de algunos sistemas SNARK, que se generan durante la configuración confiable pero pueden destruirse una vez completada la configuración. En el sistema IBE, la clave privada maestra no se puede eliminar después de la inicialización como en SNARK.

Incluso si la clave privada maestra (msk) se conserva correctamente, cada usuario registrado aún debe confiar en que el generador de claves no leerá sus mensajes. Esto se debe a que el generador de claves puede conservar una copia de la clave privada del usuario en cualquier momento o recalcular la clave privada del usuario utilizando la clave privada maestra.

También es posible que un generador de claves proporcione a un usuario una clave privada problemática o restringida que puede descifrar la mayoría de los mensajes, pero no puede descifrar ciertos mensajes para los que el generador de claves está programado. Esto significa que el generador de claves tiene la capacidad de manipular las capacidades de descifrado del usuario, ejerciendo así potencialmente algún grado de control o restricción sobre las comunicaciones del usuario.

Pros Contras El almacenamiento en cadena es constante/mínimo: la cantidad de almacenamiento requerida por el sistema en la cadena de bloques es pequeña o constante y no aumenta con el tiempo. Supuesto de confianza fuerte: el sistema depende de uno o más terceros confiables, lo que significa que debe haber una confianza fuerte en estos terceros. Si estos terceros se ven comprometidos o no son confiables, la seguridad del sistema se ve comprometida. Cifrado no interactivo: el proceso de cifrado no requiere interacción con otras partes y el remitente puede completar el cifrado de forma independiente. Anonimato del remitente: el sistema puede mantener la identidad del remitente en el anonimato y proteger la privacidad. Cualquier ID: los usuarios son libres de elegir o utilizar cualquier ID de identidad sin estar restringidos por formatos o reglas específicos.

Cifrado basado en registro (RBE)

Al igual que IBE, en este sistema la identidad del usuario (como la dirección de correo electrónico o el número de teléfono) actúa directamente como su clave pública. Pero a diferencia de IBE, este sistema ya no depende de un tercero confiable ni de un conjunto de quórum para administrar las claves. En cambio, este tercero de confianza es reemplazado por un curador clave.

Discutiré una forma eficiente de construir RBE en esta parte porque, hasta donde sé, tiene una ventaja significativa sobre otras construcciones prácticas de RBE: se puede implementar en la cadena de bloques porque se basa en pares, en lugar de en celosías.

En el sistema RBE, cada usuario genera un par de claves (incluidas la clave pública y la clave privada). Los usuarios también deben calcular algunos valores de actualización (marcados con una en el diagrama) en función de su clave privada y una cadena de referencia común (CRS). Estos valores actualizados se utilizan para operaciones posteriores en el sistema. La presencia de una cadena de referencia común (CRS) significa que el sistema no está configurado completamente sin confianza. Sin embargo, el proceso de generación de CRS adopta un método de construcción llamado potencia tau. Este método de construcción se puede completar mediante cálculos colaborativos de varios participantes en la cadena. Siempre que al menos un participante sea honesto, este CRS es seguro.

El contrato inteligente está configurado para la cantidad esperada de usuarios N, que se agrupan en diferentes grupos. Cuando los usuarios se registran en el sistema, deben enviar su ID de identidad, clave pública y valor de actualización al contrato inteligente. El contrato inteligente mantiene un conjunto de parámetros públicos pp, que son diferentes de la cadena de referencia pública (CRS) mencionada anteriormente. Puede pensar en pp como un resumen conciso de las claves públicas de todos los usuarios registrados en el sistema. Después de que el contrato inteligente recibe la solicitud de registro del usuario, verifica los valores actualizados para verificar su exactitud. Una vez que se pasa la verificación, el contrato inteligente multiplicará la clave pública del usuario en los depósitos correspondientes en las páginas. Este paso equivale a incorporar la clave pública del nuevo usuario al conjunto de parámetros públicos del sistema para su uso posterior.

En los sistemas de cifrado basado en registro (RBE), los usuarios necesitan guardar cierta información localmente, que se utiliza para ayudarles a descifrar mensajes. Esta información debe actualizarse cuando se registran nuevos usuarios en el mismo grupo que ellos. Los usuarios pueden monitorear la cadena de bloques ellos mismos para actualizar manualmente esta información, o los contratos inteligentes pueden proporcionar información de usuario registrado recientemente, y los usuarios pueden obtener estas actualizaciones regularmente para mantener actualizada su información descifrada.

En este sistema, el remitente sólo necesita hacer dos cosas:

Descargue la cadena de referencia común (CRS): solo debe descargarse una vez y no es necesario actualizarla más adelante.

Descargar parámetros públicos: el remitente necesita descargar ocasionalmente los parámetros públicos más recientes. Lo importante para el remitente es que estos parámetros públicos contengan la clave pública del destinatario, sin tener que descargar la última versión cada vez, siempre que se pueda encontrar la clave pública del destinatario.

Luego, el remitente utiliza el CRS descargado, los parámetros públicos y la identificación del destinatario para cifrar el mensaje y enviarlo al destinatario. Esto significa que el remitente no necesita actualizar los datos con frecuencia, siempre y cuando garantice que la clave pública del destinatario esté incluida en los parámetros públicos.

Cuando un usuario recibe un mensaje cifrado, primero verificará su información auxiliar almacenada localmente para ver si hay un valor que cumpla con una determinada condición (como un valor que pase una determinada verificación si el usuario no puede encontrar un valor que lo cumpla). cumple con la condición localmente, valor, lo que significa que necesitan obtener la información actualizada más reciente del contrato inteligente. Una vez que el usuario encuentra el valor de información auxiliar apropiado, puede usar este valor y su propia clave privada para descifrar el texto cifrado recibido, recuperando así. el mensaje original.

Evidentemente, este esquema es más complejo que los otros dos. Pero requiere menos almacenamiento en cadena que un directorio de claves públicas y evita la fuerte suposición de confianza de IBE.

Parámetros concisos:

  • El tamaño del parámetro almacenado en la cadena aumenta de manera sublineal con la cantidad de usuarios, que es mucho menor que la cantidad de almacenamiento requerida por el directorio de claves públicas (que crece linealmente), pero aún no es constante y, por lo tanto, no es tan bueno como IBE. (basado en identidad) en este punto sistema de cifrado).

Cifrado con cierta interactividad:

  • Al enviar un mensaje, el remitente necesita una copia de los parámetros públicos que contienen el destinatario previsto. Esto significa que el remitente necesita actualizar estos parámetros en algún momento después de que el destinatario se haya registrado, pero no necesita actualizarlos individualmente para cada destinatario, ya que una única actualización puede contener claves para varios destinatarios. En general, el envío de mensajes es más interactivo que IBE, pero menos que utilizar un directorio de clave pública.

Descifrado con cierta interactividad:

  • De manera similar al cifrado, el destinatario necesita una copia de la información auxiliar que coincida con la versión de los parámetros públicos utilizados en el cifrado. Cuando un nuevo usuario se registra en un determinado grupo, los parámetros públicos y la información auxiliar se actualizan, y el valor que puede descifrar el texto cifrado corresponde a la versión de los parámetros públicos utilizados durante el cifrado. Los usuarios pueden optar por recibir actualizaciones de información auxiliar periódicamente en lugar de hacerlo inmediatamente cada vez, a menos que falle el descifrado. A diferencia de las actualizaciones públicas de parámetros, la obtención de actualizaciones de información auxiliar con mayor frecuencia no revela información privada.

Remitente anónimo:

  • De manera similar al caso de los directorios de claves públicas, el remitente puede cifrar el mensaje de forma independiente (siempre que tenga los parámetros más recientes) sin necesidad de consultar información específica sobre el destinatario. Cuando el remitente necesita leer información de la cadena, la información es irrelevante para el destinatario previsto (a menos que el remitente solo solicite un conjunto específico de puntuaciones de parámetros, lo que puede filtrar cierta información).

Transparencia:

  • Aunque el sistema debe aprovisionarse a través de una configuración de confianza (que puede distribuirse o administrarse externamente) y generar una CRS (cadena de referencia común) corregida, una vez aprovisionado ya no depende de ningún tercero confiable o grupo de árbitros. Aunque depende de un tercero coordinador (contrato inteligente), el sistema es completamente transparente y cualquiera puede actuar como coordinador o comprobar que funciona honestamente verificando las transiciones de estado (por eso también se puede implementar como un contrato inteligente). Además, los usuarios pueden solicitar una prueba sucinta de (no) membresía para verificar si ellos mismos u otros están registrados en el sistema. Esto es diferente de los sistemas IBE, donde es difícil para un tercero confiable demostrar que no reveló en secreto la clave de descifrado (como guardar una copia secreta o filtrarla a otros). Por el contrario, el directorio de claves públicas es completamente transparente.

Recopilación de identificación restringida:

  • Aquí se describe una versión básica de la construcción RBE. Para poder determinar de forma transparente el grupo al que pertenece un ID, los ID deben tener un orden común y cierto. Los números de teléfono se pueden ordenar fácilmente, pero ordenar cadenas arbitrarias puede ser muy complejo o incluso imposible porque el número de grupos puede ser muy grande o infinito. Esto podría hacerse proporcionando un contrato separado para calcular este mapeo, o adoptando el enfoque de hash propuesto en trabajos posteriores para aliviar esta complejidad.

Destinatario anónimo:

  • Este método garantiza que el texto cifrado no revele la identidad del destinatario.