Ir para o conteúdo
Financial Context Wiki

Gerenciamento de chave privada

O gerenciamento de chave privada é o ciclo de vida para gerar, usar, fazer backup, recuperar, alternar ou migrar e retirar autoridade de assinatura sem confundir uma política de chave, semente, mnemônico, senha, dispositivo ou conta inteligente.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

O gerenciamento de chaves privadas é o ciclo de vida completo da autoridade de assinatura: geração confiável, uso protegido, backup, recuperação testada, alteração autorizada, migração de incidentes e desativação. O objetivo é confidencialidade e disponibilidade. Um segredo fácil de roubar não é seguro, mas um segredo que ninguém consegue recuperar após a perda do dispositivo também não é seguro.

Mantenha os objetos distintos. Uma chave privada controla uma identidade criptografica. Uma seed raiz HD pode derivar muitas chaves. Uma frase de recuperacao BIP-39 codifica entropia e, com uma passphrase opcional, deriva uma seed; as mesmas palavras com outra passphrase geram outra carteira. Um PIN ou a senha da carteira podem desbloquear um dispositivo local ou arquivo criptografado, mas nao revogam a chave subjacente. Um endereco ou chave publica estendida pode revelar relacoes entre identidades ou transacoes sem conceder capacidade normal de gasto. Uma carteira de hardware e um dispositivo de assinatura, nao o ativo nem o backup.

Uma conta de propriedade externa normalmente nao pode substituir sua chave e manter o mesmo endereco. Apos comprometimento, os ativos e cada funcao ou autorizacao relevante devem migrar para uma nova autoridade. Uma conta inteligente pode permitir mudancas de proprietarios ou guardioes, limiares e validacao ERC-1271, mas seus modulos, guards, controles de upgrade e codigo implantado exato passam a integrar o perimetro de seguranca.

Gerenciamento de chave privada
0 / 5
0 itens revisados; 5 itens ainda não resolvidos

A conclusão desta revisão não prova que um ativo, transação ou sistema seja seguro.

Como funciona

Comece por um inventario, nao pelo nome de um produto. Mapeie cada rede, conta, endereco, ativo, autorizacao de token, funcao contratual, credencial de validador ou saque, dispositivo de assinatura, origem da chave, padrao de derivacao e dependencia de recuperacao. Separe a autoridade operacional cotidiana daquela destinada a reserva, tesouraria, administracao e recuperacao. Reutilizar uma seed raiz em muitas contas amplia o alcance de um comprometimento, mesmo que os enderecos visiveis sejam diferentes.

A geração requer uma implementação, ambiente e fonte de entropia confiáveis. Não invente um mnemônico a partir de palavras memoráveis. Para uma carteira HD, preserve o formato, a lista de palavras, o requisito de senha opcional, os caminhos de derivação, os índices de conta e os identificadores públicos necessários para confirmar a recuperação. Uma chave pública estendida não é um metadado inofensivo: ela pode revelar relações de endereço, e algumas construções de derivação têm limites de exposição adicionais.

Os backups negociam confidencialidade em relação à disponibilidade. Várias cópias completas melhoram a recuperação apenas se a mídia e os locais permanecerem utilizáveis, mas qualquer cópia roubada pode expor todo o segredo. Um backup de limite padronizado como o SLIP-39 requer compartilhamentos suficientes e não é o mesmo que cortar uma frase BIP-39 em pedaços. As assinaturas múltiplas e de limite distribuem a autorização entre os signatários; eles não dividem um backup e sua segurança depende de pessoas, dispositivos, locais e administradores independentes.

A assinatura diária é um controle separado. Um signatário de hardware pode isolar uma chave de um host comprometido, mas não pode tornar seguro um destinatário, cadeia, quantidade, domínio ou dados de chamada incorretos. Verifique a intenção em um display confiável, limite saldos e permissões importantes e preserve um caminho de aprovação auditável. Para uma conta de contrato, verifique o limite do proprietário atual, o código de validação do assinante, os módulos, as proteções, o comportamento de fallback, a política de recuperação e a autoridade de atualização.

Use este fluxo de trabalho:

  1. Faça um inventário de cada cadeia, conta, endereço, ativo, aprovação, função do contrato, origem da chave, caminho de derivação, signatário, módulo, custodiante e dependência de recuperação.
  2. Definir ameaças e necessidades de serviço: comprometimento remoto, roubo, coerção, ação interna, danos por incêndio ou água, morte ou incapacidade, frequência de assinatura, valor em risco e objetivo de tempo de recuperação.
  3. Gerar material chave com implementação revisada e entropia confiável em um dispositivo controlado; verificar de forma independente a cadeia, o endereço e a impressão digital pública sem registrar o segredo em um sistema on-line.
  4. Escolha controles ativos, isolados por hardware, de múltiplas assinaturas, de limite, de conta inteligente ou de custódia por valor e uso; coloque backups, compartilhamentos, senhas e assinantes em domínios de falha genuinamente independentes.
  5. Execute um pequeno exercício de recuperação isolado que confirme o formato exato, a lista de palavras, a senha, o caminho de derivação, o limite, os endereços e a capacidade de assinatura, sem inserir segredos de produção em um dispositivo não confiável.
  6. Para cada operação, verifique a cadeia, o domínio, o destinatário, o valor, o token, os dados de chamada e o escopo de autoridade em um display confiável; aplicar limites, separação de funções e preencher registros de eventos ou aprovações.
  7. Reconcilie o inventário regularmente e ensaie perdas, comprometimento, mudança de pessoal, herança e saída de fornecedor; recupere após perda, mas após comprometimento, isole dispositivos limpos, migre ativos e funções, revogue aprovações, monitore a autoridade antiga e retire-a.

