Modelo de Segurança, Privacidade e Análise de Ameaças (STRIDE)

Diretrizes de Segurança em Profundidade, Proteção Criptográfica e Conformidade LGPD

O CyberCore Signer foi concebido sob os princípios de Security by Design (Segurança desde a Concepção) e Least Privilege (Menor Privilégio), seguindo as normas da Infraestrutura de Chaves Públicas Brasileira (ICP-Brasil) e as exigências da Lei Geral de Proteção de Dados (LGPD — Lei nº 13.709/2018).

1. Modelo de Ameaças STRIDE e Matriz de Mitigações

Categoria STRIDE	Ameaça Potencial	Superfície / Vetor	Mitigação Implementada no CyberCore Signer
S - Spoofing (Falsificação de Identidade)	Aplicação web maliciosa se passa por sistema corporativo para assinar documentos fraudulentos.	`POST /ccsp/v1/sign`, `GET /ccsp/v1/certificates`	1. Validação estrita de `Host` loopback (`127.0.0.1` / `localhost`). 2. Verificação de `Origin` autorizada cadastrada no `ApplicationRegistry`. 3. Handshake de consentimento explícito do usuário com diálogo nativo do sistema operacional.
T - Tampering (Adulteração de Dados)	Malware local modifica arquivo `authorized-apps.json` para autorizar origens maliciosas silenciosamente.	Sistema de arquivos local (`~/.cybercore/authorized-apps.json`)	1. Assinatura de integridade por HMAC-SHA256 (`authorized-apps.json.hmac`) com chave isolada (`.vault_key`). 2. Permissões POSIX restritas `0600`/`0700` (acesso exclusivo do usuário dono). 3. Descarte total e alerta de auditoria em caso de divergência do HMAC.
R - Repudiation (Repúdio de Operações)	Usuário ou aplicação contesta a execução de uma assinatura digital.	Transações CCSP / Logs	1. Princípio WYSIWYS: exibição obrigatória de origem, aplicação, nome/tamanho do documento e hash SHA-256 legível. 2. Logs de auditoria estruturados com `request_id` (UUID), timestamp ISO 8601, algoritmo e fingerprint do certificado (sem expor segredos).
I - Information Disclosure (Vazamento de Informações)	Vazamento de chave privada, PIN do token A3 ou documentos confidenciais.	Memória, tráfego de rede e arquivos de log	1. Chaves privadas nunca saem da máquina/hardware. 2. Operação primária por Digest (o documento confidencial nunca trafega para o agente). 3. PIN manipulado em `char[]` efêmero com limpeza de memória (`Arrays.fill`). 4. Mascaramento LGPD de CPF em carimbos visuais. 5. Loopback estrito `127.0.0.1` e cabeçalhos PNA (`Access-Control-Allow-Private-Network`).
D - Denial of Service (Negação de Serviço)	Invasor esgota conexões locais, tenta replay de assinaturas ou trava token mono-thread.	Socket HTTP local, driver PKCS#11	1. Trava FIFO serializada (`signLock` ReentrantLock) para proteção de drivers A3 mono-thread. 2. `NonceManager` com expiração TTL, tolerância a clock skew (30s) e deduplicação atômica. 3. Detecção e tratamento de colisão de porta com mecanismo de Port-Hunting sequencial.
E - Elevation of Privilege (Elevação de Privilégio)	Usuário ou script tenta forçar modo de desenvolvimento (`--dev`) em ambiente de produção para simular assinaturas.	Linha de comando / Flags de execução	1. Trava inviolável no bootstrap (`CyberCoreSignerApplication`): compilações com `flavor=production` abortam imediatamente com `SecurityException` se `--dev` for fornecido. 2. O modo dev só pode ser compilado através do perfil Maven explícito `-Pdev`.

2. Comunicação Local e Arquitetura de Transporte (HTTP vs WebSocket)

2.1 Por que HTTP REST Loopback em vez de WebSockets?

O CyberCore Signer utiliza HTTP/1.1 REST Loopback em 127.0.0.1:21325 por decisões fundamentadas de segurança:

