Los dispositivos de firma de hardware están diseñados para proteger al usuario de varios vectores de ataque comunes, como:

• Acceso no autorizado y extracción de la semilla
• Malware que infecta su billetera de software asociada
• Vulnerabilidades de software en el propio dispositivo

Como cualquier negocio, lo mejor para el fabricante es fabricar dispositivos tan irrompible como pueden Tener éxito en esta misión es primordial, y las empresas de seguridad como Ledger confían en una reputación construida sobre su trayectoria.

Sin embargo, algunos usuarios aún pueden tener preocupaciones. Lo que impide que la propia empresa oculte un puerta trasera en los dispositivos?

En la autocustodia, nosotros no confíes, nosotros verificamos.
Pero puede el usuario realmente verificar que un dispositivo no tiene una puerta trasera?

Esa es la pregunta clave en la que profundiza este artículo. Más precisamente, este artículo aborda los siguientes temas:

• qué es una puerta trasera y por qué es difícil, si no imposible, demostrar que no existe;
• por qué solo los usuarios pueden protegerse de este riesgo;
• cómo miniscript permite soluciones prácticas a este desafío para las billeteras bitcoin.

Al ser la primera billetera de hardware compatible miníndice, esperamos inspirar a los desarrolladores a crear soluciones seguras y actualizar toda nuestra industria, y eliminar la posibilidad de que tal riesgo sistémico se materialice.

Cómo construir el puerta trasera dispositivo de firma

Digámoslo claramente: no se puede.

Para defenderse de una puerta trasera potencial, necesita un modelo de ataque diferente al que describimos anteriormente: en este escenario, el adversario podría ser el propio proveedor o una persona interna corrupta.

La solución a menudo promocionada para este problema es el código abierto: después de todo, si puede inspeccionar el código, ¿qué podría salir mal?

Sin embargo, la verdad es más compleja. Dado que el proveedor ensambla el hardware, una puerta trasera podría estar completamente contenida dentro de él. El hardware podría diseñarse para ignorar el software en ciertos puntos y ejecutar código malicioso en su lugar.

A diferencia del software que se ejecuta en dispositivos informáticos de propósito general (como su computadora portátil o teléfono), examinar el hardware es prácticamente imposible con la tecnología actual. Incluso si las especificaciones del hardware fueran completamente de código abierto, completas con los detalles de cada una de las puertas del circuito, aún necesitaría un equipo de alto costo para verificar que un chip específico se construye de acuerdo con ellas.

Cómo hacer una puerta trasera a una billetera de hardware

Estos son algunos de los métodos más simples que un proveedor de hardware malicioso podría usar para introducir una puerta trasera, junto con algunas formas en que los usuarios avanzados pueden protegerse hoy.

generación de semillas

Muchos dispositivos le ofrecen la posibilidad de generar una semilla (también llamada Frase secreta de recuperación) directamente en el dispositivo, utilizando un Generador de números aleatorios verdaderos.

😈 El dispositivo maligno podría generar semillas que parecen aleatorias pero que en realidad son predecibles para el atacante.

🛡️ Los usuarios avanzados pueden sortear este problema generando un mnemotécnico fuera de línea. Además, incorporando un robusto frase de contraseña también puede generar una semilla completamente independiente que el proveedor de hardware no puede predecir. La compensación es que los usuarios deben asegurarse de hacer una copia de seguridad adecuada de la frase de contraseña además de las palabras mnemotécnicas.

Derivación de clave pública

