En la primera entrega aprendimos los fundamentos técnicos de los pagos silenciosos en general. Ahora es momento de observar más de cerca cómo funcionan en billeteras de hardware como la BitBox.
Recomendamos encarecidamente leer primero la primera parte, ya que esta publicación se basa en los conocimientos adquiridos allí, especialmente sobre qué son las claves privadas y públicas, y cómo funcionan los pagos silenciosos. Al igual que en la primera parte, usamos letras minúsculas para las claves privadas y mayúsculas para las claves públicas. Por ejemplo: A = a × G.
Para recapitular, cuando Alice hace un pago silencioso a Bob, la salida de transacción hacia Bob se deriva dinámicamente de la dirección de pago silenciosa de Bob y de las claves privadas de Alice:
P = B_spend + hash(input_hash × S) × G
...donde S es el secreto compartido. La billetera de hardware de Alice puede calcularlo con su clave privada a y la clave pública de Bob B_scan:
S = a × B_scan
Aquí, Alice toma B_spend y B_scan de la dirección de pago silenciosa de Bob, mientras que a es la suma de las claves privadas que utiliza en la transacción.
Crear vs. firmar transacciones
Lo primero que hay que entender es que los pagos silenciosos cambian significativamente el rol de las billeteras de hardware en el procesamiento de transacciones Bitcoin.
En los pagos tradicionales, la billetera anfitriona (el software en tu ordenador o teléfono, como la BitBoxApp) crea la transacción, y la billetera de hardware (como tu BitBox02) simplemente la verifica y la firma para aprobarla.
Con los pagos silenciosos, esto cambia. Ahora la billetera de hardware es responsable no solo de firmar la transacción, sino también de generar parte de ella, específicamente la salida de transacción hacia Bob. Esto se debe a que las claves privadas de Alice son necesarias para generar esa salida, y solo su billetera de hardware conoce esas claves.
Este cambio introduce algunos riesgos nuevos:
- Corrupción de memoria: si la billetera de hardware tiene un error o problema de memoria, podría derivar una salida incorrecta, enviando fondos a una dirección inutilizable y perdiéndolos efectivamente.
- Comportamiento malicioso: si la billetera de hardware está comprometida, podría crear una salida que dirija los fondos a un atacante en lugar de a Bob, sin que la billetera anfitriona lo note.
Este problema puede resolverse elegantemente haciendo que la billetera anfitriona verifique la corrección de la salida de pago silenciosa generada por la billetera de hardware. Esto es conceptualmente similar a anti-klepto, otro caso en el que la billetera anfitriona verifica que la billetera de hardware no se comporte maliciosamente.
Pruebas de igualdad de logaritmo discreto (DLEQ)
¿Cómo puede la billetera anfitriona verificar que la salida de pago silenciosa generada por la billetera de hardware sea correcta?
La billetera anfitriona no puede verificarlo directamente, ya que no puede recrearlo por sí sola. Necesitaría la clave privada de Alice a o la clave privada de Bob b_scan para calcular el secreto compartido S, pero no tiene acceso a ninguna de ellas.
En su lugar, usamos una herramienta criptográfica que permite a la billetera anfitriona verificar que la billetera de hardware creó correctamente la salida del pago silencioso. Esta herramienta se llama prueba de igualdad de logaritmo discreto (DLEQ).
Una prueba DLEQ permite demostrar que se usó la misma clave privada a para generar dos claves públicas diferentes, incluso cuando se usan distintos puntos de partida (llamados puntos base).
La primera clave pública es A1 = a × G, donde G es un punto base común (generador). La segunda clave pública es A2 = a × P2, donde P2 es otro punto base. La prueba garantiza que ambas claves públicas provienen de la misma clave privada a, sin revelar la clave en sí.
En términos simples, estás demostrando que se usó el mismo secreto (la clave privada a) en ambos casos, aunque los puntos base (G y P2) sean distintos.
En términos técnicos, es una prueba de que el logaritmo discreto de A respecto a la base G es el mismo que el de A2 respecto a la base P2.
Verificación de la corrección
El protocolo que permite a la billetera anfitriona verificar la corrección de la salida de pago silenciosa generada es el siguiente:
La billetera de hardware crea la salida de pago silenciosa y, junto con ella, una prueba DLEQ que demuestra que su clave privada a es el mismo secreto tanto en A = a × G como en el secreto compartido S = a × B_scan.
Dado que tanto A como S se derivan de la misma clave privada a, la prueba DLEQ garantiza que S se generó correctamente usando la clave privada de Alice.
La billetera de hardware envía la salida de pago silenciosa generada P, junto con la prueba DLEQ y el secreto compartido S, a la billetera anfitriona.
La billetera anfitriona verifica la prueba DLEQ usando tres elementos:
- La clave pública
A, como la suma de las claves públicas en las entradas de la transacción que Alice está gastando, B_scan, proveniente de la dirección de pago silenciosa, yS, proporcionado por la billetera de hardware.
Si la prueba es válida, la billetera anfitriona puede tener confianza en que S se calculó correctamente como a × B_scan, sin necesidad de conocer la clave privada a.
La billetera anfitriona puede entonces verificar la salida de pago silenciosa recalculándola de forma independiente:
P = B_spend + hash(input_hash × S) × G
Para esto, toma B_spend de la dirección de pago silenciosa, calcula input_hash de forma independiente a partir de las entradas de la transacción, y usa el S verificado.
Si la salida recalculada coincide con la que devolvió la billetera de hardware, la billetera anfitriona puede finalizar y transmitir la transacción con la seguridad de que la salida es correcta y no ha sido corrompida.
Resumen del flujo
- La billetera de hardware de Alice crea la salida del pago silencioso y demuestra que usó la clave privada correcta mediante una prueba DLEQ.
- La billetera anfitriona verifica la prueba para asegurar que el secreto compartido se calculó correctamente.
- La billetera anfitriona recalcula y verifica la salida del pago silencioso usando el secreto compartido y los valores conocidos de la transacción, y finaliza la transacción si todo es correcto.
Este enfoque garantiza que la billetera de hardware no se comporte maliciosamente ni por corrupción ni por ataques.
Implementación
La función para realizar pagos silenciosos de forma segura, incluyendo la verificación de corrección en la BitBoxApp descrita en este artículo, se lanzará próximamente en la versión 4.45 de la BitBoxApp junto con el firmware 9.21 de la BitBox02.
La BitBox02 es la primera billetera de hardware en admitir pagos silenciosos. Es difícil para otras billeteras, intercambios o servicios justificar el esfuerzo de añadir soporte si el ecosistema en general aún no los adopta. Es el clásico problema del “huevo y la gallina”. Esperamos poder contribuir a la adopción de los pagos silenciosos de esta manera.
Agradecimientos y colaboración abierta
Conocimos los pagos silenciosos en una charla de los autores del BIP, josibake y Ruben Somsen, durante la conferencia BTC Azores en 2023. El propio BIP ha recibido una cantidad impresionante de revisiones de alta calidad.
Cuando redactamos el primer borrador de implementación para la BitBox02, comencé a pensar en los riesgos mencionados arriba y publiqué un tuit exponiendo mis preocupaciones. Josie, Ruben y Andrew Toth rápidamente señalaron las pruebas DLEQ como posible solución y compartieron material muy útil sobre el tema. Solo faltaba una buena implementación revisada de DLEQ.
Cuando Andrew Toth comenzó a escribir un borrador de BIP para especificar DLEQ, el criptógrafo Tim Ruffing recordó que ya existía una implementación en la biblioteca de código secp256k1-zkp, que la BitBox02 ya utiliza. Fue aportada por jesseposner en un contexto diferente, pero resultó ser ideal también para los pagos silenciosos.
Con los vectores de prueba del BIP, esa implementación de DLEQ y una implementación de referencia útil (aunque no directamente utilizable en hardware wallets debido a sus requerimientos particulares), pudimos integrar esta función sin problemas en la BitBox.
Siempre es gratificante cuando tantas personas dedican su tiempo y esfuerzo a construir algo en código abierto, y todo encaja al final.
Muchas gracias a Josie, Ruben, Andrew y a muchos otros por ayudarnos a completar esta funcionalidad.
¿Aún no tienes una BitBox?
Mantener tus criptomonedas seguras no tiene por qué ser difícil. La billetera física BitBox02 almacena las claves privadas de tus criptomonedas offline. Así podrás gestionar tus monedas de forma segura.
La BitBox02 también viene en versión sólo Bitcoin, con un firmware radicalmente enfocado: menos código significa menos superficie de ataque, lo que mejora aún más tu seguridad cuando sólo almacenas Bitcoin.
Shift Crypto es una empresa privada con sede en Zurich, Suiza. Nuestro equipo de colaboradores de Bitcoin, expertos en criptomonedas e ingenieros de seguridad crea productos que permiten a los clientes disfrutar de un viaje sin estrés desde el nivel de principiante hasta el nivel de maestría en la gestión de criptomonedas. La BitBox02, nuestra billetera de hardware de segunda generación, permite a los usuarios almacenar, proteger y realizar transacciones con Bitcoin y otras criptomonedas con facilidad, junto con su software complementario, la BitBoxApp.