Frases de semente BIP39 O que essas 12 palavras realmente são e como funciona a derivação de carteira HD

Um mnemonic BIP39 é 128 ou 256 bits de dados aleatórios, codificados como palavras legíveis para humanos usando uma lista fixa de 2048 palavras. É isso o truque. O "mágico" é apenas que as palavras são mais fáceis de escrever em papel do que strings em hexa — criptograficamente, não há nada especial nas palavras em si.

O que torna interessante é a pilha de quatro camadas construída sobre essa codificação: BIP39 (a lista de palavras e a codificação), BIP32 (derivação hierárquica de chaves determinísticas), BIP43 (convenções de campo de propósito) e BIP44 (estrutura de moeda/conta/endereço). A maioria das explicações confunde essas quatro camadas. Esta separa-as.

A lista de palavras: 11 bits por palavra, incluindo checksum

O Lista de palavras em inglês BIP39 tem exatamente 2048 palavras. 2¹¹ = 2048, portanto cada palavra codifica 11 bits de informação. Uma frase de 12 palavras contém 132 bits no total; uma frase de 24 palavras contém 264 bits.

Não todos esses bits são entropia. Os últimos bits da última palavra são um checksum — os primeiros ENT/32 bits de SHA256(entropy_bytes), onde ENT é o comprimento da entropia em bits:

Comprimento da frase	Bits de entropia (ENT)	Bits de checksum (CS = ENT/32)	Bits totais
12 palavras	128	4	132
15 palavras	160	5	165
18 palavras	192	6	198
21 palavras	224	7	231
24 palavras	256	8	264

O checksum é o motivo pelo qual frases "quase válidas" falham. Inverta um único bit de entropia e o byte do checksum muda, tornando a frase inválida. Isso detecta erros de transcrição — especificamente os que ocorrem nos bits do checksum. As carteiras que validam antes de derivar chaves rejeitam a frase inteiramente. Algumas não validam; elas apenas derivam uma carteira a partir de entropia ruim.

A mapeamento entropia para palavras em 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

O mnemonic não é a chave: o passo PBKDF2

É aqui que a maioria das explicações erra. As 12 palavras não são sua chave privada e não são usadas diretamente para assinatura. Elas são uma codificação intermediária. Antes de qualquer material de chave ser derivado, o mnemonic é esticado através do 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

Dois pontos importantes:

• O sal é sempre a string literal "mnemonic" concatenada com a frase de senha. Uma frase de senha vazia significa que o sal é apenas "mnemonic" — não há modo separado de "sem senha".
• A frase de senha muda completamente o resultado da semente. As mesmas 12 palavras com frase de senha "A" vs "a" produzem carteiras completamente diferentes com endereços completamente diferentes. Isso é a "25ª palavra": uma frase de senha permite manter a denibilidade plausível (duas carteiras a partir de uma frase), mas perder a frase de senha é permanente, mesmo com as 12 palavras em mãos.

Da semente para a chave mestra: BIP32

A semente de 512 bits alimenta o HMAC-SHA512 com a chave fixa "Bitcoin seed". A saída de 64 bytes divide-se em duas metades 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

O código de cadeia é a chave para o funcionamento das carteiras HD: evita que as chaves derivadas sejam forçadas mesmo que a chave mestra seja conhecida. Sem isso, saber uma chave pública do pai e qualquer chave privada filha revelaria todas as chaves privadas dos irmãos. Com o código de cadeia, a derivação de chaves filhas exige tanto a chave do pai quanto o código de cadeia como entradas — e para derivação harden, a chave privada do pai diretamente.

Juntas, master_private_key + master_chain_code formam a chave privada estendida mestra, codificada como uma xprv... string Base58Check. A chave pública estendida correspondente é xpub... — útil para carteiras de visualização que precisam derivar endereços sem expor o material da chave privada.

Caminhos de derivação BIP44: m/44’/60’/0’/0/0 decodificado

O BIP44 define uma hierarquia de cinco níveis. Aqui está m/44’/60’/0’/0/0 — o padrão de endereço inicial do Ethereum — quebrado componente por componente:

