Recuperação de carteiras sob autoridade legal

Encontrar uma frase-semente ou um arquivo de carteira não é o mesmo que saber o que ele controla. A recuperação é a etapa que transforma o material de chaves em uma lista documentada de endereços, saldos e histórico e, quando a autoridade permite, em fundos protegidos pela agência. É também a etapa em que um examinador descuidado pode perder fundos, alertar um suspeito ou produzir um resultado que não possa ser reproduzido. Esta aula trata a recuperação como um procedimento forense realizado sob autoridade legal: os padrões envolvidos, o ambiente, os limites e o registro que torna o resultado defensável.

Recuperação como procedimento forense

A recuperação só deve começar quando quatro aspectos estiverem definidos. A autoridade abrange o exame do material de chaves e, se for o caso, a transferência dos fundos. O plano identifica quem realiza a recuperação, quem a testemunha sob controle duplo e para onde os fundos protegidos serão enviados (consulte a aula Proteção de criptoativos apreendidos). O ambiente é um dispositivo de examinador isolado, preparado para esse fim. E o registro é aberto antes da primeira ação, para que cada derivação, varredura e decisão seja anotada no momento em que acontecer.

O objetivo é duplo: determinar o que o material de chaves controla, como evidência, e eliminar o risco de que outra pessoa com uma cópia das mesmas chaves transfira os fundos primeiro.

Da frase mnemônica aos endereços

A maioria das carteiras modernas segue três propostas de melhoria do Bitcoin, que muitas outras redes reutilizam.

BIP-39 transforma entropia em palavras. A entropia de 128 a 256 bits, em incrementos de 32, recebe uma soma de verificação de um bit para cada 32 bits de entropia, obtida do hash SHA-256 correspondente. Os bits combinados são divididos em grupos de 11 bits, cada um indexando uma palavra em uma lista de 2.048 palavras, o que resulta em 12, 15, 18, 21 ou 24 palavras. A frase, normalizada para Unicode NFKD, é então convertida em uma semente de 512 bits com PBKDF2 usando HMAC-SHA512 e 2.048 iterações; o sal é a string "mnemonic" seguida pela frase secreta opcional.

BIP-32 deriva uma árvore de chaves a partir dessa semente. A chave mestra vem de HMAC-SHA512 com "Bitcoin seed" como chave. As chaves filhas são normais ou hardened (índice 2^31 ou superior, escrito com apóstrofo ou h). Uma chave pública estendida permite que qualquer pessoa derive as chaves públicas filhas normais, o que torna possíveis as carteiras somente para consulta; a BIP-32 também alerta que uma chave pública estendida combinada com qualquer chave privada filha não hardened revela a chave privada pai, razão pela qual os examinadores tratam xpubs como informações confidenciais.

BIP-44 define a estrutura da árvore: m / purpose' / coin_type' / account' / change / address_index. Os três primeiros níveis são hardened. O valor de change é 0 para a cadeia externa (de recebimento) e 1 para a cadeia interna (de troco). Os tipos de moeda são registrados na SLIP-0044, por exemplo, 0 para Bitcoin, 1 para todas as redes de teste, 2 para Litecoin, 60 para Ether e 195 para Tron. Propostas posteriores reutilizam a estrutura com um número de propósito diferente para cada tipo de script:

A consequência forense é que uma única frase pode controlar fundos em vários propósitos, várias contas e várias redes ao mesmo tempo. As carteiras Ethereum também diferem: algumas incrementam o índice do endereço (m/44'/60'/0'/0/n), outras incrementam a conta (m/44'/60'/n'/0/0). Uma recuperação que verifica apenas um caminho pode informar que uma carteira está "vazia" quando ela não está.

O problema da frase secreta

A frase secreta da BIP-39 é o limite mais importante para qualquer afirmação. Toda frase secreta, inclusive a vazia, produz uma semente válida e uma carteira válida; a BIP-39 apresenta isso como negação plausível. Não há mensagem de erro para uma frase secreta incorreta, apenas uma carteira diferente, geralmente vazia. Assim, um usuário pode manter um pequeno saldo de isca sem frase secreta e os ativos reais sob uma frase secreta oculta.

O examinador não pode provar que não existe uma frase secreta. A constatação deve ser formulada com precisão: "com uma frase secreta vazia, as carteiras derivadas não apresentaram atividade nos caminhos e nas redes listados", e não "a carteira está vazia". Procurar nos materiais do caso uma frase secreta armazenada separadamente das palavras e perguntar sobre ela conforme as regras discutidas na aula Busca e apreensão de criptoativos no local fazem parte do plano de recuperação.

Restauração em um dispositivo isolado do examinador

A sequência geral é a mesma, independentemente do software utilizado:

1. Prepare um dispositivo dedicado do examinador, recém-configurado e que nunca tenha armazenado chaves de outros casos, com a rede desativada. Use software de carteira ou derivação de código aberto cuja versão tenha sido verificada com base no hash publicado e registre o nome, a versão e o hash.
2. Verifique a frase. A soma de verificação da BIP-39 detecta a maioria dos erros de transcrição; uma frase inválida deve ser examinada novamente em relação ao original, sob controle duplo. Para uma frase de 12 palavras, cerca de uma em cada 16 sequências aleatórias de palavras passa na verificação, portanto uma soma de verificação válida é compatível com uma transcrição correta, mas não a comprova.
3. Derive offline as chaves públicas estendidas e os endereços para todos os propósitos, contas e redes plausíveis, e exporte somente material público.
4. Verifique a atividade em modo somente para consulta, de preferência nos nós próprios da unidade. Consultar servidores de terceiros revela os endereços e a identidade de rede da unidade, o que pode comprometer a confidencialidade e, por meio do operador do servidor, alertar outras pessoas. Faça a varredura de pelo menos 20 endereços não utilizados, conforme o limite de lacuna da BIP-44, e avance além disso quando se sabe que o software da carteira usa lacunas maiores.
5. Proteja os fundos conforme o plano, transferindo-os para a carteira controlada pela agência com controle duplo e uma transação de teste. Nunca envie os fundos de volta pelo próprio dispositivo ou software do suspeito.

