https://twitter.com/kanzure/status/1145019634547978240

Ver también:

• Extracción de semillas de hardware wallets
• El futuro de las hardware wallets
• coredev.tech 2019 debate de hardware wallets

Hace algo más de un año, pasé por la clase de Jimmy Song de Programación de Blockchain. Ahí fue donde conocí a M, donde él era el asistente de enseñanza. Básicamente, se escribe una biblioteca de bitcoin en python desde cero. La API de esta librería y las clases y funcciones que usa Jimmy son muy fáciles de leer y entender. Yo estaba contento con esa API, y lo que hice después fue que quería salir de la física cuántica para trabajar en bitcoin. Empecé a escribir una biblioteca que tenía una API similar - tomé una placa de arduino y escribí una biblioteca similar que tenía las mismas características, y cosas adicionales como claves HD y algunas otras cosas. Quería hacer un monedero de hardware que fuera fácil de programar, inspirado por la clase de Jimmy. Fue entonces cuando conocí y comencé CryptoAdvance. Luego hice una versión refactorizada que no requiere dependencias de arduino, así que ahora funciona con arduino, Mbed, bare metal C, con un sistema operativo en tiempo real, etc. También planeo hacer un enlace de micropython y un enlace de rust embebido.

Hoy en día sólo estoy considerando tres carteras de hardware: Trezor, Ledger y ColdCard. Básicamente todos los demás tienen arquitecturas similares a uno de estos. Quizá sepas que Trezor utiliza un microcontrolador de propósito general, como los que se usan en los microondas o en nuestros coches. Estos están más o menos en todos los dispositivos que existen. Tomaron la decisión de usar sólo esto sin un elemento seguro por algunas razones: querían hacer la cartera de hardware completamente de código abierto y decir con seguridad lo que se está ejecutando en la cartera de hardware. No creo que no tengan ningún elemento seguro en la cartera de hardware a menos que desarrollemos un elemento seguro de código abierto. Creo que nuestra comunidad podría hacerlo realidad. Quizás podríamos cooperar con Trezor y Ledger y en algún momento desarrollar un elemento seguro basado en la arquitectura RISC-V.

Creo que necesitamos varios tipos de elementos seguros para diferentes modelos de seguridad. Quieres diversificar el riesgo. Quieres usar multisig con firmas Schnorr. Quieres diferentes dispositivos con diferentes modelos de seguridad, e idealmente cada clave debería ser almacenada con diferente hardware, y diferentes modelos de seguridad en cada uno también. ¿Cómo aparecerán las vulnerabilidades? Podría ser un protocolo mal diseñado, con suerte no tendrás un bug en eso pero a veces los monederos de hardware fallan. Podría ser una vulnerabilidad de software en la que la gente que escribió el software cometió un error, como desbordamientos o errores de implementación o algunas primitivas criptográficas no muy seguras como la fuga de información a través de un canal lateral. El hardware real puede ser vulnerable a ataques de hardware, como el glitching. Hay formas de hacer que los microcontroladores no se comporten según su especificación. También puede haber bugs de hardware, que ocurren de vez en cuando, y sólo porque el fabricante del chip también puede cometer errores - la mayoría de los chips siguen siendo diseñados no automáticamente sino por humanos. Cuando los humanos ponen transistores y optimizan esto a mano, también pueden cometer errores. También existe la posibilidad de que haya puertas traseras del gobierno, y por eso queremos un elemento seguro de código abierto.

Hace algún tiempo se habló de las instrucciones en los procesadores x86, donde básicamente, tienen un conjunto específico de instrucciones que no está documentado y no... lo llaman Apéndice H. Comparten este apéndice sólo con personas de confianza ((risas)). Sí. Estas instrucciones pueden hacer cosas raras, no sabemos exactamente qué, pero un tipo fue capaz de encontrar todas las instrucciones. Incluso fue capaz de obtener privilegios desde el nivel de usuario, no sólo a nivel de root sino a nivel de ring-2, un control completo al que ni siquiera el sistema operativo tiene acceso. Incluso si ejecuta colas, no significa que el ordenador sea apátrida. Todavía hay un montón de mierda que se ejecuta bajo el sistema operativo y que tu sistema operativo no conoce. Debes tener cuidado con eso. En los ordenadores librem, no sólo tienen PureOS sino también Qubes que puedes ejecutar y también usan el -- que también es abierto-- básicamente puedes tener... comprobar que está arrancando el tails real. La herramienta librem se llama heads not tails. Deberías mirar eso si eres particularmente paranoico.

Los ordenadores Librem tienen varias opciones. Puedes ejecutar PureOS o puedes ejecutar Qubes o Tails si lo deseas. La clave librem comprueba el cargador de arranque.

Los monederos de hardware de Ledger utilizan un elemento seguro. También tienen un microcontrolador. Hay que hablar de dos arquitecturas diferentes. Trezor sólo utiliza un MCU de propósito general. Luego tenemos ColdCard, que utiliza un MCU de propósito general y además añade un elemento seguro... yo no lo llamaría un elemento seguro, pero es un almacenamiento de claves seguro. La cosa que está disponible en el mercado, los chicos de ColdCard fueron capaces de convencer al fabricante de abrir el código de este dispositivo de almacenamiento de claves seguras. Así que esperamos saber lo que se ejecuta en los microcontroladores, pero no podemos verificarlo. Si les damos el chip, no podemos verificarlo. En teoría podríamos hacer un decapping. Con el decapado, imagina un chip y tienes algo de epoxi sobre el semiconductor y el resto del espacio son sólo cables que van dentro del dispositivo. Si quieres estudiar lo que hay dentro del microcontrolador, lo que haces es ponerlo en la cortadora láser y primero haces un agujero en el dispositivo y luego puedes poner aquí el ácido nítrico que calientas a 100 grados y disolverá todo el plástico alrededor. A continuación, tiene un agujero para el microcontrolador, entonces usted puede poner esto en un microscopio óptico o microscopio electrónico o lo que usted tiene y realmente estudiar toda la superficie allí. Hubo un ATmega que alguien decapado y todavía era capaz de correr. Hubo una charla en defcon donde los chicos mostraron cómo hacer decappers DIY. Usted podría tomar un trezor u otra cartera de hardware y lo puso en un montaje, y luego sólo hay que poner la corriente de ácido nítrico para el microcontrolador y se disuelve el plástico, pero el dispositivo en sí todavía puede funcionar. Así que mientras haces algo de criptografía ahí, puedes llegar al nivel del semiconductor y ponerlo bajo el microscopio y observar cómo funciona exactamente. Entonces, cuando el microcontrolador funciona, puedes ver cómo el plástico... no sólo con el microscopio, sino también con... como cuando un transistor pasa de 0 a 1, tiene una pequeña posibilidad de emitir un fotón. Así que puedes observar los fotones emitidos y probablemente haya alguna información sobre las llaves dada por eso. Eventualmente podrías extraer las llaves. Cortas la mayor parte del plástico y luego pones el ácido nítrico para llegar al nivel de los semiconductores. En este ejemplo, el tipo estaba mirando el buffer de entrada y salida del microcontrolador. También puedes mirar los registros individuales. Sin embargo, es ligeramente diferente para los elementos seguros o el almacenamiento seguro de claves. Hacen un esfuerzo de ingeniería en el lado del hardware para asegurarse de que no es fácil hacer ningún descifrado. Cuando la criptografía está ocurriendo en el elemento seguro, tienen ciertas regiones que son partes ficticias del microcontrolador. Así que están operando y haciendo algo, pero están tratando de engañarte sobre dónde están las claves. Tienen un montón de otras cosas interesantes allí. Si estás trabajando con chips enfocados a la seguridad, entonces es mucho más difícil determinar lo que está pasando allí. La otra cosa es que en la ColdCard el dispositivo de almacenamiento de claves es bastante antiguo, así que por eso el fabricante estaba más dispuesto a abrirlo. Si somos capaces de ver lo que se está ejecutando allí, eso significa que el atacante también será capaz de extraer nuestras claves de allí. Así que ser capaz de verificar los chips, también muestra que no es seguro para los usuarios. Así que ser capaz de verificar con decapping podría no ser una buena cosa. Así que es complicado.

Normalmente el microcontrolador pide al almacenamiento seguro que le dé la clave para trasladarla al microcontrolador principal, entonces se producen las operaciones criptográficas, y luego se borra de la memoria del microcontrolador. ¿Cómo se puede obtener esta clave del almacenamiento seguro de claves? Obviamente, tiene que autentificarse. En ColdCard, lo haces con un código PIN. ¿Cómo esperas que se comporte el monedero cuando introduces un código PIN erróneo? En Trezor, se aumenta un contador y se incrementa el retardo entre las entradas del PIN, o como en Ledger, donde tienes un número limitado de intentos de entrada antes de que tus secretos se borren. ColdCard utiliza el mecanismo de aumento de retardo. El problema es que este retardo no es aplicado por el elemento seguro sino por el microcontrolador de propósito general. Para adivinar el código PIN correcto, si eres capaz de impedir de alguna manera que el microcontrolador aumente el tiempo, entonces serías capaz de forzar el código PIN. Para comunicarse con el almacenamiento de claves, el microcontrolador tiene un secreto almacenado aquí, y siempre que utiliza el secreto para comunicarse con el almacenamiento de claves, entonces el almacenamiento de claves responderá. Si el atacante puede conseguir este secreto, entonces puede tirar el microcontrolador y usar su propio equipo con ese secreto y probar todas las combinaciones de PIN hasta que encuentre la correcta. Esto es debido a la elección que hicieron donde básicamente se puede tener cualquier cantidad de intentos para el código PIN para el elemento seguro. Este almacenamiento de claves seguras en particular tiene la opción de limitar el número de intentos de introducción del PIN. Pero el problema es que no es reseteable. Esto significa que, durante toda la vida útil del dispositivo, puedes tener un número determinado de entradas de PIN erróneas y, al llegar a este nivel, puedes tirar el dispositivo. Este es un compromiso de seguridad que hicieron. En realidad preferiría establecer este límite a, por ejemplo, 1000 códigos PIN, o 1000 intentos, y dudo que falle al introducir el código PIN 1000 veces. En el caso de la ColdCard, utilizan un buen enfoque para los códigos PIN en el que lo dividen en dos partes. Puedes usar una longitud arbitraria, pero recomiendan algo como 10 dígitos. Muestran algunas palabras de verificación, que te ayudan a verificar que el elemento seguro sigue siendo el correcto. Así que si alguien cambia tu dispositivo por otro, en un ataque de criada malvada, entonces verías que hay palabras diferentes y puedes dejar de introducir el PIN. De hecho, hubo un ataque a la tarjeta fría para forzarla. Las palabras son deterministas a partir de la primera parte de tu código PIN. Tal vez intentas varios dígitos, y luego escribes las palabras, y haces una tabla de esto, y luego cuando haces el ataque de la criada malvada, entonces pones esa tabla para que muestre la información al usuario. Tienes que hacer fuerza bruta con los primeros números del PIN y obtener esas palabras, pero las palabras posteriores son difíciles de averiguar sin conocer el código PIN.

No importa el monedero de hardware que tengas, incluso un Ledger con el mejor hardware - digamos que lo cojo y lo pongo en mi habitación y pongo un dispositivo similar allí que tiene una conectividad inalámbrica con el ordenador de un atacante, entonces es un puente al Ledger real, y puedo tener esta comunicación bidireccional y hacer un ataque man-in-the-middle. Lo que sea que muestre el Ledger real, puedo mostrarlo en este dispositivo y engañar al usuario. Puedo convertirme en el último hombre en el medio aquí. Cualquier cosa que el usuario ingrese, puedo ver lo que ingresa y conozco el código PIN y entonces puedo hacer todo. Hay dos maneras de mitigar este ataque - se puede utilizar una jaula de Faraday cada vez que está utilizando la cartera de hardware, y la segunda manera es hacer cumplir en el hardware y creo que los chicos Blockstream sugirió esto - usted tiene un cierto límite en la velocidad de la luz, por lo que no puede comunicarse más rápido que la velocidad de la derecha? Tu dispositivo está aquí. Si te estás comunicando con este dispositivo aquí, entonces puedes obligar a que la respuesta llegue en unos pocos nanosegundos. Entonces es muy poco probable que - no es posible por las leyes de la física para obtener la señal a su dispositivo real y luego volver.

