¡Bienvenido! ¿Eres nuevo en Zcash?
La red de Zcash es joven, ¡pero evoluciona rápidamente! ¡Regístrate y nos pondremos en contacto con más información sobre cómo puedes comenzar con Zcash!

Idioma

El Diseño de la Ceremonia

Zooko Wilcox | Oct 26, 2016

Update: Read our full summary of what took place in the Zcash Parameter Generation Ceremony.

El Residuo Tóxico y Otras Formas de Falsificar Zcash

Como lo hemos mencionado en un artículo anterior del blog, las transacciones privadas en Zcash "Brote" 1.0 utilizan parámetros públicos SNARK para construir y verificar pruebas de conocimiento-cero. (Cuando actualicemos el protocolo Zcash y cambiemos las pruebas de conocimiento-cero -lo cual pretendemos hacer dentro de un año aproximadamente-, entonces tendremos que generar nuevos parámetros públicos SNARK desde cero). Generar parámetros públicos SNARK equivale básicamente a generar un par de claves pública/privada, manteniendo la clave pública y destruyendo la clave privada.

El problema es que, si un atacante pudiera obtener una copia de esa clave privada correspondiente, podría utilizarla para crear dinero Zcash falsificado. Ese es el único daño que podría hacer con ella -no podría violar la privacidad de nadie ni robar el dinero Zcash de otras personas.

Nosotros llamamos a la clave privada "el residuo tóxico", y nuestro protocolo está diseñado para asegurar que este residuo tóxico nunca llegue siguiera a existir. Imagina tener un montón de diferentes subproductos químicos en tu fábrica, cada uno de los cuales es inofensivo individualmente, pero si dejas que se mezclen todos, formarán una sustancia peligrosa difícil de manipular de una forma segura. Nuestro enfoque es mantener los productos químicos, individualmente inofensivos, separados, hasta que sean destruidos, para que el residuo tóxico no llegue siquiera a existir.

Nota importante: ¡destruir la clave privada no garantiza que sea imposible falsificar Zcash! Todas las tecnologías de divisas que han existido han sido vulnerables a las falsificaciones. Bitcoin tuvo una vez un bug que permitió a la primera persona que lo descubrió, falsificar 184 mil millones de BTC. Zcash podría llegar a tener una falla similar, sin relación alguna con el residuo tóxico de la clave privada.

Bitcoin pudo detectar este problema porque tiene una exposición pública constante de todas las transacciones. Zcash no tendrá esa habilidad. De hecho cualquier sistema que tenga una fuerte privacidad no podría detectar una tal falsificación.

Zcash no es la única en este sentido: ni en el riesgo de que pueda ser falsificada, ni en la dificultad de detectar falsificaciones. Volveremos a este punto al final de este artículo.

El Diseño de una Ceremonia Segura

Con el fin de reducir el riesgo de que un atacante se apropie del residuo tóxico, hemos desarrollado un protocolo de Computación Multi-Partes (MPC, por sus siglas en inglés) en el cual un conjunto de múltiples participantes en ubicaciones geográficas separadas construye la clave pública de manera colaborativa. Cada participante genera separadamente un fragmento de la clave pública, lo cual requiere de ellos que utilicen temporalmente un fragmento de la clave privada correspondiente. Todos ellos combinan sus fragmentos de la clave pública para generar los parámetros públicos finales, y luego cada uno de ellos elimina su fragmento de la clave privada.

Con el protocolo MPC, si se cumple que al menos uno de los participantes elimina exitosamente su fragmento de la clave privada, entonces es imposible que cualquier persona llegue a reconstruir el residuo tóxico. La única manera en que el residuo tóxico podría ser reconstruido sería que todos los participantes del protocolo fueran deshonestos o que los datos de todos ellos se vieran comprometidos.

Yo mismo, con otras cinco personas en quienes confío -tanto en que sean éticas como en que tengan buenas prácticas de seguridad de la información-, servimos como operadores y observadores en el protocolo. Llamamos a estas personas "Testigos", y llamamos a la ejecución del protocolo una "Ceremonia".

