Por qué un hash no vale nada sin cadena de custodia

Un disco duro con SHA-256 calculado no es una prueba. Es un dato. Se convierte en prueba cuando alguien puede responder, sin fisuras, quién lo tocó, cuándo, con qué herramienta y por qué el hash de hoy coincide con el de la incautación. Esa cadena — documentada, ininterrumpida, verificable por un tercero — es lo que separa una imagen de disco útil en juicio de un archivo que un abogado defensor tumba en cinco minutos.

El principio de fondo lo formuló Edmond Locard hace un siglo: no se interactúa con un entorno sin dejar rastro. En un sistema informático ese rastro son claves de registro, marcas de tiempo en el MFT, entradas de log, metadatos EXIF. El problema no es encontrarlo — es demostrar que el rastro que presentas en el informe es el mismo que existía antes de que tu propio proceso de análisis empezara a tocar el disco.

Qué sobrevive a un borrado (y qué no)

En NTFS, borrar un archivo no borra nada del contenido. Windows marca la entrada correspondiente en la Master File Table como libre y desasigna los clústeres que ocupaba. Los bytes siguen en el disco hasta que otro archivo los sobrescribe — que puede pasar en segundos o nunca. Esto es lo que hace viable herramientas como PhotoRec o Autopsy: no "recuperan" nada mágicamente, simplemente leen sectores que el sistema de archivos ya no reclama.

La Papelera de reciclaje complica un poco el rastreo. En Windows 7 en adelante, cada archivo eliminado genera un par: $I (metadatos — nombre original, tamaño, timestamp de borrado) y $R (el contenido, renombrado) dentro de \$Recycle.Bin\<SID>\ . Antes de XP era un único índice, INFO2 . Si el sospechoso vació la papelera, el par $I / $R desaparece de la vista normal, pero sus clústeres quedan exactamente igual de recuperables que los de cualquier otro borrado.

En Linux el mecanismo es más simple todavía: rm desvincula el inode del directorio y decrementa su contador de referencias. El bloque de datos no se toca. Con ext3 / ext4 sin journal de datos, herramientas como extundelete o debugfs pueden reconstruir buena parte del contenido mientras nadie haya escrito encima.

El borrado que sí borra — y su límite en SSD

Si el objetivo es que el dato no vuelva, hace falta sobrescritura. En Windows, sdelete (de Sysinternals) hace varias pasadas: 

          sdelete -p 3 -s -z C:\Users\usuario\Documentos\confidencial

En Linux, shred hace lo mismo por defecto con 3 pasadas (25 en versiones antiguas): 

          shred -vfz -n 3 /home/usuario/confidencial.pdf

Aquí está el matiz que suele faltar en los resúmenes de teoría: en un HDD magnético, sobrescribir el sector físico destruye el dato anterior. En un SSD, no hay esa garantía. El firmware hace wear leveling — reubica bloques físicos de forma transparente al sistema operativo — así que "sobrescribir el archivo lógico" puede dejar la copia física original intacta en otra celda NAND, marcada como inválida pero no borrada hasta que el controlador decida hacer garbage collection. Por eso en SSD el borrado seguro fiable depende del comando ATA Secure Erase o del cifrado completo del disco desde el primer uso (si todo está cifrado, borrar la clave basta).

Copiar sin tocar: adquisición bit a bit

Antes de examinar nada, se congela el estado. La regla es no montar el disco original en modo lectura-escritura bajo ningún concepto — se usa un bloqueador de escritura por hardware y se trabaja siempre sobre una copia. 

          dd if=/dev/sdb of=/mnt/evidencia/caso042.img bs=4M conv=noerror,sync
sha256sum /dev/sdb > caso042.sha256.origen
sha256sum caso042.img > caso042.sha256.copia

Si los dos hashes coinciden, tienes una copia forense verificable: la imagen es bit por bit idéntica al original y cualquier perito de la otra parte puede repetir el cálculo y comprobarlo. conv=noerror,sync importa más de lo que parece — sin eso, dd puede saltarse sectores dañados y dejar la imagen desalineada respecto al original, lo cual arruina el análisis de estructuras que dependen de offsets exactos (particiones, MFT, superbloques).

ISO/IEC 27037 formaliza este flujo a alto nivel — identificación, recolección, adquisición, preservación — sin mandar herramientas concretas. RFC 3227 baja un peldaño y da recomendaciones de orden de volatilidad: memoria RAM y caché antes que disco, disco antes que backups, porque cada minuto que pasa con el equipo encendido borra estado que no vuelve.

MD5 sigue apareciendo en informes, y es un problema

Es habitual ver MD5 y SHA-256 calculados juntos en un mismo informe pericial, uno por compatibilidad histórica con software antiguo (EnCase, FTK llevan años reportando ambos) y el otro como el hash que realmente sostiene la integridad. MD5 tiene colisiones prácticas conocidas desde 2004 — se pueden construir dos ficheros distintos con el mismo hash MD5 con recursos modestos. Eso no invalida su uso como checksum de verificación rápida entre dos copias que tú mismo generaste, pero sí lo descalifica como única prueba de integridad frente a un adversario que pudiera haber manipulado el archivo. SHA-256 es el mínimo defendible hoy; si el caso lo justifica, SHA-3 o un hash con salt para muestras de contraseñas.

Cuando el sospechoso también sabe usar shred

El otro lado de la moneda es la técnica anti-forense: cifrado de disco completo con BitLocker o LUKS, contenedores ocultos con VeraCrypt, esteganografía en imágenes o en cabeceras TCP/UDP para exfiltración silenciosa. Ninguna de estas técnicas es ilegal per se — BitLocker viene activado por defecto en muchos portátiles corporativos — pero cambian radicalmente qué es viable recuperar.

Contra el cifrado de disco, la ventana de oportunidad real está en la memoria volátil: si el equipo está encendido y desbloqueado, un volcado de RAM ( winpmem , LiME en Linux) puede contener la clave de cifrado en claro mientras el volumen está montado. Apagar el equipo antes de asegurar ese volcado es, en la práctica, perder la única vía de acceso a datos cifrados con una passphrase fuerte. Esto es exactamente lo que dice RFC 3227 sobre orden de volatilidad, aplicado a un caso real: la memoria no espera.

Para cracking de credenciales cuando hay hashes recuperables, John the Ripper detecta automáticamente el formato y Hashcat aprovecha GPU para ataques de diccionario con reglas o de máscara — pero contra un hash bcrypt o Argon2 bien configurado, fuerza bruta no es una estrategia realista en el marco temporal de una investigación.

Lo que decide si la evidencia entra en el juicio

Todo lo anterior — hash, cadena de custodia, orden de volatilidad — converge en un documento: el informe pericial. UNE 197001 exige una estructura concreta (identificación inequívoca del perito y el caso, declaración de imparcialidad, cuerpo del informe, anexos con CV del perito), pero el contenido que de verdad se ataca en sala son dos cosas: exhaustividad y fundamentación. Una omisión — un paso del análisis sin documentar, un hash que no coincide sin explicación — puede bastar para que un juez excluya la prueba entera, no solo la parte cuestionada.

La lección práctica es que el trabajo técnico y el trabajo documental pesan igual. Una imagen forense perfecta sin registro de quién la tocó vale lo mismo que ninguna.