--- title: "Carteiras frias: assinatura offline, recuperação e controles operacionais" description: "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." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Carteiras frias: assinatura offline, recuperação e controles operacionais > 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. ## 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 - [Carteira de hardware](/pt-br/crypto/hardware-wallet/) - [Frase semente](/pt-br/crypto/seed-phrase/) - [Chaves públicas e privadas](/pt-br/crypto/public-private-key/) - [Carteira multisig](/pt-br/crypto/multisig-wallet/) - [Simulação de transação](/pt-br/crypto/transaction-simulation/) ## Fontes - [Visão Geral da Tecnologia Blockchain](https://doi.org/10.6028/NIST.IR.8202) - NIST (acessado: 2026-08-19) - [BIP 32: Carteiras Determinísticas Hierárquicas](https://bips.dev/32/) - Propostas de Melhoria Bitcoin (acessado: 2026-08-19) - [BIP 39: Código Mnemônico para Geração de Chaves Determinísticas](https://bips.dev/39/) - Propostas de Melhoria Bitcoin (acessado: 2026-08-19) - [BIP 44: Hierarquia Multi-Conta para Carteiras Determinísticas](https://bips.dev/44/) - Propostas de Melhoria Bitcoin (acessado: 2026-08-19) - [BIP 174: Formato de Transação Bitcoin Parcialmente Assinada](https://bips.dev/174/) - Propostas de Melhoria Bitcoin (acessado: 2026-08-19) - [BIP 380: Operação Geral dos Descritores de Script de Saída](https://bips.dev/380/) - Propostas de Melhoria Bitcoin (acessado: 2026-08-19) - [BIP 129: Configuração Segura Multisig Bitcoin](https://bips.dev/129/) - Propostas de Melhoria Bitcoin (acessado: 2026-08-19) - [EIP-712: Hashing e Assinatura de Dados Estruturados Digitados](https://eips.ethereum.org/EIPS/eip-712) - Propostas de Melhoria Ethereum (acessado: 2026-08-19) Source: https://wiki.fcontext.com/pt-br/crypto/cold-wallet/index.mdx