Las identidades de tres de los Testigos fueron reveladas a todos los participantes y observadores al comienzo de la Ceremonia: Andrew Miller (científico de la computación y asesor técnico de Zcash), Peter Van Valkenburgh, y un servidor.

Les dije que los nombres de sus compañeros testigos eran "Moses Spears", "Fabrice Renault" y "John Dobbertin", pero en realidad yo inventé esos nombres para ocultar temporalmente las identidades de esos otros Testigos. Hice esto para esconder sus identidades de cualquier potencial atacante que pudiera "pinchar" nuestras comunicaciones (mayormente encriptadas) o subvertir a uno de nuestros otros Testigos.

Al final de la Ceremonia, el 23 de octubre, se supo que "Moses Spears" era Derek Hinch del Grupo NCC. Habíamos contratado secretamente al Grupo NCC para que fuera uno de los operadores del Nodo de Cómputos. Nadie más que Nathan Wilcox (Director de Tecnología de ZcashCo), yo mismo y el grupo NCC teníamos conocimiento de esto. La tarea del Grupo NCC era a la vez proteger su Nodo de Cómputos durante la ceremonia (lo alojaron en sus instalaciones seguras de Austin) y realizar análisis forenses durante y después de la Ceremonia para intentar detectar si había habido algún intento de ciber-ataque contra ella. Adicionalmente, establecieron un modelo redundante del Nodo de Cómputos, que no fue utilizado en la Ceremonia propiamente, e intentaron hackearlo para ver qué tan difícil sería para un Testigo robar el fragmento de la clave privada de un Nodo de Cómputos. El Grupo NCC escribirá un informe técnico sobre lo que hicieron y observaron.

El 27 de octubre, "Fabrice Renault" reveló él mismo ser Peter Todd, desarrollador de Bitcoin Core. Peter había expresado su escepticismo sobre la Ceremonia de Generación de Parámetros de Zcash, y yo le dije que el oficiar de Testigo le daría el mejor punto de vista desde el cual escudriñarlo y criticarlo. Lo que es más importante, confío en que Peter no iría nunca a confabularse para intentar robar los fragmentos de la clave privada. Finalmente, supuse que él desplegaría fuertes y creativas defensas de la seguridad de la información. Todavía no conozco los detalles de esas defensas, ya que aún no ha publicado su informe. No le hemos pagado a Peter para que hiciera esto, aunque sí estuvimos de acuerdo en reembolsar sus gastos, tales como comprar un nuevo ordenador en una tienda cualquiera y luego destruirlo completamente un par de días más tarde.

La identidad de "John Dobbertin" no ha sido revelada todavía, y no sé aún cuándo John y yo estaremos listos para hacerlo.

Varios de los Testigos han registrado fotos, videos y/o grabaciones de audio del proceso, y hemos invitado a periodistas a observar una de las estaciones -la Estación Denver, donde yo estaba ubicado. Publicaremos estos registros tan pronto como los hayamos organizado, etiquetado y alojado, además de echar un vistazo en busca de cualquier información privada y personal que pudiéramos haber registrado accidentalmente.

El diseño de la Ceremonia que hemos escogido tiene tres defensas principales que trabajan en conjunto: Computación Multi-Partes, Air Gaps y Marcas de Evidencias, o evidence trails.

Computación Multi-Partes

El efecto de la Computación Multi-Partes es que solamente hace falta que una de estas personas elimine con éxito su fragmento de clave privada para que ganemos. Tan pronto como uno de los Testigos haya eliminado su fragmento de clave privada, el residuo tóxico no podrá jamás ser creado. Este es el punto de partida de nuestro diseño, y se ensambla bien con las otras defensas.

Air Gaps

El fragmento de clave privada de cada participante fue utilizado únicamente en una máquina con air-gap. Air-gapping significa que el ordenador está fisicamente desconectado de todas las redes.

