cybercore-signer/docs/limitations.md

Limitações Técnicas e Dependências Declaradas

Declaração Formal de Dependências de Plataforma, Limitações de Hardware e Concorrência (Regra 23)

Em estrita conformidade com a Regra 23 do projeto CyberCore Signer ("Não invente suporte a certificados, tokens, providers, algoritmos ou hardware que não tenham sido realmente implementados/testados. Quando algo depender de fabricante, middleware, Windows ou hardware físico, declare a dependência"), as seguintes limitações técnicas e dependências são formalmente declaradas:

---

1. Dependências de Sistema Operacional e Repositório Nativo

1. Repositório Nativo do Windows (Windows-MY):

   • O provedor WindowsCertificateStoreProvider depende exclusivamente das APIs Win32/CryptoAPI e CNG expostas pelo provedor SunMSCAPI do JDK.
   • Disponibilidade: Suportado exclusivamente em Microsoft Windows (Windows 10 e Windows 11).
   • Comportamento em Linux e macOS: O provedor declara-se indisponível (isAvailable() == false) em sistemas não-Windows, operando através de arquivos A1 (PKCS#12) ou acesso PKCS#11 direto.

2. Arquitetura de CPU dos Middlewares Proprietários:

   • A maioria dos drivers comerciais de tokens USB no Brasil (ex: SafeSign Identity Client da AET Europe e SafeNet da Thales) é compilada nativamente para a arquitetura x86_64 (64-bit).
   • Ambientes executando em processadores ARM64 (como novos computadores Windows on ARM ou Apple Silicon) requerem a camada de emulação x64 do sistema operacional para carregar essas bibliotecas dinâmicas legadas.

---

2. Dependências de Hardware e Middlewares de Terceiros

1. Tokens A3 e Leitores de Smartcard Físicos:

   • O CyberCore Signer não substitui os drivers do fabricante do token. É indispensável que os drivers de hardware e o middleware do fabricante (SafeSign, SafeNet, GD Burti, Certisign, OpenSC, etc.) estejam instalados na estação de trabalho para que o sistema operacional e a leitora USB reconheçam o chip físico.
   • O agente detecta a presença da biblioteca e interage com o dispositivo através de interfaces padronizadas (PKCS#11 ou CAPI/CNG).

2. Política de Bloqueio por PIN Incorreto (Controle do Chip Físico):

   • O chip criptográfico de qualquer smartcard ou token ICP-Brasil possui um contador de segurança interno em hardware (geralmente limitado a 3 tentativas incorretas consecutivas).
   • O bloqueio do cartão e a exigência do código de desbloqueio (PUK) são governados com exclusividade pelo hardware do fabricante. O software do CyberCore Signer não tem como burlar, redefinir ou impedir esse bloqueio.

---

3. Concorrência e Acesso a Dispositivos Mono-Thread

1. Serialização Mandatória de Operações (signLock):

   • A especificação PKCS#11 e a maioria das implementações de drivers de smartcard operam sob canal serial exclusivo de I/O por leitora.
   • Requisições simultâneas de assinatura contra o mesmo token físico causam erro de sessão ou congelamento no driver caso executadas em paralelo.
   • Solução Arquitetural: O CyberCore Signer enfileira todas as operações criptográficas através de uma trava FIFO (signLock), processando cada assinatura individualmente e garantindo a estabilidade do hardware.

2. Isolamento de Origem e Rede Loopback:

   • O servidor local CCSP/1 vincula-se estritamente ao endereço 127.0.0.1:21325. O agente não suporta e deliberadamente rejeita conexões de computadores remotos da rede local (LAN), priorizando a segurança e a inviolabilidade da máquina do usuário.