Las billeteras de hardware derivan y exportan el claves públicas (también llamado x pubs, corto para clave pública extendida como se define en BIP-32. x pubs se utilizan para generar las posibles direcciones de recepción de monedas.

😈 El dispositivo maligno podría devolver claves públicas controladas por el atacante en lugar de las correctas derivadas de la semilla.

🛡️ Los usuarios podrán validar el derivado xpub en otro dispositivo fuera de línea. Sin embargo, ingresar la semilla en otros dispositivos conlleva sus propios riesgos. Los usuarios conscientes de la seguridad pueden considerar cualquier dispositivo que haya accedido a la semilla como peligroso, potencialmente hasta el punto de destruirlos. El usuario típico puede tener dificultades para realizar correctamente este procedimiento mientras gestiona los riesgos adicionales.

Fuga de información

An espacio de aire se propone con frecuencia como una solución para evitar que un dispositivo malicioso o comprometido extraiga claves privadas. Después de todo, si un dispositivo no puede comunicarse con el mundo exterior, no puede hacer nada dañino, ¿verdad?

¡No exactamente!

El dispositivo siempre puede comunicarse cuando está en uso: produce firmas. Estas firmas terminan dentro de transacciones que se transmiten y almacenan para siempre en la cadena de bloques.

Una firma es una cadena de bytes de aspecto aleatorio de al menos 64 bytes. Sin embargo, dado que más de una firma válida puede corresponder al mismo mensaje, un dispositivo malicioso podría comunicar algunos bits de información cada vez que se produce una firma, generando varias firmas y eligiendo selectivamente cuál publicar.

😈 ¡Un dispositivo malicioso puede producir firmas no aleatorias que, en muchas transacciones, revelan la semilla al atacante!

Un atacante que lograra instalar una puerta trasera de este tipo simplemente tendría que esperar a que aparecieran firmas maliciosas en la cadena de bloques hasta que tuviera suficiente información para reconstruir la semilla completa.

🛡️ Para firmas ECDSA, usando un método estandarizado para derivar el nonce de forma determinista (como RFC6979) frustra este ataque, siempre que se valide que la firma producida coincida con la esperada. Sin embargo, garantizar que esto sea así requiere cargar un segundo dispositivo con la misma semilla, lo que conduce a los mismos problemas prácticos mencionados en la sección anterior.

🛡️ Un enfoque interesante es utilizar una forma inteligente de forzar el dispositivo para elegir realmente un nonce aleatorio. Un protocolo para este propósito, conocido como antiexfiltración or anti-cleptómano, se implementa actualmente en las billeteras de hardware Blockstream Jade y ShiftCrypto BitBox02. Leer más sobre Blog de ShiftCrypto, que también incluye una descripción técnica de cómo podría ejecutarse dicho ataque.

Ok, entonces, ¿no hay esperanza?

La mayoría de las defensas🛡️ enumeradas anteriormente requieren que el usuario realice acciones explícitas e intrusivas para protegerse: ya sea generando la semilla por su cuenta (esencialmente, usando su cerebro para reemplazar la funcionalidad de la billetera de hardware) o utilizando un dispositivo adicional para verificar que los cálculos se ejecutan correctamente.

Sin embargo, se destaca el protocolo anti-exfil: dado que siempre hay una máquina intermediando entre el firmante del hardware y el mundo exterior, esta máquina puede ayudar. A través de un protocolo interactivo con el firmante del hardware, puede hacer cumplir el uso de un nonce genuinamente aleatorio, lo que disminuye o elimina la posibilidad de manipular significativamente la firma final.

En esta publicación de blog, estamos interesados ​​principalmente en este tipo de medidas: si bien las estrategias que empeoran significativamente la UX podrían ser atractivas para los usuarios avanzados, es probable que hagan las cosas peor en la práctica para los usuarios menos expertos técnicamente, que es la gran mayoría.

El modelo de seguridad

Modelo estándar para firmantes de hardware

Los fabricantes de firmantes de hardware tienen como objetivo proteger a los usuarios de una variedad de amenazas potenciales (para obtener más detalles, consulte Modelo de amenaza). En este artículo, nos centramos en una propiedad muy importante, que se puede resumir de la siguiente manera:

Los usuarios no pueden ser engañados en una acción que resulte en la pérdida de fondos, siempre que entiendan y verifiquen la información en pantalla antes de la aprobación.

Se necesita aprobación para cualquier acción sensible, particularmente las firmas. ¡Proteger la semilla sería inútil si el malware pudiera producir firmas para mensajes arbitrarios, como una transacción que agota todos los fondos!

Es crucial enfatizar que la propiedad anterior debe ser cierta incluso si la billetera de software está completamente comprometida. No se puede confiar en lo que se muestra en la pantalla de su computadora portátil/teléfono: el malware podría reemplazar direcciones, engañarlo sobre cuáles son las suyas, presentar una transacción pero luego reenviar una diferente al dispositivo para que la firme, etc.

Por lo tanto, el firmware y las aplicaciones que se ejecutan en un dispositivo de firma de hardware consideran la billetera de software inherentemente no confiable y poco fiable.

Modelo de seguridad anti-puerta trasera para carteras de software

En esta sección, cambiamos los roles por completo. Ahora queremos diseñar un billetera de software que evita que el fabricante del hardware robe o cause la pérdida de fondos, incluso si el dispositivo es completamente malicioso.

Por lo tanto, esto no puede ser una propiedad de la dispositivo: más bien, es una propiedad del billetera de software configuración. Podríamos resumirlo de la siguiente manera:

Siempre que la billetera de software no se vea comprometida, el fabricante del hardware no puede hacer que el usuario pierda fondos.

Esto puede parecer contradictorio, ya que contradice directamente el modelo de seguridad estándar detallado anteriormente. Sin embargo, “no tener una puerta trasera” significa “hacer exactamente lo que se supone que deben hacer”. Dado que la billetera de software es el sol interfaz entre el dispositivo de firma y el mundo exterior, es el único lugar donde se puede hacer cumplir la protección contra el mal comportamiento, ya sea debido a un error o compromiso explícito del dispositivo.

Tenga en cuenta que este modelo se extiende significativamente más allá de una falla del dispositivo, como un error explotable. En este caso, estamos operando en un escenario en el que el dispositivo busca activamente causar la pérdida de fondos.

Por supuesto, no hay protección posible si el fabricante ha comprometido con éxito ambas el dispositivo y también su máquina que ejecuta la billetera de software. Por lo tanto, es absolutamente vital asegurarse de que su billetera de software sea de código abierto y auditable, especialmente si la crea el mismo proveedor que fabrica el hardware.

El papel del miniguion

Miniscript equipa a los desarrolladores de billeteras con la capacidad de utilizar completamente las funciones avanzadas de bitcoin Script. Para obtener una descripción general de las increíbles posibilidades que abre el miniscript, consulte nuestra publicación de blog anterior. Es posible que también desee escuchar Episodio 452 del Podcast de Stephan Livera para una discusión sobre lo que miniscript aporta al panorama de bitcoin.

La aplicación Ledger Bitcoin admite miniscript desde su lanzamiento 2.1.0, que se implementó en febrero de 2023. En la conferencia Bitcoin 2023 en Miami, Wizardsardine anunció el lanzamiento 1.0 de su billetera liana, la primera billetera implementada basada en miniscript.

La idea básica de esta publicación es que una cuenta de billetera bitcoin puede protegerse no solo con uno, sino con múltiples llaves. Esto permite marcos de seguridad flexibles donde incluso una falla total o el compromiso de una clave no es catastrófico.

Reflexiones multigrado

Multisig es una mejora significativa en la solidez de una solución de autocustodia. Al aprovechar la capacidad de programación de Bitcoin Script, permite la creación de billeteras que requieren múltiples claves en lugar de solo una. A k-de-n billetera multisig requiere una combinación de k firmas válidas, de un total de n los posibles.

Sin embargo, multisig también impone una carga de UX al usuario e introduce nuevas oportunidades de errores. Una configuración multisig 3 de 3, que involucra tres claves diferentes respaldadas de forma segura en ubicaciones separadas, ofrece una seguridad sólida... pero también significa que si incluso un soltero ¡La llave se pierde, las monedas se vuelven permanentemente inaccesibles!

Por lo tanto, las configuraciones que ofrecen más redundancia (como 2 de 3 o 3 de 5) tienden a ser más populares: si se pierde una sola clave, las otras claves aún pueden facilitar la recuperación. Pero esto presenta una compensación: si una clave se ve comprometida sin que usted lo sepa, ¡la seguridad general se reduce significativamente!

Empresas como Hogar y Capital no activado se especializan en soluciones de autocustodia en las que tienen una minoría de las llaves para sus clientes. También ayudan a sus usuarios guiándolos a través del proceso de incorporación y simplificando el uso de los sistemas de custodia, que de otro modo puede ser desalentador para la mayoría de los usuarios no técnicos.

Miniscript y rutas de recuperación con bloqueo de tiempo

Liana usa miniscript para crear billeteras que tienen múltiples formas de gastar:

• una condición de gasto principal, que está disponible de inmediato;
• una o más condiciones de gasto adicionales que estén disponibles después de un cierto período (el llamado bloqueo de tiempo).

Esto permite muchos casos de uso interesantes:

• Recuperación: una billetera estándar con firma única o multisig como ruta de gasto principal; pero un mecanismo de recuperación separado (una clave con una semilla diferente, un multisig, un amigo experto en tecnología, un custodio) está disponible después de 6 meses.
• Gobierno: Una empresa con dos directores podría establecer un 2 de 2 para la tesorería de la empresa; en caso de desacuerdo, un abogado de confianza podría acceder a los fondos después de 6 meses.
• Multigrado en descomposición: Una billetera comienza como 3 de 3, pasa a 2 de 3 después de 6 meses y se convierte en 1 de 3 después de 9 meses.
• Herencia automática: El camino de recuperación después de 6 meses incluye un 2 de 3 de sus tres hijos; tal vez una segunda ruta de recuperación después de 1 año involucre a un notario, en caso de que los herederos no puedan llegar a un consenso.

Observación: todos los ejemplos anteriores usan un bloqueo de tiempo relativo, que hace referencia a la antigüedad de las monedas (es decir: la última vez que se movieron los fondos). La compensación es que el usuario debe acordarse de gastar las monedas (enviándoselas a sí mismo) si el bloqueo de tiempo está a punto de caducar.

Estos son solo algunos ejemplos, pero deberían ser suficientes para convencer al lector de que el miniscript es un paso significativo hacia la realización del potencial de Bitcoin como dinero programable.

Registro de política de billetera

Para las cuentas de billetera Bitcoin que utilizan múltiples claves (ya sea multisig o soluciones más sofisticadas basadas en miniscript), es crucial entrenar el dispositivo para identificar las direcciones que pertenecen a esa cuenta. Esta es la única forma en que el dispositivo puede ayudar al usuario a asegurarse de que está recibiendo o gastando en las direcciones correctas...

Validación de la póliza y la x pubs del cosignatario contra una copia de seguridad de confianza es esencial, pero requiere relativamente mucho tiempo.
La buena noticia es que solo hay que hacerlo una vez:

Una vez que se registra una política con un nombre (en el ejemplo, "3 de 3 en descomposición"), su dispositivo podrá reconocerla cada vez que se emplee dicha política.

Aquellos interesados ​​en detalles técnicos pueden encontrar más información en el propuesta BIP.

Respaldo de política

Un aspecto crítico a tener en cuenta es que, si bien las políticas de claves múltiples permiten un subconjunto de llaves privadas para autorizar transacciones, el conocimiento de todo el las claves públicas (y la exacto política) son obligatorios.

Sin embargo, a diferencia de la semilla, hacer una copia de seguridad de la política y las claves públicas es mucho menos riesgoso: si alguien lo descubriera, podría rastrear todas las transacciones vinculadas a esa política. Aunque esto no es lo ideal, ¡la privacidad es importante! − no es tan desastroso como perder sus monedas y menos atractivo para los posibles atacantes. En consecuencia, almacenar múltiples copias de la póliza en hot wallets, imprimirla y almacenarla en varios lugares, cifrarla y almacenarla en almacenamiento en la nube, etc., son estrategias viables.

La billetera de una sola firma que no se puede volver atrás

Demos un paso atrás. Hemos discutido las billeteras de múltiples firmas, pero ahora vamos a volver a lo básico para crear una billetera de una sola firma. Más precisamente, queremos una billetera que se siente y miradas como una billetera de firma única, después de una fase de configuración inicial. Sin embargo, nuestro objetivo es crear una billetera de la que el fabricante no pueda robar sus fondos, incluso si son maliciosos 😈, y el dispositivo de firma de hardware se comporta de manera impredecible.

El enfoque se puede generalizar fácilmente para billeteras de múltiples firmas.

Los siguientes ejemplos estarán escritos en un lenguaje llamado política, en lugar de miniguión. La política es más fácil de leer y pensar para los humanos, y se puede compilar en miniscript con herramientas automatizadas. Leer más sobre miniscript y política.

La billetera de hardware puede protegerlo en el modelo de seguridad estándar. Miniscript puede protegerlo en el modelo de seguridad anti-backdoor (¡y mucho más!).

Paso cero: el statu quo

Esta es la política que la mayoría de los usuarios utilizan hoy en día: una clave única que se deriva de una semilla producida en la billetera de hardware.

pk(key_ledger)

Por supuesto, no hay forma de probar la ausencia de una puerta trasera.

Paso uno: dobla esas teclas

El primer paso es sencillo:

and(pk(key_ledger), pk(key_client))

Aquí, key_client se genera en la máquina del usuario, por lo tanto, un tecla de acceso rápido. Esencialmente, es una configuración multigrado 2 de 2. El aspecto clave es que el usuario no interactúa mucho con key_client: la billetera de software genera esta clave, la incluye en la copia de seguridad de la billetera y firma cuando sea necesario (por ejemplo, mientras el usuario está ocupado firmando con su firmante de hardware).

Esto ya parece bastante interesante: los fondos son indiscutibles sin key_client, que no está disponible para el proveedor de hardware; incluso si el malvado proveedor tuviera pleno conocimiento de la clave en el dispositivo, aún no podría mover los fondos sin apuntar explícitamente al usuario, por ejemplo, al comprometer la máquina que ejecuta su billetera de software.

Sin embargo, hay un problema: durante la incorporación de la billetera, el firmante del hardware es la única entidad capaz de generar la clave pública (xpub) key_ledger usado en la billetera. Por lo tanto, el dispositivo podría generar intencionalmente un Mal xpub controlado por el atacante, y luego rechazar (o ser incapaz) de firmar. Podría decirse que este es un escenario de ataque bastante extremo: el creador de la puerta trasera no puede robar los fondos, y lo máximo que puede hacer es apuntar individualmente al usuario y exigir un rescate ("Puedo ayudarlo a recuperar su dinero si me paga la mitad").

De manera más realista, esto aumenta la posibilidad de errores de errores: ahora tiene dos semillas / claves privadas, y necesita ambas para poder gastar. Pierde cualquiera de las dos y las monedas quedan bloqueadas para siempre.

Paso dos: recuperación programada

Presentamos una clave de recuperación separada, accesible solo después de un bloqueo de tiempo específico: and(older(25920), pk(key_recovery)), donde 25920 es el número aproximado de bloques en 6 meses. La póliza completa se convierte en:

or(
  and(pk(key_ledger), pk(key_client)), and(after(25920), pk(key_recovery))
)

Esto es similar al escenario anterior, pero con un giro: si key_ledger or key_client deja de estar disponible por algún motivo (más comúnmente, ¡perdiendo la copia de seguridad inicial!), un camino de recuperación se vuelve accesible después de 6 meses.

Hay varias opciones para key_recovery, cada uno con sus propias compensaciones:

a. Usa otro tecla de acceso rápido. Esta es una solución práctica siempre que el usuario recuerde restablecer el bloqueo de tiempo. Sin embargo, si las teclas de acceso rápido están comprometidas (¡un escenario que generalmente debería considerarse bastante probable!), el atacante podría intentar acceder a los fondos tan pronto como expire el bloqueo de tiempo, iniciando una carrera con el propietario legítimo.

b. Utilice un dispositivo de firma de hardware independiente. Esta es una solución robusta y se puede usar en combinación con un proveedor diferente si se desea; sin embargo, aumenta la complejidad de la configuración y el costo para el usuario en términos de experiencia de usuario.

c. Utilice un servicio externo de confianza. La billetera de software podría importar un xpub desde un servicio externo, usándolo como key_recovery. Solo se confía en este tercero si el bloqueo de tiempo caduca, lo que podría ser una compensación atractiva para algunos usuarios.

Como se mencionó, al igual que para cualquier política con bloqueos de tiempo, es importante que el usuario recuerde actualizar las monedas antes de que expire el bloqueo de tiempo.

Paso tres: el tercero no confiable

Combinemos ambas ideas (a) y (c): para la ruta de recuperación, necesitamos una tecla de acceso rápido local key_recovery_local, Y un key_recovery_remote que está alojado con un servicio semi-confiable; también conservamos el bloqueo de tiempo.

or(
and(pk(key_ledger), pk(key_client)),
  and(older(25920),
    and(pk(key_recovery_local), pk(key_recovery_remote))
)
)

Esto disminuye el nivel de confianza necesario del servicio de recuperación. Sin embargo, debemos tener cuidado: el servicio en sí podría estar monitoreando la cadena de bloques y detectando nuestros UTXO; después de todo, nos proporcionaron la key_recovery_remote xpub, para que puedan buscar UTXO que contengan claves públicas derivadas de key_recovery_remote. Podrán conocer nuestro historial financiero, incluso antes de que caduque el bloqueo de tiempo, e incluso si nunca utilizamos su servicio.

Observación: Los árboles de raíz pueden eliminar este problema de privacidad para ciertas políticas, pero no siempre es así y requiere una evaluación cuidadosa basada en la política específica.

Paso cuatro: cegar al tercero 🙈

Para evitar que el servicio de recuperación conozca nuestro historial financiero, en lugar de usar la clave pública que nos comunican, podemos usar un xpub ciego la técnica explicado por mflaxman en detalle aquí. En resumen, en lugar de usar key_recovery_remote en nuestra política, elegimos cuatro números aleatorios de 31 bits a, b, c, d (la factores de cegamiento), y usamos lo siguiente BIP-32 clave pública derivada:

key_recovery_remote_blind = key_recovery_remote_blind/a/b/c/d

Es crucial que también añadamos key_recovery_remote, y los factores de cegamiento a, b, c y d a nuestra copia de seguridad, para referencia futura.

Si alguna vez necesitamos usar el servicio de recuperación, revelaremos a, b, c, d a ellos Hasta entonces, no tienen forma de descubrir que las claves derivadas de su key_recovery_remote se están publicando en la cadena de bloques: el número de combinaciones posibles para los 4 factores de cegamiento es 2^(31*4) = 2^124, lo que hace que sea imposible aplicarles fuerza bruta a todos.

Paso cinco: demasiadas teclas de acceso rápido pueden quemarte 🔥

Tuvimos éxito en hacer que nuestra billetera de software no fuera compatible con puertas traseras. Sin embargo, presentamos un problema diferente: ambas condiciones de gasto utilizan una generación local, calientes clave que no está verificada por la billetera de hardware. Por lo tanto, si la máquina host está comprometida, podría engañarlo para que registre la política usando las claves públicas. key_client y key_recovery_local, pero coloque claves privadas aleatorias y no relacionadas en nuestra copia de seguridad (recuerde, el calientes ¡las llaves son parte de nuestra copia de seguridad!).

Eso básicamente haría que los fondos enviados a la billetera indiscutible, ya que nadie controla las claves privadas necesarias para firmar.

Hay algunas soluciones para resolver este problema:

• Durante la incorporación, después de imprimir nuestra copia de seguridad en papel, podemos usar un dispositivo separado para verificar que las teclas de acceso rápido privadas y públicas en la copia de seguridad coincidan. Este enfoque eliminaría el problema, ya que estaríamos seguros de que tenemos todas las claves necesarias para la reconstrucción y la firma.
• Podemos agregar otra condición de gasto con un período de tiempo aún más largo (9 meses, 38880 bloques) que solo requiere un key_ledger_failsafe desde el dispositivo de hardware. De esta forma, en el peor de los casos, donde todo lo demás falla, volvemos a la seguridad de un único dispositivo de firma. En operaciones normales, nunca dejaríamos que el primer bloqueo de tiempo expire, por lo tanto, ¡el segundo bloqueo de tiempo tampoco expirará!

Con el segundo enfoque, la política final se vería así

or(
  and(pk(key_ledger), pk(key_client)),
  or(
    and(older(25920),
        and(pk(key_recovery_local), pk(key_recovery_remote_blind))
    ),
    and(older(38880), pk(key_ledger_failsafe))
  ),
)

Esta configuración de billetera de software satisface todas las propiedades de seguridad que reclamamos al principio. Además, ofrece una vía de recuperación en caso de que las principales claves de gasto key_ledger Esta perdido. ¡Una buena característica para tener!

Incorporación a la billetera de software sin respaldo

¿Cómo sería la experiencia del usuario para una billetera usando una política tan compleja? He aquí una breve descripción:

• El usuario abre la billetera del software y comienza a crear una nueva cuenta.
• La billetera de software solicita al usuario que conecte su dispositivo de firma y recupera los xpubs para key_ledger y key_ledger_failsafe.
• La billetera de software genera de forma autónoma la tecla de acceso rápido key_client.
• La billetera de software obtiene key_recovery_remote de un servicio de firma conjunta o permite al usuario especificar una clave de otra manera. Opcionalmente, calcula el key_recovery_remote_blind usando la técnica de cegamiento mencionada anteriormente.
• La billetera de software genera una copia de seguridad de la política que contiene la política de miniscript precisa, todos los xpubs y la clave privada extendida para el key_client tecla de acceso rápido Esta copia de seguridad se almacena de forma segura (por ejemplo, se imprime en papel o se guarda en un dispositivo separado).
• Finalmente, la billetera de software le indica al usuario que registre la póliza en el dispositivo. El usuario verifica la copia de seguridad (en papel o en cualquier otro medio que no sea la pantalla controlada por la billetera del software).

La billetera de software administra la mayoría de los pasos anteriores, lo que hace que la participación del usuario no sea más onerosa que el esfuerzo esperado que se necesita hoy para configurar una billetera de múltiples firmas.

La incorporación solo debería requerir unos minutos una vez que se haya creado una buena experiencia de usuario. Una vez completada, la billetera de software puede proporcionar una experiencia de usuario muy similar a la de una billetera típica de firma única. Así es como miniscript lo cambiará todo: ¡desapareciendo de la vista del usuario!

Mejoras de raíz principal

Ledger admite miniscript desde la versión 2.1.0 de la aplicación Bitcoin, lanzada en marzo. Si bien el soporte para recibir y gastar desde direcciones taproot estuvo habilitado desde el bifurcación primaria en noviembre de 2021, ahora estamos dando los toques finales al siguiente paso de la hoja de ruta: compatibilidad con miniscript para taproot.

Taproot tendrá un gran impacto en la usabilidad de los enfoques presentados en este artículo. Si la ruta de gasto principal es una condición de gasto de clave única, la existencia de rutas de gasto de recuperación será indetectable en la cadena de bloques a menos que se utilicen. Esto mejorará en gran medida la privacidad al eliminar por completo cualquier huella digital para la ruta de gasto estándar. Además, mejora la escalabilidad, ya que la ruta de gasto estándar se vuelve lo más rentable posible. Esto significa que no se incurrirá en ningún costo adicional debido a la presencia de rutas de recuperación, a menos que se utilicen. Esta es una actualización significativa de las transacciones de SegWit, que requieren la publicación de la secuencia de comandos completa, incluidas todas las condiciones de gasto, durante cualquier gasto.

Finalmente, protocolos más avanzados como MuSig2 (recientemente estandarizado) y ESCARCHA sobrecargará la ruta de acceso de la raíz primaria. Basados ​​en las firmas de Schnorr, estos protocolos permiten crear un único clave pública agregada que se puede utilizar para representar un n-de-n multifirma o una k-de-n esquema de umbral Esto permitiría el uso de la ruta de acceso de raíz principal incluso en casos que hoy en día se representan más comúnmente con scripts multisig específicos.

Conclusiones

Este artículo explora un nicho pequeño (pero importante) del vasto espacio de diseño que miniscript libera para las carteras de software.

Mostramos cómo se puede usar miniscript para crear una billetera de software "no retroactiva", al mismo tiempo que agregamos una ruta de recuperación adicional que permite evitar pérdidas de claves desastrosas. Si bien los dispositivos de firma de hardware no pueden hacer cumplir el modelo de seguridad anti-puerta trasera, al admitir miniscript, ¡habilitan billeteras de software que hacen exactamente eso!

Al utilizar hábilmente una combinación de esquemas de firmas múltiples, bloqueos de tiempo, xpubs ciegos y teclas de acceso rápido, hemos demostrado una configuración de billetera segura que equilibra la seguridad, la privacidad y la solidez.

Además, argumentamos que esto es posible sin afectar negativamente la experiencia del usuario, ya que la complejidad de la configuración no se traduce en una gran carga adicional de UX.

Estamos emocionados por las posibilidades que miniscript desbloqueará para la próxima generación de autocustodia de bitcoin.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Automoción / vehículos eléctricos, Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• Desplazamientos de bloque. Modernización de la propiedad de compensaciones ambientales. Accede Aquí.
• Fuente: https://www.ledger.com/blog/towards-a-trustless-bitcoin-wallet-with-miniscript