Frases de semilla BIP39 Qué son esas 12 palabras y cómo funciona la derivación de billeteras HD

Un mnemonic BIP39 es 128 o 256 bits de datos aleatorios, codificados como palabras humanamente legibles usando una lista fija de 2048 palabras. Eso es la clave. El «mágico» es simplemente que las palabras son más fáciles de escribir en papel que cadenas hexadecimales — criptográficamente, no hay nada especial en las palabras mismas.

Lo que se vuelve interesante es la pila de cuatro capas construida sobre ese codificación: BIP39 (la lista de palabras y la codificación), BIP32 (derivación jerárquica de claves determinísticas), BIP43 (convenios de campos de propósito) y BIP44 (estructura de moneda/cuenta/dirección). La mayoría de las explicaciones mezclan los cuatro. Este uno los separa.

La lista de palabras: 11 bits por palabra, incluido el checksum

El Lista de palabras en inglés de BIP39 tiene exactamente 2048 palabras. 2¹¹ = 2048, por lo que cada palabra codifica 11 bits de información. Una frase de 12 palabras lleva un total de 132 bits; una frase de 24 palabras lleva 264 bits.

No todos esos bits son entropía. Los últimos pocos bits de la última palabra son un checksum — los primeros ENT/32 bits de SHA256(entropy_bytes), donde ENT es la longitud de la entropía en bits:

Longitud de la frase	Bits de entropía (ENT)	Bits de checksum (CS = ENT/32)	Bits totales
12 palabras	128	4	132
15 palabras	160	5	165
18 palabras	192	6	198
21 palabras	224	7	231
24 palabras	256	8	264

El checksum es la razón por la que las frases «casi válidas» fallan. Invierta un solo bit de entropía y el byte del checksum cambia, haciendo que la frase sea inválida. Esto detecta errores de transcripción — específicamente los que caen en los bits del checksum. Las billeteras que validan antes de derivar claves rechazan la frase por completo. Algunas no validan; simplemente derivan una billetera a partir de entropía basura.

La asignación de entropía a palabras en Python:

import hashlib, os

# Generate 128 bits of entropy
entropy = os.urandom(16)  # 16 bytes = 128 bits

# Compute checksum: first 4 bits of SHA256(entropy)
h = hashlib.sha256(entropy).digest()
checksum_bits = format(h[0], '08b')[:4]  # first 4 bits of SHA256 output

# Combine entropy bits + checksum bits
all_bits = format(int.from_bytes(entropy, 'big'), '0128b') + checksum_bits
# all_bits is now 132 bits

# Split into 11-bit groups -> 12 word indices (0-2047)
word_indices = [int(all_bits[i:i+11], 2) for i in range(0, 132, 11)]
# Look up each index in the BIP39 word list to get the mnemonic

El mnemonic no es la clave: el paso PBKDF2

Aquí es donde la mayoría de las explicaciones se equivocan. Las 12 palabras no son tu clave privada y no se usan directamente para firmar. Son un codificación intermedia. Antes de que cualquier material de clave se derive, el mnemonic se estira mediante PBKDF2-HMAC-SHA512:

import hashlib

mnemonic = "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about"
passphrase = ""  # optional; empty string = no passphrase

seed = hashlib.pbkdf2_hmac(
    'sha512',
    mnemonic.encode('utf-8'),                    # password: the mnemonic words
    ('mnemonic' + passphrase).encode('utf-8'),   # salt: always "mnemonic" + passphrase
    2048,                                         # iterations
    dklen=64                                      # 512 bits output
)
# seed is 64 bytes (512 bits) -- this is what actually seeds key derivation

Dos cosas a notar:

• La sal siempre es la cadena literal "mnemonic" concatenada con la contraseña. Una contraseña vacía significa que la sal es simplemente "mnemonic" — no hay un modo separado de «sin contraseña».
• La contraseña cambia completamente el resultado del semilla. Las mismas 12 palabras con contraseña "A" vs "a" producen billeteras completamente diferentes con direcciones completamente diferentes. Esto es la característica de la «25ª palabra»: una contraseña te permite mantener una denegación plausible (dos billeteras a partir de una frase), pero perder la contraseña es permanente, incluso teniendo las 12 palabras en mano.

De semilla a clave principal: BIP32

La semilla de 512 bits se introduce en HMAC-SHA512 con la clave fija "Bitcoin seed". La salida de 64 bytes se divide en dos mitades de 256 bits:

import hmac, hashlib

master = hmac.new(b'Bitcoin seed', seed, hashlib.sha512).digest()
master_private_key = master[:32]   # left 256 bits: the actual EC private key
master_chain_code  = master[32:]   # right 256 bits: used for all child derivation

