Ir para o conteúdo
Financial Context Wiki

Carteiras frias: assinatura offline, recuperação e controles operacionais

Aprenda como projetar e verificar a custódia de cold-wallet em geração de chaves, identidade da carteira, backups, revisão de transações, assinatura offline, multisig, recuperação e resposta a incidentes.

Atualizado

Para fins educacionais apenas; não é um conselho de investimento. Investir pode resultar em perda.

Resposta direta

Uma carteira fria é um sistema de custódia que mantém o material secreto de assinatura e a etapa decisiva de aprovação fora da exposição normal de softwares conectados à internet. Os ativos permanecem na blockchain; o sistema controla as chaves ou outra autoridade que pode autorizar mudanças de estado. “Carteira fria” é um rótulo operacional, não uma classe de dispositivo definida por protocolo, e a frieza é uma propriedade do fluxo de trabalho completo, em vez de uma marca ou tipo de conexão.

Um assinador de hardware pode suportar armazenamento a frio enquanto conectado por USB porque a chave privada pode permanecer isolada, mas o fluxo de trabalho é inseguro se o usuário assinar um destino não verificado ou uma chamada de contrato opaca. Por outro lado, um computador isolado da rede não é seguro apenas porque não possui uma interface de rede: entropia comprometida, mídia de instalação, analisadores de transações, mídias removíveis, backups ou displays ainda podem violar a barreira. O armazenamento a frio reduz a exposição à extração remota de chaves; ele não prova a intenção da transação, a correção do software, a recuperação, a privacidade ou a finalização.

A cópia de recuperação não é “apenas um backup”. Um mnemônico, seed bruta, chave privada estendida ou parte de recuperação equivalente pode recriar a autoridade de gasto e, portanto, exige proteção comparável à de um signatário. Uma passphrase, caminho de derivação, rede, tipo de script, descritor da carteira, ordem das chaves e política de limiar também podem ser necessários para recuperar os endereços esperados. Uma carteira pública somente para consulta normalmente não assina, mas um xpub ou descritor pode revelar relações entre endereços e o histórico de transações; chaves públicas estendidas BIP-32 têm implicações de segurança maiores que chaves públicas comuns.

carteira fria
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 projetar e verificar armazenamento a frio

1. Definir a autoridade e o modelo de ameaças

Registre a rede exata, ativo, conta ou política de saída, proprietários, beneficiários, autoridade de recuperação, frequência esperada de transações e exposição máxima operacional. Identifique malware remoto, aplicativos maliciosos, comprometimento da cadeia de suprimentos, conluio interno, roubo físico, coerção, incêndio, inundação, perda, incapacidade e herança como ameaças separadas. Decida o que deve permanecer frio: uma única chave privada, todas as chaves em um limite, um quórum de signatários, uma chave de autorização EIP-712 ou um administrador capaz de alterar o código da carteira.

2. Inicializar entropia e software confiáveis

Obtenha dispositivos e software por canais autenticados, inspecione o estado de inicialização, verifique as versões quando houver suporte e rejeite qualquer mnemônico ou segredo pré-gerado na embalagem ou fornecido por terceiros. Gere entropia em ambiente controlado e registre o padrão e a implementação usados. BIP-39 codifica de 128 a 256 bits de entropia como um mnemônico e deriva uma seed de 512-bit do mnemônico mais uma passphrase opcional; não é um padrão para transformar uma frase inventada pelo usuário em carteira segura.

3. Vincular a identidade reproduzível da carteira

Antes de receber valor substancial, registre a rede, a impressão digital mestre, o padrão de derivação e o caminho completo, o índice da conta, o tipo de endereço ou script e os primeiros endereços de recebimento verificados. Para políticas Bitcoin, preserve o descritor de saída, o checksum, as origens das chaves, o limiar, a quantidade de signatários, a ordem das chaves e os ramos de troco. Cada signatário deve confirmar de forma independente sua chave e a política exibida. Trate um xpub como metadado sensível: ele deriva descendentes públicos não endurecidos, afeta a privacidade e, combinado com a chave privada filha não endurecida correspondente, pode expor a chave privada estendida pai no BIP-32.

4. Fazer backup e testar a recuperação

Proteja todas as entradas necessárias à recuperação, incluindo o mnemônico ou as partes, a passphrase opcional, o descritor ou a configuração da conta inteligente, o caminho de derivação e as instruções. Não invente um esquema dividindo palavras do mnemônico em fragmentos improvisados; use um limite especificado ou desenho multisig quando uma única cópia não deva bastar. Guarde as cópias em domínios de falha realmente independentes e acompanhe o acesso sem expor o conteúdo. Em um dispositivo reserva confiável ou signatário reinicializado, ensaie a restauração e compare impressão digital, política e endereço de recebimento antes de limpar o ambiente de teste.