Nível	Valor	Índice em hexa	Significado
m	—	—	Raiz da chave mestra
44'	Propósito	0x8000002C	Propósito BIP44. Derivação harden (apóstrofo = 0x80000000 + índice).
60'	Tipo de moeda	0x8000003C	Ethereum, de acordo com SLIP-0044. Bitcoin = 0′, Solana = 501′, etc.
0'	Conta	0x80000000	Primeira conta. Incremente para contas isoladas separadas.
0	Mudança	0	Cadeia externa (0 = endereços de recebimento, 1 = endereços de mudança). As carteiras raramente usam a cadeia de mudança para cadeias EVM.
0	Índice	0	Índice do endereço. Incremente para o 2º endereço, 3º, etc.

Os apóstrofos indicam derivação harden. As chaves filhas harden podem ser derivadas apenas a partir da chave privada do pai, não da chave pública do pai. Isso importa porque, com derivação normal (não harden), uma chave privada filha comprometida mais a chave pública do pai revelaria a chave privada do pai e todas as chaves privadas dos irmãos. Para os níveis de propósito, tipo de moeda e conta, a derivação harden é a especificação.

Por que a mesma frase gera endereços diferentes em carteiras diferentes

A frase e o caminho padrão da carteira são variáveis independentes. As carteiras historicamente discordaram sobre o caminho, e algumas discordâncias ainda não foram resolvidas.

Para o Ethereum, a principal divisão:

• MetaMask, Ledger Live, a maioria das carteiras modernas: m/44'/60'/0'/0/N — padrão BIP44.
• MyEtherWallet (padrão legado): m/44'/60'/0'/N — um nível mais curto. Uma carteira restaurada a partir da mesma frase em MEW com o caminho legado produz um conjunto completamente diferente de endereços do que o MetaMask.
• Trezor Suite: Segue o padrão BIP44 para ETH agora, mas historicamente tinha suas próprias particularidades com algumas moedas alternativas.

