TRUSTFIELD

TRUSTFIELD / SECURITY COMMAND

Security
Command.

Simule um saque e veja a camada de proteção decidir antes da assinatura.

01 / LIVE DEMO

Controle de saques

  1. 01Solicitação
  2. 02Política independente
  3. 03Assinatura
Valor fictício
—
Total em 1 hora
—
Estado da IA
—
Trilha da sessão

    Ambiente fictício. Nenhuma carteira, rede ou operação real.

    02 / ARQUITETURA TÉCNICA · PT-BR

    Seis controles, da fraude à recuperação

    01 · Engenharia social

    Trate recrutamento falso, suporte impostor e urgência de tesouraria como portas de entrada. Confirme a solicitação por um canal conhecido e confira o conteúdo que será assinado em outro dispositivo. FIDO/WebAuthn protege a autenticação; a autorização do saque tem controle próprio.

    02 · Assinatura sob política

    Fixe rede, ativo, destino, valor e tipo de operação. Um limite por operação e outro acumulado ajudam a detectar saques grandes e fracionados. IA pede revisão; um assinador independente faz cumprir as regras.

    03 · Chaves e recuperação

    Para autocustódia compatível, BIP39 usa entropia aleatória e checksum para formar 12 a 24 palavras de uma lista padronizada. A passphrase é opcional, separada e altera a carteira derivada. BIP32 deriva a árvore de chaves; BIP44 organiza caminhos onde adotado.

    04 · Continuidade operacional

    Isole a rota, suspenda novas assinaturas, confira autorizações que já estão na rede, rotacione credenciais e reconcilie o estado. Retome com quórum separado e um teste de baixo impacto. Meça tempo de contenção, recuperação e perda de estado.

    05 · Redes e contratos

    Em Ethereum e redes EVM, a política pode ser aplicada por uma conta programável ou guarda que revise chamadas e módulos. Em Solana, uma multisig baseada em programa pode controlar propostas e limites. Em Bitcoin, scripts e bloqueios por tempo ajudam a desenhar saídas; a política da tesouraria fica no fluxo de assinatura.

    06 · Reservas e liquidez

    Separe movimentação para custódia fria, saída externa e evidência insuficiente. A comparação com passivos exige escopo, entidade e data compatíveis. Abrir Radar de Reservas ↗

    Como as chaves se relacionam
    1. Entropia → palavras mnemônicas.
    2. Palavras + passphrase opcional → seed.
    3. Seed + caminho de derivação → pares de chaves.
    4. Chave privada assina; chave pública verifica. O endereço segue o formato da rede.

    Uma passphrase digitada de outro jeito gera outra seed. Teste a recuperação offline e compare o endereço esperado. Esta central não pede seed ou chaves. O SHIELD Live Lab usa chaves P-256 efêmeras no navegador.

    Como preparar a migração pós-quântica
    1. Inventariar assinaturas, verificadores e protocolos por rede.
    2. Versionar os formatos e pré-registrar novas chaves em ambiente controlado.
    3. Testar ML-DSA ou SLH-DSA para assinaturas fora da cadeia e ML-KEM para estabelecimento de chaves.
    4. Migrar e retirar o algoritmo anterior só após validar suporte, recuperação e interoperabilidade. Se o destino não verificar o formato exigido, pausar a rota.

    Carteiras, consenso, pontes e sistemas de provas têm dependências distintas. A adoção em blockchain depende das regras de cada rede. Uma multisig clássica continua usando assinaturas clássicas.

    Onde o pré-bloqueio precisa acontecer

    A corretora precisa colocar a política antes do assinador ou no caminho obrigatório do contrato. Um painel externo só observa e alerta. A política deve proteger mudanças de configuração, impedir aprovação repetida, vincular cada aprovação à solicitação, verificar todos os caminhos de assinatura e limitar exposição por carteira. O protótipo público simula essa lógica e as duas aprovações.

    Fontes: BIP39 · BIP32 · BIP44 · NIST pós-quântico · NIST incidentes · Safe Guards · Bitcoin BIP112 · Squads em Solana · EIP-7702.

    03 / IDENTIDADE E AUTORIZAÇÃO · PT-BR

    A identidade em três verificações

    01 · Cadastro verificado

    Vincular a conta a uma pessoa ou função institucional por um processo de cadastro proporcional ao risco. Se houver captura de imagem para identificação, testar apresentação falsa, injeção de vídeo e falsos positivos, com revisão humana e alternativa acessível.

    02 · Passkey vinculada ao serviço

    O servidor valida desafio único, origem, domínio, assinatura e verificação local do usuário. Rosto, impressão digital ou PIN podem desbloquear o autenticador. O serviço recebe uma assinatura, sem receber o molde biométrico.

    03 · Intenção e segunda chave

    Para saque crítico, outra pessoa aprova o resumo exato em um dispositivo independente. As aprovações valem apenas para aquele destino, rede, valor e prazo. Uma troca de dados exige nova validação.

    Gêmeos parecidos, deepfakes, coação e dispositivos comprometidos têm riscos diferentes. Face ID tem taxa de falso aceite maior para gêmeos e irmãos parecidos segundo a Apple. A proposta combina credenciais independentes e teste de recuperação. Um PIN local ou chave física dá uma opção acessível sem biometria centralizada.

    Este teste consulta a capacidade do navegador. Não solicita biometria, não cadastra uma passkey e não confirma identidade.

    Padrões e código: W3C WebAuthn · NIST identidade e ataques de apresentação · Apple Face ID · SimpleWebAuthn · Yubico WebAuthn.

    04 / GUIA INTERATIVO · PT-BR

    Pergunte sobre a proteção

    O guia procura a resposta mais próxima na base local do TRUSTFIELD. As perguntas ficam nesta aba. Use perguntas gerais, sem inserir chaves, credenciais ou dados pessoais.

    Guia de respostas revisáveis, sem modelo generativo ou acesso ao assinador.