5. Construir e verificar a intenção completa

Um coordenador online pode obter o estado da cadeia e construir uma solicitação não assinada, mas não é confiável. Para um Bitcoin PSBT, verifique a rede, cada entrada e valor UTXO, a saída do destinatário, o valor, a taxa, a taxa por unidade, locktime, política de sighash e se toda outra saída é troco autenticado. Para uma transação EVM, verifique chainId, nonce, to, value, limite de gás, limites de taxa e data decodificado; para EIP-712, verifique o domínio, chainId, verifyingContract, campos da mensagem, nonce e prazo, quando aplicável. EIP-712 estrutura dados e separa domínios, mas o padrão não fornece proteção contra replay por si só.

6. Assinar por uma fronteira de transferência controlada

Mova apenas a carga útil não assinada ou parcialmente assinada necessária através do QR, cartão, cabo ou outro canal aprovado. Intervalos de ar e códigos QR não tornam os analisadores ou mídias confiáveis: o assinante deve analisar a carga, autenticar a política e alteração, exibir consequências materiais e recusar campos não suportados. Em multisig, mantenha assinantes, operadores, locais, fornecedores e caminhos de recuperação independentes o suficiente para corresponder ao modelo de ameaça; trate o coordenador como substituível e incapaz de alterar a política sem ser notado. Compare a transação ou operação assinada com a intenção aprovada antes da transmissão.

7. Reconciliar, manter e preparar a migração

Após a transmissão, verifique o identificador da transação, a transação incluída, saídas ou registros, taxa real, troco, nonce da conta, autorizações e saldos resultantes em relação à intenção assinada, e depois aguarde a finalização apropriada para a cadeia e o caso de uso. Mantenha software compatível, caminhos de firmware verificados, backups legíveis, descritores documentados e exercícios periódicos de recuperação sem inserir segredos de produção em um dispositivo online. Se algum segredo de assinatura ou recuperação puder ser exposto, uma conta simples com uma única chave não pode revogar essa chave: estabeleça uma autoridade nova, migre ativos e funções, invalide permissões restantes onde o protocolo permitir e preserve um registro do incidente.

Exemplos resolvidos

Alocação e financiamento escalonados

Um plano de custódia limita a carteira de interação online a 5% de 100,000 units de valor do ativo: 100,000 × 5% = 5,000 units quente e 95,000 units fria. O destino frio primeiro recebe um teste 100-unit, e a transferência restante é 95,000 - 100 = 94,900 units. Após ambas as transferências, o saldo alvo frio é 100 + 94,900 = 95,000 units; o pequeno teste limita um erro de configuração, mas não valida assinaturas futuras ou recuperação de backup.

Bitcoin PSBT taxa e mudança

Um PSBT gasta entradas de 0.80 BTC e 0.35 BTC, totalizando 1.15 BTC. Ele paga 1.00 BTC ao destinatário e estima 250 vbytes × 8 sat/vbyte = 2,000 sat = 0.000020 BTC. O troco autenticado deve, portanto, ser 1.15 - 1.00 - 0.000020 = 0.149980 BTC. Se o assinante não puder identificar essa saída de troco a partir de sua política registrada, ele não deve assinar mesmo quando os totais aritméticos coincidirem.

Orçamento máximo EVM versus taxa real

Uma conta EVM começa com 5 ETH e aprova uma transferência de 1.2 ETH. Um limite 30,000 gas e uma taxa máxima 50 gwei implicam um orçamento de taxa de 30,000 × 50 gwei = 0.001500 ETH. Se a transação usar 21,000 gas a um preço efetivo de 25 gwei, a taxa real será 21,000 × 25 gwei = 0.000525 ETH, restando 5 - 1.2 - 0.000525 = 3.799475 ETH. O signatário deve revisar os limites de taxa e data, não assumir que o orçamento máximo será cobrado ou que uma interface aparentemente vazia comprove uma transferência ordinária.

Resiliência de dois em três signatários

Uma política 2-of-3 com signatários A, B e C possui 3 pares de assinatura válidos: AB, AC e BC. Se um signatário estiver indisponível, exatamente 1 par permanece; se um signatário for comprometido, esse signatário sozinho controla 0 pares válidos; se dois signatários forem comprometidos, eles controlam 1 par válido e podem gastar. Portanto, o design tolera uma perda ou um comprometimento isolado, mas não dois, e a recuperação ainda exige o descritor correto, dados de derivação e ordem das chaves.

