Introduction

Dans les enquêtes numériques, dès qu’un fichier quitte son support de stockage d’origine, il devient susceptible d’une altération non intentionnelle. Même une conversion apparemment anodine — changer une image disque de E01 à RAW, compresser un fichier journal ou rendre un PDF pour une présentation en salle d’audience — peut corrompre les hachages, supprimer les horodatages ou effacer des attributs cachés qui deviendront plus tard cruciaux pour le témoignage d’un expert. Cet article parcourt l’ensemble du cycle de vie de la conversion, de la préparation des preuves à la vérification du résultat final, en insistant sur la reproductibilité, l’auditabilité et la solidité juridique. Les principes décrits s’appliquent que vous travailliez sur une violation d’entreprise, une saisie policière ou un audit interne, et supposent l’utilisation d’outils fiables et respectueux de la vie privée, tels que le service cloud proposé sur convertise.app le cas échéant.

1. Établir un environnement de conversion contrôlé

Avant que le premier octet ne soit touché, les auditeurs doivent verrouiller l’environnement dans lequel la conversion aura lieu. Cela commence par une station de travail bloquée en écriture ou une station de travail légale démarrée à partir d’une image légale connue (par exemple, une clé USB « write‑once » protégée par BitLocker). Tous les logiciels utilisés pour la conversion doivent être inventoriés, signés numériquement et versionnés. Il faut privilégier les outils open‑source dont les hachages binaires peuvent être vérifiés, les binaires propriétaires présentant une surface d’attaque non documentée. Une fois la station isolée, un répertoire de travail dédié et chiffré doit être créé ; son chemin et ses permissions sont consignés dans le journal de l’affaire, et le répertoire lui‑même est stocké sur un support « write‑once » dès que possible. Ces étapes créent une base reproductible, facilitant la démonstration que le processus de conversion n’a pas introduit de variables étrangères.

2. Capturer les hachages de référence et les métadonnées

La pierre angulaire de l’intégrité forensique est la valeur de hachage (MD5, SHA‑1, SHA‑256 ou, de préférence, SHA‑512) calculée sur la preuve originale AVANT toute conversion. Le calcul du hachage doit être effectué avec un outil conforme aux normes NIST SP 800‑90, et la valeur obtenue doit être enregistrée avec les métadonnées d’origine du fichier : horodatages de création, de modification et d’accès ; attributs du système de fichiers ; et, pour les images disque, les détails au niveau secteur tels que les tables de partitions et les signatures du système de fichiers. Il est recommandé de capturer le hachage avec au moins deux utilitaires de hachage indépendants, en documentant toute divergence comme preuve potentielle de manipulation. Le hachage consigné devient le point de référence pour chaque étape de vérification ultérieure.

3. Choisir le format cible approprié

Toutes les conversions ne se valent pas. La décision de convertir doit être guidée par l’objectif de l’enquête : conservation, analyse ou présentation. Pour la conservation, un format sans perte, secteur par secteur, tel que RAW (dd) ou E01 est privilégié ; ils conservent la séquence exacte des octets du support source. Lorsque les outils d’analyse n’acceptent qu’un conteneur spécifique (par exemple, une suite légale qui lit l’AFF), la conversion vers ce format est justifiée, mais il faut toujours conserver une copie intacte de l’original. Pour la présentation, un fichier PDF‑/A ou TIFF peut être approprié, à condition que la chaîne de conversion intègre un checksum de la source dans les métadonnées du fichier de sortie, créant ainsi un lien vérifiable entre les deux. Choisir un format qui supporte nativement les métadonnées (par exemple, AFF) peut simplifier cette liaison.

4. Effectuer la conversion avec traçabilité

Les utilitaires de conversion modernes exposent souvent un journal verbeux qui consigne chaque opération, y compris les chemins source et destination, les horodatages et les transformations appliquées (niveau de compression, rééchantillonnage d’image, etc.). Lors de l’utilisation d’un outil en ligne de commande, le drapeau --log doit être activé et le fichier journal sauvegardé à côté de l’artéfact converti. Si la conversion s’effectue via un service cloud, le service doit fournir un enregistrement d’audit immuable (requête API horodatée, hachage source, format de destination). Quelle que soit la méthode, l’auditeur doit capturer un second hachage sur le fichier converti immédiatement après la fin du processus. Ce second hachage, combiné avec le hachage original, forme une paire de hachages qui pourra être présentée ultérieurement à un expert ou à un juge.

5. Vérifier l’intégrité après conversion

La vérification dépasse la simple comparaison de hachages. Pour les formats sans perte, une comparaison octet à octet (par exemple, cmp sous Unix) est possible et doit être réalisée lorsque le format cible le permet. Pour les formats avec perte ou transformés, la vérification doit se concentrer sur la préservation de la valeur probante : s’assurer que les horodatages, les EXIF incorporés ou les flux de données alternatifs NTFS, ainsi que tout attribut de fichier caché, ont survécu à la conversion. Des outils comme exiftool ou fsstat peuvent extraire et comparer ces attributs avant et après conversion. Toute déviation doit être documentée, expliquée et, dans la mesure du possible, atténuée (par exemple en intégrant le hachage original dans les métadonnées du nouveau fichier à l’aide d’une balise XMP personnalisée).

6. Documenter la chaîne de possession tout au long du processus

