por: johan
fondo
La vulnerabilidad "Bingxin" de Frozen Heart fue nombrada por el equipo de Trail of Bits, donde Frozen significa Forging Of Zero kNowledgeproofs y Heart se refiere a la transformación Fiat-Shamir, que es el núcleo de muchos sistemas de prueba. Esta vulnerabilidad se refiere al problema de seguridad que ocurre cuando se aplica una transformación "Fiat-Shamir débil", que solo codifica parte del mensaje del probador sin codificar la información pública (como parámetros, entradas públicas, etc.).
A continuación realizaremos un análisis exhaustivo de esta vulnerabilidad. Primero hablemos de qué es la transformación Fiat-Shamir.
Transformación Fiat-Shamir
La transformación Fiat-Shamir, también llamada heurística Fiat-Shamir o paradigma Fiat-Shamir, es una transformación propuesta por Fiat y Shamir en 1986 para transformar protocolos interactivos de prueba de conocimiento cero en protocolos no interactivos de prueba de conocimiento cero. Logra esta transformación reemplazando desafíos aleatorios en el protocolo con la salida de una función hash. De esta manera, el probador puede generar una prueba y enviarla al verificador sin desafío ni respuesta interactivos.
La prueba de Schnorr es un protocolo interactivo de prueba de conocimiento cero que permite al probador demostrarle al verificador que una determinada afirmación es verdadera sin revelar los detalles de la afirmación, y el verificador puede realizar una verificación interactiva. Normalmente se utiliza cuando el probador conoce un valor secreto pero no lo revela.
Las pruebas interactivas de Schnorr se pueden transformar en no interactivas mediante la transformación Fiat-Shamir.
Schnorr se puede implementar en campos finitos o curvas elípticas (EC). Las especificaciones técnicas son básicamente las mismas, solo el grupo cíclico subyacente es diferente. A continuación describimos principalmente estos dos procesos en forma de campos finitos [1]:
* Descripción del símbolo:
Alice: la identidad asumida del probador en el protocolo
Bob: La identidad asumida del validador en el protocolo.
a | b: a divide b
a || b: conexión entre a y b
[a, b]: rango de números enteros, incluidos a y b
t: El número de bits en el desafío seleccionado por Bob
H: función hash criptográfica segura
p: un número primo grande
q: un factor primo grande de p-1, es decir, q | p-1
Zp*: grupo multiplicativo de números enteros módulo p
Gq: un subgrupo de Zp* con orden primo q
g: generador de Gq
g^d: g elevado a la potencia d
un mod b: un módulo b
Fp: un cuerpo finito de p elementos, donde p es un número primo
Implementación basada en campos finitos.
1. Interactivo
Primero, Alice calcula A = g^a mod p, donde la clave privada a toma el valor [0, q-1] y luego revela la clave pública A;
Luego, Alice le demuestra a Bob que conoce la clave privada a correspondiente a A sin revelar a:
Si la verificación es verdadera, se puede demostrar que Alice conoce a. El principio es el siguiente:
La razón por la que Bob necesita generar una c aleatoria aquí es porque si el atacante conoce este valor antes de revelar A, entonces puede falsificar la prueba sin conocer la a real. El atacante falsifica (A, V, r) de la siguiente manera:
1) Generar un valor aleatorio r
2) El método de cálculo de V permanece sin cambios, sea
Después de que Verifier reciba estos tres parámetros y los sustituya en la fórmula de verificación, podrá pasar la verificación. Pero prestemos atención al proceso de generación de algunos parámetros, que no tienen nada que ver con el valor secreto a a demostrar.
2. No interactivo
La transformación no interactiva también es muy fácil. Sobre la base de lo interactivo, cambie el proceso de Bob de generar c aleatoriamente a la forma Hash de parámetros:
Implementación basada en curvas elípticas.
Primero, Alice calcula A = G x [a], donde la clave privada a toma el valor [0, n-1], y luego revela la clave pública A;
Luego, Alice le demuestra a Bob que conoce la clave privada a correspondiente a A sin revelar a:
Si la verificación es verdadera, se puede demostrar que Alice conoce a. El principio es el siguiente:
El método de implementación no interactivo es el mismo que el método de implementación basado en campos finitos mencionado anteriormente y no se describirá en detalle.
Transformada débil de Fiat-Shamir
En el proceso de implementación no interactivo anterior, números aleatorios:
Es una forma correcta y segura de generar, pero desafortunadamente, en algunos de los primeros artículos, este proceso no se describía estrictamente, sino que simplemente se describía como:
Hay un problema de seguridad, lo llamamos la transformación débil Fiat-Shamir, que puede usarse para falsificar la prueba y engañar al verificador precalculando A.
Reconstruya los parámetros (A, r) usando:
1. Generar un valor aleatorio
2. Calcule a = (v-r) / c, el método de cálculo permanece sin cambios
3. Cálculo
Podemos ver que A se convierte en un parámetro que no tiene nada que ver con a y se sustituye en la ecuación de verificación:
puede ser igual a V .
Esto significa que un atacante puede pasar la verificación del protocolo sin conocer el valor secreto.
También hay algunos artículos [3] que describen este proceso de la siguiente manera:
El contenido expresado es el mismo.
laguna jurídica de Bingxin
El equipo de Trail of Bits ha publicado un artículo [2] señalando que la implementación de Fiat-Sharmir en sistemas ZKP como Bulletproofs y Plonk tiene vulnerabilidades que permiten a usuarios malintencionados falsificar pruebas de declaraciones aleatorias.
Tomando a Plonk como ejemplo, el algoritmo Fiat-Shamir se utiliza para generar números aleatorios en las Rondas 2, 3, 4 y 5 generados por la prueba.
En el artículo [3], se investigaron muchas implementaciones de código abierto de sistemas modernos a prueba de conocimiento cero y se encontró que 36 usaban transformaciones débiles de Fiat-Shamir, incluidos Bulletproofs, Plonk, Spartan y Wesolowski's VDF, etc. Un atacante puede generar una prueba que pase la verificación sin conocer el secreto de prueba válido.
Ejemplo de vulnerabilidad
1. rechinar
Aquí fs es una instancia de cálculo de Fiat-Shamir. Cuando la prueba Round2 calcula el parámetro z (X), la información de la prueba se puede falsificar porque la entrada pública no está vinculada al desafío.
2. snarkjs
Además, debido a que publicSignals no está incluido, la información de certificación puede falsificarse.
Resumir
Del contenido revelado, podemos ver la versatilidad y amplitud de esta vulnerabilidad. Causará graves daños a las pruebas de conocimiento cero. En aplicaciones prácticas, debemos prestar atención para revisar la exactitud de la implementación de Fiat-Shamir y agregar datos de testigos públicos. Durante la generación de números aleatorios, el atacante puede evitar falsificar pruebas.
Finalmente, nos gustaría agradecer a Safeheron, un proveedor líder de servicios integrales de autocustodia de activos digitales, por brindar asesoramiento técnico profesional.
Documentos de referencia:
[1]. https://datatracker.ietf.org/doc/html/rfc8235
[2]. https://blog.trailofbits.com/2022/04/13/part-1-coordinated-disclosure-of-vulnerabilities-affecting-girault-bulletproofs-and-plonk/
[3]. https://eprint.iacr.org/2023/691.pdf