El código de cadena es la clave por la que las billeteras HD funcionan: evita que las claves derivadas se puedan forzar incluso si se conoce la clave principal. Sin él, conocer una clave pública padre y cualquier clave privada hija revelaría todas las claves privadas hermanas. Con el código de cadena, la derivación de claves hijas requiere tanto la clave padre como el código de cadena como entradas — y para derivaciones endurecidas, la clave privada padre directamente.

Juntas, master_private_key + master_chain_code forman la clave extendida principal, codificada como una xprv... cadena Base58Check. La clave extendida pública correspondiente es xpub... — útil para billeteras de lectura solo que necesitan derivar direcciones sin exponer el material de clave privada.

Rutas de derivación BIP44: m/44’/60’/0’/0/0 decodificada

BIP44 define una jerarquía de cinco niveles de derivación. Aquí está m/44’/60’/0’/0/0 — la ruta estándar para la primera dirección de Ethereum — descompuesta por componentes:

Nivel	Valor	Índice en hexadecimal	Significado
m	—	—	Raíz de la clave principal
44'	Propósito	0x8000002C	Propósito BIP44. Derivación endurecida (apóstrofo = 0x80000000 + índice).
60'	Tipo de moneda	0x8000003C	Ethereum, según SLIP-0044. Bitcoin = 0′, Solana = 501′, etc.
0'	Cuenta	0x80000000	Primera cuenta. Incrementa para cuentas aisladas separadas.
0	Cambio	0	Cadena externa (0 = direcciones de recepción, 1 = direcciones de cambio). Las billeteras raramente usan la cadena de cambio en cadenas EVM.
0	Índice	0	Índice de dirección. Incrementa para la segunda dirección, tercera, etc.

Los apóstrofos indican derivación endurecida. Las claves hijas endurecidas se derivan únicamente a partir de la clave privada padre, no de la clave pública padre. Esto importa porque con derivación normal (no endurecida), una clave privada hija comprometida más la clave pública padre revelaría la clave privada padre y todas las claves privadas hermanas. Para los niveles de propósito, tipo de moneda y cuenta, la derivación endurecida es la especificación.

¿Por qué la misma frase genera direcciones diferentes en diferentes billeteras?

La frase y la ruta predeterminada de la billetera son variables independientes. Las billeteras han tenido históricamente opiniones diferentes sobre la ruta, y algunas diferencias aún no están resueltas.

Para Ethereum, la principal división:

• MetaMask, Ledger Live, la mayoría de las billeteras modernas: m/44'/60'/0'/0/N — estándar BIP44.
• MyEtherWallet (ruta predeterminada legada): m/44'/60'/0'/N — una nivel más corta. Una billetera restaurada desde la misma frase en MEW con la ruta legada produce un conjunto completamente diferente de direcciones que MetaMask.
• Trezor Suite: Sigue el estándar BIP44 para ETH ahora, pero históricamente tenía sus propios detalles con algunas criptomonedas alternativas.

