Guión:
Si una clave privada de una billetera determinista se ve comprometida (conocido por un aviso), ¿las otras claves (y la semilla) siguen siendo seguras?
Por diseño, este no es el caso de la billetera determinista electrum y los desarrolladores son conscientes de ello. ¿Qué hay de otras billeteras deterministas, por ejemplo, Armory?
El estándar propuesto para carteras deterministas jerárquicas (ver BIP 32 ) está diseñado para permitir esto (y más).
Todavía no está implementado, pero varios autores de clientes han acordado adoptarlo, una vez que sea definitivo.
Tenía la misma necesidad y no pude encontrar soluciones fáciles de usar, así que terminé rodando la mía. Soy nuevo en bitcoin y crypto, así que úsalo con cuidado:
Asumiré que puede crear su propia billetera, como dijo. Bajo tal circunstancia, le sugiero que siga la lógica a continuación.
En primer lugar, supongamos que alguien ha codificado (ya que el sitio web de blockchain lanzó algunas herramientas en su sección API) un software capaz de crear direcciones de bitcoin para usuarios externos. En tal escenario, si los algoritmos contenidos en dicho software, alojados en un servidor, pueden crear una billetera de múltiples firmas para los usuarios, en el sentido de que cierto usuario necesitaría ambas claves privadas (2 claves por cada dirección) creadas por el software para gastar las monedas de una billetera de una sola dirección, y si, por ejemplo, el servidor guarda la clave privada A y entrega al usuario la clave privada B, entonces tendríamos la situación de una "billetera híbrida en línea" donde solo el usuario puede usar ambas claves, A + B, para crear, firmar y transmitir transacciones relacionadas con su dirección de bitcoin.
Dicho sistema sería bastante seguro para el usuario si el propietario del software no tuviera conocimiento o interacción con la clave privada A (o B) y si el cifrado utilizado antes de almacenar esa clave privada A hiciera inútil a cualquier tercero (incluso si llega a allí) cualquier acceso a esa clave almacenada desde la base de datos del servidor.
Ahora, por otro lado, la única forma de construir una transacción y firmarla con ambas claves privadas podría tener lugar solo en el servidor (siendo esta una condición muy importante, como explicaré más adelante en este escenario).
Si el propietario del software está dispuesto a permitir que los usuarios abandonen el servidor con ambas claves (por ejemplo, solo para eliminar sus cuentas y establecer direcciones como algunas billeteras realmente frías), podría emplear dos opciones.
Una sería entregar directamente al usuario la clave privada A, lo que le permitiría usar en otro lugar (si es necesario y cuando sea necesario) las claves A y B para firmar transacciones, o la otra (de alguna manera mejor) en la que el algoritmo permite crear una tercera tecla, la tecla C, que podría usarse junto con la tecla B para gastar monedas desde esa dirección. Es decir, el usuario vuelve a salir con dos claves privadas en el bolsillo, suficientes para utilizarlas para vaciar la dirección correspondiente (clave pública). Eso se puede realizar utilizando una semilla (cierta clave privada "D"), única para el servidor (o para la cuenta de usuario), o estableciendo como semilla incluso la clave A. Si la clave A se usa como semilla, entonces, prácticamente cualquier persona con acceso al código fuente del software podría replicar todo el rango de direcciones creadas para el usuario específico (si la clave A es "específica de la cuenta del usuario" y no "específica de la dirección"). Veo que el último es imposible de usar por cualquier administrador de sistemas decente (si tiene la más mínima idea sobre los riesgos incurridos en una elección de seguridad de tan bajo nivel). Así que supongamos que el servidor crea semillas con mayores privilegios (también conocido como específico del usuario). Eso, nuevamente, podría tener consecuencias catastróficas para cualquier usuario descuidado que importara esa clave A a cualquier billetera desde un dispositivo infectado con malware. (¿Quizás eso nos recuerda de alguna manera a la billetera Electrum? :/ ...) Veo que el último es imposible de usar por cualquier administrador de sistemas decente (si tiene la más mínima idea sobre los riesgos incurridos en una elección de seguridad de tan bajo nivel). Así que supongamos que el servidor crea semillas con mayores privilegios (también conocido como específico del usuario). Eso, nuevamente, podría tener consecuencias catastróficas para cualquier usuario descuidado que importara esa clave A a cualquier billetera desde un dispositivo infectado con malware. (¿Quizás eso nos recuerda de alguna manera a la billetera Electrum? :/ ...) Veo que el último es imposible de usar por cualquier administrador de sistemas decente (si tiene la más mínima idea sobre los riesgos incurridos en una elección de seguridad de tan bajo nivel). Así que supongamos que el servidor crea semillas con mayores privilegios (también conocido como específico del usuario). Eso, nuevamente, podría tener consecuencias catastróficas para cualquier usuario descuidado que importara esa clave A a cualquier billetera desde un dispositivo infectado con malware. (¿Quizás eso nos recuerda de alguna manera a la billetera Electrum? :/ ...)
La última opción disponible que queda es aquella en la que el servidor tiene una clave semilla propia (con los privilegios más altos) a la que no puede acceder ningún tercero, y que se combina con al menos otra (servidor protegido con firma múltiple también).
Volviendo a su situación, debería tener la clave B que ofrece privilegios elevados (lo que le permite crear claves D y más, pero cualquiera que use la D no podrá crear otras claves). Sin embargo, debido a que tal cosa sería una carga para el código, sugeriría una opción más simple: la transacción de una sola vía. Lo que significa que importas en cualquier billetera de tu elección las claves después de una dulce limpieza de las funciones básicas. Como dijo una vez Henry Ford sobre sus autos "puedes pedir cualquier color, siempre y cuando sea solo negro".
La dirección importada, donde sea que esté almacenada, puede codificarse para hacer posible una sola operación : enviar un pago de la cantidad precisa únicamente hacia otra dirección X de usted (por ejemplo, solo puede enviar cada vez alrededor de 0.1 BTC hacia su billetera caliente -- dinero de bolsillo). ¿Necesitas algo más? Otro tramo fijo de 0.100 BTC, hacia la misma dirección. Solo eso. Un retoque perfecto. Por supuesto, la dirección X podría almacenarse en una billetera de hardware, completamente segura. Otros tipos de gastos pueden ser posibles solo usando el propio servidor (para desbloquear el control total sobre el saldo de la dirección).
Todo depende de cómo se creó su billetera determinista, si es algo basado en hash, sería seguro. Lo que necesita es que es imposible descubrir la semilla con las claves privadas reales, por lo que debe usar una función unidireccional (es decir, función hash).
Y, en general, comprometer una clave privada en una billetera no comprende el resto de la billetera.
KEY=HASH(SEED + offset)funcionaría también? De esa manera, SEEDni las otras direcciones ni las otras serían adivinables.La billetera Armory permite esto y no compromete la seguridad de la billetera en absoluto. Aunque compromete la integridad de sus copias de seguridad. Las billeteras deterministas son útiles porque puede hacer una sola copia de seguridad desde el principio (antes de usarla) y será una buena copia de seguridad para siempre.
Es decir, a menos que importe direcciones de otro lugar. Esas nuevas direcciones no estarán en su copia de seguridad anterior, por lo que debe hacer una nueva copia de seguridad en ese momento.
Alok