BIP 39

Alice crea una cartera que utiliza BIP39 y guarda sus palabras de recuperación de forma segura, siguiendo las instrucciones. Tiempo después, su teléfono se rompe. Sus bitcoins no han desaparecido de la red: ha perdido el dispositivo que guardaba las claves para firmar sus pagos. En un dispositivo de sustitución de confianza puede usar la opción de recuperación de una cartera compatible. Las mismas palabras, en el mismo orden y con la misma passphrase si la utilizó, producen la misma semilla. Los procedimientos posteriores vuelven a generar las claves privadas necesarias y la cartera localiza los pagos en la red Bitcoin. No es una cuenta cuya contraseña pueda restablecer el servicio de asistencia. Si Alice utilizaba una passphrase, también la necesita; el PIN de su antiguo teléfono no la sustituye. Ver un saldo de cero tras la recuperación no significa necesariamente que las monedas se hayan perdido: además de las palabras y la passphrase, hay que comprobar la cuenta y la configuración de recuperación. Por eso conviene verificar todo el proceso antes de guardar una cantidad importante. [1] [5] [13] [14]

Para una persona es más fácil copiar y comprobar palabras que una larga representación de datos informáticos. Marek Palatinus, Pavol Rusnak, Aaron Voisine y Sean Bowe propusieron una forma de convertir la aleatoriedad generada por un ordenador en algo que una persona pudiera copiar a mano. La propuesta recibió la fecha del 10 de septiembre de 2013 y figura en la especificación con el estado Deployed. Las palabras deben proceder de una entrada aleatoria de calidad; no debe inventarlas a partir de una frase favorita. Eso crearía una Brainwallet con un secreto humano predecible. Los nodos de Bitcoin no comprueban BIP39: validan transacciones y bloques, no el método con el que una cartera generó sus claves. [1]

Una copia bien escrita solo ayuda si sabe recuperar la cartera con ella. Antes de confiarle fondos importantes, compruebe en un dispositivo de confianza el procedimiento de recuperación recomendado por el fabricante. Además del orden exacto de las palabras, conserve la passphrase necesaria, los datos de la cartera y los posibles ajustes de derivación o firma. En una cartera habitual de una sola firma, quien disponga de la copia completa y la passphrase necesaria puede derivar las claves sin el dispositivo original; en Multisig siguen siendo necesarias las demás claves exigidas y las reglas correspondientes. Una fotografía, una copia en la nube, una impresora o el historial del portapapeles pueden exponer el secreto a otras personas y servicios. El papel y el metal tienen limitaciones físicas diferentes; ningún material evita por sí solo un robo. [9] [13] [14]

Por compatibilidad, BIP39 recomienda encarecidamente la lista inglesa: muchas carteras no admiten otras listas. Traducir la copia de seguridad no conserva la cartera original, porque la propia frase entra en la derivación. También hay que distinguir otros sistemas. Electrum utiliza su propio procedimiento de versionado para sus copias nativas; unas palabras parecidas no las convierten automáticamente en BIP39. SLIP39 es otro formato, con una lista propia de 1 024 palabras y reglas sobre cuántas partes se necesitan para recuperar el secreto. No consiste en cortar una copia BIP39 en trozos. Repartir 24 palabras entre varios sobres no crea Shamir Secret Sharing y puede empeorar tanto la protección como la posibilidad de recuperación. Siempre hay que conocer el formato real de la copia de seguridad. [1] [11] [12]

El punto de partida es la entropía: datos aleatorios de longitud ENT = 128, 160, 192, 224 o 256 bits. A ellos se añade una suma de comprobación formada por los primeros CS = ENT/32 bits del resultado de aplicar SHA-256 a los datos originales. El conjunto se divide en grupos de 11 bits, y cada grupo determina una palabra. La relación MS = (ENT+CS)/11 produce así exactamente 12, 15, 18, 21 o 24 palabras. Doce palabras representan 128 bits de aleatoriedad y 4 bits de comprobación; por tanto, los 132 bits no constituyen un secreto totalmente independiente. Con 24 palabras se trata de 256+8 bits. La confianza en la copia de seguridad empieza por el generador de números aleatorios, no por lo extrañas que parezcan las palabras. [1]

