FatoCadeia de Custódia

Documento Técnico · Segurança · Público

Garantias de Integridade e Autenticidade
de Gravações Fato

Este documento descreve os mecanismos criptográficos aplicados a cada gravação produzida pela plataforma Fato. Destina-se a advogados, peritos, auditores e órgãos do Poder Judiciário que precisem aferir a confiabilidade técnica das evidências apresentadas.

Versão
1.1
Vigência
18 abr 2026
Algoritmos
SHA-256 · Ed25519
Conformidade
FIPS 180-4 · RFC 8032
§ 1 · Sumário Executivo

Objeto e alcance

Toda gravação produzida pela plataforma Fato é registrada com três mecanismos criptográficos independentes, descritos no § 2. Em conjunto, esses mecanismos asseguram que (a) o conteúdo binário do arquivo de vídeo não sofreu alteração após a captura, (b) os metadados (autor, horário, ambiente) são autênticos e (c) a sequência temporal dos blocos de vídeo é verificável.

A verificação pode ser executada por terceiros, sem dependência da infraestrutura Fato, mediante o procedimento descrito no § 5. As propriedades criptográficas decorrem de padrões normativos elencados no § 6.

Nota

Este documento trata exclusivamente de garantias técnicas aplicadas ao arquivo gravado. A análise probatória do conteúdo exibido em tela permanece sob responsabilidade do operador do Direito.

§ 2 · Arquitetura de Garantia

As três camadas independentes

A integridade de uma gravação Fato repousa sobre três mecanismos independentes. A adulteração bem-sucedida de uma gravação exigiria comprometer simultaneamente os três, sem deixar inconsistência verificável em nenhum.

  1. I

    Assinatura ed25519 do cliente sobre os metadados

    Chave gerada localmente para cada sessão; nunca transita pela rede. Detalhe em § 2.1.

  2. II

    Hash SHA-256 encadeado a cada bloco de vídeo

    Estrutura semelhante a uma cadeia de blocos: cada hash incorpora o anterior. Detalhe em § 2.2 e na Especificação de Hash.

  3. III

    Manifesto contra-assinado pelo servidor

    Sumário JSON de toda a sessão, assinado com chave ed25519 persistente do servidor Fato. Detalhe em § 2.3.

§ 2.1Assinatura ed25519 do cliente

No início da sessão, o cliente (versão web ou aplicativo desktop) gera um par de chaves ed25519 efêmero, válido exclusivamente para aquela gravação. A chave privada é mantida em memória local e descartada ao encerramento. A chave pública acompanha o quadro inicial de metadados enviado ao servidor.

A assinatura recai sobre a serialização canônica do bloco de metadados — identidade do operador, horário de início, ambiente de captura, motivo declarado e demais campos listados no fluxo de captura. Uma vez aposta, qualquer alteração ulterior nesse bloco é detectada na verificação (§ 5).

AlgoritmoEd25519 (Edwards-curve DSA, Curve25519)
Tamanho da chave256 bits (32 bytes)
Tamanho da assinatura512 bits (64 bytes)
PersistênciaChave efêmera, descartada ao fim da sessão
NormaRFC 8032 [2]; FIPS 186-5 [3]

§ 2.2Hash SHA-256 encadeado

Cada bloco de vídeo (segmento fMP4 de aproximadamente um segundo) gera um hash SHA-256 calculado sobre a concatenação do hash do bloco anterior e do conteúdo binário do bloco corrente. O resultado é uma sequência matemática em que a modificação de qualquer bloco invalida todos os hashes subsequentes.

A construção, propriedades e procedimento de cálculo estão descritos integralmente no documento Geração de Hash.

§ 2.3Manifesto contra-assinado pelo servidor

Ao receber o quadro de encerramento, o servidor compõe um manifesto JSON contendo a totalidade dos parâmetros da sessão (vide tabela abaixo) e o assina com sua chave ed25519 persistente. A chave do servidor é gerada na primeira inicialização da plataforma e armazenada em arquivo de seed de acesso restrito ao processo do servidor.