Nem toda frase segue a BIP-39. As sementes do Electrum codificam um número de versão em um hash da frase, em vez de uma soma de verificação da BIP-39; carteiras Monero legadas usam 25 palavras; participações Shamir da SLIP-39 exigem um número mínimo de participações. Identifique primeiro o padrão e, em seguida, escolha um software que o implemente.

O registro da recuperação documenta cada execução:

{
  "case": "CASE-0417",
  "recovery_id": "REC-002",
  "source_item": "CASE-0417-I-012 (metal plate, seal TE-88213 opened 2026-03-16T10:05Z)",
  "operator": "Examiner 2", "witness": "Examiner 4",
  "environment": "Examiner device EX-07, offline, rebuilt 2026-03-15",
  "software": "open-source derivation tool v4.2.1, release SHA-256 9d0c…41ee",
  "phrase_standard": "BIP-39, 24 words, checksum valid",
  "passphrase": "empty (no passphrase found in case material)",
  "paths_scanned": ["m/44'/0'/0'", "m/49'/0'/0'", "m/84'/0'/0'..m/84'/0'/2'", "m/86'/0'/0'", "m/44'/60'/0'/0/0..19"],
  "gap_limit_used": 50,
  "activity_found": "m/84'/0'/0': 31 used addresses, balance 4.21907 BTC at block 940112",
  "public_material_exported": "xpub list, SHA-256 b77a…0c3e",
  "funds_action": "Transferred under order OR-2026-118; see transfer record TR-004"
}

O registro vincula a execução ao item de origem lacrado e ao momento em que o lacre foi aberto, identifica o operador e a testemunha, especifica o ambiente e o software verificado, informa o padrão, a premissa sobre a frase secreta e cada caminho examinado, e apresenta o resultado com a altura do bloco para que qualquer pessoa possa verificar novamente o saldo mais tarde.

Arquivos de carteira criptografados e recuperação de senhas

Os arquivos de carteira em computadores e telefones geralmente criptografam o material de chaves com uma chave derivada de uma senha do usuário. Se a senha for desconhecida, a recuperação depende de encontrá-la ou recuperá-la. Em termos gerais, a recuperação de senhas em laboratórios forenses usa senhas candidatas elaboradas a partir de informações do caso: senhas encontradas em outros dispositivos apreendidos, em gerenciadores de senhas ou anotações, fornecidas durante entrevistas ou baseadas em padrões conhecidos do usuário. Ferramentas validadas testam as candidatas em uma cópia do arquivo da carteira, nunca no original. As configurações de derivação de chave da carteira determinam o custo de cada tentativa, portanto o sucesso nunca é garantido, e o esforço, os dados utilizados e os resultados são registrados como qualquer outra etapa do exame. A autoridade para esse trabalho deve ser explícita.

Carteiras de hardware são um caso diferente. Como a proteção por PIN e os mecanismos de apagamento após falhas significam que a recuperação normalmente é feita por meio do backup da semente, e não do dispositivo. Ataques físicos ao hardware do dispositivo são uma atividade especializada e específica para cada modelo, fora do escopo deste curso.

Multisig, MPC e quando a recuperação não é possível

Uma carteira multisig precisa de M entre N chaves para gastar, mas sua recuperação também exige a chave pública estendida de cada coassinante e a configuração exata do script, geralmente registrada como um descritor de saída (a família BIP-380). Uma semente de uma carteira 2 de 3 não revela nada que possa ser gasto por si só; o examinador precisa procurar o arquivo de configuração ou de backup da carteira e os outros coassinantes. Uma carteira MPC ou de assinatura por limite nunca forma uma chave completa: as participações ficam no dispositivo do usuário e com um provedor ou outra parte, portanto uma única participação não é suficiente, e a recuperação normalmente depende do processo de recuperação próprio do provedor ou de um processo legal direcionado a ele (consulte a aula IDFE-DA Tecnologias de gerenciamento de chaves).

Quando a recuperação falha, o trabalho não é em vão. O material público ainda permite atribuir endereços, ajuda no rastreamento e possibilita solicitar o congelamento assim que os fundos chegarem a um serviço (consulte a aula Opções de congelamento e apreensão).

Foco no exame: os quatro pré-requisitos da recuperação (autoridade, plano, ambiente isolado, registro); parâmetros da BIP-39 (128 a 256 bits, soma de verificação de ENT/32 bits, 2.048 palavras, PBKDF2-HMAC-SHA512 com 2.048 iterações e sal "mnemonic" mais a frase secreta, semente de 512 bits); chaves hardened da BIP-32, xpubs para carteiras somente para consulta e o risco de combinar um xpub com uma chave privada filha; níveis de caminho da BIP-44, valores de change, tipos de moeda da SLIP-0044, limite de lacuna de 20 e propósitos 44, 49, 84 e 86 com seus tipos de endereço; por que uma frase secreta incorreta gera uma carteira válida e vazia e como expressar esse limite; derivação offline, verificações somente para consulta nos próprios nós e formatos que não seguem a BIP-39; recuperação de senhas em termos gerais e recuperação de carteiras de hardware por meio da semente; requisitos de multisig e MPC e as próximas etapas quando a recuperação falha.