BIP 39

A Alice cria uma carteira que utiliza BIP39 e guarda as palavras de recuperação em segurança, seguindo as instruções. Mais tarde, o telemóvel avaria. Os bitcoins não desapareceram da rede: perdeu o dispositivo que guardava as chaves usadas para assinar os seus pagamentos. Num dispositivo de substituição de confiança, pode recorrer à função de recuperação de uma carteira compatível. As mesmas palavras, na mesma ordem e com a mesma passphrase, caso a tenha usado, produzem o mesmo seed. Os procedimentos seguintes voltam a gerar as chaves privadas necessárias, e a carteira encontra os pagamentos na rede Bitcoin. Não se trata de uma conta cuja palavra-passe possa ser reposta pelo apoio ao cliente. Se a Alice utilizava uma passphrase, também precisa dela; o PIN do telemóvel antigo não a substitui. Um saldo de zero após a recuperação não significa necessariamente que as moedas se perderam: além das palavras e da passphrase, é preciso verificar a conta escolhida e as definições de recuperação. Por isso, convém verificar todo o processo antes de guardar um montante elevado. [1] [5] [13] [14]

É mais fácil copiar e conferir palavras do que uma longa representação de dados informáticos. Marek Palatinus, Pavol Rusnak, Aaron Voisine e Sean Bowe propuseram uma forma de converter aleatoriedade gerada por computador em algo que uma pessoa pudesse copiar à mão. A proposta recebeu a data de 10 de setembro de 2013 e tem o estado Deployed na especificação. As palavras devem resultar de uma entrada aleatória de qualidade; não devem ser inventadas a partir de uma frase de que goste. Esse procedimento criaria uma Brainwallet com um segredo humano previsível. Os nós Bitcoin não verificam BIP39: validam transações e blocos, não o método pelo qual a carteira gerou as suas chaves. [1]

Um registo correto só ajuda se souber recuperar a carteira a partir dele. Antes de confiar valores importantes à carteira, verifique num dispositivo de confiança o procedimento de recuperação recomendado pelo fabricante. Além da ordem exata das palavras, preserve a passphrase necessária, os dados da carteira e as eventuais definições de derivação ou assinatura. Numa carteira habitual de assinatura única, quem possuir a cópia completa e a passphrase necessária pode derivar as chaves sem o dispositivo original; em Multisig, é necessário cumprir os requisitos relativos às outras chaves e às regras de assinatura. Uma fotografia, uma cópia na nuvem, uma impressora ou o histórico da área de transferência podem expor o segredo a outras pessoas e serviços. O papel e o metal têm limitações físicas diferentes; nenhum material impede, por si só, um roubo. [9] [13] [14]

Por razões de compatibilidade, BIP39 recomenda vivamente a lista inglesa: muitas carteiras não suportam outras listas. Traduzir a cópia de segurança não preserva a carteira original, porque a própria frase entra na derivação. É também necessário distinguir outros sistemas. Electrum utiliza um procedimento próprio de controlo de versões para as suas cópias nativas; palavras semelhantes não as tornam automaticamente BIP39. SLIP39 é um formato diferente, com uma lista própria de 1 024 palavras e regras sobre quantas partes são necessárias para recuperar o segredo. Não consiste simplesmente em cortar uma cópia BIP39 em pedaços. Distribuir 24 palavras por vários envelopes não cria Shamir Secret Sharing e pode prejudicar tanto a proteção como a possibilidade de recuperação. É sempre necessário conhecer o verdadeiro formato da cópia de segurança. [1] [11] [12]

O ponto de partida é a entropia, ou seja, dados aleatórios com comprimento ENT = 128, 160, 192, 224 ou 256 bits. Acrescenta-se uma soma de verificação formada pelos primeiros CS = ENT/32 bits do resultado de aplicar SHA-256 aos dados originais. O conjunto divide-se em grupos de 11 bits, e cada grupo determina uma palavra. A relação MS = (ENT+CS)/11 produz assim exatamente 12, 15, 18, 21 ou 24 palavras. Doze palavras representam 128 bits de aleatoriedade e 4 bits de verificação; os 132 bits não constituem, portanto, um segredo inteiramente independente. Com 24 palavras, são 256+8 bits. A confiança na cópia de segurança começa no gerador de números aleatórios, não no aspeto invulgar das palavras. [1]

