Evidência de vídeo que se sustenta: integridade, carimbo e verificação por terceiros
Resposta curta
Um hash criptográfico prova uma coisa só: que estes bytes são os mesmos de quando o hash foi calculado. A norma que define o SHA-256, a FIPS 180-4 do NIST, diz exatamente isso — os resumos servem para detectar se as mensagens mudaram desde que os resumos foram gerados, e qualquer alteração na mensagem produz, com altíssima probabilidade, um resumo diferente.
O que o hash não prova: que a cena aconteceu como se alega, que a hora declarada é verdadeira, nem que o arquivo não foi trocado antes do cálculo. Cada uma dessas três lacunas exige um instrumento diferente — carimbo dentro dos pixels medidos, referência de tempo externa e verificação que qualquer terceiro possa refazer sozinho.
Neste texto
O que um hash criptográfico realmente prova?
Um hash transforma um arquivo de qualquer tamanho num valor de tamanho fixo. No SHA-256 esse valor tem 256 bits, escritos em geral como 64 caracteres hexadecimais.
A FIPS 180-4, publicada pelo NIST em agosto de 2015, declara os algoritmos seguros porque é computacionalmente inviável encontrar uma mensagem que corresponda a um resumo dado e encontrar duas mensagens diferentes que produzam o mesmo resumo. É a segunda propriedade que sustenta o uso probatório: ninguém consegue fabricar um segundo arquivo, com outro conteúdo, que apresente o mesmo código.
Na prática forense isso vira uma afirmação estreita e forte: este arquivo é bit a bit o mesmo que existia quando o código foi calculado. Recortar, clarear, recomprimir ou salvar de novo em outro programa quebra a correspondência.
O que o hash não prova
A confusão mais cara em discussão de prova digital é tratar integridade como autenticidade. São coisas diferentes, e o hash resolve apenas a primeira.
| Afirmação | O hash sustenta? | O que sustentaria |
|---|---|---|
| O arquivo não foi alterado depois do cálculo | Sim | O próprio hash, recalculado por quem duvida. |
| O arquivo já existia antes de uma certa data | Não | Carimbo de tempo emitido por terceiro sobre o hash. |
| A hora impressa na imagem é a hora real | Não | Relógio sincronizado com fonte externa, mais o carimbo de terceiro. |
| A cena retrata o que se alega | Não | Contexto, testemunho, coerência com outros registros, perícia. |
| Nada foi trocado antes do cálculo do hash | Não | Cadeia de custódia e cálculo o mais perto possível da origem. |
| Quem gerou o arquivo é quem diz ser | Não | Assinatura digital com chave associada a uma identidade. |
A última linha merece nota. Hash não é assinatura: hash é público e qualquer um calcula; assinatura envolve chave privada e amarra o resultado a um titular. Um sistema pode ter integridade perfeita e nenhuma autoria demonstrável — aceitável, desde que se diga com clareza.
Por que o carimbo visual precisa estar dentro dos pixels que o hash cobre
Toda evidência de vídeo carrega informação sobre si mesma: data, hora, identificação da câmera, local, e no nosso caso a velocidade medida. O que decide se essa informação vale alguma coisa é onde ela mora.
Se mora fora do que foi medido — metadado editável, nome do arquivo, planilha ao lado —, é possível mudar a data sem quebrar o hash: o código continua batendo e a afirmação temporal continua sem sustentação. Se está desenhada dentro dos próprios pixels, alterá-la muda a imagem, muda o hash e o conflito aparece na hora.
É princípio geral, não truque de implementação: o que o hash não cobre, o hash não protege. Vale para carimbo de data, identificação de câmera e qualquer anotação que alguém pretenda usar como afirmação de fato.
Quem garante a hora?
Ninguém, se a única fonte for o relógio de quem produziu o arquivo. Relógio de gravador de CFTV atrasa, é reconfigurado, perde a bateria e volta para uma data de fábrica. E é controlado por uma das partes da discussão.
A solução padrão da internet é a autoridade de carimbo de tempo da RFC 3161: terceira parte confiável que fornece prova de existência de um dado num instante no tempo, obrigada a usar fonte de tempo confiável. Dois detalhes da mesma norma dizem onde isso para: a autoridade carimba apenas uma representação em hash do dado, nunca o dado; e é obrigada a não examinar aquilo que carimba, além de conferir o comprimento do valor.
Ou seja: a testemunha externa atesta o instante e declara desinteresse total pelo conteúdo. É virtude, porque preserva o sigilo, e é limite, porque nenhum carimbo de tempo diz que a imagem é verdadeira. Ele diz que ela é antiga.
Cada registro que o OpenRadar produz sai com uma assinatura SHA-256 que qualquer pessoa pode recalcular sem falar com a gente. A página de verificação é pública, roda inteira no navegador de quem confere e não envia a imagem para servidor nenhum — inclusive quando o resultado é que o arquivo não bate.
Em que momento o hash deve ser calculado?
O mais perto possível da origem. Todo intervalo entre o instante em que a imagem foi formada e o instante em que o resumo foi calculado é um período que o hash não cobre — e é nesse período que uma troca de arquivo passaria despercebida.
A consequência de arquitetura é direta: calcular o resumo no servidor central, depois de o arquivo atravessar rede, gravador e sistema de gestão, protege muito menos do que calcular na borda. O algoritmo é o mesmo, mas a afirmação encolhe — de “nada mudou desde o registro” para “nada mudou desde a chegada ao servidor”.
Por isso integridade não substitui cadeia de custódia. Ela documenta com precisão matemática um trecho da vida do arquivo; quem responde por cada trecho anterior continua sendo questão de organização, contrato e registro de acesso.
Verificação independente é o que dá força numa disputa
Um sistema de evidência tem duas arquiteturas possíveis. Na primeira, o fornecedor guarda a verdade e emite laudos: quem duvida acredita nele ou contrata perícia. Na segunda, ele publica o suficiente para que qualquer pessoa refaça a conferência com ferramentas comuns, e a resposta não depende de ninguém estar de boa-fé.
A diferença aparece no momento em que o sistema é atacado. Numa assembleia ou numa audiência, a pergunta não é se o fornecedor é sério — é se o outro lado consegue conferir sozinho. Verificação independente troca confiança por aritmética, e aritmética não tem lado.
Daí três exigências de projeto, todas verificáveis por quem contrata.
- Algoritmo público e padronizado.
- Valor de referência publicado junto com a evidência ou em canal separado.
- Conferência que funcione com ferramentas já existentes no computador de qualquer pessoa.
Como você mesmo confere a integridade de um arquivo?
Se você recebeu um arquivo e o valor SHA-256 correspondente, a conferência leva menos de um minuto e não exige instalar nada.
- Baixe o arquivo original, sem abrir e salvar de novo. Reencaminhar por aplicativo que recomprime imagem já invalida a conferência — não é defeito do método, é o método funcionando.
-
Calcule o resumo. No macOS ou no Linux:
shasum -a 256 arquivo.jpg. No Windows, no Prompt de Comando:certutil -hashfile arquivo.jpg SHA256. - Compare com o valor declarado. São 64 caracteres: compare todos, não só o começo e o fim.
- Registre o que você fez. Data da conferência, comando usado e valor obtido. É o que torna a sua checagem citável por outra pessoa.
Para as evidências do OpenRadar existe o caminho curto: a página verificar uma evidência recalcula a assinatura da foto dentro do seu próprio navegador, sem enviar a imagem para nenhum servidor. E vale a advertência: resultado positivo diz que o arquivo está íntegro, não que o registro está certo. Integridade é o piso da discussão, não o teto — por isso precisa vir acompanhada de método declarado, como em medir velocidade por vídeo.
Não afirma que um hash prove quando a imagem foi feita, nem que ela retrate a realidade. Ele prova apenas que o arquivo não mudou desde o cálculo.
Não afirma que carimbo de tempo de terceiro valide conteúdo. A RFC 3161 obriga a autoridade a não examinar o que está sendo carimbado, o que é exatamente o contrário de atestar veracidade.
Não descreve o formato interno do marcador do OpenRadar, o layout do carimbo nem como a assinatura viaja junto do arquivo. Tudo o que está aqui vale para qualquer sistema que use hash padronizado.
Não é orientação jurídica sobre admissibilidade de prova. Descreve o que cada instrumento técnico sustenta; o que um juízo ou uma assembleia aceita é outra discussão.
Fontes
- NIST. FIPS PUB 180-4 — Secure Hash Standard (SHS), agosto de 2015. nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf Origem da definição de que os resumos servem para detectar se as mensagens mudaram desde que foram gerados, das duas propriedades de inviabilidade computacional e da afirmação de que qualquer alteração produz, com altíssima probabilidade, um resumo diferente. Consultado em 4 de setembro de 2026.
- Adams, C.; Cain, P.; Pinkas, D.; Zuccherato, R. RFC 3161 — Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). IETF, agosto de 2001. rfc-editor.org/rfc/rfc3161.txt Origem da descrição da autoridade de carimbo de tempo como terceira parte confiável que fornece prova de existência de um dado num instante, do requisito de usar fonte de tempo confiável, da regra de carimbar apenas uma representação em hash e da obrigação de não examinar o valor carimbado. Consultado em 4 de setembro de 2026.
Trabalhamos sobre as câmeras que já existem e produzimos registro assinado em SHA-256, com conferência pública que não passa por nós. Preferimos um sistema que qualquer pessoa pode auditar a um sistema que só funciona enquanto acreditarem na nossa palavra.