146 / 736SLIP39

SLIP-39

Copia de seguridad dividida en partes de recuperación

Cómo recuperar una cartera con suficientes partes de su copia y por qué no equivale a recortar una Seed Phrase ni a usar Multisig.

SLIP-39 es un estándar para respaldar una cartera mediante varias listas de palabras, llamadas partes de recuperación. Se decide de antemano cuántas partes diferentes harán falta. Con un esquema de dos de tres, por ejemplo, se puede perder una y aun así recuperar la cartera. Una sola no basta. El estándar, creado por SatoshiLabs, utiliza Shamir’s Secret Sharing, un método matemático para compartir un secreto. Sus partes no se obtienen simplemente reescribiendo una Seed Phrase de BIP 39.

Anna elige una copia de dos de tres. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. La cartera crea tres partes distintas y dos cualesquiera permiten recuperarla; ese mínimo se llama umbral. Dos fotografías de la misma parte siguen contando como una sola. El esquema sencillo utiliza un grupo. SLIP-39 admite reglas más complejas: por ejemplo, 2 de 3 grupos, con 2 de 3 partes necesarias en cada uno. Dos partes del grupo A y dos del B bastan. Tres de A y una de B no, porque solo está completo A. Importa la distribución, no solo cuántos papeles hay. [1] [6]

Cada lista contiene datos diferentes y la información necesaria para combinarlos correctamente. SLIP-39 utiliza un diccionario fijo de 1024 palabras inglesas; las palabras de la copia no se traducen aunque la interfaz esté en español. Un secreto de 128 bits produce partes de 20 palabras; uno de 256 bits, de 33. Un bit es una unidad básica de datos, no otra palabra que anotar. Cada parte incluye la identificación del conjunto, del grupo y de su posición, los umbrales y los ajustes de cifrado. La recuperación comprueba su coherencia y que las partes sean distintas. No se pueden mezclar listas arbitrarias solo porque tengan la misma longitud. [1]

Anna puede usar además una passphrase, una contraseña adicional elegida por ella. Reunir suficientes partes no la sustituye, y una combinación correcta no detecta por sí sola un error al escribirla: otra passphrase produce otro secreto maestro y, por tanto, otra cartera. Hay que comparar el resultado con direcciones conocidas, no conformarse con un aviso de copia válida. Sin passphrase se usa una entrada vacía. SLIP-39 permite los caracteres ASCII imprimibles 32–126: caracteres latinos básicos sin acentos, incluido el espacio. Es una regla de este estándar, no de todas las carteras. La passphrase no es el PIN que desbloquea el dispositivo. [1]

Una Seed Phrase de BIP 39 se genera de otra manera y utiliza otro diccionario. Repartir sus palabras entre papeles no las convierte en partes SLIP-39. Para conservar la misma cartera, una conversión tendría que mantener el seed, los datos secretos que originan el árbol de claves BIP 32, y la Derivation Path correcta, la ruta hasta las claves utilizadas. No basta recodificar la entropía original, los datos aleatorios anteriores a las palabras. BIP 39 calcula un seed de 512 bits a partir de las palabras y la passphrase; respaldarlo directamente con SLIP-39 produce partes de 59 palabras. Convertir una cartera tampoco traslada automáticamente las que se abren con otras passphrase. Hay que comprobar antes el procedimiento concreto admitido. [1] [3] [2]

Una copia compatible con el indicador extendable permite cambiar el reparto y conservar las mismas carteras. Trezor describe así el paso de una sola parte a varias. Pero cambiar los papeles no ha cambiado el secreto de Anna: una combinación antigua suficiente sigue funcionando. No deben mezclarse partes viejas y nuevas. Técnicamente, el indicador con valor 1 excluye el identificador del conjunto de la entrada auxiliar del cifrado llamada salt. Así, el mismo encrypted master secret (EMS), el secreto maestro cifrado, puede repartirse de nuevo con otro identificador sin conocer la passphrase. Esto no remedia la exposición de una copia antigua utilizable. [1] [4]

Una clave privada es un valor numérico secreto que la cartera utiliza para crear una firma digital que autoriza el gasto. Una vez recuperada, la cartera de Anna puede firmar de la manera habitual. Los poseedores de partes no tienen que aprobar cada pago: SLIP-39 recupera un secreto, mientras que Multisig exige varias firmas según las condiciones de gasto. Un incendio puede destruir tres partes guardadas en el mismo piso. Distribuirlas debe dificultar tanto su pérdida simultánea como que un atacante reúna las necesarias; un esquema más complejo también complica la recuperación. La prueba debe seguir un procedimiento admitido en un dispositivo fiable. La biblioteca de referencia python-shamir-mnemonic sirve a los desarrolladores para comprobar compatibilidad con ejemplos públicos de prueba, no para procesar tu copia real. Advierte expresamente que no protege los secretos de forma suficiente. [1] [4] [5] [6]

En una cartera BIP 32, el secreto maestro es el seed de entrada, no la raíz privada extendida ya calculada del árbol de claves. Primero se cifra el seed y después se divide el EMS resultante. El cifrado utiliza cuatro rondas de una construcción Feistel; cada una contiene PBKDF2-HMAC-SHA256 con 2500×2^e iteraciones, cuyo coste depende del exponente e almacenado. Es un tratamiento definido de la contraseña, no la incorporación de palabras aleatorias. La división opera byte a byte en GF(256), un entorno matemático con 256 valores. El polinomio guarda el secreto en f(255); si el umbral es al menos 2, f(254) contiene un dato de verificación llamado digest. [1] [2]

Las tres últimas palabras de una parte forman la suma de comprobación RS1024. Garantiza detectar errores que afecten como máximo a tres palabras, pero no es la firma del creador ni una prueba de propiedad. El estándar desaconseja la corrección automática: el programa podría producir palabras válidas pero diferentes. Al combinar partes, otro digest de 32 bits ayuda a detectar un conjunto incorrecto. También tiene una consecuencia teórica: quien tenga una parte menos de las necesarias puede descartar ciertos secretos candidatos mediante una búsqueda exhaustiva. Por eso requiere matices la afirmación matemática de que por debajo del umbral no se filtra información alguna. No significa que sea fácil romper la protección; explica por qué se exige un secreto original suficientemente fuerte. [1]

Para obtener la imagen más completa, lee esta entrada junto con Shamir Secret Sharing, BIP 39, Trezor, Multisig, HD Wallet, Seed Phrase. También enlazan con esta entrada BIP 39, Trezor, Pavol «Stick» Rusnák, Shamir Secret Sharing.

DOC · 001SLIP-0039 — Shamir Secret-Sharing for Mnemonic CodesEspecificación DOC · 002BIP 32 — Hierarchical Deterministic WalletsEspecificación DOC · 003BIP 39 — Mnemonic code for generating deterministic keysEspecificación DOC · 004Trezor — Multi-share BackupDocumentación DOC · 005Trezor — python-shamir-mnemonic reference implementationFuente primaria DOC · 006Bitcoin Developer Guide — WalletsDocumentación
Revisado: Fuentes primero · No es asesoramiento financiero