Evidencia de video que se sostiene: integridad y sello
Respuesta corta
Un hash criptográfico prueba una sola cosa: que estos bytes son los mismos de cuando se calculó el hash. La norma que define el SHA-256, la FIPS 180-4 del NIST, dice exactamente eso: los resúmenes sirven para detectar si los mensajes cambiaron desde que los resúmenes fueron generados, y cualquier alteración del mensaje produce, con altísima probabilidad, un resumen distinto.
Lo que el hash no prueba: que la escena ocurrió como se alega, que la hora declarada es verdadera, ni que el archivo no fue cambiado antes del cálculo. Cada una de esas tres lagunas exige un instrumento distinto: sello dentro de los píxeles medidos, referencia de tiempo externa y verificación que cualquier tercero pueda rehacer por su cuenta.
En este texto
¿Qué prueba realmente un hash criptográfico?
Un hash transforma un archivo de cualquier tamaño en un valor de tamaño fijo. En SHA-256 ese valor tiene 256 bits, escritos en general como 64 caracteres hexadecimales.
La FIPS 180-4, publicada por el NIST en agosto de 2015, declara los algoritmos seguros porque es computacionalmente inviable encontrar un mensaje que corresponda a un resumen dado y encontrar dos mensajes distintos que produzcan el mismo resumen. Es la segunda propiedad la que sostiene el uso probatorio: nadie consigue fabricar un segundo archivo, con otro contenido, que presente el mismo código.
En la práctica forense eso se convierte en una afirmación estrecha y fuerte: este archivo es bit a bit el mismo que existía cuando se calculó el código. Recortar, aclarar, recomprimir o guardar de nuevo en otro programa rompe la correspondencia.
Lo que el hash no prueba
La confusión más cara en una discusión de prueba digital es tratar la integridad como autenticidad. Son cosas distintas, y el hash resuelve solo la primera.
| Afirmación | ¿El hash la sostiene? | Qué la sostendría |
|---|---|---|
| El archivo no fue alterado después del cálculo | Sí | El propio hash, recalculado por quien duda. |
| El archivo ya existía antes de cierta fecha | No | Sello de tiempo emitido por un tercero sobre el hash. |
| La hora impresa en la imagen es la hora real | No | Reloj sincronizado con fuente externa, más el sello de un tercero. |
| La escena retrata lo que se alega | No | Contexto, testimonio, coherencia con otros registros, peritaje. |
| Nada fue cambiado antes del cálculo del hash | No | Cadena de custodia y cálculo lo más cerca posible del origen. |
| Quien generó el archivo es quien dice ser | No | Firma digital con clave asociada a una identidad. |
La última fila merece una nota. Un hash no es una firma: el hash es público y cualquiera lo calcula; una firma implica clave privada y ata el resultado a un titular. Un sistema puede tener integridad perfecta y ninguna autoría demostrable, lo cual es aceptable siempre que se diga con claridad.
Por qué el sello visual tiene que estar dentro de los píxeles que el hash cubre
Toda evidencia de video lleva información sobre sí misma: fecha, hora, identificación de la cámara, lugar y, en nuestro caso, la velocidad medida. Lo que decide si esa información vale algo es dónde vive.
Si vive fuera de lo que fue medido —metadato editable, nombre del archivo, planilla al lado—, es posible cambiar la fecha sin romper el hash: el código sigue coincidiendo y la afirmación temporal sigue sin sustento. Si está dibujada dentro de los propios píxeles, alterarla cambia la imagen, cambia el hash y el conflicto aparece al instante.
Es un principio general, no un truco de implementación: lo que el hash no cubre, el hash no protege. Vale para el sello de fecha, la identificación de la cámara y cualquier anotación que alguien pretenda usar como afirmación de hecho.
¿Quién garantiza la hora?
Nadie, si la única fuente es el reloj de quien produjo el archivo. El reloj de una grabadora de CCTV se atrasa, se reconfigura, pierde la batería y vuelve a una fecha de fábrica. Y está controlado por una de las partes de la discusión.
La solución estándar de internet es la autoridad de sellado de tiempo de la RFC 3161: una tercera parte confiable que provee prueba de existencia de un dato en un instante en el tiempo, obligada a usar una fuente de tiempo confiable. Dos detalles de la misma norma dicen dónde eso se detiene: la autoridad sella apenas una representación en hash del dato, nunca el dato; y está obligada a no examinar aquello que sella, más allá de comprobar la longitud del valor.
Es decir: el testigo externo da fe del instante y declara desinterés total por el contenido. Es una virtud, porque preserva la confidencialidad, y es un límite, porque ningún sello de tiempo dice que la imagen es verdadera. Dice que es antigua.
Cada registro que produce OpenRadar sale con una firma SHA-256 que cualquier persona puede recalcular sin hablar con nosotros. La página de verificación es pública, corre entera en el navegador de quien comprueba y no envía la imagen a ningún servidor, incluso cuando el resultado es que el archivo no coincide.
¿En qué momento debe calcularse el hash?
Lo más cerca posible del origen. Todo intervalo entre el instante en que se formó la imagen y el instante en que se calculó el resumen es un período que el hash no cubre, y es en ese período donde un cambio de archivo pasaría desapercibido.
La consecuencia de arquitectura es directa: calcular el resumen en el servidor central, después de que el archivo atraviese la red, la grabadora y el sistema de gestión, protege mucho menos que calcularlo en el borde. El algoritmo es el mismo, pero la afirmación se encoge: de “nada cambió desde el registro” a “nada cambió desde la llegada al servidor”.
Por eso la integridad no sustituye la cadena de custodia. Documenta con precisión matemática un tramo de la vida del archivo; quién responde por cada tramo anterior sigue siendo cuestión de organización, contrato y registro de acceso.
La verificación independiente es lo que da fuerza en una disputa
Un sistema de evidencia tiene dos arquitecturas posibles. En la primera, el proveedor guarda la verdad y emite informes: quien duda le cree o contrata un peritaje. En la segunda, publica lo suficiente para que cualquier persona rehaga la comprobación con herramientas comunes, y la respuesta no depende de que nadie actúe de buena fe.
La diferencia aparece en el momento en que el sistema es atacado. En una asamblea o en una audiencia, la pregunta no es si el proveedor es serio: es si el otro lado puede comprobar por su cuenta. La verificación independiente cambia confianza por aritmética, y la aritmética no tiene bando.
De ahí salen tres exigencias de proyecto, todas verificables por quien contrata.
- Algoritmo público y estandarizado.
- Valor de referencia publicado junto con la evidencia o en un canal separado.
- Comprobación que funcione con herramientas ya existentes en la computadora de cualquier persona.
¿Cómo compruebas tú mismo la integridad de un archivo?
Si recibiste un archivo y el valor SHA-256 correspondiente, la comprobación lleva menos de un minuto y no exige instalar nada.
- Descarga el archivo original, sin abrirlo y guardarlo de nuevo. Reenviarlo por una aplicación que recomprime imágenes ya invalida la comprobación: no es un defecto del método, es el método funcionando.
-
Calcula el resumen. En macOS o en Linux:
shasum -a 256 archivo.jpg. En Windows, en el Símbolo del sistema:certutil -hashfile archivo.jpg SHA256. - Compara con el valor declarado. Son 64 caracteres: compáralos todos, no solo el principio y el final.
- Registra lo que hiciste. Fecha de la comprobación, comando usado y valor obtenido. Es lo que vuelve tu chequeo citable por otra persona.
Para las evidencias de OpenRadar existe el camino corto: la página verificar una evidencia recalcula la firma de la foto dentro de tu propio navegador, sin enviar la imagen a ningún servidor. Y vale la advertencia: un resultado positivo dice que el archivo está íntegro, no que el registro esté correcto. La integridad es el piso de la discusión, no el techo, y por eso necesita venir acompañada de un método declarado, como en medir velocidad por video.
No afirma que un hash pruebe cuándo se hizo la imagen, ni que ella retrate la realidad. Prueba apenas que el archivo no cambió desde el cálculo.
No afirma que un sello de tiempo de un tercero valide el contenido. La RFC 3161 obliga a la autoridad a no examinar lo que está sellando, que es exactamente lo contrario de dar fe de la veracidad.
No describe el formato interno del marcador de OpenRadar, el diseño del sello ni cómo viaja la firma junto al archivo. Todo lo que hay aquí vale para cualquier sistema que use un hash estandarizado.
No es orientación jurídica sobre la admisibilidad de la prueba. Describe lo que sostiene cada instrumento técnico; lo que un juzgado o una asamblea acepta es otra discusión.
Fuentes
- NIST. FIPS PUB 180-4 — Secure Hash Standard (SHS), agosto de 2015. nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf Origen de la definición de que los resúmenes sirven para detectar si los mensajes cambiaron desde que fueron generados, de las dos propiedades de inviabilidad computacional y de la afirmación de que cualquier alteración produce, con altísima probabilidad, un resumen distinto. Consultado el 4 de septiembre 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 Origen de la descripción de la autoridad de sellado de tiempo como tercera parte confiable que provee prueba de existencia de un dato en un instante, del requisito de usar una fuente de tiempo confiable, de la regla de sellar apenas una representación en hash y de la obligación de no examinar el valor sellado. Consultado el 4 de septiembre de 2026.
Trabajamos sobre las cámaras que ya existen y producimos un registro firmado en SHA-256, con una comprobación pública que no pasa por nosotros. Preferimos un sistema que cualquier persona pueda auditar a un sistema que solo funciona mientras crean en nuestra palabra.