Riscos e falhas de revisão

  • Rede ou política errada: restaurar uma chave válida com cadeia, tipo de endereço, script, conta ou política de conta inteligente incorretos pode gerar endereços diferentes ou inutilizáveis.
  • Entropia insuficiente: aleatoriedade previsível, uma brainwallet ou um gerador comprometido podem tornar uma chave adivinhável mesmo offline.
  • Segredo fornecido por terceiros: uma frase mnemônica pré-impressa, importada, fotografada ou entregue por um assistente pode já estar sob controle do invasor.
  • Exposição do backup: papel, metal, cópias na nuvem, impressoras, câmeras, transporte ou documentos sucessórios podem revelar toda a autoridade de gasto.
  • Falha da passphrase: perder ou digitar incorretamente a passphrase BIP-39 pode derivar outra carteira sem apresentar erro.
  • Parâmetros de derivação incompatíveis: caminhos, tipos de moeda, índices de conta ou convenções ausentes podem ocultar ativos recuperáveis.
  • Perda da configuração: chaves multisig sem descritor, limite, tipo de script, origem e ordem das chaves talvez não reconstruam a carteira financiada.
  • Vazamento de metadados públicos: um xpub, descritor, inventário de endereços ou banco do coordenador pode expor saldos, vínculos e endereços futuros.
  • Comprometimento da cadeia de suprimentos: hardware, firmware, software, embalagem ou canais de atualização alterados podem substituir entropia, endereços ou assinaturas.
  • Substituição pelo host: o coordenador online pode trocar destinatário, valor, taxa, troco, calldata, mensagem tipada ou payload não assinado.
  • Exibição insuficiente: truncamento, assinatura cega, scripts sem suporte ou decodificação incompleta podem ocultar uma autorização importante.
  • Ataque ao endereço de troco: se o signatário não autenticar o troco contra a política, uma transação Bitcoin pode enviá-lo ao invasor.
  • Erro de taxa ou nonce: taxas excessivas, nonces EVM antigos, locktimes errados ou modos sighash inesperados podem atrasar, substituir ou alterar a execução.
  • Autoridade contratual persistente: aprovações de token, permits, módulos, delegados e chamadas administrativas podem continuar válidos após a transação visível.
  • Ataque ao canal de transferência: QR, USB, cartões, cabos e formatos de parser podem carregar payloads maliciosos ou vazar metadados.
  • Quórum correlacionado: signatários no mesmo local, seeds compartilhadas ou dependência de um único fornecedor, operador ou local de recuperação reduzem a independência do limite.
  • Ataque físico: roubo, coerção, vigilância, adulteração e descoberta de segredos continuam possíveis sem acesso à rede.
  • Perda ambiental: incêndio, inundação, corrosão, degradação da mídia, cofres inacessíveis, morte ou incapacidade podem tornar um segredo correto indisponível.
  • Degradação de compatibilidade: firmware antigo, derivações ou scripts sem suporte e migrações não documentadas podem impedir recuperação ou assinatura futura.
  • Resposta incompleta ao incidente: consultar o saldo sem migrar chaves, funções, aprovações e autoridade de recuperação pode manter ativo o comprometimento original.

Equívocos comuns

Uma carteira fria precisa permanecer fisicamente desconectada para sempre?

Não. A propriedade de segurança é que a autoridade secreta permanece isolada e a assinatura ocorre por meio de um limite controlado e verificável. Um assinador de hardware conectado por cabo pode preservar essa propriedade; um computador isolado com configuração comprometida ou revisão de payload pode não preservá-la.

As moedas são armazenadas dentro do dispositivo de hardware?

Não. O estado do blockchain registra os ativos. O dispositivo protege ou usa autoridade que pode assinar transações, e material de recuperação compatível pode reproduzir essa autoridade em outra implementação.

Um backup mnemônico é menos sensível do que o dispositivo de assinatura?

Não. Uma mnemônica completa e a senha necessária podem recriar a carteira. Um backup normalmente está inativo, mas seu comprometimento pode ser tão decisivo quanto a extração da chave de assinatura ativa.

O multisig elimina a necessidade de backups e registros de configuração?

Não. Limiares reduzem pontos únicos de falha selecionados, mas cada chave precisa de um plano de recuperação e a política da carteira ou descritor deve ser reproduzível. Poucas chaves sobreviventes ou uma configuração perdida ainda podem bloquear os fundos.

Um teste de transferência bem-sucedido prova que o sistema de armazenamento a frio é seguro?

Não. Isso confirma um caminho limitado de cada vez. Não prova qualidade de entropia, sigilo de backup, restauração, decodificação de transações futuras, independência do quórum, atualizações de software, segurança do contrato ou recuperação de incidentes.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...