Cada grupo de 11 bits seleciona uma entrada de uma lista ordenada de 2 048 palavras. A primeira palavra não é, portanto, a primeira chave privada: todas as palavras em conjunto representam os dados originais e a respetiva soma de verificação. Na lista inglesa, as primeiras quatro letras bastam para distinguir as palavras. Contudo, isto não é uma regra geral para qualquer idioma nem uma indicação para abreviar a cópia de segurança por iniciativa própria ao recuperá-la. Alterar a ordem, substituir uma palavra por um sinónimo ou traduzi-la muda os dados de entrada. Por vezes, o resultado terá uma soma de verificação inválida; noutros casos, será outra cópia de segurança válida. É por isso necessário preservar exatamente as palavras e a sua ordem. [1] [2]

O computador precisa de saber que caracteres recebeu realmente. BIP39 exige a normalização Unicode NFKD, seguida da codificação UTF-8, tanto para a frase de recuperação como para a passphrase. NFKD uniformiza algumas formas diferentes de escrever caracteres; por exemplo, decompõe certas letras com sinais diacríticos. Duas grafias diferentes podem assim produzir o mesmo resultado após a normalização, mas a semelhança visual, por si só, não o garante. A ordem das palavras, os espaços e os caracteres da passphrase continuam a importar. Um procedimento de normalização diferente pode derivar outro seed durante a recuperação. A implementação de referência e os vetores de teste públicos ajudam a verificar se o programa respeita o procedimento especificado. [1] [3] [4]

PBKDF2 recebe duas entradas separadas. A entrada password contém as verdadeiras palavras de recuperação. A segunda entrada chama-se salt e fornece dados adicionais ao cálculo criptográfico. Consiste no texto literal «mnemonic», seguido da passphrase, sem separador. As próprias palavras de recuperação não voltam a ser introduzidas nesta entrada. Ambas as entradas são normalizadas com NFKD e codificadas em UTF-8. BIP39 estabelece HMAC-SHA512, 2 048 iterações e um resultado com 512 bits, ou seja, 64 bytes. Sem passphrase, o salt continua a ser «mnemonic»; só a passphrase fica vazia. O cálculo não decifra as palavras nem cria nova aleatoriedade independente. Por isso, se as palavras forem expostas, as iterações, por si só, não protegem uma passphrase fácil de adivinhar. [1] [10]

BIP39 termina no seed de 64 bytes. Outra norma, BIP32, utiliza habitualmente HMAC-SHA512 com a chave fixa «Bitcoin seed» para derivar dele a chave privada mestra e um chain code de 32 bytes. O chain code contém dados adicionais usados em conjunto com uma chave para derivar outras chaves. Estes dois elementos são o ponto de partida da árvore de chaves. Regras como BIP44, BIP49, BIP84 e BIP86 definem diferentes caminhos de derivação e tipos de scripts. Durante a recuperação, pode assim introduzir as palavras e a passphrase corretas e continuar a ver um saldo nulo se o programa procurar outra conta, outro ramo ou outro tipo de endereço. Também importa o gap limit: quantos endereços consecutivos não utilizados o programa admite durante a pesquisa. O nome da carteira original, os dados das contas, os caminhos de derivação ou um Output Descriptor podem fornecer informação que as palavras, por si só, não contêm. [5] [6] [7] [8] [9] [14]

A passphrase é outra entrada secreta na derivação do seed. Não é o PIN do dispositivo, e BIP39 não consegue avisar que introduziu a passphrase errada: também calcula um resultado para outro valor. Um erro de escrita que altere a entrada normalizada conduz geralmente a outra carteira, na qual não verá os seus fundos. Em contrapartida, grafias diferentes com o mesmo resultado NFKD derivam o mesmo seed. Quem obtiver as palavras de recuperação e dados que permitam reconhecer a carteira pretendida pode experimentar possíveis passphrases sem ligação à Internet. Se utilizar uma passphrase, esta precisa de ser suficientemente forte, de ser introduzida de forma fiável e de ter a sua própria cópia de segurança. Guardá-la separadamente deve reduzir o risco de roubo conjunto, sem a transformar num segredo que desapareça consigo. [1] [13]

A soma de verificação ajuda a detetar erros de escrita, mas não prova a quem pertence uma cópia de segurança nem se foi gerada com segurança. Tem 4 bits numa frase de 12 palavras e 8 bits numa de 24 palavras. Assim, uma sequência de palavras escolhida de forma uniforme e aleatória da lista correspondente passa a verificação com probabilidade de 1/16 ou 1/256, respetivamente. Deteta muitos erros, mas não todos, e também não os corrige por si só. Um atacante pode construir outra cópia de segurança com uma soma válida. A especificação exige um aviso quando a soma não corresponde e distingue a verificação das palavras da derivação do seed. Se a soma for inválida, investigue a carteira original e o seu formato; não introduza a sua cópia de segurança real num verificador na Internet. [1]