Ir para o conteúdo
Financial Context Wiki

Carteira com chave de sessão

Entenda como chaves de sessão de contas inteligentes delegam autoridade limitada, quais restrições devem ser aplicadas e como verificar, revogar e reagir ao vazamento de uma chave.

Atualizado

Conteúdo apenas educacional; não constitui aconselhamento de investimento. Uma chave de sessão vazada ou com privilégios excessivos pode causar perda irreversível de ativos digitais.

Resposta direta

Uma chave de sessão de carteira costuma ser uma chave de assinatura secundária, ou uma credencial delegada vinculada a ela, aceita por uma conta inteligente somente dentro de regras definidas. Essas regras podem limitar tempo, contratos de destino, seletores de função, quantias de tokens, número de transações ou outras condições. O objetivo é permitir que um aplicativo realize ações repetidas sem pedir ao titular que aprove cada operação com o signatário principal.

“Chave de sessão” é um padrão de projeto, não um padrão universal do Ethereum. O ERC-4337 oferece validação programável de contas e validação temporal de UserOperation, enquanto sistemas modulares como o ERC-7579 podem hospedar validadores, executores e hooks. O código implantado da conta e dos módulos determina, em última instância, o que a chave pode fazer. A expiração por si só não torna a sessão segura, e apagar uma cópia do navegador não revoga necessariamente a autoridade registrada on-chain ou contida em uma delegação ainda válida.

Como funciona

Um fluxo típico tem 5 etapas:

  1. O titular cria um novo par de chaves em um dispositivo ou autoriza uma credencial que identifica o signatário da sessão. A chave privada de sessão nunca deve ser enviada ao servidor do aplicativo, a menos que o projeto torne esse servidor explicitamente um custodiante confiável.
  2. O titular autoriza uma política com a carteira principal. Alguns sistemas instalam a chave e a política on-chain; outros usam uma delegação assinada que a conta valida quando uma operação chega.
  3. O aplicativo monta uma operação e a assina com a chave de sessão. Em um fluxo ERC-4337, a lógica validateUserOp da conta verifica assinatura e política; a simulação de um bundler é um teste de admissão, não prova de execução ou segurança.
  4. A conta deve aplicar todas as restrições antes da execução. A autoridade efetiva pode ser resumida como A_effective = K ∩ P ∩ S: a posse da chave (K), a política configurada (P) e o estado atual da conta ou da rede (S) devem permitir a ação.
  5. A sessão termina por expiração, esgotamento do nonce ou da cota, revogação explícita, remoção do módulo ou outra via de invalidação específica da implementação. Confirme o estado resultante da conta na rede correta.

Antes de autorizar uma sessão, verifique:

  • o ID da rede, o endereço da conta inteligente, a implementação da conta e o endereço do validador ou módulo;
  • a chave pública de sessão ou o identificador da credencial e onde o material privado será armazenado;
  • cada destino, seletor de função, token e regra de destinatário permitidos, além do limite de valor nativo e do teto por chamada ou acumulado;
  • validAfter, validUntil, regras de nonce, contagem de usos e se o tempo é medido pelo timestamp do bloco ou por outra fonte;
  • se lotes, chamadas aninhadas, delegatecall, aprovações de tokens, instalação de módulos, upgrades de conta e assinaturas de mensagem ERC-1271 ficam bloqueados salvo necessidade explícita;
  • quem pode revogar a sessão, se o titular mantém uma rota independente de recuperação e se a revogação exige Gas ou um bundler ou paymaster em funcionamento.

A política precisa inspecionar a ação que será realmente executada. Verificar apenas o destino externo de um lote pode deixar chamadas internas sem restrição; verificar apenas o destinatário e ignorar função e valor causa o mesmo problema. Um limite só é efetivo quando o código que o aplica cobre todos os caminhos de execução.

Exemplo