Mitigação de CSWSH (Cross-Site WebSocket Hijacking): WebSockets não respeitam a política Same-Origin Policy (SOP) tradicional e ignoram restrições CORS padrão de preflight OPTIONS. Um script malicioso em qualquer aba poderia abrir conexões bidirecionais diretas sem controle prévio.
Compatibilidade com Private Network Access (PNA): Navegadores modernos (Chromium / Firefox) impõem restrições rigorosas quando páginas web públicas acessam 127.0.0.1. O protocolo HTTP REST permite responder ao preflight com Access-Control-Allow-Private-Network: true, atendendo integralmente às diretrizes do W3C.
Preflight CORS Determinístico: Cada método sensível é precedido por um preflight que valida o Origin contra o registro de aplicações autorizadas antes que qualquer payload seja consumido.

3. Isolamento de Rede e Proteção Local

3.1 Ligação Estrita ao Loopback (`127.0.0.1`)

O servidor HTTP do protocolo CCSP/1 vincula-se exclusivamente ao endereço IPv4 local 127.0.0.1.

Sem Escuta Externa: O agente nunca realiza bind em 0.0.0.0 ou em interfaces de rede de área local (LAN) ou externa (WAN).
Bloqueio no Socket: Tentativas de acesso originadas fora da própria estação de trabalho são sumariamente recusadas pelo subsistema de rede do sistema operacional antes de qualquer processamento da aplicação.

3.2 Proteção Contra Ataques de DNS Rebinding

Para neutralizar ataques em que domínios externos tentam resolver para 127.0.0.1 e burlar a política de mesma origem do navegador:

O CcspServer valida expressamente o cabeçalho HTTP Host em todas as requisições (incluindo preflight OPTIONS).
Somente requisições com Host correspondente a 127.0.0.1:{porta}, localhost:{porta} ou [::1]:{porta} são aceitas; qualquer outro valor é rejeitado com status 403 Forbidden (INVALID_ORIGIN).

4. Integridade Criptográfica do Registro de Aplicações (`ApplicationRegistry`)

As aplicações autorizadas pelo usuário são armazenadas em disco sob um esquema de proteção em profundidade:

Caminho: ~/.cybercore/authorized-apps.json.
Assinatura HMAC-SHA256: Arquivo companheiro authorized-apps.json.hmac calcula o HMAC dos bytes JSON usando chave mestre de 256 bits gerada via SecureRandom e armazenada em ~/.cybercore/.vault_key.
Permissões de Arquivo: Aplicação de restrições POSIX (0600 para arquivos e 0700 para diretórios) garantindo que apenas o usuário logado no sistema operacional possua direitos de leitura e escrita.
Detecção de Adulteração: Se o arquivo JSON for modificado externamente (por malware ou editor de texto) sem a chave mestre, o carregamento descarta 100% das autorizações e emite alerta crítico de auditoria.

5. Proteção de Memória e Ciclo de Vida do PIN/Chaves

Assinatura Exclusivamente Assistida: Toda operação de assinatura exige interação humana voluntária. O agente nunca assina documentos em segundo plano de forma desassistida via API.
Inviolabilidade da Chave Privada: As chaves privadas ICP-Brasil nunca são exportadas em formato de bytes brutos. Operações em certificados A3 utilizam handles nativos do hardware/middleware (PKCS#11 / MSCAPI).
Higienização de Memória Volátil:
- O PIN de smartcards e senhas de certificados A1 nunca são convertidos para strings imutáveis do Java (java.lang.String).
- São manipulados estritamente como arrays de caracteres mutáveis char[].
- Imediatamente após a autenticação do token, o array é sobrescrito com zeros via Arrays.fill(pinBuffer, (char) 0).
Remoção de Hardware (TOKEN_REMOVED): Se o usuário desconectar o token USB ou retirar o cartão do leitor, o SmartCardWatcher força a limpeza imediata do cache de sessão e dos buffers do sistema operacional.

6. Software Bill of Materials (SBOM) e Cadeia de Suprimentos

CycloneDX SBOM: O build padronizado do projeto gera automaticamente o SBOM nos formatos target/bom.json e target/bom.xml conforme a especificação CycloneDX 1.6.
Análise Estática e Vulnerabilidades: O pipeline de CI executa verificações contínuas de segurança:
- SpotBugs + FindSecBugs: Análise estática profunda de vulnerabilidades criptográficas e injeções de código.
- Enforcer Plugin: Verificação rigorosa de versões mínimas do compilador e convergência de dependências transitivas.

8.2 KiB Raw Blame History