¿Y si se utiliza un canal de comunicación cifrado con el monedero hardware? El atacante intenta obtener el código PIN. Sigue siendo vulnerable. En lugar de introducir el código PIN, en su lugar se utiliza un ordenador - entonces usted tiene su billetera de hardware conectado a él, y luego en la situación potencialmente comrpomised tenemos este atacante malicioso que tiene conectividad inalámbrica a la billetera de hardware real. Digamos que nuestro ordenador no está comprometido. A través de este canal encriptado, puede obtener la máscara para su código PIN, como algunos números aleatorios que debe añadir a su código PIN para introducirlo en el dispositivo. Tu MITM no sabe esto a menos que comprometa tu ordenador también. O una situación de "one-time pad". Cada vez que introduces el código PIN, introduces el código PIN más este número. Podría funcionar con un one-time pad. Cuando estás operando con tu billetera de hardware, probablemente quieras firmar una transacción en particular. Si el atacante es capaz de reemplazar esta transacción con la suya, y mostrarte tu propia transacción entonces estás jodido. Pero si la transacción se pasa encriptada al monedero hardware real, entonces él no puede reemplazarla porque sí estaría sin autentificar.

Otra forma de deshacerse del almacenamiento seguro de la clave es hacer que todo el monedero hardware sea efímero, para que te centres en guardar la semilla y la frase de contraseña y la introduzcas cada vez. El monedero hardware es entonces desechable. Puede que nunca vuelvas a usar esa cartera de hardware. Estaba pensando en esto con respecto a la generación segura de mnemónicos en un dispositivo de consumo. Si tienes un microcontrolador desechable pero todo lo demás estamos seguros de que no tiene componentes digitales ni memoria, entonces cada vez podríamos sustituir el microcontrolador por uno nuevo y el viejo simplemente lo aplastamos con un martillo. Si ya te acuerdas de la mnemotecnia, pues el PIN te desanima a recordarla. Si usas hardware desechable, y no se almacena en la bóveda, entonces cuando alguien accede a la bóveda no ve nada y no sabe cuál es tu configuración realmente.

Prefiero las mnemotecnias de 12 palabras porque son más fáciles de recordar y siguen teniendo una buena entropía, como la de 128 bits. Todavía puedo recordar las 12 palabras. Lo respaldaría con un esquema de intercambio de secretos Shamir. Tomamos nuestra mnemónica y la dividimos en partes. Si recuerdas la mnemónica, entonces no necesitas ir a recuperar tus acciones. No se requieren todas las acciones para recuperar el secreto, pero se puede configurar cuántas acciones se requieren.

Si te preocupa tu generador de números aleatorios, entonces deberías añadir entropía del usuario. Si tienes un generador de números aleatorios manipulado y estás añadiendo entropía de usuario de todos modos, la nit no importa. Los portátiles más antiguos pueden ser un problema, como las máquinas de 32 bits y los monederos podrían no soportar más CPUs de 32 bits o algo así. Si tu cartera fue escrita para python2.6.... ahora tienes que escribir algo para manejar enteros grandes, etc. Esto es un montón de bitrot en sólo 5-7 años.

En cuanto a la generación mnemotécnica fuera de línea o la generación mnemotécnica segura... usar un tablero de dardos, usar dados, ¿confías en ti mismo para generar tu entropía? Estoy pensando en algo así... tenemos verdaderos generadores de números aleatorios en las fichas; podemos pedir a las fichas los números aleatorios, luego usar esos números y luego mostrarlos al usuario. La palabra y el índice correspondiente. También sabemos que los circuitos se degradan con el tiempo, por lo que los generadores de números aleatorios podrían verse comprometidos de forma predecible basándose en las estadísticas de fallos del hardware.

Puedes tirar unos dados y luego sacar una foto. Si estoy construyendo un monedero de hardware malicioso y quiero robar tu bitcoin, esta es de lejos la forma más fácil. Tal vez el hardware es genial, pero el software que estoy ejecutando no está utilizando ese generador de números aleatorios de hardware. O tal vez hay un secreto conocido por el atacante. Esperas unos años, y entonces tienes una gran cuenta de retiro. También podrías aplicar un protocolo seguro que te permita usar un monedero de hardware aunque no confíes en él. Puedes generar una mnemotecnia con la entropía del usuario y verificar que la entropía fue efectivamente utilizada.

Si sigo siendo un fabricante malvado del monedero de hardware, y fui forzado por la comunidad a incluir este mecanismo de verificación de entropía, y también quiero gustarle a la comunidad, entonces decimos que tenemos una solución completamente airgapped con códigos QR y cámaras... y decimos que puedes usar cualquier monedero de software que quieras porque funciona con todo. Ahora tienes una configuración como esta; digamos que tienes una computadora no comprometida, sólo una billetera de hardware comprometida que fue fabricada por medios malignos. Estás preparando la transacción sin firmar aquí, la pasas a la cartera de hardware usando los códigos QR. El monedero de hardware entonces te muestra la información y verificas que todo es correcto, y lo verificas en el ordenador también. Entonces la firmas, y obtienes de vuelta la transacción firmada. Entonces obtienes una transacción de bitcoin perfectamente válida que verificas que es correcta y la difundes a la red. Es el ataque nonce. Sí, exactamente. El problema es que la firma en bitcoin tiene dos números, uno es un nonce aleatorio. Nuestro monedero hardware puede elegir un nonce derivado de forma determinista o un nonce aleatorio para cegar la clave privada. Si este nonce se elige de forma insegura, ya sea porque estás usando un mal generador de números aleatorios que no está produciendo valores uniformemente aleatorios, o porque eres malvado, entonces con sólo mirar las firmas podré obtener información sobre tu clave privada. Algo así sucedió con yubikey recientemente. Había yubikeys con certificación FIPS y estaban filtrando tus claves privadas en 3 firmas. Lo estúpido es que introdujeron la vulnerabilidad por error cuando estaban preparando su dispositivo para el proceso de certificación, que te pide que uses números aleatorios, pero en realidad no quieres usar números aleatorios: quieres usar derivación determinista de nonces porque no confías en tus números aleatorios. Puedes seguir utilizando los números aleatorios, pero deberías utilizarlos junto con la derivación determinista de nonces. Digamos que tienes tu clave privada que nadie conoce, y quieres firmar un determinado mensaje.... idealmente debería ser HMAC algo.... Esta es la forma más bonita, pero no puedes verificar que tu billetera de hardware esté realmente haciendo esto. Tendrías que conocer tu clave privada para verificar esto, y no quieres poner tu clave privada en algún otro dispositivo. Además, no quieres que tu dispositivo sea capaz de cambiar a una generación de nonce maliciosa. Quieres asegurarte de que tu monedero por hardware no puede elegir nonces aleatorios arbitrarios. Puedes forzar a la billetera de hardware a usar no sólo los números que le gustan, sino también los números que a ti te gustan.

Podrías enviar el hash del número aleatorio que vas a utilizar, de tal manera que el monedero hardware no necesita utilizar un RNG, puede utilizar un algoritmo determinista para derivar este valor R. Sería un esquema de comunicación bastante seguro en ambos casos, tanto para el software como para el hardware, pero no para ambos al mismo tiempo. Uno de ellos debería estar bien.

Actualmente, todos los monederos de hardware lo ignoran. Estoy preparando una propuesta para incluir este campo en el PSBT bip174. Nuestro monedero de hardware lo soportará definitivamente. Quiero construir un sistema en el que no sea necesario confiar demasiado en el monedero de hardware, incluso si está comprometido o si hay errores. Todas las billeteras de hardware son hackeadas de vez en cuando.

Con las llaves falsas, puedes comprobar que las firmas se generan de forma determinista y asegurarte de que así es y entonces te sientes seguro con el monedero hardware quizás. Pero el cambio de este algoritmo determinista al malicioso puede ocurrir en cualquier momento. Podría ser provocado por una actualización de hardware o alguna fase de la luna, no puedes estar seguro.

Otra solución es que se puede utilizar la generación verificable de estos nonces aleatorios, creo que esto fue propuesto por Pieter Wuille. Para esto necesitas una función hash particular que soporte pruebas de conocimiento cero de que estabas usando este algoritmo sin exponer tus claves privadas. El problema aquí es que es un cálculo muy pesado para un microcontrolador, así que probablemente no lo vas a meter en un microcontrolador.

También hay una idea sobre el uso de firma de contrato como medida contra el canal de no-cierre.

Si tienes p2sh multisig y este monedero era sólo una de las firmas, entonces incluso si era malicioso no controla todas las claves... y lo ideal es que estés usando un hardware diferente para las otras claves. El problema con la multifirma es que... bueno, Trezor lo soporta muy bien. Estoy muy contento con Trezor y la multifirma. ColdCard lanzó un firmware que soporta multisig hace un día. Ledger tiene una implementación terrible de la multifirma. Lo que esperaba del monedero es que mostrara cuando estás usando la multifirma, quieres ver tu dirección de bitcoin, y quieres ver cuál es la cantidad que realmente estás enviando o firmando? ¿Cuál es la salida de cambio? ¿Cuáles son las cantidades? Con el Ledger multisig, siempre ves dos salidas y no sabes cuál estás gastando y cuál es la dirección de cambio, si es que la hay. Con dos Ledgers en una configuración multisig, estás menos seguro que usando un solo Ledger. Si alguien quiere hacer un pull request a la aplicación bitcoin de Ledger, por favor, que lo haga. Está ahí, la gente se queja de este tema desde hace más de un año creo. Ledger no es muy bueno en la multifirma.

Sé de algunos ataques a la cadena de suministro, pero esos se basaban en que los usuarios hicieran cosas estúpidas. No conozco ningún ataque dirigido al hardware. Ahora mismo la forma más fácil de atacar la cartera de hardware de alguien es convencerle de que haga algo estúpido. Creo que por el momento no hay suficientes hackers que se dediquen a este campo. Pero el valor va a aumentar. Definitivamente ha habido ataques a monederos de software.

walletrecoveryservices.com vende algo de esto como un servicio de recuperación de carteras de hardware. El editor de la revista Wired perdió su código PIN o algo así, e hizo mucho trabajo para sacar los datos del dispositivo. Así que esto no es un ataque malicioso, pero no deja de ser un ataque.

Hay que desconfiar de los dispositivos de hardware de terceros de código cerrado sin marca. ¿Cómo se puede confiar en todo esto?

Ahora mismo puede ser más fácil conseguir criptodivisas lanzando malware o iniciando una nueva altcoin o algo así o un hard-fork de otra altcoin. Esas son las formas más fáciles. Ahora mismo es fácil apuntar a los nodos lightning y tomar el dinero allí; conoces sus direcciones públicas y cuánto dinero tienen, así que sabes que si puedes llegar al servidor entonces puedes recuperar tu costo de ataque. Así que esos objetivos son mucho más obvios y más fáciles de atacar en este punto. Hay ataques remotos más fáciles en este punto, que atacar carteras de hardware.

https://btctranscripts.com/breaking-bitcoin/2019/extracting-seeds-from-hardware-wallets/

¿Cómo funcionan los elementos de seguridad? Parece una bala de plata que lo hace todo, ¿verdad? Puedo decirle la diferencia entre los microcontroladores normales y los elementos seguros. Los microcontroladores normales están hechos para la velocidad, la eficiencia y son fáciles de desarrollar. Existen los llamados bits de seguridad que se configuran cuando se termina de programar el microcontrolador. Cuando el microcontrolador arranca, así que como te imaginarías es que debería arrancar con permisos de no-lectura-no-escritura y luego comprueba los bits de seguridad para ver si deberías ser capaz de comunicarte con él, y entonces deberías permitirle tener acceso de lectura/escritura. Pero a veces se hace al revés, donde el microcontrolador está en modo abierto para lectura-escritura y luego comprueba los bits de seguridad y luego se bloquea. Pero el problema es que si hablas con el microcontrolador antes de que sea capaz de leer esos bits, entonces podrías ser capaz de extraer un solo byte de la memoria flash del microcontrolador. Podrías seguir haciendo esto reiniciando una y otra vez; si eres rápido y el microcontrolador es lento, puedes hacer esto incluso más rápido. Creo que esto es algo a lo que Ledger hace referencia en todas sus charlas: este "ataque sin solución" a todos los microcontroladores como Trezor y otros. Creo que está relacionado con esto, porque esto es exactamente lo que está roto por diseño y no se puede arreglar sólo porque el sistema evolucionó así. No, no necesitan usar baja temperatura aquí. Sólo necesitan ser más rápidos que el microcontrolador, lo cual es fácil porque los microcontroladores utilizados en las carteras de hardware son de 200 MHz o así. Así que si usas una GPU o un ordenador moderno entonces podrías hacer algo.

