La computación multipartita firma con dos algoritmos de clave: ECDSA en secp256k1 y EdDSA en Ed25519 (próximamente). En esta página, se abordan el protocolo ECDSA de umbral, DKLS23, y los cambios que Google le hizo. Para conocer los algoritmos admitidos, consulta Blockchains admitidas.
ECDSA de umbral y DKLS23
A diferencia de otros esquemas de firma, el problema de la firma de umbral para ECDSA ha sido notoriamente difícil. Hasta 2017, la mayoría de las soluciones implicaban compensaciones severas.
En 2018, DKLS presentó la primera solución para la firma de 2 de 2 para ECDSA que solo se basaba en suposiciones criptográficas basadas en ECDSA (p.ej., no requería Paillier, RSA ni otra familia diferente de suposiciones de dureza criptográfica). La idea innovadora de este protocolo fue una forma novedosa de defender la seguridad maliciosa para un enfoque basado en MPC (los intentos anteriores de aplicar técnicas genéricas de MPC con seguridad maliciosa dieron como resultado protocolos que requerían minutos para ejecutarse en lugar de milisegundos).
Las mejoras posteriores de los mismos autores llevaron a un protocolo k-out-of-n y, finalmente, la mejora de DKLS23 llevó a un framework genérico para el ECDSA de umbral k-out-of-n de 3 rondas que capturó todos los enfoques anteriores y que identificó el enfoque de DKLS como el más eficiente en las métricas de rendimiento notables. En particular, esa versión del protocolo solo se basa en primitivas de compromiso ideal y multiplicación de dos partes. El protocolo resultante requiere milisegundos de un solo dígito de procesamiento por parte (lo que genera un orden de magnitud de aceleración en comparación con los enfoques de la competencia) y, lo que es más importante, se basa en primitivas criptográficas más simples que solo usan operaciones de curva elíptica (en contraste con las costosas operaciones homomórficas de Paillier y las costosas pruebas de rango de conocimiento cero y pruebas de formación correcta de claves criptográficas que se requieren en otros trabajos).
Varios auditores evaluaron internamente el protocolo, incluidos expertos contratados por Coinbase y otros expertos en criptografía. Doerner y Roy DR26 identificaron recientemente un error de cálculo en el análisis de seguridad del multiplicador de DKLS que requiere 22 invocaciones adicionales de OT para lograr los 120 bits de seguridad declarados. Este cambio ya se implementó. De manera similar, otros auditores externos señalaron que faltaban detalles en la descripción del protocolo con respecto a las implicaciones de la transmisión en el modelo de canal punto a punto (en particular, es importante repetir algunos parámetros de configuración para lograr un conocimiento común).
El trabajo posterior en Google sobre el protocolo ha reforzado sustancialmente la implementación, ha reducido los recursos necesarios para operar el protocolo a gran escala y ha ampliado la funcionalidad del esquema. Por ejemplo, la literatura académica no especifica la selección ni la implementación del oráculo aleatorio. Si bien es una abstracción académica útil, la implementación del oráculo aleatorio es una tarea sutil que generó varias fallas documentadas por auditorías de seguridad.
Un aspecto notable de nuestro trabajo fue desarrollar un sistema de tipos (basado en dos operaciones de generación y bifurcación, así como en el uso riguroso de sistemas de tipos para evitar la copia, el movimiento y el uso de alias de punteros a oráculos) para garantizar que cada sesión y subsesión use un oráculo aleatorio diferente.
Otra mejora importante se relaciona con la selección de identificadores de sesión y de subsesión. El modelo de UC y, por lo tanto, todos los protocolos que se demuestran seguros en ese modelo, requieren que el entorno proporcione identificadores de sesión nuevos. En la práctica, un sistema debe garantizar que el adversario no pueda infringir esta suposición, y esto suele requerir que los participantes mantengan un estado ilimitado para este propósito. Ampliamos el protocolo DKLS original con rondas adicionales para seleccionar este identificador de una manera que solo requiere un estado de tamaño constante.
En conjunto, el protocolo actualizado y reforzado sigue completando una operación de firma en decenas de milisegundos.
En términos de funcionalidad, el artículo de DKLS23 solo considera la estructura de acceso de umbral estándar de k de n. En la práctica, es posible que los clientes requieran una estructura de acceso que imite las reglas de la organización. La literatura criptográfica contiene muchos enfoques para diseñar estructuras de acceso para el uso compartido de secretos. Aquí, ampliamos el protocolo DKLS para que admita estructuras de acceso más generales que se puedan componer a partir de puertas de umbral k de n. Esto permite políticas como "2 de 3 de los siguientes grupos: (a) el cliente, (b) 2 de 10 de los oficiales de control de riesgos, (c) 2 de 3 de los líderes de los departamentos de finanzas, legal y contabilidad", etc.
En la API v1beta, defines esta estructura de acceso como la política de claves de un KeyRing, en el campo keyPolicy. Cada clave creada en el llavero de claves la usa. Una política de claves puede tener, como máximo, dos niveles: la regla de umbral raíz y las reglas de umbral que se encuentran directamente debajo de ella. Una regla de umbral en la raíz no puede contener otra regla de umbral.