Segurança, criptografia e MFA com passkeys

Arquitetura de segurança

A Evercore foi projetada com uma arquitetura sem estado e voltada à segurança. Nenhum dado em texto claro toca a infraestrutura da Evercore — a criptografia é aplicada antes de qualquer dado sair do seu ambiente.

O ciclo de vida da solicitação é:

1. O cliente criptografa a carga útil usando AES-256-GCM com uma chave sob seu controle 2. O cifrado é transmitido para a API da Evercore via TLS 1.3 3. A Evercore valida a solicitação, aplica tags da Arweave e encaminha o cifrado para a rede Arweave 4. O ID da transação da Arweave é retornado ao cliente 5. Nenhum texto em claro nem material de chave é mantido em nenhum momento

Padrões de criptografia

Dados em repouso

Todos os dados armazenados na Arweave são criptografados com AES-256-GCM antes do envio:

• Algoritmo: AES-256-GCM (NIST SP 800-38D) • IV: nonce aleatório de 96 bits gerado por arquivo • Auth Tag: tag de autenticação GCM de 128 bits, armazenada na cadeia como metadado • Material da chave: derivado via PBKDF2-SHA256 (mínimo de 310.000 iterações) ou Argon2id quando suportado

O IV de criptografia e a tag de autenticação são armazenados como tags de transação da Arweave (visíveis publicamente), mas o material da chave nunca é armazenado em nenhum lugar pela Evercore.

Dados em trânsito

• TLS 1.3 é obrigatório para todos os endpoints da API da Evercore — conexões TLS 1.2 são rejeitadas • Pinning de certificados é recomendado para integrações móveis e de CLI • As comunicações com o gateway da Arweave são criptografadas com TLS e validação de certificado

Gestão de chaves

A Evercore segue um modelo rigoroso de conhecimento zero em relação às chaves de criptografia:

• As chaves são derivadas no cliente e nunca são transmitidas ou armazenadas pela Evercore • As chaves de API usadas na autenticação são armazenadas como hashes bcrypt — o texto simples nunca é mantido • Os JWKs de wallets da Arweave são gerenciados via segredos do Encore.dev e são criptografados em repouso no cofre de segredos • Políticas de rotação de chaves são aplicadas a todas as credenciais internas do serviço

Segurança da infraestrutura

A Evercore roda em infraestrutura gerenciada pelo Encore.dev com os seguintes controles:

• Isolamento de rede: os serviços se comunicam por canais privados e autenticados • Princípio do menor privilégio: cada componente do serviço tem apenas as permissões de que precisa • Varredura de dependências: análise automática de vulnerabilidades em cada build • Hardening de containers: imagens base mínimas, sem pacotes desnecessários • Gestão de segredos: todas as credenciais são gerenciadas pelo cofre de segredos criptografado do Encore.dev — sem arquivos .env em produção • Rate limiting: limites por IP e por chave de API aplicados na camada de gateway da API

Considerações específicas da Arweave

Como a Arweave é um livro-razão público e imutável, aplicam-se as seguintes considerações:

• IDs de transação e tags são visíveis publicamente — não inclua metadados sensíveis em tags em texto simples • O cifrado é público, mas ilegível sem a chave de descriptografia • Depois de confirmados na cadeia, os dados não podem ser excluídos — escolha com cuidado o que você envia • Os nós gateway da Arweave são operados por terceiros; use apenas gateways HTTPS • Há suporte a redundância multi-gateway para evitar ponto único de falha na recuperação

Controle de acesso

Autenticação da API: • Chaves de API são exigidas para todos os endpoints não públicos • As chaves têm escopo para operações específicas (leitura, gravação, admin) • Chaves comprometidas podem ser revogadas instantaneamente no painel • Todo uso de chave é registrado com IP, timestamp e endpoint

Autenticação de wallet: • Transações assinadas pelo usuário usam ArConnect ou assinaturas compatíveis de wallets da Arweave • A Evercore verifica a propriedade da wallet sem nunca manter chaves privadas • A gestão do pool de wallets fica protegida atrás de chaves de API de nível admin

Autenticação multifator (Passkey)