Para o Bitcoin, a divergência é estrutural: BIP44 (m/44'/0'/0', legacy P2PKH, endereços começam com 1), BIP49 (m/49'/0'/0', P2SH-P2WPKH, endereços começam com 3), e BIP84 (m/84'/0'/0', P2WPKH nativo segwit, endereços começam com bc1q) geram endereços diferentes a partir da mesma semente. O formato do endereço indica qual caminho foi usado, o que é o motivo pelo qual o formato do endereço importa ao resolver uma recuperação.

Se você importar uma frase e "os fundos não estão lá", verifique o caminho de derivação antes de assumir que a frase está errada. A maioria das carteiras permite que você especifique o caminho manualmente durante a importação avançada.

Modos de falha de segurança

A criptografia aqui não é o ponto fraco. Cada ataque que funciona contra carteiras BIP39 ataca o lado humano do pipeline.

Phishing: "insira sua frase de recuperação para continuar"

O ataque de maior volume, com uma margem significativa. Interfaces falsas de carteira, extensões do navegador injetadas por scripts maliciosos, atendentes falsos no Discord — todos pedindo aos usuários para digitar suas 12 palavras em algum lugar. O modelo mental correto: o software legítimo de carteira nunca pede sua frase de recuperação após a configuração inicial. Uma solicitação da frase é um ataque, independentemente de como pareça a interface.

Monitoramento do clipboard

Malware que monitora o clipboard, detecta uma sequência de 12 ou 24 palavras conhecidas BIP39 e extrai. A janela de extração é de milissegundos. Copiar e colar uma frase de recuperação em qualquer lugar — mesmo brevemente em um editor de texto — cria exposição. Gerenciadores de histórico do clipboard (Windows Clipboard History, gerenciadores de clipboard do macOS, histórico de colar em IDEs) são especialmente de alto risco.

Tirar screenshots e sincronização de fotos na nuvem

Fazer uma tela de captura de uma frase de recuperação em um celular a submete ao iCloud Photos ou Google Photos em segundos, antes que a maioria das pessoas leia de volta. Esses backups não são criptografados no lado do cliente. "Eu fiz uma captura para mantê-la segura" é um caminho direto de exposição. Um backup em papel em um local fisicamente seguro não é uma recomendação brincadeira.

Geração de mnemonic no servidor

Qualquer site que gere uma frase BIP39 no servidor tem uma cópia da entropia. O único lugar seguro para gerar é um dispositivo que você controla, offline no momento da geração. Uma carteira hardware, uma máquina com isolamento do ar ou uma ferramenta auditada no lado do cliente. Um site não é nenhum desses — mesmo que o JavaScript pareça correto, você não pode verificar se o servidor não está registrando a saída.

Se você precisar inspecionar ou verificar a estrutura de uma frase — verificar a entropia, ver a semente derivada, validar um caminho — o Conversor de Mnemônicos BIP39 executa totalmente no navegador. A frase nunca sai do seu computador, o que é a única arquitetura segura para esse uso.

O ponto de vista do desenvolvedor: você quase certamente não deveria lidar com frases de seed em seu aplicativo

Se você está construindo um aplicativo próximo à criptografia, a intuição de "lidar com a frase de seed" no seu backend é quase sempre errada. A superfície de ataque:

• Registro. Cada framework web registra corpos de requisição em algum lugar. Uma linha de depuração, um nível de log incorreto, e toda frase que passou pelo seu API está em disco — indefinidamente, em múltiplos destinos de log que você não auditou.
• Transição. O HTTPS protege o canal. Ele não protege o balanceador de carga, o processo do backend, a base de dados ou o agregador de logs. Cada um é uma superfície de ruptura separada.
• Memória. Arquivos de dump de processo, relatórios de falha, arquivos de core e snapshots de heap capturam strings em memória. Uma frase de seed em um dicionário Python ou objeto JavaScript não é zero-copy; ela provavelmente aparece em múltiplas alocações antes de ser "apagada".
• Responsabilidade. Se seu backend processa frases de seed dos usuários e você for comprometido, o dano é permanente. Diferente das senhas, não há mecanismo de redefinição. Os usuários afetados perdem fundos sem recurso.

A arquitetura que realmente funciona: derive o que você precisa no lado do cliente e transmita apenas a saída — uma chave pública, um xpub de leitura apenas, uma transação assinada. O backend nunca vê a frase. Bibliotecas que fazem isso corretamente: @scure/bip39 (audita, com dependências mínimas), ethers.jse, e bitcoinjs-lib. Para integrações com carteiras hardware, os SDKs do Trezor e Ledger retornam uma transação assinada — a chave nunca sai do dispositivo.

A cadeia completa de derivação em resumo

Etapa	Entrada	Operação	Saída
1. Entropia	128–256 bits aleatórios	Checksum SHA256 → grupos de 11 bits	12–24 palavras de mnemonic
2. Semente	Palavras do mnemonic + “mnemonic” + frase de senha	PBKDF2-HMAC-SHA512, 2048 rodadas	Semente de 512 bits (64 bytes)
3. Chave mestra	Bytes da semente	HMAC-SHA512(“Bitcoin seed”, semente)	Chave privada mestra (256 bits) + código de cadeia (256 bits)
4. Chave da conta	Chave mestra + caminho m/44’/60’/0’	Derivação de filhos BIP32 harden × 3	Chave privada estendida da conta
5. Chave do endereço	Chave da conta + caminho /0/N	Derivação de filhos BIP32 normal × 2	Chave privada filha → chave pública secp256k1 → keccak256 → endereço

O BIP39 fez exatamente o que foi projetado para fazer: tornar a entropia legível e recuperável. A superfície de ataque não está na criptografia — PBKDF2 com 2048 rodadas, HMAC-SHA512, secp256k1 — tudo isso é sólido. Os ataques são operacionais: inserir a frase em algum lugar onde não deveria, armazenar digitalmente, confiar em uma ferramenta que a gera no servidor. A matemática está correta. O humano é a fraqueza, o que é o motivo pelo qual a recomendação para o desenvolvedor é "arquitetar seu sistema para que a frase nunca toque sua infraestrutura".

Você também pode gostar