Cada máquina fue comprada nueva, exclusivamente con este propósito, y nunca estuvo conectada a ninguna red durante toda su existencia, desde el momento en que fue comprada en la tienda por el Testigo. El Testigo removió físicamente los radios (wifi y bluetooth) del ordenador antes de encenderlo por primera vez.

Estas máquinas con air-gap fueron llamadas "Nodos de Cómputos".

El air gap eliminó la mayor parte del área de ataque que podría haber permitido a un atacante comprometer la seguridad de los Nodos de Cómputos, ya que los Nodos de Cómputos eran físicamente incapaces de enviar o recibir conexiones de red.

un Nodo de Cómputos con air-gap siendo montado

Marcas de Evidencias

Necesitábamos enviar y recibir mensajes entre los Nodos de Cómputos para poder realizar el protocolo de Computación Multi-Partes.

Cada Testigo tenía, además del Nodo de Cómputos, una máquina aparte que estaba conectada a Internet y que hemos llamado "Nodo de Red". El Nodo de Red recibía mensajes entrantes y los registraba en un disco, y luego el Testigo movía el disco a través del air-gap hacia el Nodo de Cómputos.

Esto reemplazaba el área de ataque que habíamos eliminado -la red- por un área de ataque diferente -la lectura del DVD. Nuestra intención era que la nueva área de ataque fuera más difícil de vulnerar, pero es difícil estar seguro de estas cosas. Por ejemplo, si alguien pudiera haber introducido en los discos datos creados de forma malintencionada (i.e., si ya había comprometido previamente el Nodo de Red), entonces habría sido posible vulnerar el firmware del lector DVD del Nodo de Cómputos, o habría sido posible explotar el código del espacio de usuario en el Nodo de Cómputos que leía los mensajes.

Una gran ventaja de utilizar discos ópticos append-only es que ofrecen un evidence trail, esto es, un rastro de pruebas, indeleble, de los mensajes exactos que fueron enviados durante una Ceremonia en particular. Por ejemplo, supongamos que en el futuro alguien descubre que existió un bug capaz de ser explotado en el firmware del dispositivo DVD que había sido utilizado en uno de los Nodos de Cómputos. Podemos preguntarnos entonces: bueno, es que estos mensajes introducidos en el Nodo de Cómputos han explotado este bug? Podemos inspeccionar los discos ópticos para ver si se pasó al Nodo de Cómputos algún dato que haya podido explotar tal vulnerabilidad.

Es importante que los discos ópticos no sean sobrescribibles -que sean DVD-R, no DVD-RW- porque de esa manera, incluso si un atacante hubiera tenido éxito en tomar el control del Nodo de Cómputos, eso no le otorga la posibilidad de borrar la evidencia de que lo ha hecho.

diseño de la ceremonia

Defensas Adicionales

Sumado a la tríada de defensas centrales que hemos esbozado más arriba, hemos utilizado también muchas otras técnicas adicionales para hacer más fácil nuestro trabajo de defensores y para hacer más difícil la tarea de cualquier potencial atacante. Mantuvimos en secreto los detalles de la Ceremonia -cuándo sería llevada a cabo, quiénes serían los participantes, qué código fuente ejecutaríamos, etc.- hasta después de que la Ceremonia estuviera completa... ¡hasta ahora! Utilizamos una versión de Linux con seguridad reforzada en los Nodos de Cómputos. Escribimos todo el código que necesitábamos para los cálculos computacionales y las funciones de red en Rust -un lenguaje de programación que hace que sea fácil evitar escribir los bugs de seguridad más comunes. Hicimos un hash chain seguro de todos los mensajes que fueron transmitidos, posteamos ese hash chain en Twitter y en el Internet Archive, y fue colocado con marca de tiempo en el blockchain de Bitcoin. Además de eso, cada uno de los Testigos escogió sus propias defensas locales adicionales, que iremos describiendo con más detalle en futuros documentos.

Trabajo Futuro