Para Bitcoin, la divergencia es estructural: BIP44 (m/44'/0'/0', legacy P2PKH, direcciones comienzan con 1), BIP49 (m/49'/0'/0', P2SH-P2WPKH, direcciones comienzan con 3), y BIP84 (m/84'/0'/0', P2WPKH nativo segwit, direcciones comienzan con bc1q) generan direcciones diferentes a partir de la misma semilla. El formato de dirección te dice cuál ruta se utilizó, por lo que el formato de dirección importa al resolver un problema de recuperación.

Si importas una frase y «los fondos no están allí», revisa la ruta de derivación antes de asumir que la frase es incorrecta. La mayoría de las billeteras te permiten especificar manualmente la ruta durante la importación avanzada.

Modos de fallo de seguridad

La criptografía aquí no es el punto débil. Cada ataque que funciona contra billeteras BIP39 ataca al lado humano del pipeline.

Phishing: «introduce tu frase de recuperación para continuar»

El ataque de mayor volumen por una amplia margen. Interfaces falsas de billeteras, extensiones del navegador inyectadas por scripts maliciosos, atendientes de soporte falsos en Discord — todos pidiendo a los usuarios que escriban sus 12 palabras en algún lugar. El modelo mental correcto: el software legítimo de billeteras nunca pide tu frase de recuperación después de la configuración inicial. Una solicitud de la frase es un ataque, independientemente de cómo parezca legítimo el interfaz.

Monitoreo del portapapeles

Malware que monitorea el portapapeles, detecta una secuencia de 12 o 24 palabras conocidas de BIP39 y exfiltrará. El periodo de exfiltración es de milisegundos. Copiar y pegar una frase de recuperación en cualquier lugar — incluso brevemente en un editor de texto — crea exposición. Los gestores de historial del portapapeles (Historial del portapapeles de Windows, gestores del portapapeles de macOS, historial de pegado en IDE) son especialmente de alto riesgo.

Capturas de pantalla y sincronización en la nube

Tomar una captura de pantalla de una frase de recuperación en un teléfono la sube a iCloud Photos o Google Photos en segundos, antes de que la mayoría de las personas terminen leerla. Esas copias no están cifradas en el cliente. «Tomé una captura para guardarlo con seguridad» es un camino directo de exfiltración. Un respaldo en papel en un lugar físicamente seguro no es una recomendación en broma.

Generación de frase de recuperación en el servidor

Cualquier sitio web que genere una frase BIP39 en el servidor tiene una copia de la entropía. El único lugar seguro para generarla es un dispositivo que controle, fuera de línea en el momento de la generación. Una billetera hardware, una máquina aislada, o una herramienta auditada en cliente. Un sitio web no es ninguno de esos — incluso si el JavaScript parece correcto, no puede verificar que el servidor no esté registrando el resultado.

Si necesitas inspeccionar o verificar la estructura de una frase — revisar la entropía, ver la semilla derivada, verificar una ruta — el Convertidor de Mnemónicos BIP39 corre completamente en el navegador. La frase nunca abandona tu máquina, lo cual es la única arquitectura segura para este caso de uso.

Desde el punto de vista del desarrollador: casi seguramente no deberías manejar frases de recuperación en tu aplicación

Si estás construyendo una aplicación cercana al mundo cripto, la intención de «manejar la frase de recuperación» en tu backend es casi siempre la mala decisión. El área de ataque:

• Registro. Cada marco web registra los cuerpos de solicitud en algún lugar. Una línea de depuración, un nivel de registro mal configurado, y cada frase que pasó por tu API está en el disco — indefinidamente, en múltiples destinos de registro que no auditaste.
• Tránsito. HTTPS protege el cable. No protege el equilibrador de carga, el proceso del backend, la base de datos o el agregador de logs. Cada uno es una superficie de brecha separada.
• Memoria. Los dumps de proceso, los informes de error, los archivos de core y las capturas de heap capturan cadenas en memoria. Una frase de recuperación en un diccionario de Python o un objeto de JavaScript no es cero-copia; probablemente aparezca en múltiples asignaciones antes de que se «elimine».
• Responsabilidad. Si tu backend procesa frases de recuperación de usuarios y te comprometes, el daño es permanente. A diferencia de las contraseñas, no hay mecanismo de recuperación. Los usuarios afectados pierden fondos sin posibilidad de reclamación.

La arquitectura que realmente funciona: deriva lo que necesitas en el lado del cliente y solo transmite el resultado — una clave pública, una clave xpub de solo lectura, una transacción firmada. El backend nunca ve la frase. Las bibliotecas que lo hacen correctamente: @scure/bip39 (auditada, mínima dependencia), ethers.jsy bitcoinjs-lib. Para integraciones con billeteras hardware, los SDKs de Trezor y Ledger devuelven una transacción firmada — la clave nunca abandona el dispositivo.

La cadena completa de derivación en resumen

Paso	Aporte	Operación	Producción
1. Entropía	128–256 bits aleatorios	Checksum SHA256 → grupos de 11 bits	Frase de 12 a 24 palabras
2. Semilla	Palabras de la frase + «mnemonic» + contraseña	PBKDF2-HMAC-SHA512, 2048 vueltas	Semilla de 512 bits (64 bytes)
3. Clave principal	Bytes de semilla	HMAC-SHA512(«Bitcoin seed», semilla)	Clave privada principal (256 bits) + código de cadena (256 bits)
4. Clave de cuenta	Clave principal + ruta m/44’/60’/0’	Derivación jerárquica endurecida de BIP32 × 3	Clave extendida de cuenta
5. Clave de dirección	Clave de cuenta + ruta /0/N	Derivación jerárquica normal de BIP32 × 2	Clave privada hija → clave pública secp256k1 → keccak256 → dirección

BIP39 hizo exactamente lo que fue diseñado para hacer: hizo que la entropía fuera escrita y recuperable. La superficie de ataque no está en la criptografía — PBKDF2 con 2048 vueltas, HMAC-SHA512, secp256k1 — todo eso es sólido. Los ataques son completamente operativos: introducir la frase en algún lugar donde no debería estar, almacenarla digitalmente, confiar en una herramienta que la genere en el servidor. La matemática está bien. El humano es la debilidad, por eso la recomendación para el desarrollador es «arquitectura de sistema para que la frase nunca toque tu infraestructura».

También te puede interesar