¿Así que la amenaza es que se pueda leer la memoria del microcontrolador, antes de que se pueda bloquear? El problema es que se puede leer toda la memoria flash. Esto significa que aunque esté encriptada, tienes una clave en alguna parte para desencriptarla. ¿Qué se almacena en la memoria flash? ¿Qué se protege aquí? Algunos tienen claves secretas. Todos los dispositivos IoT probablemente tienen tu contraseña de wifi. Hay un montón de secretos diferentes que podrías querer proteger. La clave de descifrado podría, en teoría, estar almacenada en otro lugar. Parece que la amenaza es que el microcontrolador puede exponer los datos escritos en ellos, y tal vez usted se preocupa por eso porque son datos propietarios o un secreto o una clave privada de bitcoin en texto plano, entonces eso es un gran problema. Si tienes un microcontrolador en algún dispositivo informático que has programado... parece que esta amenaza es menos interesante. Sí, por eso la mayoría de la gente no se preocupa por el microcontrolador. En los dispositivos de consumo, normalmente la gente hace cosas aún más fáciles. Se olvidan de deshabilitar la interfaz de depuración, y entonces tienes acceso completo directo al microcontrolador con como JTAG o algo así. Así que puedes leer la memoria flash o estas otras cosas, y reprogramarlo si quieres.

También está la interfaz JTAG. También hay otro estándar, la interfaz de depuración por cable en serie (SWDI). Estas interfaces se utilizan para la depuración. Te permiten durante el desarrollo ver y controlar completamente todo el microcontrolador, puedes establecer puntos de interrupción, puedes observar la memoria, puedes disparar todos los pines alrededor del dispositivo. Puedes hacer lo que quieras usando estas interfaces. Hay una manera de desactivar esto, y eso es lo que hacen los fabricantes de carteras de hardware. O otro bit de seguridad, pero de nuevo el bit de seguridad no se comprueba en el momento del arranque, sino un poco más tarde, así que es otra condición de carrera. Ledger se olvidó de desactivar la interfaz JTAG en el microcontrolador que controla su pantalla, hace algún tiempo. Pero todavía tenían un elemento seguro, así que no fue un gran problema. Sí, deshabilitarla es una cosa de software. Todos los bits de seguridad son medidas de software. Sólo tienes que configurar las banderas de tu firmware para desactivar ciertas características.

Además, los microcontroladores como los normales, están diseñados para trabajar en ciertas condiciones. En el rango de temperatura de aquí a aquí, o el nivel de voltaje o fuente de alimentación aquí de 1,7 voltios a +- 0,2 voltios, y con una velocidad de reloj dentro de un cierto rango. ¿Qué sucede si este entorno cambia? Puedes obtener un comportamiento indefinido, que es exactamente lo que quiere el atacante. Lo que esto significa es que el microcontrolador operado más allá de esos límites podría saltarse instrucciones, hacer cálculos erróneos, puede hacer muchas cosas diferentes. También puede reiniciar. Puede saltarse instrucciones, o hacer cálculos incorrectos.

Como ejemplo, uno de los ataques a las carteras de hardware Trezor que utilizan este material fue ..... cuando conectan el Trezor a mi ordenador a través de USB, el ordenador pregunta al dispositivo ¿quién eres y en qué puedo ayudarte? ¿Qué tipo de dispositivo es usted? El Trezor dice soy Trezor modelo G por ejemplo. Entonces lo que el atacante fue capaz de hacer - incluso antes de desbloquear su cartera de hardware - como estos datos se envían a la computadora ... Trezor está básicamente comprobando cuál es la longitud que debe enviar al ordenador... Y esta longitud se calcula durante ciertas instrucciones. Si se rompe el microcontrolador en este momento, y se hace que este cálculo haga algo aleatorio, como más de los 14 bits que la cartera de hardware espera, se obtiene no sólo la información del modelo X del trezor, sino que además se podría obtener la mnemotecnia y el contenido completo de la memoria. La información del modelo se almacenaba justo al lado de la información mnemónica. Sin embargo, han arreglado esto. Ahora mismo, tienes que desbloquear el Trezor con el PIN, no envía ningún dato hasta que se desbloquea. Hay una parte no legible de la memoria que el microcontrolador no puede leer; así que si hay desbordamiento, lanzará un error y no podrá leer esos bits. Así que este es también un buen enfoque. En principio, han hecho muchas correcciones recientemente. Este fue un arreglo de software no un arreglo de hardware.

La frase mnemotécnica del monedero hardware se almacenaba en texto plano y la verificación del PIN era vulnerable a un ataque de canal lateral. Otro gran ataque para los microcontroladores son los ataques de canal lateral. Cuando los microcontroladores están comparando números, pueden filtrar información simplemente consumiendo diferentes cantidades de energía, o tomando una cantidad de tiempo ligeramente diferente para calcular algo. Trezor fue vulnerable a esto también, hace algún tiempo, en particular a la verificación del código PIN. Así que estaban verificando esto introduciendo un PIN y comparándolo con un PIN almacenado. Esta comparación estaba consumiendo diferentes ciclos, diferentes patrones estaban causando diferentes - mediante la observación de la emisión de este sidechannel desde el microcontrolador, LedgerHQ fue capaz de distinguir entre diferentes dígitos en el PIN. Construyeron un sistema de aprendizaje automático para distinguir entre los sistemas y después de probar 5 PINs diferentes, este programa fue capaz de decir su PIN real. 5 PINs todavía era factible en términos de retraso, por lo que se puede hacer en unas pocas horas. Esto también fue arreglado. Ahora los códigos PIN no se almacenan en texto plano; ahora lo utilizan para obtener una clave de descifrado que descifra la frase mnemónica. Esta forma es más agradable porque incluso si tienes un PIN erróneo, la clave de descifrado es errónea y entonces no puedes descifrar el mnemónico y no es vulnerable a ningún tipo de ataque de canal lateral.

En cuanto al hardware, hay condiciones de carrera, ataques de canal lateral, manipulación del entorno operativo e interfaces de depuración para microcontroladores. También puedes decapitarlo y dispararle con láseres o algo así, y hacer que se comporte de forma extraña. Así que esto puede ser explotado por un atacante.

Por otro lado, ¿qué hace un elemento seguro? Son similares a los microcontroladores, pero no tienen interfaces de depuración. No tienen banderas de lectura y escritura. También tienen un montón de contramedidas diferentes contra estos ataques, por ejemplo, medidas de hardware. Hay un watchdog que monitorea el voltaje en el PIN de la fuente de alimentación y tan pronto como ve que va por debajo de algún valor, dispara la alarma y puedes borrar las llaves tan pronto como veas que esto ocurre. O simplemente dejas de operar. Si ves que la tensión de alimentación está variando, simplemente dejas de operar. Si ves que la temperatura está variando demasiado, también puedes parar el funcionamiento. Puedes parar o borrar tus secretos. También está este mecanismo que permite al microcontrolador detectar si estás tratando de decapitar, como con un simple sensor de luz. Si decapitas el chip, tienes acceso al semiconductor y puedes ver que sale mucha luz y entonces detienes las operaciones. Aquí definitivamente quieres limpiar tus secretos y borrarlos todos. También utilizan un montón de técnicas interesantes contra los ataques de canal lateral. Por ejemplo, no se limitan a hacer un consumo de energía constante y una temporización constante, sino que además introducen retrasos aleatorios adicionales y ruido aleatorio en las líneas de alimentación, lo que hace cada vez más difícil que el atacante obtenga datos de ahí. Además, normalmente tienen una capacidad muy limitada de bits. Tienen un pin de alimentación, tierra, tal vez algunos más para manejar algo simple como un LED en la ColdCard o en el moderno Ledger Modelo X son realmente capaces de hablar con el controlador de pantalla para controlar la pantalla, lo que es una buena mejora en el hardware. En principio, no es muy capaz. No puedes esperar que el elemento seguro maneje una pantalla grande o que reaccione a la entrada del usuario. El botón está probablemente bien, pero definitivamente no es lo mejor.

La razón por la que el Ledger tiene una pantalla diminuta con baja resolución es porque están tratando de manejar todo desde el elemento seguro, al menos en el Ledger Model X. Anteriormente no era así, donde tenían un microcontrolador normal que hablaba con el elemento seguro donde lo desbloqueas y luego firma lo que quieras. Y luego este microcontrolador controla la pantalla. Esto fue en realidad un gran punto que fue señalado por --- ... esta arquitectura no es perfecta porque tienes este hombre en el medio que controla esta pantalla. Tienes que confiar en tu cartera de hardware tiene una pantalla de confianza, pero con esta arquitectura no puedes porque hay un hombre en el medio. Es difícil mitigar esto y averiguar cómo compensar la seguridad completa frente a la usabilidad del usuario. Espero que te hagas una idea de por qué los elementos seguros son realmente seguros.