Exemplos

  • Comprimento e soma de verificacao do BIP-39. Com ENT = 128 bits, o comprimento da soma de verificacao e CS = ENT / 32 = 4 bits; 132 / 11 = 12 words. Com ENT = 256 bits, obtem-se CS = 8 bits e 264 / 11 = 24 words. Um candidato aleatorio de 12 palavras tem probabilidade didatica de passar na soma de verificacao de 1 / 16 = 6.25%. A soma curta detecta alguns erros de transcricao; nao prova autenticidade, sigilo nem metadados de derivacao corretos.
  • Cópias completas versus compartilhamentos limite. Suponha que três mídias independentes estejam disponíveis, cada uma, com probabilidade 0.98 e comprometidas independentemente com probabilidade 0.01. Três backups completos são recuperados se algum sobreviver: 1 - 0.02^3 = 0.999992, enquanto a probabilidade de pelo menos um vazamento é 1 - 0.99^3 = 0.029701. Um limite 2-of-3 tem disponibilidade 3 x 0.98^2 x 0.02 + 0.98^3 = 0.998816 e probabilidade de comprometimento 3 x 0.01^2 x 0.99 + 0.01^3 = 0.000298. A mídia real e os custodiantes estão correlacionados, portanto, são suposições, não garantias.
  • Perda e substituição do signatário. Uma conta inteligente tem proprietários A, B e C com limite 2-of-3. Perder um proprietário ainda deixa duas assinaturas; comprometer um proprietário é insuficiente. Se houver suspeita de que B esteja comprometido, A + C autorize a substituição por D. Até que essa alteração seja executada de acordo com as regras reais da conta, B permanece o proprietário; depois o conjunto é A / C / D com limite 2.
  • Alcance da reutilizacao de uma seed. A seed raiz S deriva duas contas com 1.2 ETH e 0.8 ETH; uma seed fria independente contem 8.0 ETH. O saldo direto conhecido exposto pelo comprometimento de S e 1.2 + 0.8 = 2.0 ETH. Reutilizar S na conta fria elevaria o total a 10.0 ETH. Tokens, NFTs, autorizacoes, funcoes e outras redes exigem inventario separado; o saldo nativo visivel nao e um limite completo de perda.

Riscos

  • A entropia é fraca, tendenciosa ou gerada por uma fonte aleatória quebrada.
  • O dispositivo de geração, construção de carteira ou dependência é malicioso.
  • Um signatário de hardware, firmware ou cadeia de suprimentos foi violado.
  • Uma semente ou chave chega a uma captura de tela, área de transferência, impressora, nuvem ou nota online.
  • Phishing ou suporte falso obtém material de recuperação ou assinatura.
  • O host substitui a cadeia, destinatário, quantidade, domínio ou dados de chamada.
  • Uma senha foi esquecida ou digitada incorretamente em uma carteira válida diferente.
  • Um único backup é perdido devido a roubo, incêndio, água ou deterioração da mídia.
  • Backups duplicados completos aumentam a superfície de roubo.
  • Lista de palavras, formato, caminho de derivação, tipo de moeda ou índice de conta estão errados.
  • Uma chave pública estendida ou metadados de derivação vazam privacidade financeira.
  • A recuperação nunca foi testada e falha durante o incidente.
  • Os assinantes com múltiplas assinaturas compartilham um dispositivo, local, nuvem ou administrador.
  • Um limite é muito alto para disponibilidade ou muito baixo para resistência a comprometimentos.
  • Os guardiões conspiram, tornam-se obsoletos ou são socialmente projetados.
  • Um módulo de conta inteligente, guarda, gerenciador de fallback, proxy ou atualização ignora a política.
  • Os registros de saída, falecimento, incapacidade ou herança de pessoal não são atualizados.
  • Após comprometimento, a chave antiga é reutilizada ou a alteração de um PIN é confundida com rotação.
  • Um custodiante, HSM, MPC ou provedor de recuperação congela, falha, conspira ou sai.
  • A migração perde outra cadeia, token, NFT, aprovação, função ou credencial de validador especializado.

Erros comuns

  • Uma carteira de hardware torna todas as transações seguras. O isolamento ajuda, mas os riscos de intenção maliciosa, exibição, firmware, cadeia de suprimentos e recuperação permanecem.
  • Uma frase-semente e a chave privada de uma conta são o mesmo objeto. Uma semente pode derivar muitas chaves, enquanto os formatos e as senhas determinam a recuperação.
  • Backups mais completos apenas melhoram a segurança. Eles melhoram a disponibilidade e aumentam o número de cópias que um invasor pode roubar.
  • Assinaturas múltiplas são apenas uma semente dividida em pedaços. Assinantes independentes, assinaturas de limite e backups de compartilhamento de segredos são mecanismos diferentes.
  • Alterar a senha ou PIN da carteira revoga uma chave EOA vazada. A chave antiga ainda controla seu endereço; migrar ativos e autoridade e lidar com aprovações explicitamente.

Tópicos relacionados

Fontes oficiais

Navegação

Pesquisar na wiki...