Glossário / Endereços e chaves
Derivação hardened vs não hardened
- O que é a derivação hardened vs não hardened?
- A derivação hardened e a não hardened dividem ao meio os índices de chaves filhas do BIP-32: as filhas não hardened podem ser calculadas a partir de uma chave pública estendida, as hardened não.
Especificação no BIP-32.
O hardening é uma fronteira no seu caminho de derivação, não um ajuste que você liga e desliga. O BIP-32 foi atribuído em 11 de fevereiro de 2012 apenas com a derivação não hardened; a derivação privada para índices iguais ou superiores a 0x80000000 foi adicionada em 16 de abril de 2013, e essas chaves passaram a se chamar hardened em 15 de janeiro de 2014. Onde essa fronteira cai decide quanto da sua carteira uma chave pública estendida compartilhada entrega.
Como funciona
A derivação não hardened tem uma propriedade que a derivação hardened deliberadamente não tem, e o BIP-32 registra a diferença como uma identidade algébrica. Escreva N() para a neutralização, o passo que descarta a metade privada de uma chave estendida e mantém o código de cadeia de 32 bytes. Ao longo de níveis não hardened, N(m/a/b/c) é igual a N(m)/a/b/c, então neutralizar antes de derivar e neutralizar depois de derivar chegam à mesma chave. Em um nível hardened a reescrita se rompe: N(m/a') não pode ser transformado em N(m)/a', porque a derivação pública está definida apenas para filhas não hardened e retorna falha para qualquer outra.
Mecanicamente os dois modos diferem em um único campo. Ambos usam o código de cadeia da chave pai como chave de um HMAC-SHA512 e acrescentam o índice de 4 bytes. O modo não hardened fornece a chave pública comprimida da chave pai; o modo hardened fornece o segredo da chave pai, preenchido com um byte zero à esquerda até a mesma largura de 33 bytes. Nada que tenha apenas uma xpub possui essa segunda entrada, então a derivação para na fronteira.
O BIP-32 é incomumente direto sobre o que as chaves não hardened não conseguem proteger. Sua seção de segurança lista duas propriedades como ausentes e não como presentes: dada uma chave pública estendida pai e uma chave pública filha, encontrar o índice não é difícil, e dada essa mesma chave pública estendida pai mais qualquer chave privada filha não hardened, recuperar a chave privada estendida pai também não é difícil. A primeira custa sua privacidade. A segunda custa o ramo.
Onde você vê isso
Os níveis não hardened são o que torna uma chave pública estendida digna de ser exportada, e o BIP-32 dedica uma seção aos arranjos de compartilhamento construídos sobre eles. Um auditor que recebe as chaves públicas estendidas das contas vê cada pagamento que entra e sai de cada conta, e nenhuma chave secreta. Duas empresas que negociam com frequência podem compartilhar a cadeia externa de uma única conta como endereço permanente para receber pagamentos, de modo que nenhuma precise solicitar um novo endereço a cada transferência. Uma loja virtual pode entregar o mesmo tipo de chave ao seu servidor web, que então gera endereços de recebimento dos quais não tem poder de gastar.
A estrutura que coloca a fronteira no nível da conta é um conselho, não uma regra. O BIP-32 chama sua estrutura de mestre, conta, cadeia e subcadeia de apenas orientativa e diz às implementações que podem se desviar dela por necessidades específicas, razão pela qual uma carteira compatível com a especificação pode aplicar hardening em mais níveis do que a carteira compatível ao lado dela.
Vale conhecer uma armadilha de interoperabilidade, porque a especificação foi corrigida por causa dela duas vezes. Os vetores de teste de derivação hardened com zeros à esquerda foram adicionados em 24 de fevereiro de 2017 e de novo em 4 de novembro de 2020. A entrada hardened tem largura fixa de 33 bytes, um byte zero seguido do segredo de 32 bytes, então o software que corta um zero à esquerda em vez de manter essa largura calcula o hash de dados diferentes, produz um ramo diferente e encontra uma carteira vazia quando alguém restaura essa frase de recuperação em outro programa. A derivação não hardened nunca encontra esse bug, porque uma chave pública comprimida sempre começa com 0x02 ou 0x03 e, portanto, não tem nenhum zero à esquerda a perder.