Sin embargo, hay algunos problemas con los elementos seguros. Tienen todos estos bonitos mecanismos anti-manipulación, pero también les gusta ocultar otras cosas. La práctica común en el campo de la seguridad es que cuando cierras la fuente de tu solución de seguridad, obtienes algunos puntos extra en la certificación de seguridad como ELF 5 y otros estándares. Sólo por el hecho de cerrar la fuente de lo que escribiste o lo que hiciste, obtienes puntos extra. Ahora lo que tenemos es el problema de que no podemos averiguar realmente lo que se está ejecutando dentro de estos dispositivos. Si quieres trabajar con un elemento seguro, tienes que ser lo suficientemente grande como para hablar con estas empresas y conseguir las claves necesarias para programarlo. Y también tienes que firmar su acuerdo de no divulgación. Y sólo en ese momento te darían la documentación; y entonces el problema es que no puedes abrir el código de lo que has escrito. Como alternativa, se utiliza un elemento seguro que ejecuta un [sistema operativo de tarjetas Java] (https://en.wikipedia.org/Java_Card), por lo que es algo así como un subconjunto de Java desarrollado para la industria bancaria, porque a los banqueros les gusta Java por alguna razón. Básicamente tienen esta máquina virtual Java que puede ejecutar tu applet... así que no tienes ni idea de cómo está operando la cosa, sólo confías en ellos porque está certificada y ya ha estado ahí durante 20-30 años y sabemos que todos los institutos de investigación de seguridad están tratando muy duro de conseguir incluso un único .... y entonces puedes abrir completamente el applet de la tarjeta Java que subes al elemento seguro pero no sabes lo que se está ejecutando debajo de él. Java Card se considera un elemento seguro, sí.

Por cierto, las tarjetas Java más seguras o los elementos seguros se desarrollaron normalmente para el ... como cuando compras esta tarjeta, tienes un secreto allí que te permite ver la televisión desde una determinada cuenta. Eran muy buenos para proteger los secretos porque tenían el mismo secreto en todas partes. La señal viene del espacio o del satélite, la señal es siempre la misma. Estás obligado a usar el mismo secreto en todos los dispositivos. Esto significa que si incluso uno es hackeado, tienes televisión gratis para todos, así que pusieron mucho esfuerzo en asegurar este tipo de chip porque tan pronto como es hackeado entonces estás realmente jodido y tienes que reemplazar todos los dispositivos.

Además, hablemos de el ataque de compromiso de claves de Sony Playstation 3. Utilizan la firma ECDSA, y no se supone que todos los juegos sean gratuitos, ¿verdad? La única forma de conseguir que el juego funcione, es tener una firma adecuada en el juego, por lo que la firma de Sony. El problema es que se supone que no contrataron a un criptógrafo o a alguien decente en criptografía... implementaron un algoritmo de firma digital de forma que reutilizaban el mismo nonce una y otra vez. Es el mismo problema con las billeteras de hardware que describimos hoy. Si estás reutilizando el mismo nonce, entonces puedo extraer tu clave privada con sólo tener dos firmas tuyas. Entonces puedo obtener tu clave privada y luego puedo ejecutar cualquier juego que quiera porque tengo la clave privada de Sony. Esto fue para la Sony Playstation 2. Creo que fue el hackeo más rápido de una consola de juegos.

Restricción de la unidireccionalidad de la información. Los bits no pueden fluir hacia atrás. El único lugar en el que debería estar una clave descifrada es en una cartera de hardware en funcionamiento. Hay una implementación en python de slip39. Chris Howe contribuyó con una biblioteca slip39 en C.

Con multisig y cada clave fragmentada, ¿se pueden mezclar los fragmentos de las diferentes claves y es eso seguro?

El código qr es json -> gzip -> base64 y cabe como 80-90 salidas y está bien. Los códigos QR animados podrían molar, pero hay algunas librerías como los códigos QR de colores que te dan un empujón. Es la paquetización. ¿Se le va a pedir al usuario que muestre ciertos códigos QR en un orden determinado, o se va a negociar gráficamente entre los dispositivos? Puedes utilizar cámaras de alto contraste.

Código QR impreso... cada paquete puede decir que es 1-de-n, y a medida que lo lee, averigua cuál es, y luego averigua cuál está hecho o no hecho todavía.

Las firmas podrían agruparse en un código QR de salida más grande en el dispositivo. Así que todavía no es un gran cuello de botella. Los códigos QR empaquetados son un área interesante. Cuando se analiza el código QR del material de Christopher Allen, el código QR dice lo que dice.

Hubo algunos ataques recientes que demostraron que incluso si usted está usando un hardware seguro, no significa que esté seguro. Cuando hay un atacante que puede llegar a tu dispositivo, entonces estás en problemas y pueden hacer ataques desagradables contra el microcontrolador. Otra idea es borrar el dispositivo cada vez. Hay monederos que utilizan elementos seguros, como el monedero de hardware de Ledger.

En cuanto al hardware, es maravilloso. El equipo es fuerte en el lado del hardware. Vienen de la industria de la seguridad. Conocen la certificación de elementos seguros, saben cómo hackear microcontroladores y siguen mostrando interesantes ataques a Trezor y otros monederos aleatorios. Son extremadamente buenos en el lado del software, pero eso no significa que no puedan meter la pata en el lado del software. De hecho, ha sucedido algunas veces.

Uno de los ataques más aterradores en Ledger ocurrió a finales del año pasado, y estaba relacionado con el cambio de dirección. Cuando estás enviando dinero a alguien, lo que esperas es que tengas tus entradas y digamos que tienes las entradas de... un bitcoin, digamos, y luego tienes normalmente dos salidas, como una es para el pago y la otra es la salida de cambio. ¿Cómo verificas que esta es la dirección de cambio? Deberías ser capaz de derivar la correspondiente clave privada y la clave pública que controlará esa salida. Si obtienes la misma dirección para la salida de cambio, entonces estás seguro de que el dinero vuelve a ti. Normalmente lo que haces es proporcionar la ruta de derivación para la clave privada correspondiente, porque tenemos este árbol jerárquico determinista de claves. Así que el monedero de hardware sólo necesita saber cómo derivar la clave. Así que envías al monedero la ruta de derivación también, como la ruta de derivación bip32. Entonces la cartera de hardware puede derivar la clave correspondiente y ver exactamente esta salida será controlada por esta clave por lo que tiene la dirección correcta. .... Así que lo que Ledger hizo es que no hicieron la verificación.... sólo asumieron que si había una salida con alguna ruta de derivación, entonces es probablemente correcta. Esto significa que el atacante podría reemplazar la dirección de esta salida a cualquier dirección, sólo hay que poner cualquier ruta de derivación y todo el dinero podría ir al atacante cuando usted está enviando una pequeña cantidad de bitcoin entonces todo el cambio va al atacante. Fue revelado el año pasado, y fue descubierto por los chicos de Mycelium porque estaban trabajando en la transferencia de fondos entre diferentes cuentas en Ledger y encontraron que de alguna manera es demasiado fácil de implementar esto en Ledger por lo que algo va mal aquí y descubrieron el ataque. Se arregló, pero quién sabe cuánto tiempo estuvo el problema. Desde la perspectiva de la cartera de hardware, si alguien no me dice que es una salida de cambio o me lo demuestra, entonces debería decir que no es una salida de cambio. Este era un problema.

También hubo un problema menor, ya que no leyeron la documentación del microcontrolador. El problema era, ¿cómo verificaron el firmware que se ejecuta en este microcontrolador? Básicamente .... cuando tenemos nuestro nuevo firmware, entonces el Ledger tiene una región específica en la memoria donde hda una secuencia mágica de bytes en particular para Ledger era algún número mágico hexadecimal. Entonces ellos almacenan eso allí. Lo que sucede es que cuando se actualiza el firmware del Ledger, el Ledger primero borra esto y luego flashea el firmware y luego al final verifica si la firma de este firmware es correcta. Si la firma era generada por la llave del Ledger, entonces ellos ponían de nuevo este número mágico en el registro y entonces eras capaz de iniciar este firmware y hacer que empezara a funcionar. Suena bien, ¿verdad? Si se le proporciona una firma incorrecta, entonces estos bytes mágicos son todos ceros en el momento por lo que no se ejecutaría este firmware, sólo retrocedería al firmware anterior. El problema es que si lees la documentación del microcontrolador, ves que hay dos direcciones diferentes para acceder a esta región de memoria donde almacenan estos bytes mágicos. Una de ellas estaba completamente bloqueada a la lectura-escritura externa, de manera que si se intentaba escribir en estos registros, se fallaba porque sólo el microcontrolador podía hacerlo. Pero luego había otro que tenía acceso a la misma región de memoria y podías escribir cualquier byte allí, y entonces podías hacer que el microcontrolador ejecutara cualquier firmware que le dieras. Alguien fue capaz de jugar un juego de la serpiente en la cartera de hardware Ledger como resultado de esto. Si consigues el control de esta pantalla y de los botones, con un firmware personalizado, puedes ocultar salidas arbitrarias. Puedes engañar al usuario de diferentes maneras, porque estás controlando lo que el usuario verá cuando esté firmando. Así que creo que es un problema bastante grande. Es un problema difícil de explotar, pero sigue siendo un problema.

Otra cagada súper grave que ocurrió con Bitbox... ¿la conoces? Algunos de los monederos tienen una bonita función de monedero oculto. La idea es que si alguien coge tu billetera por hardware y te dice que por favor la desbloquees, que si no te voy a dar con una llave inglesa. Probablemente la desbloquearás, y luego gastarás el dinero al atacante porque no quieres morir. La función de monedero oculto se supone que asegura tu dinero de tal manera que también hay un monedero oculto que el atacante no conoce y sólo obtendrá una fracción de tu dinero. Usas la misma mnemotecnia pero utilizas una frase de contraseña diferente, normalmente. Los chicos de Bitbox lo hicieron de forma ligeramente diferente, y fue una mala idea reinventar el protocolo con sus propias reglas. Así que lo que hicieron fue, tienes esta clave privada maestra como un bip32 xprv. Tiene un código de cadena y la clave privada allí. Así que cuando tienes la clave pública maestra, tienes el mismo chaincode y sólo la clave pública correspondiente a esta clave privada. Dada la clave pública maestra, puedes derivar todas tus direcciones pero no gastar, y si tienes la clave privada podrías gastar. El monedero oculto usaron el mismo xpub con el mismo chaincode pero voltearon el chaincode y la clave. Así que eso significa que si tu cartera de software conoce la clave pública maestra tanto de la cartera normal como de la cartera oculta, entonces básicamente conoce tanto el chaincode como la clave privada para que puedan obtener todo tu dinero. Si usted está utilizando esta función de cartera oculta, entonces usted está jodido.

¿Se supone que el atacante no conoce la función de cartera oculta? ¿Cómo se supone que funciona? En principio, esta función de monedero oculto es cuestionable. Como atacante, seguiría golpeándote con una llave inglesa hasta que me dieras todas las carteras ocultas que tienes. Seguiría golpeándote hasta que me dieras la siguiente contraseña o la siguiente frase de paso y así sucesivamente, nunca confiarían en que no tienes una siguiente cartera. El monedero tendría que estar suficientemente financiado para que el atacante pensara que es probable que lo sea todo. También podrías hacer la carrera de reemplazo por cuota en la que quemas todo tu dinero a los mineros ((esperemos que firmes las posibilidades de cuota correctamente)). El atacante no va a dejar de atacarte físicamente. Pero todavía hay una gran diferencia entre golpear físicamente a alguien y matarlo. El asesinato parece una línea que menos gente estaría dispuesta a cruzar.

TruCrypt tenía una negación plausible en el cifrado porque podías tener varias unidades cifradas, pero no sabías cuántas había. Podría ser sospechoso que un volumen encriptado de 1 GB sólo tenga un único archivo de 10 kb... pero la idea es poner algo realmente incriminatorio junto a tus 10 BTC, y simplemente dices estoy tan avergonzado y esto haría parecer más legítimo que en realidad es tu cantidad de monedas completa.

Tener un hardware seguro no significa que no seas vulnerable a los ataques. Realmente creo que lo mejor es utilizar la multifirma.

Si estás dispuesto a esperar un retraso, puedes usar un timelock, o gastar instantáneamente con llaves multisig de 2 en 2. Usted haría cumplir en la cartera de hardware para hacer sólo estas transacciones timelock. El atacante proporciona la dirección. No importa lo que diga su monedero; en el mejor de los casos, su monedero ya lo ha bloqueado. No se puede gastar de forma que se bloquee, porque presumiblemente el atacante quiere usar su única dirección. Podrías pre-firmar la transacción y borrar tu clave privada... espero que hayas entendido bien esa tarifa.

Si puedes demostrar a un banco que obtendrás 1.000 millones de dólares dentro de un año, entonces te adelantarán el dinero. Tú consigues el uso del dinero, negocias con el atacante y le pagas un porcentaje. Pero esto entra en el tema de los seguros K&R .... También podrías usar un banco, que es 2-de-2 multisig o mi llave pero con un retraso de 6 meses. Así que esto significa que cada vez que necesites hacer una transacción, vas al banco y haces una transacción... todavía puedes recuperar tu dinero si el banco desaparece, y entonces el atacante no puede conseguir nada porque probablemente no quiera ir contigo al banco o cruzar múltiples fronteras mientras viajas por el mundo para conseguir todas tus llaves o algo así.

La mejor protección es no decir nunca a nadie cuánto bitcoin tienes.

¿Cómo se puede combinar un timelock con un tercero? Timelock con multisig está bien.

Estamos planeando añadir soporte para miniscript, que podría incluir timelocks. Pero, que yo sepa, ningún monedero de hardware aplica actualmente los timelocks.

Miniscript (o aquí) fue introducido por Pieter Wuille. No es un mapeo uno a uno de todos los posibles scripts de bitcoin, es un subconjunto de scripts de bitcoin pero cubre como el 99,99% de todos los casos de uso observados en la red hasta ahora. La idea es que describas la lógica de tu secuencia de comandos en una forma conveniente, de manera que una cartera pueda analizar esta información y averiguar qué claves o información necesita obtener para producir una clave. Esto también funciona para muchos de los scripts lightning y también para varios scripts multisig. A continuación, puede compilar esta política miniscript en bitcoin script. Entonces puede analizar y decir que esta rama es la más probable que usaré la mayor parte del tiempo, y luego ordenar las ramas en el script para hacerlo más eficientemente ejecutado en promedio en términos de sigops. Puede optimizar el script de tal manera que en realidad sus tarifas o sus datos que tiene cuando está firmando este script serán mínimos de acuerdo a sus prioridades. Así que si estás gastando principalmente con esto, entonces esto será superóptimo y esta otra rama podría ser un poco más larga.

Después de implementar miniscript, será posible utilizar timelock. Hasta entonces, necesitas algo como una raspberrypi con un firmware personalizado. Podemos tratar de implementar una característica timelock juntos mañana si todavía estará aquí.

Pieter tiene una prueba de concepto en su página web en la que puedes escribir las políticas y obtener un script de bitcoin real. No creo que tenga la demostración de ir al revés; pero se describe con muchos detalles cómo funciona todo esto. Creo que están terminando sus múltiples implementaciones en este momento y creo que está casi listo para empezar realmente. Algunos pull requests han sido fusionados para los descriptores de salida. En Bitcoin Core puedes proporcionar un descriptor de script y alimentar esto en la cartera, como si es segwit o legacy, segwit anidado o segwit nativo, etc. También puedes usar descriptores de script para monederos multifirma, ya puedes usar Bitcoin Core con los monederos de hardware existentes... todavía es un poco problemático porque necesitas ejecutar una interfaz de línea de comandos y no es súper fácil de usar y no está en la GUI todavía, pero si estás bien con las interfaces de línea de comandos y si estás dispuesto a hacer un pequeño script que lo haga por ti, entonces probablemente estés bien. Creo que la integración con Bitcoin Core es muy importante y es bueno que tengamos esto en marcha.

https://btctranscripts.com/breaking-bitcoin/2019/future-of-hardware-wallets/

Algo que podríamos hacer es coinjoin. Ahora mismo los monederos hardware sólo admiten situaciones en las que todas las entradas pertenecen a los monederos hardware. En las transacciones coinjoin, ese no es el caso. Si podemos engañar al monedero hardware para que muestre algo incorrecto, entonces podemos potencialmente robar los fondos. ¿Cómo podría el monedero hardware entender si esta entrada pertenece al monedero hardware o no? Necesita derivar la clave y comprobar si es capaz de firmar. Para ello necesita la ayuda del monedero software. El usuario necesita firmar las transacciones dos veces para este protocolo.

Es bastante normal que haya varias firmas de una transacción coinjoin en un corto período de tiempo, porque a veces el protocolo coinjoin se estanca debido a que los usuarios se caen de la red o simplemente se retrasan demasiado.

La firma de transacciones con entradas externas es complicada.

Digamos que somos un monedero malicioso. No soy un servidor de coinjoin, sino una aplicación cliente. Puedo poner dos entradas de usuario idénticas, lo que suele ser común en coinjoin, y las pones en las entradas y pones sólo una salida de usuario y luego las otras son otras salidas. ¿Cómo puede el monedero hardware decidir si la entrada pertenece al usuario o no? Ahora mismo no hay manera. Así que confiamos en que el software marque la entrada necesaria para firmar. El ataque consiste en marcar sólo una de las entradas del usuario como mía, y entonces el monedero hardware la firma y obtenemos la firma de la primera entrada. El monedero software entonces finge que la transacción de coinjoin ha fallado, y envía al monedero hardware la misma transacción pero marcando la segunda entrada como nuestra. Así que el monedero hardware no tiene forma de determinar qué entradas eran suyas. Podría hacer pruebas SPV para probar que una entrada es suya. Necesitamos una forma fiable de determinar si la entrada pertenece a la cartera de hardware o no. Trezor está trabajando en esto con achow101.

https://github.com/satoshilabs/slips/blob/slips-19-20-coinjoin-proofs/slip-0019.md

Podríamos hacer una prueba para cada entrada, y necesitamos firmar esta prueba con una clave. La idea es probar que puedes gastar y probar que... puede comprometer toda la transacción de coinjoin para probar al servidor que esto es propio, y ayuda al servidor a defenderse contra ataques de denegación de servicio porque ahora el atacante tiene que gastar sus propios UTXOs. La prueba sólo puede ser firmada por el propio monedero hardware. También tiene un identificador de transacción único.. Es sign(UTI||prueba_cuerpo, entrada_clave). No pueden tomar esta prueba y enviarla a otra ronda de coinjoin. Esta técnica demuestra que somos dueños de la entrada. El problema surge del hecho de que tenemos esta ruta de derivación loca. Utiliza la clave de identidad única, que puede ser una clave bitcoin normal con una ruta de derivación fija. El cuerpo de la prueba será HMAC(id_key, txid || vout). Esto puede ser específico de la cartera y el host puede recogerlos para UTXOs. No se puede falsificar esto porque la cartera de hardware es la única que puede generar esta prueba.

Esto podría extenderse a la agregación de claves multisig o incluso MuSig.

Podemos pedir a todos los participantes de esta transacción coinjoin que firmen un determinado mensaje con la clave privada que controla esta entrada. Así que tenemos un mensaje y una firma. La firma nos demuestra a nosotros, a todo el mundo, que el tipo que puso este mensaje controla realmente la clave privada correspondiente. Esta es la firma de la clave que controla esta entrada. En el lado del mensaje, podemos poner lo que el monedero de hardware quiera. El monedero de hardware es el tipo que puede firmar esta prueba. Es el único que controla esta clave. Así que lo que puede hacer es generar un mensaje particular que será capaz de reconocer después. Así que tomo el hash de la transacción y lo combino con mi clave fija que almaceno en mi memoria, y entonces obtengo un mensaje único que parece aleatorio pero que seré capaz de reproducir cada vez que lo vea y podré asegurarme de que fue mi entrada porque yo fui el tipo que generó esto dentro del mensaje. Una vez que proporcionamos todas estas pruebas para cada entrada, nuestro monedero de hardware puede revisar cada entrada y asegurarse de qué entradas son mías y cuáles no. Esto puede ayudar a detectar cuando la cartera de software está tratando de engañarte.

Espero que los monederos de hardware puedan hacer coinjoins muy pronto. Probablemente, Trezor lo desplegará primero porque estamos trabajando con ellos en ello.

P: ¿Cuál es el caso de uso de esto? ¿Digamos que quiero dejar algo conectado a Internet para ganar dinero con algo como joinmarket? ¿O que quiero ser un tomador de privacidad?

R: Funciona en ambos casos. Si quieres participar en coinjoin y ganar algo- pero ahora mismo no funciona así. Ahora mismo todos los ingresos van a parar a los chicos de Wasabi Wallet. Sus servidores cobran por conectar a la gente. Por el momento creo que si quieres usar el coinjoin para obtener algo de privacidad, entonces necesitas este tipo de protocolo, así que probablemente necesites conectar tu monedero de hardware para hacer esto o todavía puedes hacerlo usando el airgap.

En nuestro caso, por ejemplo, estaba pensando en tener una pantalla en el ordenador y luego un código QR y que puedan comunicarse a través de los códigos QR como esto es una cámara web y esto es una pantalla. También estaba pensando en la salida de audio, como una toma de 3,5 mm de la cartera de hardware a la computadora. El ancho de banda allí es bastante bueno. También podrías reproducir audio en un altavoz. Pero entonces tu billetera de hardware necesita un altavoz, y sólo puede enviar tu clave privada. Pero una toma de audio de 3,5 mm tiene sentido.

P: ¿Qué pasa con el coinshuffle o el coinswap?

R: Sólo sé un poco sobre esto. Para wasabi wallet, no sabe qué entradas corresponden a qué salidas porque las registra por separado. Te devuelven una firma ciega y les das una salida ciega o algo así. Generan una firma ciega y no saben lo que están firmando. Esto permite que el servidor de coinjoin verifique que sí, que he firmado algo y que este tipo quiere registrar esta salida para que se vea bien y la ponga en el coinjoin. Para toda esta comunicación utilizan las firmas Schnorr porque allí se pueden utilizar firmas ciegas. En principio esto significa que tienen dos identidades virtuales que no están conectadas entre sí; sus entradas y salidas están completamente desconectadas incluso para el servidor de coinjoin. También generan salidas del mismo valor y luego hacen otra sección de las salidas con un valor diferente por lo que también se puede conseguir el anonimato por alguna cantidad de cambio.

El monedero Wasabi soporta monederos de hardware, pero no para coinjoin. Entonces el único beneficio restante de usar Wasabi es tener un control completo de las monedas y poder elegir las monedas para enviar a la gente.

P: ¿Cómo maneja Wasabi la privacidad cuando obtiene sus UTXOs?

R: Creo que utilizan el protocolo Neutrino, piden los filtros al servidor y luego descargan bloques de nodos bitcoin aleatorios. No necesitas confiar en su servidor central en ese punto. Creo que ya está habilitado para conectarte a tu propio nodo, impresionante eso es genial. Genial. Entonces ahora puedes obtenerlo desde tu nodo de Bitcoin Core.

Lightning aún está en desarrollo, pero ya está funcionando en vivo en mainnet. Sabemos que el software no es súper estable todavía, pero la gente estaba entusiasmada y empezó a usarlo con dinero real. No es mucho dinero real, es como unos pocos cientos de bitcoin en toda la red Lightning en este momento.

Ahora mismo la red de rayos sólo funciona con carteras calientes con las claves de su ordenador. Probablemente no sea un problema para nosotros, pero para los clientes normales que compran café a diario esto es un problema. Puede que esté bien almacenar unos cientos de dólares en tu monedero móvil y quizás te lo roben, no pasa nada, es una cantidad pequeña de dinero. Pero para los comerciantes y procesadores de pagos, entonces te preocupa perder monedas o pagos, y quieres tener suficientes canales abiertos para no tener que cerrar ninguno y no tener problemas de liquidez en la red. Tienes que almacenar tus claves privadas en un ordenador online que tiene una dirección IP concreta, o quizás a través de tor, y ciertos puertos abiertos, y estás transmitiendo a todo el mundo cuánto dinero tienes en esos canales. No es muy bueno, ¿verdad? Así que esta es otra cosa que estamos trabajando en que sería bueno para obtener las claves privadas de rayos en una cartera de hardware. Desafortunadamente, aquí no puedes realmente usar un airgap.

Podrías utilizar parcialmente el almacenamiento en frío. Podrías al menos asegurarte de que cuando el canal se cierra el dinero va a la cámara frigorífica. Hay una buena separación de diferentes claves en lightning. Cuando abres un canal, deberías verificar qué dirección usar al cerrar el canal. Entonces, incluso si tu nodo es hackeado, si el atacante intenta cerrar los canales y obtener el dinero, entonces falla porque todo el dinero va al almacenamiento en frío.

Pero si él es capaz de conseguir todo el dinero a través de la red de rayos a su nodo, entonces usted está probablemente jodido. Para almacenar estas claves privadas en la cartera de hardware es un reto, pero usted podría tener un .... él también puede hacer una actualización del canal firmado. Si proporcionas suficiente información al monedero de hardware, que realmente estás dirigiendo una transacción y que tu saldo está aumentando, entonces el monedero de hardware hot wallet podría firmar automáticamente. Si la cantidad está disminuyendo, entonces definitivamente tiene que pedir al usuario que confirme. Así que estamos trabajando en eso.

La ventaja de las firmas Schnorr para los monederos hardware es la agregación de claves. Imagina que utilizas transacciones multisig normales, como 3 de 5. Esto significa que cada vez que estás firmando la transacción y poniéndola en la blockchain, ves que hay 5 pubkeys y 3 firmas. Es una gran cantidad de datos, y todo el mundo puede ver que estás usando una configuración multisig de 3 de 5. Terrible para la privacidad, y terrible en términos de tarifas.

Con las firmas Schnorr, puedes combinar estas claves en una sola. Así que puedes tener varios dispositivos o firmantes que generen firmas y luego puedes combinar las firmas y las claves públicas correspondientes en una sola clave pública y una sola firma. Entonces todas las transacciones en la cadena de bloques y la mayoría de las transacciones en la cadena de bloques tendrían un aspecto similar, sólo una clave pública y una firma.

Con taproot (o aquí), es aún mejor. Usted puede agregar la funcionalidad de scripting allí también. Si todo va bien, como en un relámpago tal vez usted y su contraparte están cooperando libremente y no necesita hacer un cierre unilateral. Podrías hacer un cierre mutuo multisig 2 de 2, y entonces se parece exactamente a una clave pública y una firma única. Si alguien no está cooperando y las cosas van mal, entonces puedes mostrar una rama en el script de taproot que muestra que se te permite reclamar el dinero, pero este script sólo se revela si tienes que ir por este camino. De lo contrario, se obtiene una única clave pública y una única firma en la blockchain.

Podemos utilizar chips en un único dispositivo de monedero de hardware con diferentes arquitecturas y diferentes modelos de seguridad heterogéneos, y poner tres chips diferentes con tres claves diferentes allí, y asegurarnos de que podemos gastar el bitcoin sólo si cada uno de estos chips está firmando en el monedero de hardware. Así que uno puede ser un elemento de seguridad propio, y luego otros microcontroladores en el mismo monedero de hardware, y la salida es sólo una única clave pública y una única firma. También podríamos hacer un chip de Rusia y otro de China. Así que, aunque haya una puerta trasera, es poco probable que tanto el gobierno ruso como el estadounidense cooperen para atacar su monedero. Desde la perspectiva del usuario, parece que sólo hay una única clave o una única firma.

Todos estos perros guardianes y mecanismos anti-sabotaje y prevención de inyecciones de fallos y stuff.... aún no están implementados, pero sé que hay algunas empresas que están trabajando en periféricos de seguridad en torno a la arquitectura RISC-V. Así que es de esperar que pronto tengamos elementos seguros. El único problema en este momento es que la mayoría... algunas de las empresas, diría, toman esta arquitectura RISC-V de código abierto y le ponen encima un montón de módulos propietarios de código cerrado y esto arruina toda la idea. Necesitamos un chip RISC-V de código abierto. Definitivamente, recomendaría mirar a RISC-V.

Los IBM Power9 también son de código abierto en este momento. Raptor Computing Systems es uno de los pocos fabricantes que realmente le venderá el dispositivo. Es un servidor, así que no es lo ideal, pero en realidad es de código abierto. Es un equipo de 2000 dólares, es un ordenador completo. Así que no es un dispositivo de consumo ideal para carteras de hardware. Creo que la CPU y la mayor parte del dispositivo de la placa son de código abierto, incluido el núcleo. Es una arquitectura de IBM. Vale, probablemente debería mirar eso. Suena interesante.

Quiero hablar de las mejores prácticas, y luego hablar de desarrollar nuestra propia cartera de hardware. Pero primero sobre las mejores prácticas.

Nunca almacene los mnemónicos como texto plano. Nunca cargues la mnemotecnia en la memoria del microcontrolador antes de que se desbloquee. Hubo algo llamado "ataque de Trezor congelado". Coges tu Trezor, lo enciendes, lo primero que hace es cargar tu mnemónico en la memoria y luego lo que puedes hacer es congelar el Trezor con baja temperatura para asegurarte de que la memoria de la clave sigue siendo visible. Luego actualizas el firmware a un firmware personalizado, lo que permite Trezor, que normalmente está bien porque tu memoria flash se borra y suponen que tu RAM está decayendo pero a bajas temperaturas se queda ahí. Luego, una vez que tienes el firmware ahí, no tienes la mnemotecnia pero puedes imprimir en la serie... pero puedes seguir sacando los datos de ahí. El problema es que cargaban la mnemónica en la RAM antes de comprobar el bit. Así que nunca hagas eso.

Lo último y lo que impide que un atacante gaste sus fondos es el código PIN o el método de verificación que esté utilizando. Aquí es extremadamente mejor almacenar el código PIN correcto en el dispositivo. En principio, comparar el código PIN correcto con el código PIN incorrecto es malo porque durante estas comparaciones hay un ataque de canal lateral. En lugar de eso, quieres utilizar un código PIN y otro método de autenticación para obtener la clave de descifrado para descifrar el mnemónico cifrado. De esta manera, eliminas todos los ataques de canal lateral y no tienes el mnemónico como texto plano.

Otra buena característica que la gente debería utilizar es, ¿has oído hablar de funciones físicamente no clonables? Es una función muy buena. Digamos que tienes un microcontrolador fabricado... cuando la RAM se fabrica, hay ciertas fluctuaciones en el entorno de tal manera que la RAM se fabrica de forma diferente para cada bit. Cuando enciendas el microcontrolador, el estado de tu memoria será aleatorio. Luego la borras y empiezas a usarla normalmente. Pero esta aleatoriedad tiene un cierto patrón, y este patrón es inclasificable porque no puedes observarlo y no puede ser reproducido en otro dispositivo RAM. Puedes utilizar este patrón como una huella digital, como la clave única del dispositivo. Por eso se llama una función físicamente no clonable, se debe a las variaciones en el proceso de fabricación. Puedes usar eso junto con un código PIN y otras cosas para encriptar tu mnemónico. Cuando el dispositivo se inicie, será capaz de descifrar la mnemotecnia. Pero la extracción de la memoria flash completa no ayudará a esto, porque todavía necesita obtener la función físicamente no clonable que está en el dispositivo. La única manera de conseguir eso es flashear el firmware, leer la clave y extraerla por serie o lo que sea. Es un fallo tanto de la protección de lectura como de la protección de escritura.

P: ¿Por qué no eliminar el PIN y el almacenamiento mnemotécnico y exigir al usuario que lo introduzca y borre el dispositivo?

R: Se podría. Así que es un dispositivo de firma seguro, pero no un dispositivo de almacenamiento seguro. Así que hay un almacenamiento seguro y una firma segura. Así que almacenas la frase de contraseña o el monedero encriptado en papel o CryptoSteel en una cámara acorazada de un banco o algo así con la mnemotecnia o algo así... y está encriptado, y recuerdas la frase de contraseña. Así que nunca guardas la frase de contraseña en ningún sitio.

El problema del almacenamiento seguro y el de la firma segura deberían estar separados. Así que se podría utilizar hardware reemplazable para la firma, y la mnemotecnia debería almacenarse encriptada en papel o algo así. El problema de introducir un mnemotécnico cada vez es que podrías tener un ataque de criada malvada. La prevención aquí es no tener wifi ni nada. Pero tal vez el atacante es inteligente y pone un paquete de baterías y algún tipo de mecanismo de transmisión, pero esto vuelve a tener una cartera de productos desechables.

Además de la RAM, puedes utilizar un trozo de cristal para hacer una función físicamente incopiable. Podrías poner un trozo de cristal en la cartera y ésta tiene un láser y puede medir las imperfecciones de la pantalla y lo utiliza para obtener la clave de descifrado de tu mnemónica. Esto no es una huella digital. Sin embargo, el vidrio puede degradarse con el tiempo. Un trozo de plástico puede tener un patrón único que genere un patrón de interferencia y entonces se puede utilizar para extraer una clave de descifrado de eso. Pero eso no va a suceder por un tiempo.

Esta otra cosa sobre los ataques de la criada malvada y los implantes de hardware, ¿cómo podemos evitarlo? Hay una forma de hacer una malla antimanipulación alrededor del dispositivo, de manera que cuando alguien intente entrar en él, por ejemplo haciendo un agujero, se activen automáticamente las medidas de seguridad. En los HSM del sector bancario, básicamente tienen un dispositivo constantemente conectado a la corriente y que controla la corriente que pasa por esta malla conductora. Si detectan el cambio de corriente en esta malla, entonces borran el dispositivo. El problema aquí es que cuando te quedas sin energía, tienes que depender de la batería, y entonces cuando la batería se está agotando antes de que se agote tienes que borrar las claves de todos modos.

Hay una forma mejor, en la que no sólo se comprueba la corriente, sino que también se comprueba la capacidad de los cables en la malla y se utiliza eso como una huella digital única para generar la clave de descifrado única de tus secretos. Incluso si alguien hace un agujero de 100 micras aquí, la clave de descifrado cambia y ya no podrá extraer los secretos. De momento no se puede comprar un dispositivo así, pero es un enfoque muy prometedor. Probablemente sea para gente que realmente se preocupe por las grandes cantidades de dinero, porque esto es realmente caro.

Si vas a borrar las claves, entonces también podrías pre-firmar una transacción antes de borrar las claves, para enviar las monedas a un almacenamiento en frío de respaldo o algo así.

No debes esperar que rodar tu propia cartera de hardware sea una buena idea. Tu dispositivo probablemente no será tan seguro como Trezor o Ledger porque tienen grandes equipos. Pero si hay un error en el firmware de Trezor, entonces los atacantes probablemente tratarán de explotarlo en todos los usuarios de Trezor. Pero si tienes una implementación personalizada que puede no ser súper segura pero es personalizada, entonces ¿cuáles son las posibilidades de que el tipo que viene a tu casa y encuentra un dispositivo de aspecto extraño y se da cuenta de que es una cartera de hardware y entonces cómo se da cuenta de cómo romperlo? Otra cosa que puedes hacer es esconder tu cartera de hardware en una carcasa de Trezor ((risas)).

Alguien en un video sugirió hacer una billetera de hardware falsa, y cuando es encendida por alguien, entonces envía un mensaje de alerta a un grupo de telegram y dice llama al 911 estoy siendo atacado. Usted podría poner esto en la carcasa de Trezor. Cuando el tipo se conecta a él, envía el mensaje. Otra cosa que podrías hacer es instalar un malware en el ordenador del atacante, y luego rastrearlo y hacer varias cosas de vigilancia. También podrías alegar que sí, que necesito usar Windows XP con esta configuración o algo igualmente inseguro, lo cual es plausible porque tal vez configuraste este sistema hace 10 años.

¿Qué podemos utilizar para hacer una cartera de hardware? Si crees que hacer hardware es difícil, no lo es. Sólo tienes que escribir un firmware y cargarlo. También puedes usar FPGAs que son divertidas para desarrollar. Me gustan las placas que soportan micropython, que es una versión limitada de python. Puedes hablar con periféricos, mostrar códigos QR, etc. Trezor y ColdCard utilizan micropython para su firmware. Sin embargo, creo que micropython tiene un largo camino por recorrer, porque tan pronto como te alejas de lo que ya se ha implementado, entonces terminas teniendo problemas en los que tienes que bucear en el interior de micropython y terminas teniendo que escribir nuevo código C o algo así. Pero si te gusta todo lo que ya existe, entonces es extremadamente fácil trabajar con él.

Otra opción es trabajar con arduinos. Se trata de un framework desarrollado hace quizá 20 años, no lo sé, y que se utiliza en toda la comunidad de bricolaje. Se hizo extremadamente fácil empezar a escribir código. Conozco a gente que aprendió a programar usando arduino. Es C++, y no es tan fácil de usar como python, pero aún así la forma en que hacen todas las bibliotecas y todos los módulos, es extremadamente amigable para el usuario. Sin embargo, no desarrollaron este marco con la seguridad en mente.

También está el framework Mbed. Soporta una gran variedad de placas. Este marco fue desarrollado por ARM. Vuelves a escribir código C++, lo compilas en el binario y cuando conectas la placa lo arrastras y lo sueltas en la placa. Es literalmente arrastrar y soltar. Es más, no necesitas instalar ninguna cadena de herramientas. Puedes conectarte a Internet y utilizar su compilador de navegador en línea. No es muy conveniente, excepto para empezar y conseguir que algunos LEDs parpadeen. Ni siquiera necesitas instalar nada en tu ordenador.

Otra cosa a la que hay que prestar atención es al lenguaje rust, que se centra en la seguridad de la memoria. Tiene mucho sentido. También tienen rust para sistemas Mbed. Así que puedes empezar a escribir rust para microcontroladores, pero también puedes acceder a las librerías que normalmente escribe el fabricante o algo así, como para hablar con las pantallas, los LEDs y todas estas cosas. En el mundo de los microcontroladores, todo está escrito en C. Puedes escribir tu lógica de cartera de hardware en rust, y luego seguir teniendo los enlaces a las bibliotecas de C.

Hay un proyecto muy interesante llamado TockOS. Se trata de un sistema operativo escrito completamente en rust, pero puedes seguir escribiendo en C o C++, pero el propio sistema operativo, como el sistema de gestión, puede asegurarse de que incluso si una de tus bibliotecas está completamente comprometida, sigues estando bien y no puede acceder a la memoria de otros programas. Así que creo que eso está muy bien. Por el momento, creo que no hay mucha gente que conozca rust, pero eso está mejorando. Definitivamente es una cadena de herramientas muy interesante.

Otra cosa buena que puedes hacer con los monederos de hardware DIY, o no sólo DIY sino con hardware flexible, es la autenticación personalizada. Si no estás contento con sólo un código PIN, como si quisieras una contraseña más larga, o quieres tener un acelerómetro y quieres girar la cartera de hardware de una manera determinada que sólo tú conoces o algo así, o por ejemplo puedes aplicar contraseñas de un solo uso y autenticación multifactor. No sólo requieres el PIN sino también una firma de tu yubikey, y todo este tipo de cosas raras, o incluso tu huella digital pero eso es una mala idea porque las huellas digitales tienen una baja entropía y la gente puede simplemente tomar tu dedo de todos modos o robar tus huellas digitales.ç

Podrías usar yubikey, Google Titan, o incluso algunas tarjetas bancarias. Podrías hacer autenticación multifactor y diferentes dispositivos de almacenamiento de claves privadas para hacer multisig que no tienen nada que ver con bitcoin, para autenticar para entrar en una cartera de hardware.

Ten en cuenta que todas estas placas de las que hablo no son súper seguras. Todas usan microcontroladores y no tienen un elemento seguro. Puedes conseguir una placa muy barata que cuesta como 2 dólares. Ten en cuenta que está fabricada y diseñada en China. Está muy extendida, pero quién sabe, tal vez todavía hay una puerta trasera en el dispositivo en alguna parte. Quién sabe. Además, tiene bluetooth y wifi así que eso es algo a tener en cuenta. Si quieres una versión no muy segura del Ledger X, entonces podrías hacerlo. Probablemente sería más seguro que guardar el dinero en tu portátil que está constantemente conectado. Todas las demás placas para desarrolladores tienden a tener microcontroladores simples para aplicaciones específicas. Esta de aquí tiene el mismo chip que tiene Trezor, en teoría podrías portar Trezor a esto. Así que obtienes la seguridad de un monedero Trezor, una pantalla mucho más grande y tal vez alguna funcionalidad adicional que te pueda gustar. Así que podría tener sentido en algunos casos. Yo no confiaría completamente en el hardware DIY para la seguridad.

También hay algunos chips baratos enfocados a la seguridad disponibles en el mercado. El que se utiliza en la ColdCard está en el mercado, una especie de ECC blahblahblha de Microchip. También se puede aplicar en el factor de forma arduino. Así que puede proporcionarle un almacenamiento de claves seguro para sus claves de bitcoin, y el resto se puede hacer en el microcontrolador normal.

Actualmente no hay elementos seguros en el mercado que permitan utilizar la criptografía de curva elíptica para la curva de bitcoin. Todavía no se han construido.

Hacer un elemento totalmente seguro que sea completamente de código abierto desde la base hasta la cima, costará como 20 millones de dólares. Lo que estamos liberando es lo que es accesible para nosotros en este momento. Así que lo que podemos hacer es conseguir este elemento seguro que tiene un sistema operativo de tarjeta Java propietario en la parte superior, y luego en la parte superior de esto podemos escribir un bitcoin específico que puede hablar con el hardware y utilizar todos los aceleradores de curva elíptica y las características de hardware y todavía puede ser de código abierto porque no tenemos saber exactamente este sistema operativo de tarjeta Java funciona por lo que no es totalmente de código abierto, sólo estamos abriendo todo lo que podemos. En la ColdCard, no se puede utilizar la criptografía de curva elíptica en el elemento de almacenamiento seguro de claves, pero en otros elementos seguros sí se puede ejecutar ECDSA y otra criptografía de curva elíptica.

Quería hablar de cómo hemos diseñado nuestra cartera de hardware y obtener su opinión acerca de si esto tiene sentido o no y cómo podemos mejorar, especialmente Bryan y M. Después de eso, creo que podemos, si ustedes tienen sus ordenadores portátiles con usted, entonces podemos configurar el entorno de desarrollo para mañana para que podamos incluso dar las tablas para probar en la noche y llevarlos a casa. Si prometéis no robarla, podéis llevaros alguna a casa si queréis, si es que vais a probarla. Tened en cuenta que mañana os molestaré todo el tiempo, así que esta noche es vuestra oportunidad de mirar esto a solas. Mañana entonces podemos trabajar en algunas carteras de hardware loco.

Lo que decidimos hacer es que tenemos algunos socios de hardware que pueden fabricar chips personalizados para nosotros. Podemos tomar los componentes de los microcontroladores normales y ponerlos de forma agradable en un solo paquete. ¿Qué componentes tienen normalmente los monederos de hardware? Los que también tienen un elemento seguro, al menos. Así que decidimos primero ir al código abierto. No vamos a trabajar con un elemento seguro de metal desnudo y un sistema operativo de código cerrado que no podemos abrir debido a los acuerdos de confidencialidad. Así que estamos utilizando un sistema operativo de tarjeta Java y, aunque no sabemos cómo funciona, parece que funciona, así que debería ser bastante seguro. Luego, para escribir encima de eso, estamos escribiendo un applet de bitcoin que funciona con el elemento seguro. Sólo podemos poner allí cosas que firmamos y que subimos usando nuestras claves de administración. Esto significa que podemos desarrollar y subir el software, y luego puede sugerir ciertos cambios que podemos habilitar para la carga. Esto requiere cierta comunicación con nosotros primero. No puedo dar las claves a nadie más, porque si se filtran tenemos problemas con el gobierno porque están preocupados por los criminales que comprometen los canales de comunicación súper seguros o los usan para organizar sus actividades ilegales. Por desgracia, este es el estado de la industria. Queríamos desarrollar un elemento seguro de código abierto, pero por ahora sólo podemos hacer un monedero de hardware quizás más seguro y un poco más flexible.

Así que estamos utilizando la tarjeta inteligente Java Card, y luego tenemos otros dos microcontroladores. También tenemos una pantalla algo grande para mostrar toda la información sobre la transacción y darle un buen formato y para habilitar este airgap de código QR necesitamos poder mostrar códigos QR bastante grandes. Tenemos que usar otro microcontrolador de propósito general porque sólo ellos pueden manejar pantallas grandes por el momento. Luego tenemos un tercer microcontrolador que hace todo el trabajo sucio que no es crítico para la seguridad, como la comunicación a través de USB, hablar con las tarjetas SD, procesar las imágenes de la cámara para leer los códigos QR y cosas por el estilo. Esto hace que se aísle físicamente la gran base de código que no es crítica para la seguridad y que maneje todos los datos del usuario y los datos del ordenador frío. También tenemos otro microcontrolador que se dedica a la conducción de la pantalla para que pueda tener una pantalla de cierta confianza. Todos estos microcontroladores están empaquetados en el mismo paquete. En el interior, tenemos dispositivos semiconductores estratificados en el paquete, y están estratificados en una estructura de seguridad. El de arriba es el elemento seguro, y los otros dos están por debajo. Así que, en teoría, el calor de un chip del paquete puede detectarse en el otro, pero es de suponer que la tarjeta inteligente tiene mucho trabajo hecho en materia de análisis de potencia y prevención de canales laterales.

Incluso si el atacante tiene acceso a este chip y lo descifra, primero golpeará el elemento seguro que tiene todos estos mecanismos anti-manipulación como perros guardianes y detección de voltaje y mapeo de memoria y otras cosas, y comparte esta capacidad con otros chips. Obviamente comparten el mismo suministro de voltaje, así que primero se gana un poco de seguridad en el elemento seguro con los otros microcontroladores. Incluso si el atacante trata de entrar en la memoria de los microcontroladores no muy seguros, el elemento seguro está en el camino y es difícil llegar por debajo de él. Los clientes anteriores para los que hicieron esto era para los satélites, y en ese caso tienes problemas con la radiación y esas cosas. Para nosotros, esto nos ayudó porque significa que no se puede, en primer lugar, ninguna radiación electromagnética va desde el chip hacia el exterior, por lo que esto elimina algunos ataques de canal lateral, y en segundo lugar, la radiación electromagnética limitada entra en el chip. Y como he dicho, todos están en el mismo paquete. En nuestras placas de desarrollo, no están en el mismo paquete porque no tenemos el dinero para desarrollar el chip, pero empezaremos pronto. Aun así, ya tiene todo este hardware.

Los microcontroladores normales tienen estas interfaces de depuración. Incluso si están deshabilitadas con los bits de seguridad, el atacante puede hacer un montón de cosas de condición de carrera e incluso volver a habilitarlas. Así que incluimos un fusible que rompe físicamente la conexión de la interfaz JTAG con el mundo exterior. Así que sólo teniendo el chip, el atacante no es capaz de utilizar la interfaz JTAG. Esto es algo bueno que normalmente no está disponible. En la placa de desarrollador, exponemos un montón de conexiones con fines de desarrollo, pero en el producto final las únicas conexiones serán la pantalla, la pantalla táctil, y para la cámara no hemos decidido cuál de ellas queremos utilizar. Normalmente la cámara se utiliza para almacenar el código QR y obviamente está relacionada con la comunicación y debería estar en el microcontrolador de comunicación. Podemos tomar una foto de los dados como entropía definida por el usuario.

Tenemos un código completamente airgapped que funciona con códigos QR para escanear transacciones y códigos QR para transmitir firmas. Lo llamamos la función M porque fue él quien lo sugirió. Es tan bonito y fluido como funciona que tengo este bonito video que puedo mostrarte. Así que primero escaneamos el código QR del dinero que queremos enviar; el monedero watchonly del teléfono conoce todos los UTXOs y prepara las transacciones sin firma y se lo muestra al monedero hardware. A continuación, en el monedero físico escaneamos el código QR. Ahora vemos la información sobre la transacción en el monedero físico, que podemos firmar, y luego obtenemos la transacción firmada. A continuación, la escaneamos con el monedero de reloj, y luego la emitimos. El flujo es bastante conveniente.

Se trata de un flujo de datos unidireccional. Sólo va en una dirección. Es un flujo de datos muy controlado. También está limitado en cuanto a los datos que se pueden pasar de un lado a otro. Esto es algo bueno y malo a la vez. Para una transacción grande, puede ser un problema. Para datos pequeños, es genial. Todavía no hemos probado los códigos QR animados. Pude hacer PSBT con unas pocas entradas y salidas, por lo que era bastante grande. Con transacciones bitcoin parcialmente firmadas y entradas heredadas, entonces tus datos van a explotar en tamaño bastante rápido. Antes de segwit, tenías que poner mucha información en la función de hash para derivar el valor del sighash. Ahora con segwit, si la cartera miente sobre las cantidades, entonces simplemente generará una firma inválida. Para calcular la cuota del monedero hardware, tengo que pasar toda la transacción anterior, y puede ser enorme. Tal vez usted obtiene las monedas del intercambio, y el intercambio podría crear una gran transacción con miles de salidas y tendría que pasar todo a la cartera de hardware. Si estás usando direcciones heredadas, probablemente tendrás problemas con los códigos QR y entonces tendrás que hacer animaciones. Para transacciones segwit y un número razonable de entradas y salidas, estás bien. Podrías simplemente decir, no usar más legacy, y barrer esas monedas. El único vector de ataque razonable ahí es si eres un pool de minería y vas a engañarte para transmitir eso y robarte, pero fuera te perjudica pero no beneficia al atacante así que realmente no tiene incentivo. También puedes mostrar una advertencia y decir que si quieres usar las tasas, entonces usa bech32 o al menos compruébalo aquí. Puedes mostrarles la tarifa en la máquina caliente, pero eso probablemente esté comprometido.

Con el modo airgapped, tienes almacenamiento en frío y es un airgap y es razonablemente seguro. Nada es perfecto, habrá errores y ataques a nuestra cartera de hardware también. Sólo esperamos cometer menos errores de los que vemos en este momento. Además, otra cosa de la que no hablé es el .... dentro de las tarjetas inteligentes, tenemos que reutilizar el SO de la tarjeta Java sólo porque los applets tienen que ser escritos en java. Entonces decidimos ir con rust embebido, y aunque es un poco más difícil de desarrollar y no mucha gente conoce rust, esta parte es realmente crítica para la seguridad y no queremos dispararnos en el pie con errores allí. Además, se evita un montón de aislamiento y las mejores prácticas del mundo de la seguridad. En tercer lugar, nos abrimos a los desarrolladores y se está ejecutando micropython. Así que esto significa que si quieres una funcionalidad personalizada en la cartera de hardware, como un esquema de comunicación personalizado como bluetooth que no queremos, pero si lo quieres entonces eres bienvenido a hacerlo tú mismo. Entonces escribes un script en python que maneje este tipo de comunicación, y luego solo lo usas. Otra forma de hacerlo es que, si estás usando un script personalizado particular que no conocemos, y estamos mostrando esta transacción de una manera fea que es tal vez difícil de leer, entonces tal vez lo que puedes hacer es añadir algunos metadatos para enviarlo al otro microcontrolador para mostrarte algo. Todavía lo marcará como no súper confiable porque viene de esta aplicación de python, pero si usted está confiando en los desarrolladores de la aplicación, entonces usted puede hacer algunas opciones. Pero al menos puedes ver alguna información adicional sobre esta transacción si nuestro material no fue capaz de analizarla; como si es una transacción coinjoin que está aumentando tu conjunto de anonimato en 50 o lo que sea - todavía ves las entradas y salidas, además de la información extra normalmente. Así que esto podría ayudar a la experiencia del usuario.

Además del modo airgapped, hay otro caso de uso completamente diferente en el que se utiliza como una cartera caliente como para una cartera de hardware de rayos. Usted mantiene el monedero conectado a la computadora, y la computadora conectada ejecuta un monedero lightning de vigilancia, y luego se comunica con el monedero de hardware para las firmas de las transacciones que aumentan estrictamente el balance de su canal. Entonces, usted podría estar en el bucle para cualquier transacción que reduzca su saldo. Ten en cuenta todavía que este no es un modo de airgapped, pero es un modo de seguridad diferente. Probablemente quieras la mayor parte de tus fondos en el almacenamiento en frío, y luego alguna cantidad puede estar en este dispositivo de monedero de hardware caliente. Además, uno de los problemas con coinjoin es que puede tomar algún tiempo como unos pocos minutos, especialmente si usted necesita para reintentar varias veces, que es una especie de cartera caliente.

Probablemente no quieras llevar tu monedero hardware todo el tiempo, o ir a casa a pulsar un botón para confirmar tu pago relámpago o algo así. Así que lo que puedes hacer es configurar un teléfono con una aplicación que está emparejado con la cartera de hardware, por lo que la cartera de hardware es consciente de la aplicación y la aplicación almacena algún secreto para autenticarse y luego se puede establecer un límite en la mañana para su teléfono. Así, el monedero de hardware debe autorizar los pagos hasta una cierta cantidad si viene de esta aplicación segura. Incluso más, puedes establecer permisos particulares a la aplicación móvil. Por ejemplo, el monedero de intercambio debería poder pedir a la cartera de hardware una factura, pero sólo una factura para pagarte. Lo mismo con las direcciones de bitcoin, sólo puede pedir direcciones de bitcoin para una ruta particular. Si quieres, puedes hacerlo más flexible y conseguir una mejor experiencia de usuario. El monedero de hardware está conectado a Internet, y las solicitudes se reenvían a través de la nube en este esquema.

Lo primero que vamos a lanzar es el tablero de desarrolladores y el elemento seguro. Otra cosa que quiero discutir es la API de la primera versión del elemento seguro. En concreto, como desarrolladores, ¿qué os gustaría que tuviera? Tengo algunas ideas sobre lo que puede ser útil. Tal vez ustedes puedan pensar en algo más.

Obviamente, debe almacenar la mnemotecnia, las contraseñas, las frases de paso, y debe ser capaz de hacer todos los cálculos de derivación bip32 y almacenar claves públicas bip32. También queremos ECDSA y la firma de curva elíptica estándar que estamos utilizando en este momento. Además, quiero incluir este protocolo de mitigación de ataques anti-nonce. No queremos confiar en el elemento seguro propietario; queremos estar seguros de que no está tratando de filtrar nuestras claves privadas utilizando este ataque nonce elegido. Así que queremos aplicar este protocolo. Además, queremos utilizar las firmas Schnorr en particular con la compartición de secretos Shamir. Esto permitiría tomar las claves Schnorr, y luego obtener una firma que utiliza el punto correcto. La agregación de claves con Shamir, necesitas una función elegante para combinar cada uno de los puntos de las partes.

Tiene sentido usar a Shamir aquí porque puedes hacer umbrales. Con Musig también puedes hacerlo, pero con Schnorr es sólo k-de-k. Compartición de secretos Shamir verificable usando compromisos pedersen. Digamos que tenemos 3 claves viviendo en nuestro hardware, y estas otras partes están en algún otro hardware de respaldo en otro lugar. Todas ellas pueden comunicarse entre sí. Cada uno genera su propia clave, y luego usando compromisos pedersen y algún otro algoritmo de fantasía, pueden estar seguros de que cada uno de ellos termina con una parte de algún secreto común, pero ninguno de ellos sabe cuál es el secreto común. Así que tenemos una clave privada virtual o un secreto completo que se divide con el esquema de compartición de secretos de Shamir con todos estos tipos y ninguno de ellos conoce el secreto completo. El único problema es ¿cómo lo respaldas? No puedes ver una mnemotecnia correspondiente a esto. Nadie conoce esta clave, así que nadie puede mostrarla. Así que la única manera de hacerlo es de alguna manera - digamos que este tipo controla la pantalla, entonces puede optar por mostrar su propia clave privada, pero entonces ¿qué pasa con los demás? No quieren comunicarse con este tipo para mostrarla porque entonces pueden reconstruirla.... así que podrías usar algo como la pantalla que conectas a diferentes dispositivos para mostrar esta mnemotecnia, pero entonces el controlador de la pantalla puede robarlas todas. Lo ideal es que el controlador de pantalla sea un dispositivo muy simple que sólo tenga memoria y una pantalla. También podrías utilizar hardware desechable para generar la clave privada, pero entonces ¿cómo la recuperas?

Otra idea son las copias de seguridad sin semillas, de modo que si uno de los chips se rompe, si no usas 5 de 5, sino 3 de 5, puedes hacer que estos chicos se comuniquen entre sí, renegocien la misma clave, generen un nuevo fragmento para el nuevo miembro y reemplacen todas las partes antiguas de este esquema de compartición de secretos Shamir con el nuevo. En lugar del viejo polinomio, eliges el nuevo polinomio y hay una manera tal que cada uno de estos dispositivos puede cambiar a la nueva clave y en lugar de comprometer a uno obtenemos el nuevo miembro. Esto también es útil si uno de los fragmentos o claves se compromete o se pierde, siempre y cuando tengas suficientes claves para reconstruirlo.

Para la firma, no es necesario reensamblar la clave privada compartida secreta de Shamir porque es Schnorr. Así que las firmas se generan parcialmente, y luego se pueden combinar en la firma final correcta sin reensamblar la clave privada en una sola máquina.

Digamos que estás haciendo SSS sobre una clave privada maestra. Con cada fragmento, generamos una firma parcial sobre una transacción. Una firma Schnorr es la suma de este punto aleatorio más el hash por la clave privada, y es lineal. Podemos aplicar la misma función para recombinar las partes de la firma. Podemos aplicar la misma función a s1, s2 y s3 y entonces se obtiene la firma completa S de esta manera sin combinar nunca las partes de las claves en la clave completa.

La multifirma está bien cuando no eres el único propietario de las claves privadas, como en el caso de la custodia con tus amigos y familiares o lo que sea. El esquema Shamir Secret Sharing con Schnorr es genial si eres el único propietario de la clave, así que sólo necesitas los fragmentos de la clave. Hay un documento que puedo darte que explica cómo se generan los fragmentos, o si la clave privada maestra virtual se genera en una sola máquina. Multisig es mejor para la custodia comercial, y Shamir es mejor para la autocustodia y el autoalmacenamiento en frío. La multifirma clásica seguirá estando disponible con Schnorr, no tienes que usar la combinación de claves, seguirías usando el CHECKMULTISIG. Creo que todavía se puede utilizar. ((No, no se puede - ver la sección "Diseño" de bip-tapscript o CHECKDLSADD.)) Desde la perspectiva de la minería, CHECKMULTISIG hace que sea más caro validar esa transacción porque tiene muchas firmas.

Estaba pensando en utilizar políticas de miniscript para desbloquear el elemento seguro. Para desbloquear el elemento seguro, se podría utilizar simplemente un código PIN o se podría utilizar de forma que se necesitaran firmas de otros dispositivos o códigos de una sola vez de algún otro mecanismo de autenticación. Teníamos que implementar miniscript de todos modos. No estamos restringidos a los límites de sigop de bitcoin ni a nada aquí; así que el elemento seguro debería ser capaz de verificar este miniscript con cualquier clave de autenticación o contraseña que estés usando. Incluso puede ser CHECKMULTISIG con el límite de 15 claves eliminado.

Le enviaré a Bryan el documento sobre la compartición lineal de secretos para las firmas de umbral de Schnorr, en el que cada fragmento se puede utilizar para generar firmas parciales que luego se pueden recombinar. Tal vez el documento de Pedersen sobre la compartición de secretos verificable de 1999. Y luego hay una respuesta a ese papel donde se puede arreglar cómo una parte puede sesgar la clave pública, que sesgar la clave pública no importa, pero lo que sea. GJKR'99 sección 4 lo tiene. No es un esquema de compartición de secretos de Shamir si no reúnes la clave privada; es sólo un esquema de firma de umbral que resulta que utiliza la compartición lineal de secretos. Llamarlo de otra manera es peligroso porque podría animar a la gente a implementar SSSS donde la clave puede ser recuperada.

P: ¿Y si te deshaces del elemento de seguridad, y haces que el almacenamiento sea efímero y lo borres al apagar? Básicamente lo que hace Tails. El usuario tiene que introducir su mnemónico y su frase de contraseña. Incluso se puede guardar el mnemónico y sólo requerir una frase de contraseña. ¿Sería más fácil y barato si nos deshacemos del elemento de seguridad?

R: Bueno, ¿qué pasa con el ataque de una criada malvada? Sube cierto firmware a tu microcontrolador. ¿Cómo verificas que no ha cogido la contraseña?

P: Es posible, pero esta doncella malvada tiene que volver y conseguir el acceso de nuevo en el futuro. Pero mientras tanto, podrías destruirlo, y desmontarlo y confirmar e instalar el software cada vez.

R: Realmente quiero una cartera de hardware desechable. Mientras la firma sea válida, eso es todo lo que necesitas. Vas a destruir el dispositivo de hardware después de usarlo.

P: Si utilizas este enfoque sin un elemento seguro, ¿qué pasa con una situación de monedero caliente como para un rayo?

R: Si no tienen acceso a la cartera de hardware, entonces está bien. Pero si tienen acceso, entonces será aún peor en el escenario sin el elemento seguro. Está utilizando las claves privadas para las operaciones criptográficas, y si está en el microcontrolador normal, entonces se puede observar el consumo de energía y extraer las claves. Es bastante difícil deshacerse de esto. Trezor sigue siendo vulnerable a este problema. Los chicos de Ledger descubrieron un ataque de canal lateral cuando obtienes una clave pública a partir de tu clave privada, filtras alguna información sobre tu clave privada. Están trabajando en arreglar esto, pero básicamente para derivar una clave pública necesitas desbloquear el dispositivo y esto significa que ya conoces el código PIN así que no es un problema para ellos. Pero en modo automático, si tu dispositivo está bloqueado pero sigue haciendo criptografía en un microcontrolador, entonces sigue siendo un problema. Yo preferiría que sólo se hicieran operaciones de criptografía en un elemento seguro. Si implementamos algo que pueda almacenar las claves o borrar las claves también, y que pueda hacer operaciones criptográficas sin canales laterales, entonces creo que se puede pasar a una placa de desarrollador normal o a un microcontrolador extendido y hacer todo allí ya. Creo que no es puramente una restricción, es más como... tiene algunas limitaciones porque no podemos conectar la pantalla al elemento seguro, pero son compensaciones en las que estamos pensando. Para los desechables, creo que está perfectamente bien usar el... hacer una cosa desechable muy barata. Los microcontroladores utilizados en Trezor cuestan como 2 dólares o algo así. Así que podemos tener un montón de ellos, comprarlos al por mayor en digikey o algo así por miles y luego los pones en el chip y tienes que soldar un poco. Lo ideal sería un chip con un paquete DIP o un zócalo y simplemente poner el controlador allí. Estaría bien probarlo.

P: Si te preocupa el ataque de una doncella malvada, puedes utilizar una bolsa a prueba de manipulaciones. La doncella malvada podría sustituir tu cartera de hardware, pero en teoría lo sabrías gracias a la bolsa a prueba de manipulaciones. Puedes usar purpurina, sacarle una foto y guardarla, y cuando vuelvas a tu dispositivo compruebas tu purpurina o algo así. O tal vez tiene una conexión a Internet y si alguna vez es manipulado, entonces dice hey fue desconectado y no confío más.

Estos escáneres de huellas dactilares en los portátiles son completamente estúpidos. Además, un lugar fácil para encontrar esas huellas es el propio teclado ((risas)). Deberías encriptar tu disco duro con una frase de contraseña muy larga que escribes.

https://btctranscripts.com/bitcoin-core-dev-tech/2019-06-07-statechains/

Con las cadenas de estados, puedes transferir la clave privada a otra persona, y entonces haces que sólo la otra persona pueda hacer una firma. Ruben vino con una construcción interesante donde encima de esto puedes hacer transacciones relámpago donde sólo transfieres parte de este dinero, y puedes hacer rebalanceo y cosas. Pero requiere firmas de Schnorr, firmas ciegas para Schnorr, y si ocurre pues no será por el momento.

La forma en que podemos ayudar con esto es que, podemos proporcionar la funcionalidad en el elemento seguro que extrae la clave y luego - de tal manera que usted está seguro de que la clave privada se mueve. Usted necesita confiar en el fabricante todavía, pero usted puede diverisificate la confianza de ella, de modo que usted no tiene que confiar plenamente en esta federación que está haciendo cumplir esta política.

https://bitcoin-hardware-wallet.github.io/