Nuestra tarea aún no está completa. He aquí dos pasos importantes a seguir:

Archivo de Evidencias e Inspección Independiente

Vamos a escribir más documentación explicando los detalles del protocolo y de la Ceremonia, incluyendo quiénes son los Testigos, cuándo y dónde se llevó a cabo la Ceremonia (¡seis lugares distintos!), y extensos detalles sobre el proceso. Vamos a publicar las evidencias que registramos en video, audio, imágenes y textos. También solicitamos a cada uno de los Testigos que escriban un testimonio sobre lo que han hecho y lo que han observado. Estamos trabajando duro en escribir, publicar y archivar todo este material para que cualquiera pueda inspeccionarlo.

Pienso que este material resultará extremadamente interesante para nuestros paranoicos colegas expertos de la seguridad de la información. Estoy ansioso por escuchar su evaluación de nuestras precauciones de seguridad y de lo que observamos durante la ejecución de la Ceremonia. Hasta donde sé, la Ceremonia de Generación de Parámetros de Zcash es la ceremonia criptográfica más notable y sofisticada que jamás se haya llevado a cabo!

Ya hemos comenzado este proceso publicando el código fuente del proceso de red y del proceso de cálculos computacionales. Por favor léelo y haznos saber inmediatamente si le encuentras algún fallo que lo haga vulnerable.

Una Función de Detección de Falsificaciones Propuesta para Zcash

Si bien estamos satisfechos actualmente de que el residuo tóxico de la clave privada correspondiente a los parámetros públicos de Zcash 1.0 nunca llegó a existir, y no puede llegar a existir jamás, no estoy seguro de que falsificar divisas Zcash sea imposible. Esto se debe a que, como lo escribí más arriba, podrían haber otras formas de crear monedas Zcash falsificadas, aparte de reconstruyendo el residuo tóxico de la clave privada.

Además, la gente que no tuvo la oportunidad de presenciar la Ceremonia de primera mano podría todavía tener dudas de que haya sido ejecutada honestamente y con toda seguridad. No existe de hecho ninguna manera de probar que realmente hicimos lo que dijimos que hicimos. Nos podríamos haber confabulado los seis para realizar el proceso completo -incluso registrándolo en video- como si fuera un truco de magia montado en escena, y podríamos en realidad haber copiado secretamente los fragmentos de la clave privada y haberlos combinado para formar el residuo tóxico. Escogí a los otros cinco Testigos por ser gente que yo, personalmente, confío en que nunca harían algo así, pero si no conoces a esta gente como yo los conozco, entonces podrías necesitar garantías adicionales.

Por tanto, tengo la intención de abogar por una actualización del protocolo de Zcash en el futuro -luego del lanzamiento de Zcash 1.0 "Brote"- que agregará una función de detección de falsificaciones. Esto proporcionará a todo el mundo (i.e. el público en general) la posibilidad de conocer la base monetaria total de monedas Zcash en circulación. Esto nos permitirá determinar si ha habido falsificación -ya sea explotando el residuo tóxico de la clave privada o por cualquier otro mecanismo.

Escribiré más al respecto en un futuro artículo del blog.

Conclusiones

Hemos realizado una hazaña notable de ingeniería criptográfica y de seguridad de la información para poder generar parámetros públicos SNARK para Zcash 1.0 "Brote". El diseño general de esta Ceremonia se basó en la Computación Multi-Partes, air-gaps y marcas indelebles de evidencias. Seis diferentes personas formaron cada uno una parte de la Ceremonia. La Computación Multi-Partes asegura que incluso si los otros cinco, todos ellos, se vieran comprometidos, o estuvieran complotando secretamente para intentar reconstruir el residuo tóxico, alcanzaría con que un sólo Testigo, actuando honestamente, eliminara su fragmento del residuo tóxico, para que este sea irreconstruible. A pesar de la notable fuerza de esta Ceremonia, pretendo abogar por una actualización importante del protocolo de Zcash el año próximo que agregará una capa de detección a la actual capa de prevención.