Intégrité
Comment démontrer que le jeu de données que vous remettez est le même que celui qui vous revient des mois plus tard ?
Le chiffrement n’est pas l’intégrité
BitLocker protège contre la lecture par un tiers, pas contre la modification. Qui détient la clé peut modifier le contenu et refermer proprement le support. Il reste alors toujours un volume chiffré, mais avec d’autres données dedans.
N’écrivez donc jamais dans un rapport qu’un support est « protégé contre la manipulation » parce qu’il est chiffré. C’est une affirmation qui tombe à la première relecture critique, et elle n’est pas nécessaire : c’est à cela que sert une somme de contrôle.
Ce que fait une somme de contrôle
Une empreinte SHA-256 est une valeur fixe de 64 caractères hexadécimaux qui découle du contenu d’un fichier. Un seul message modifié, ajouté ou supprimé donne une autre valeur. Celle-ci ne correspond alors plus à la valeur de référence, et n’importe qui disposant du fichier et de la valeur peut le refaire. Vous n’avez pas à être présent et personne n’a à vous croire sur parole.
Ce qu’une somme de contrôle ne fait pas : elle ne dit rien de ce qui aurait dû s’y trouver. Un fichier qui disparaît discrètement ne laisse pas d’empreinte divergente derrière lui, puisqu’il n’y a plus rien à hacher. C’est pourquoi le support doit porter, à côté des empreintes, un inventaire.
La construction qui rend l’ensemble contraignant
Un CHECKSUMS_SHA256.txt posé sur le support ne prouve rien à lui seul. Qui peut modifier les fichiers peut modifier ce fichier texte avec, et tout redevient cohérent.
Les valeurs de référence doivent donc se trouver hors de portée de quiconque a accès au support. Reprenez-les dans le rapport que vous signez électroniquement. Chaque empreinte est ainsi rattachée à votre signature et à l’heure de celle-ci, et le contenu est fixé tel qu’il était au moment de la remise.
Ce qui figure sur chaque support
- les fichiers de données eux-mêmes ;
MANIFEST.txt, avec le contenu et la délimitation du jeu de données : ce qui s’y trouve, ce qui en est délibérément exclu, et pourquoi ;CHECKSUMS_SHA256.txt, avec une empreinte par fichier.
Reprenez également au rapport l’empreinte de MANIFEST.txt lui-même. Sans cela, la description du jeu de données est la seule partie qui puisse être retouchée après coup sans que rien n’y paraisse, et c’est justement la partie qui porte la délimitation.
Calculer
Un fichier, avec le PowerShell présent sur toute machine Windows :
Get-FileHash -Algorithm SHA256 -LiteralPath .\fichier.pst
Toute l’arborescence en une fois, écrite dans un CHECKSUMS_SHA256.txt situé un niveau au-dessus du répertoire de données :
Get-ChildItem -Recurse -File |
Get-FileHash -Algorithm SHA256 |
ForEach-Object { '{0} *{1}' -f $_.Hash, (Resolve-Path -LiteralPath $_.Path -Relative) } |
Set-Content -Encoding utf8 ..\CHECKSUMS_SHA256.txt
Pour qui préfère cliquer, il y a fHash : gratuit, libre, pour Windows et macOS, avec une entrée dans le menu contextuel de l’Explorateur. Il calcule MD5, SHA-1, SHA-256 et SHA-512. Mentionnez cet outil dans votre rapport, ou un équivalent. Une partie qui veut contrôler un seul fichier doit pouvoir le faire sans apprendre d’abord la ligne de commande.
Recalculer
Indiquez aussi comment le contrôle s’effectue. Exécuté depuis le répertoire de données :
$erreurs = 0
Get-Content ..\CHECKSUMS_SHA256.txt -Encoding utf8 | Where-Object { $_ } | ForEach-Object {
$attendu, $chemin = $_ -split ' \*', 2
if (-not (Test-Path -LiteralPath $chemin)) { $erreurs++; "MANQUANT : $chemin"; return }
if ((Get-FileHash -Algorithm SHA256 -LiteralPath $chemin).Hash -ne $attendu) { $erreurs++; "DIVERGENCE : $chemin" }
}
if ($erreurs -eq 0) { 'Tous les fichiers correspondent.' } else { "$erreurs divergence(s) trouvée(s)." }
Cela signale aussi bien les fichiers modifiés que les fichiers manquants. Ce que cela ne signale pas, c’est un fichier qui s’est ajouté et qui ne figure pas dans la liste. Pour cela, MANIFEST.txt reste nécessaire, ainsi que la constatation que le nombre de lignes de la liste de sommes de contrôle correspond au nombre de fichiers sur le support.
Pièges
Hachez à la réception, pas seulement à la livraison. Une empreinte qui ne naît qu’à la fin ne couvre que la fin. Calculer à la réception fixe l’état initial et fait apparaître chaque traitement ultérieur comme une étape assumée plutôt que comme un écart inexplicable.
Mettez -Encoding utf8 sur Set-Content. Windows PowerShell 5.1 écrit par défaut dans la page de codes ANSI du système. Un fichier dont le nom porte un accent ou un caractère cyrillique arrive alors corrompu dans la liste et devient introuvable par la suite. Dans un dossier contenant des pièces jointes de courriels, cela se produit dès la première pièce venue.
-Path saute silencieusement les fichiers dont le nom contient des crochets droits. Les noms venus des boîtes aux lettres en contiennent régulièrement. PowerShell lit les crochets comme des jokers, ne trouve rien, et ne signale rien. Utilisez partout -LiteralPath, sans quoi ce sont précisément les fichiers aux noms les plus difficiles qui échappent au contrôle.
N’écrivez pas la liste de sommes de contrôle dans le répertoire que vous êtes en train de hacher. Sinon le fichier se reprend lui-même à moitié écrit, ou manque de justesse. Écrivez un niveau au-dessus et déplacez-le ensuite.
Prévoyez un contrôle du débit du support. Le hachage en soi coûte peu : 2 Go depuis le cache de fichiers, c’est l’affaire de quelques secondes, de l’ordre de plusieurs dizaines de Go par minute. Dès que vous lisez depuis un disque externe ou un partage réseau, c’est cette liaison qui détermine la durée de l’attente. Vérifier un disque plein prend donc à peu près autant de temps que le lire.
Nettoyage après coup
Supprimez la copie de travail locale dès que les supports sont prêts et contrôlés, à plus forte raison lorsque le jugement détermine qui peut conserver les données. Notez au rapport que vous l’avez fait, et quand.
Le rapport signé avec les empreintes subsiste, lui, et il permet encore, des années plus tard, d’établir si le support posé sur la table porte le même contenu.