A Evercore suporta autenticação multifator baseada em WebAuthn/Passkey para chaves de API administrativas. Isso adiciona uma segunda camada de verificação usando biometria (Face ID, Touch ID), autenticadores de plataforma (Windows Hello) ou chaves físicas de segurança (YubiKey).

Como funciona

A MFA é vinculada a chaves de API individuais, não a sessões do navegador:

• As passkeys são registradas pelo padrão WebAuthn (FIDO2) • A chave privada do autenticador nunca sai do dispositivo — apenas a chave pública é armazenada no servidor • Cada autenticação produz uma resposta assinada ao desafio que é verificada pelo servidor • Um token MFA de curta duração (TTL de 15 min, assinado com HMAC) é emitido com sucesso • O token é enviado pelo cabeçalho X-Evercore-MFA para operações de step-up • A prova é vinculada criptograficamente ao IP e dispositivo solicitante — um token capturado não pode ser reutilizado de outra rede ou navegador

Autenticação de elevação

A elevação é um controle opcional que você ativa por chave de API no seu perfil. Quando ativa, as ações mais sensíveis exigem um toque de passkey recente (uma prova emitida nos últimos 2 minutos), não apenas uma sessão válida:

• Apagamento GDPR — criar, aprovar e executar (crypto-shred irreversível) • Criação, revogação e rotação de chaves de API • Alterações de wallet da Arweave e de credenciais do operador Hedera • Emissão e revogação de credenciais S3 • Criação/revogação de transferências criptografadas e alterações de controles de conformidade

Agentes autônomos agem com a sua chave de API, então enquanto a elevação estiver ativa eles não podem executar essas ações — recebem uma negação explícita para que um humano as conclua. Desativar a elevação também exige um toque recente.

Propriedades de segurança

• Detecção de autenticador clonado: regressões do contador de assinatura são rejeitadas • Proteção contra replay: as provas são vinculadas a IP + dispositivo e verificadas contra hashes armazenados • Rate limiting: limitação por requisição mais um bloqueio de 30 minutos após 5 tentativas falhas • Validação de origem: RP ID e origem são verificados estritamente para evitar phishing • Códigos de recuperação: 10 códigos de uso único para recuperar acesso sem passkey • Enrolamento obrigatório (opcional): implantações podem exigir uma passkey antes de qualquer acesso • Múltiplas credenciais: até 10 passkeys por chave de API para redundância de dispositivos • Sem segredos compartilhados: WebAuthn usa criptografia de chave pública — sem sementes TOTP nem códigos compartilhados

Conformidade e certificações

A arquitetura sem estado e a criptografia da Evercore ajudam na conformidade com:

• HIPAA: a criptografia AES-256-GCM satisfaz o safe harbor de criptografia da HIPAA para PHI. A Evercore não armazena PHI. Clientes que precisarem de um BAA devem entrar em contato. • GDPR: o design sem estado significa que a Evercore mantém poucos dados pessoais. Veja a Política de privacidade para detalhes sobre os direitos dos titulares. • SOC 2 (em andamento): estamos buscando a certificação SOC 2 Type II. Entre em contato para a documentação atual da nossa atestação de segurança. • ISO 27001: as políticas de segurança da infraestrutura estão alinhadas aos controles ISO 27001.

Observação: a conformidade é uma responsabilidade compartilhada. Os clientes devem implementar controles apropriados em seus próprios ambientes.

Divulgação de vulnerabilidades

Levamos vulnerabilidades de segurança muito a sério. Se você descobrir um problema de segurança na Evercore, faça a divulgação de forma responsável.

Como reportar: • Email: {{email}} • Chave PGP disponível mediante solicitação para comunicações criptografadas • Inclua: componente afetado, passos para reproduzir, impacto potencial

Nosso compromisso: • Confirmaremos o recebimento em até 48 horas • Forneceremos uma avaliação inicial em 7 dias • Vulnerabilidades críticas serão corrigidas e divulgadas em 90 dias • Não tomamos medidas legais contra pesquisadores de boa-fé que sigam esta política

No momento não oferecemos programa de bug bounty, mas achados relevantes serão reconhecidos em nosso changelog.