O que um cofre biométrico homomórfico custa hoje: cinco critérios medidos

Rótulo honesto: o cofre descrito aqui é pesquisa, arquivada, sem caminho para produção. O produto da Hummand usa custódia centralizada, com envelope de chaves em módulo gerenciado, isolamento por cliente no banco e destruição criptográfica na retenção, e declara isso. Esta nota é o que aprendemos medindo a alternativa, e o motivo de ela não ser o produto.

A tese, e o gate

A tese do cofre é verificar identidade sem que o operador decifre o modelo biométrico: o template fica cifrado com criptografia homomórfica, a comparação acontece sobre o texto cifrado, e a decifração do resultado exige a cooperação de várias partes, entre elas o próprio cliente. Bonita no papel, e por isso mesmo perigosa: é o tipo de arquitetura que se promete antes de medir.

Antes de qualquer código de produto, fixou-se um gate com seis critérios e limites de aceitação escritos: (5) os bindings Python cobrem o fluxo inteiro; (1) o protocolo multipartidário funciona ponta a ponta com três partes; (2) a precisão numérica não contamina a decisão biométrica; (4) tudo se reproduz na mesma versão travada, semanas depois; (3) a latência cabe numa API interativa em hardware representativo; (6) outra pessoa reproduz os resultados só com o código e a documentação. A ordem de execução foi 5, 1, 2, 4, e o combinado era: falha em qualquer um reabre a escolha do esquema.

O esquema é CKKS, o único homomórfico com aritmética aproximada sobre reais, que é o que produto interno entre embeddings pede. A biblioteca é OpenFHE 1.5.1, com os bindings Python travados numa versão exata. Parâmetros: profundidade multiplicativa 1, escala de 50 bits, lote de 512, segurança clássica de 128 bits.

O que passou

Critério	O que se mediu	Resultado	Limite
5, bindings	Todas as operações do fluxo via Python	expostas e funcionais; teste de fumaça com erro de 2e-12	fluxo inteiro sem C++
1, protocolo	Três partes, geração de chaves distribuída, soma, multiplicação e produto escalar, cem execuções	100 de 100; erro máximo 8,5e-12	cem execuções sem falha
2, precisão (distância)	Distância euclidiana ao quadrado, dez mil pares, dimensão 512	erro relativo médio 1,69e-13; pior caso 3,75e-12	médio abaixo de 1e-3; pior abaixo de 1e-2
2, precisão (face)	Produto interno, dez mil pares normalizados, dimensão 512	erro relativo médio 8,73e-11; pior caso 8,27e-8	os mesmos
4, estabilidade	Critérios 1 e 2 repetidos 28 dias depois, mesma versão	correção idêntica; variação numérica abaixo de 3%	variação abaixo de 10%

A margem de precisão é de sete a onze ordens de grandeza. Os pares próximos, que simulam a mesma pessoa e são a região em que a decisão acontece, não têm erro maior de forma sistemática: na distância, o erro deles é cerca de cinco vezes o dos pares distantes, mas ambos na casa de 1e-13; no produto interno, é menor. Num teste de fumaça com duzentos pares de rostos reais de um conjunto público, a degradação das taxas de falsa aceitação e falsa rejeição foi zero; a execução completa de seis mil pares foi abandonada por instabilidade da máquina e dispensada com justificativa registrada, porque um erro de 1e-8 não move uma decisão cujo intervalo entre distribuições é de cerca de 0,4.

Em resumo: a aritmética não é o custo. Sobre os erros de aproximação do CKKS, nesta operação e nesta dimensão, não há nada a temer.

O que custou, e onde o custo mora

O protocolo exige todas as partes, não um subconjunto. O plano era custódia dois de três: qualquer duas partes cooperam para decifrar, e uma pode cair. No primeiro critério, a decifração com duas de três partes lançou exceção em cem de cem execuções. O esquema multipartidário do OpenFHE para CKKS é N de N. Como confidencialidade, isso é mais forte que o plano. Como disponibilidade, é o oposto: a perda permanente do segredo de qualquer parte torna a base daquele cliente irrecuperável por meio criptográfico, e o que resta é mitigação operacional, com módulos de chave redundantes e procedimentos, não protocolo. Devolver a propriedade de subconjunto exige uma camada adicional de compartilhamento de segredo sobre as chaves, reconstruída dentro de um enclave atestado e descartada depois. Isso foi estudado e é viável; não é código.

A decifração é um oráculo, e o esquema é frágil diante dele. CKKS é inseguro contra um adversário que observa saídas de decifração: com acesso a esse oráculo, recupera-se a chave. A mitigação padrão, inundar as parciais com ruído, existe na biblioteca para os esquemas exatos e não existe para CKKS, porque o ruído necessário destruiria a precisão que o esquema oferece. A consequência é uma restrição de arquitetura, não um parâmetro: só podem chegar ao pipeline de decifração textos cifrados gerados pelo próprio cofre, nunca de origem externa. É uma restrição sustentável, mas é mais uma coisa que precisa ser verdade o tempo todo.

O desempenho no ambiente de referência nunca foi medido. O critério 3 pede mil verificações ponta a ponta, com a recuperação do texto cifrado e a decifração por três partes, em instância de nuvem representativa, com mediana abaixo de 500 ms e p95 abaixo de 1,5 s. A instância não foi contratada e o critério ficou aberto. O que existe são latências laterais, sem valor de gate: a operação de produto interno com cifração e decifração num único processo, em ambiente de desenvolvimento virtualizado, custou cerca de 91 ms por par, e a mesma suíte de distância variou de 76 ms a 147 ms por par entre a execução original e a repetição, uma oscilação de 48% atribuída ao ambiente, com os erros numéricos idênticos. Nada disso inclui rede nem o protocolo entre partes.

A verificação independente não aconteceu. O critério 6 pede que alguém de fora reproduza tudo só com o código e a documentação. O código e a documentação existem; a pessoa de fora, não.

O ambiente é estreito. Os bindings Python só rodam em Linux, e a captura no navegador, que a tese pede para o template nunca sair em claro do dispositivo, não tem binding maduro para a web na biblioteca escolhida. O código de pesquisa que existe tem custódia distribuída apenas nominal: as três chaves vivem no mesmo processo, e o limiar de decisão biométrica não foi calibrado com dados reais.

A leitura honesta

O gate foi desenhado para reprovar o esquema, e ele não reprovou: a matemática do CKKS, para esta operação, é sólida e reproduzível. O que o gate fez foi mais útil do que reprovar. Mostrou que o custo de um cofre homomórfico hoje não está na precisão, e sim em três lugares que a promessa costuma esconder: a disponibilidade sob N de N, a superfície de ataque da decifração, e o desempenho e a verificação externa que ficaram por medir.

Foi com esse retrato que o cofre saiu da linha de produto e virou trilha de pesquisa. O produto que existe faz o oposto, e diz isso: decifra sob custódia centralizada, dentro de limites declarados, com destruição criptográfica na retenção. Não é a tese. É o que se sustenta com o que foi medido.

Limites

• Os critérios foram executados em ambiente de desenvolvimento virtualizado, com uma única máquina simulando as três partes. Nenhum número de latência aqui é um resultado de gate.
• A precisão foi medida com vetores sintéticos e um teste de fumaça com rostos de um conjunto público; a execução completa com rostos reais foi dispensada por justificativa, não concluída.
• Os parâmetros são os de uma profundidade multiplicativa 1, suficiente para produto interno. Operações mais profundas mudam o custo e não foram medidas.
• O gate não está concluído: dois de seis critérios continuam abertos, e a trilha está parada desde 2026-05-31. Se for retomada, começa por eles.