Un journal de chaîne de possession est un enregistrement chronologique de chaque personne ayant manipulé la preuve, de chaque opération réalisée et de chaque lieu où la preuve a résidé. L’étape de conversion ajoute un nouveau nœud à cette chaîne. L’entrée de journal pour la conversion doit inclure :

• Date, heure et décalage UTC de la conversion.
• Nom de l’analyste et identifiant de la station de travail.
• Ligne de commande exacte ou requête API utilisée.
• Hachage du fichier source avant conversion.
• Hachage du fichier résultant après conversion.
• Motif de la conversion (conservation, analyse ou présentation).
• Paramètres de compression ou de qualité appliqués.

Intégrer ces informations directement dans le fichier converti — dans un bloc de métadonnées dédié — crée un artefact autodécrivant qui pourra être inspecté même si le journal externe venait à être perdu.

7. Gérer de gros volumes et les conversions par lots

Les enquêtes impliquent souvent des centaines de gigaoctets de preuves. Les scripts de conversion par lots doivent être déterministes et reproductibles. Un schéma courant consiste à générer un fichier manifeste (CSV ou JSON) répertoriant chaque fichier source, son hachage de référence et le format cible souhaité. Le script lit le manifeste, traite chaque entrée, écrit le fichier converti dans un répertoire de sortie contrôlé, puis ajoute une nouvelle ligne à un journal de résultats contenant les deux hachages, le code de sortie et les éventuels avertissements. Utiliser un manifeste sous contrôle de version garantit que la même conversion peut être relancée à la demande du tribunal, et permet aux auditeurs de vérifier qu’aucun fichier n’a été omis ou traité deux fois.

8. Traiter les preuves chiffrées ou protégées

Les conteneurs chiffrés — volumes TrueCrypt, disques protégés BitLocker ou PDF protégés par mot de passe — posent un défi particulier. La démarche légale consiste à acquérir le conteneur chiffré sous sa forme brute et à documenter les paramètres de chiffrement (algorithme, longueur de clé, sel) sans tenter de le déchiffrer sur la machine d’acquisition. Si le déchiffrement est requis pour l’analyse, il doit être effectué sur un système isolé, air‑gappé, après que la clé de déchiffrement a été correctement documentée et authentifiée. Une fois déchiffré, le fichier en clair peut être converti, mais les deux versions — l’original chiffré et la copie déchiffrée — doivent être conservées, chacune avec son propre hachage, afin de préserver la traçabilité probante.

9. Considérations juridiques et recevabilité

Les tribunaux examinent toute transformation de preuves numériques. Pour répondre aux exigences de recevabilité (Daubert, Frye, etc.), le processus de conversion doit être :

1. Scientifiquement solide : basé sur des outils et des méthodes largement acceptés.
2. Transparent : toutes les étapes sont entièrement documentées et reproductibles.
3. Validé : la sortie de l’outil a été benchmarkée sur des échantillons de référence sains.
4. Indépendant : idéalement vérifié par un second analyste ou une revue par les pairs externe.

Lorsque la conversion est réalisée via un service cloud tiers, l’enquêteur doit obtenir un Service Level Agreement (SLA) incluant des clauses de gestion des données, et conserver tout document de certification (ISO 27001, SOC 2) attestant de l’engagement du prestataire en matière de confidentialité et d’intégrité.

10. Stockage d’archives des preuves converties

Après conversion, l’artefact doit être stocké dans un dépôt de preuves appliquant des politiques WORM (Write‑Once, Read‑Many). Le dépôt doit conserver la paire de hachages pour chaque fichier, et le support de stockage doit être vérifié périodiquement au moyen d’un contrôle de fixité (re‑hachage) afin de détecter la détérioration des bits. Si le dépôt supporte le versionnage, le fichier original et chaque conversion dérivée doivent être considérés comme des versions séparées, chacune avec son propre enregistrement de métadonnées immuable. Cette pratique assure que les examinateurs futurs puissent retracer la lignée d’un artefact depuis son acquisition brute jusqu’à chaque transformation ultérieure.

11. Résumé de la checklist des bonnes pratiques

• Isoler la station de travail de conversion et utiliser le blocage en écriture lorsque cela est possible.
• Enregistrer les hachages de référence et l’ensemble des métadonnées avant toute transformation.
• Sélectionner un format cible conforme à l’objectif de l’enquête et conservant les attributs critiques.
• Activer la journalisation verbeuse ou les traces d’audit pour chaque commande de conversion ou appel d’API.
• Calculer un hachage post‑conversion et le comparer selon un plan de vérification préétabli.
• Documenter minutieusement l’étape de conversion dans le journal de chaîne de possession, en intégrant les informations clés dans le fichier lui‑même.
• Utiliser des manifestes déterministes pour le traitement par lots et les conserver sous contrôle de version.
• Traiter les conteneurs chiffrés comme des preuves séparées ; ne déchiffrer que lorsqu’il est absolument nécessaire et conserver les deux copies.
• Valider la sortie de l’outil de conversion à l’aide de jeux de données de référence et obtenir une vérification par un pair.
• Stocker les artefacts convertis dans un dépôt conforme WORM avec des contrôles de fixité réguliers.

En suivant ces étapes, une conversion de fichier ordinaire devient une opération forensiquement fiable, préservant le poids probant des artefacts numériques depuis le moment de la saisie jusqu’à leur présentation en justice.