Cada grupo de 11 bits selecciona una entrada de una lista ordenada de 2 048 palabras. La primera palabra no es, por tanto, la primera clave privada: todas las palabras juntas representan los datos originales y su suma de comprobación. En la lista inglesa, las primeras cuatro letras bastan para distinguir las palabras. Sin embargo, esto no es una regla general para cualquier idioma ni una indicación para abreviar la copia de seguridad por cuenta propia al recuperarla. Cambiar el orden, sustituir una palabra por un sinónimo o traducirla modifica los datos de entrada. A veces el resultado tendrá una suma de comprobación inválida; otras veces será otra copia de seguridad válida. Por eso hay que conservar exactamente las palabras y su orden. [1] [2]

El ordenador necesita saber qué caracteres ha recibido realmente. BIP39 prescribe la normalización Unicode NFKD seguida de la codificación UTF-8, tanto para la frase de respaldo como para la passphrase. NFKD unifica algunas formas de escribir un carácter; por ejemplo, descompone ciertas letras con signos diacríticos. Dos escrituras distintas pueden dar el mismo resultado tras la normalización, pero el parecido visual por sí solo no lo garantiza. El orden de las palabras, los espacios y los caracteres de la passphrase siguen siendo relevantes. Un procedimiento de normalización diferente puede derivar otro seed durante la recuperación. La implementación de referencia y los vectores de prueba públicos ayudan a comprobar que un programa sigue el procedimiento especificado. [1] [3] [4]

PBKDF2 recibe dos entradas separadas. La entrada password contiene las palabras de respaldo reales. La segunda entrada se llama salt y aporta datos adicionales al cálculo criptográfico. Consiste en el texto literal «mnemonic» seguido de la passphrase, sin separador. Las propias palabras de respaldo no se vuelven a introducir aquí. Ambas entradas se normalizan con NFKD y se codifican en UTF-8. BIP39 establece HMAC-SHA512, 2 048 iteraciones y un resultado de 512 bits, es decir, 64 bytes. Sin passphrase, el salt sigue siendo «mnemonic»; solo la passphrase está vacía. El cálculo no descifra las palabras ni crea nueva aleatoriedad independiente. Por eso, si las palabras se filtran, las iteraciones por sí solas no protegen una passphrase fácil de adivinar. [1] [10]

BIP39 termina con el seed de 64 bytes. Otro estándar, BIP32, suele utilizar HMAC-SHA512 con la clave fija «Bitcoin seed» para derivar de él la clave privada maestra y un chain code de 32 bytes. El chain code contiene datos adicionales que se usan junto con una clave para derivar otras claves. Ambos elementos forman el punto de partida del árbol de claves. Reglas como BIP44, BIP49, BIP84 y BIP86 establecen distintas rutas de derivación y tipos de scripts. Así, durante una recuperación puede introducir las palabras y la passphrase correctas y aun así ver un saldo cero si el programa busca otra cuenta, otra rama u otro tipo de dirección. También importa el gap limit: cuántas direcciones consecutivas sin utilizar admite el programa al buscar. El nombre de la cartera original, los datos de las cuentas, las rutas de derivación o un Output Descriptor pueden aportar información que las palabras no contienen. [5] [6] [7] [8] [9] [14]

La passphrase es otra entrada secreta en la derivación del seed. No es el PIN del dispositivo, y BIP39 no puede avisarle de que ha introducido una incorrecta: también calcula un resultado para un valor distinto. Un error de escritura que cambie la entrada normalizada suele conducir a otra cartera, en la que no verá sus fondos. En cambio, distintas formas de escritura que produzcan el mismo resultado NFKD derivan el mismo seed. Quien consiga las palabras de respaldo y datos que le permitan reconocer la cartera buscada puede probar posibles passphrases sin conexión. Si utiliza una passphrase, necesita suficiente fortaleza, una forma fiable de introducirla y su propia copia de seguridad. Guardarla por separado debe reducir el riesgo de un robo conjunto, sin convertirla en un secreto que desaparezca con usted. [1] [13]

La suma de comprobación ayuda a detectar errores de escritura, pero no demuestra a quién pertenece una copia de seguridad ni si se generó de forma segura. Tiene 4 bits en una frase de 12 palabras y 8 bits en una de 24 palabras. Por eso, una secuencia de palabras elegida de manera uniforme y aleatoria de la lista correspondiente supera la comprobación con una probabilidad de 1/16 o 1/256, respectivamente. Detecta muchos errores, pero no todos, y tampoco los corrige por sí sola. Un atacante puede construir otra copia de seguridad con una suma válida. La especificación exige advertir cuando la suma no coincide y distingue entre comprobar las palabras y derivar el seed. Si la suma es inválida, investigue el formato de la cartera original; no introduzca su copia de seguridad real en un comprobador de Internet. [1]