Uma carteira de jogo cria uma sessão com duração de 24 horas. Ela permite chamadas apenas a um contrato de jogo verificado, bloqueia delegatecall e aprovações de tokens, limita o valor nativo a 0.02 ETH por chamada e o gasto total a 20 USDC. O jogo pode enviar movimentos permitidos sem confirmações repetidas, mas um pedido para transferir um NFT não relacionado deve falhar na validação.

Antes do uso, o titular registra conta, rede, módulo, chave pública da sessão, expiração, limites e método de revogação. Ele testa uma ação de baixo valor, confere a chamada decodificada e o evento da conta e depois testa a revogação separadamente. Isso confirma o caminho configurado; não prova que o módulo não tenha vulnerabilidades nem que um dispositivo comprometido não possa gastar até os limites restantes.

Riscos e controles

  • Política ampla demais: destinos curinga, seletores irrestritos, aprovações ilimitadas, lotes ou delegatecall podem transformar uma chave “limitada” em autoridade próxima à do titular. Use listas explícitas de permissão e bloqueie ações administrativas.
  • Roubo da chave: armazenamento do navegador, logs, backups, extensões, malware e dispositivos compartilhados podem expor a chave. Prefira armazenamento isolado ou protegido por hardware quando houver suporte, prazos curtos e tetos acumulados baixos.
  • Aplicação defeituosa: conta, validador, executor ou hook pode decodificar chamadas incorretamente ou deixar de cobrir uma rota alternativa. Use implantações verificadas, código revisado, auditorias e testes de desvio.
  • Replay e confusão de contexto: nonce fraco ou falta de vínculo com rede, conta, módulo ou política pretendidos pode permitir reutilização. Verifique o domínio exato assinado e a proteção on-chain contra replay.
  • Suposições sobre expiração: validUntil pode limitar uma operação ERC-4337 sem remover automaticamente chave registrada, allowance de token ou outra delegação. Confira o estado real de cada permissão após a expiração.
  • Falha na revogação: apagar dados locais remove apenas uma cópia do segredo. Revogue pelo caminho documentado e confira o resultado on-chain; mantenha Gas suficiente e uma rota alternativa controlada pelo titular.
  • Módulos atualizáveis ou maliciosos: podem ter grande poder de execução, e upgrades podem alterar a política. Verifique titulares, atraso de upgrade, poderes de pausa, endereço de implementação e procedimento de remoção.
  • Abuso de Gas e patrocínio: a sessão pode consumir fundos da conta em Gas ou ficar inutilizável se um paymaster a rejeitar. Limite as taxas quando possível e mantenha uma rota independente de envio.

Se houver suspeita de exposição, pare de usar o aplicativo afetado, preserve o identificador da sessão e os hashes relevantes e revogue ou desative a chave em um dispositivo limpo controlado pelo titular. Depois examine operações pendentes e recentes, aprovações de tokens, módulos instalados, upgrades de conta e saldos em todas as redes compatíveis. Transfira os ativos restantes apenas se o projeto da conta ou módulo tornar a revogação pouco confiável; correr para um site de “recuperação” não verificado pode ampliar a perda.

Equívocos comuns

  • “Uma chave de sessão não pode mover ativos.” Ela pode executar tudo o que a política aplicada permitir, inclusive transferências, swaps, aprovações ou assinaturas.
  • “O ERC-4337 define permissões de chave de sessão.” O ERC-4337 fornece uma estrutura de validação e execução; a política continua específica da carteira ou módulo.
  • “Expiração curta limita a perda máxima.” A perda também depende de limites por chamada e acumulados, frequência, Gas, aprovações, preços e todos os caminhos alcançáveis.
  • “Sair da sessão revoga a chave.” Isso pode apagar uma cópia local, mas não prova que o registro on-chain ou uma delegação assinada sejam inválidos.
  • “Simulação bem-sucedida significa operação segura.” Ela pode mostrar que a validação atual aceita a operação; não prova intenção, inclusão futura, execução, finalidade nem ausência de vulnerabilidades.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...