La cadena de emails intercambiados entre el equipo de Neha Narula y la IOTA Foundation en relación al episodio de un supuesto descubrimiento de colisiones en Curl (la función criptográfica utilizada por IOTA) se ha filtrado. El intercambio se compone de 83 correos y se inicia el 15 de Julio por Ethan Heilman indicando «vulnerabilidades criptográficas en Curl». El último correo data del 21 de Octubre y pertenece a Sergey Ivancheglo. Para este entonces el equipo del MIT Media Lab había dejado de responder a las solicitudes de ejemplos concretos que demostraran la vulnerabilidad señalada.
A continuación se enumeran algunas consideraciones que surgen luego de una meticulosa lectura del intercambio epistolar y el estudio de la situación.
Descargar PDF con emails filtrados
Falta de claridad y pruebas en el reporte de la vulnerabilidad
Según el correo inicial de Ethan Heilman, se han encontrado colisiones en Curl que afectan la seguridad del mecanismo utilizado para firmar digitalmente los bundles, lo cual permitiría vulnerar las firmas y hacerlas extensivas a otros Bundles no firmados originalmente por una de las partes. Esta clase de vulnerabilidad implica la posibilidad de romper la Existential Unforgeability under a Chosen Message Attack, o EU-CMA, e implica un error muy grave que podría conducir a robo de fondos.
A lo largo de los 83 correos, la Fundación y su equipo de criptógrafos (propios y externos contratados para revisar la plausibilidad del reporte) intentan obtener por parte de Ethan Heilman pruebas concretas que permitan confirmar el modo en que han logrado esto. Se invita a los creadores del reporte a Slack para discutir con más fluidez. El equipo de Neha Nerula se niega, aduciendo que tienen «Fatiga de Slack» y prefieren continuar por email, respondiendo esporádicamente y evitando aportar pruebas que demuestren lo que enuncian originalmente.
Neha Narula envía varios ejemplos de Bundles afectados por la vulnerabilidad y es corregida por Sergey Ivancheglo en cada caso debido a que se detectan bugs en su código que ella misma reconoce. La Fundación no logra un ejemplo conciso del modo en que estas colisiones comprometen el proceso de firmas digitales.
Neha: Hi Sergey, Sorry, you’re not crazy — I added a bug to my code when I started doing the trunk transaction chaining
Sergey: Hi Neha, We can’t get your bundles to be validated successfully.
Neha: (luego de enviar nuevamente bundles que no demostraban la vulnerabilidad) I apologize! That’s what I get for sending an email in a rushed fashion. Thank your for continuing to bear with me.
David: neha, the repeated bugs in your code lead to weeks of postponements, and you still have not answered even half of our questions.
A pesar de esta falta de claridad y evidencias, la Fundación decide cambiar Curl por Kekkac, debido a que ambas poseen una interface similar. Curl, ampliamente criticada por violar el principio de «Dont run your own crypto» es en realidad una implementación de Keccak, con algunas optimizaciones, con lo cual afirmar que IOTA creó su propia función criptográfica es erroneo: Curl utiliza la bien conocida sponge construction de Keccak.
Conflicto de intereses
Los cuatro miembros detrás de la investigación del MIT Media Lab tienen conflicto de intereses (COI), debido a que participan activamente en proyectos que compiten directamente con IOTA. Neha Narula se encuentra brindando soporte activo al proyecto de Lightning Network, Tadge Dryja es Co-autor del whitepaper de Lightning Networks, Madars Virza es Co-autor whitepaper de Zerocash (que utiliza su propia cripto, pero eso no parece haber llamado la atención del MIT ML). Por último, Ethan Heilman, quien encabeza el reporte sobre la vulnerabilidad en IOTA, es miembro líder en DAGLabs y participa de la Paragon Foundation. Para la fecha en que el reporte se publicó, DAGLabs estaba en medio de una ronda de Serie-A Funding. Muy conveniente …
En mayo del 2017 la Fundación IOTA contactó a Ethan Heilman para que éste auditara la función Curl que utilizaban. La respuesta fue clara y concisa: no podía realizar el trabajo porque estaba trabajando para Paragon Foundation en un proyecto de similares características. Sin embargo. Un mes más tarde Heilman envía su correo reportando la vulnerabilidad en Curl.
El COI es extensivo a Joichi Ito, director del MML, quien replicó a un post favorable a IOTA del MIT Technology Review con una fuerte crítica acerca de IOTA e inmediatamente editó la página en que clarifica sus participaciones en corporaciones e intereses financieros para quitar su participación en Helium Systems, empresa dedicada al IoT.
Profesionalismo en la divulgación de la supuesta vulnerabilidad
Desde un principio el equipo de Neha Narula recomienda cambiar Curl por otra función y dice que están pensando en publicar el reporte en dos semanas. Debido a que este tiempo no es suficiente para que IOTA reemplace su crypto y haga los test correspondientes, se establecen fechas para que la Fundación logre resolver el problema siguiendo el modelo de Responsible disclosure que promueve la divulgación de una vulnerabilidad luego de transcurrido un tiempo desde su corrección.
La Fundación cumple con las fechas pautadas para realizar el cambio, pero el reporte que Ethan Heilman le envía a Sergey está repleto de errores que éste señala. Ethan deja de responder a los correos mientras Neha Narula envía ejemplos de Bundles vulnerados que poseen errores y no pueden ser verificados por la Fundación.
En medio de este escenario, periodistas y personas del ámbito contactan a la Fundación respecto al reporte: el MIT Media Lab ha comenzado a hablar con gente acerca de la vulnerabilidad, a pesar de que las partes no se ponen de acuerdo aún en lo que el reporte sostiene y los criptografos comienzan a convencerse de que la ausencia de pruebas fehacientes por parte de Heilman significan que nunca existió realmente una vulneración del EU-CMA.
En este punto, Sergey Ivancheglo invita a Neha Narula a seguir la discusión en público debido a que «si el equipo del MML arregla todos los errores en el reporte señalados por Sergey Ivancheglo no quedará nada que publicar».
Conclusión
La Fundación se toma el reporte inicial con la seriedad que éste amerita y le da prioridad absoluta. En la medida en que el intercambio avanza no se logran evidencias concretas del modo en que las colisiones vulneran el sistema de firmas digitales en IOTA. Debido a que el MIT Media Lab publicará el reporte, aún sin haber dado pruebas fehacientes de cómo se ha arribado a la vulnerabilidad, la Fundación reemplaza su crypto para evitar el efecto que el reporte tendrá.
Ethan Heilman deja entrever la naturaleza real de su reporte en un correo del 15 de Julio de 2017:
Como participante en el concurso de funciones de hash SHA-3 que rompió una de las 51 Round-1 SHA-3 proposals y que trabajó en pruebas de seguridad para otra propuesta de SHA-3. Puedo decir con cierta autoridad que usar sponge construction y mostrar las propiedades estadísticas de la función de transformación no es suficiente para garantizar la seguridad.
Existe una sospecha de que las colisiones en Curl pueden afectar el esquema de firmas en IOTA. Sin embargo, no se demuestra en ningún momento al menos un escenario en que una Sig1 aplicada a un Msg1 pueda ser aplicada a un Msg2 vulnerando EU-CMA. La actitud inicial por parte del MIT Media Lab de no entablar un contacto más fluído a través de Slack y continuar con comunicaciones vía email que a veces dilataban por días algunas cuestiones que pudieron resolverse en pocas horas en Slack es coherente con esta hipótesis.
La simple existencia de al menos un escenario de vulneración de firmas hubiera consagrado el trabajo del equipo de Neha Nerula, dándole el tono académico y crédito por haber logrado, de hecho, el descubrimiento. Sin embargo, esta pieza fundamental falta y eso habla por sí mismo.
Por último, el modo en que la Fundación se puso a disposición del MIT Media Lab y colaboró en todos los aspectos posibles con el avance del reporte es ejemplar. A partir de determinado punto el intercambio comienza a tornarse tenso, debido a que IOTA acató la sugerencia de Heilman migrando de Curl a Kecakk (lo cual implicó una pérdida de performance) y no consigue que el equipo proporcione pruebas concretas.