CampoConteúdo
session_idIdentificador único da gravação (UUID v4)
user_idE-mail do operador autenticado
client_pubkeyChave pública ed25519 do cliente (§ 2.1)
started_at / ended_atTimestamps em UTC, formato ISO-8601
sha256_finalHash SHA-256 do arquivo de vídeo completo
chain_hashHash final da cadeia descrita em § 2.2
tamper_detectedIndicador booleano (vide § 3)
tamper_eventsLista cronológica de eventos suspeitos detectados
metadata_signatureAssinatura do cliente sobre os metadados (§ 2.1)
server_signatureAssinatura ed25519 do servidor sobre o JSON acima
Justificativa da dupla assinatura

A assinatura do cliente atesta a autoria da captura. A assinatura do servidor atesta o recebimento íntegro. A forjadura conjunta exigiria o comprometimento simultâneo do dispositivo do operador e da infraestrutura da plataforma — sem que qualquer dos dois processos deixasse vestígio verificável.

§ 3 · Detecção de Adulteração

Eventos monitorados em tempo real

Durante a captura, o cliente monitora o ambiente operacional e registra qualquer ocorrência que possa indicar manipulação ou degradação da fidelidade da gravação. Tais eventos não interrompem a captura — são apenas registrados no manifesto (§ 2.3) para subsidiar a análise pericial subsequente.

EventoDescrição
DOM modificadoEm capturas de aba (versão web), execução de scripts de console ou extensões alterando o conteúdo da página durante a sessão.
Permissão revogadaInterrupção, pelo usuário, da permissão de captura de tela, áudio do sistema ou microfone.
Mudança de dispositivoSubstituição do dispositivo de saída ou entrada de áudio monitorado durante a sessão.
Janela perdidaEncerramento da janela ou aba capturada antes do comando explícito de finalização.
§ 4 · Modelo de Ameaças

Vetores cobertos e fora de escopo

§ 4.1Vetores cobertos

Os mecanismos descritos em § 2 protegem, com nível de segurança equivalente a 128 bits, contra:

  • edição posterior do arquivo de vídeo (qualquer byte);
  • substituição do arquivo no armazenamento;
  • alteração de metadados (autor, horário, ambiente, IP);
  • falsificação de gravações por terceiros;
  • repúdio pelo próprio operador (negativa de autoria);
  • corte, inserção ou reordenação de trechos do vídeo.

§ 4.2Vetores fora de escopo

A plataforma não pretende proteger, e o operador deve estar ciente, contra:

  • conteúdo falso ou ilícito exibido na tela durante a captura;
  • filmagem da tela com câmera externa ao dispositivo capturado;
  • comprometimento físico do dispositivo do operador;
  • engenharia social aplicada ao operador.

Em síntese: Fato comprova o que foi capturado. A análise probatória do que foi exibido permanece competência do operador do Direito.

§ 5 · Procedimento de Verificação

Como aferir a autenticidade

Toda gravação finalizada pode ser verificada por terceiros independentemente da infraestrutura Fato. Requerem-se quatro artefatos: o arquivo de vídeo, o manifesto JSON, a assinatura do servidor e a chave pública do servidor (publicada no portal e disponível para fixação prévia por escritórios).

EtapaOperação
1.Calcular SHA-256 do arquivo de vídeo recebido. Comparar com o campo sha256_final do manifesto.
2.Verificar a assinatura do servidor sobre o manifesto JSON, usando a chave pública pinada.
3.Verificar a assinatura do cliente sobre os metadados, usando o campo client_pubkey do próprio manifesto.
4.Aprovação simultânea das três etapas atesta a integridade e a autenticidade da gravação.

Implementação de referência em Python disponível no documento Geração de Hash, § 6.

§ 6 · Referências Normativas

Padrões aplicáveis

  1. NIST FIPS 180-4 Secure Hash Standard (SHS). National Institute of Standards and Technology, agosto de 2015. nvlpubs.nist.gov/.../FIPS.180-4
  2. RFC 8032 — Josefsson & Liusvaara, Edwards-Curve Digital Signature Algorithm (EdDSA). IETF, janeiro de 2017. rfc-editor.org/rfc/rfc8032
  3. NIST FIPS 186-5 Digital Signature Standard (DSS). National Institute of Standards and Technology, fevereiro de 2023. nvlpubs.nist.gov/.../FIPS.186-5
  4. NIST SP 800-107 Rev. 1 Recommendation for Applications Using Approved Hash Algorithms. Agosto de 2012.
  5. Lei nº 13.709/2018 (LGPD) considerada na concepção dos campos de identidade e retenção de metadados.
Fato · Documento Técnico de Segurança · Versão 1.1Vigência 18.04.2026