La solution par défaut serait d'utiliser des signatures cryptographiques. Demandez à chaque technicien de générer une paire de clés PGP, de publier la clé publique et de sécuriser la clé privée.

Lorsqu'un technicien effectue une analyse, il signe le fichier de résultat avec sa clé privée. Désormais, toute personne souhaitant vérifier le fichier peut vérifier la signature à l'aide de la clé publique du technicien. Lorsque quelqu'un modifie le fichier, la signature ne sera plus correcte.

Considérations de sécurité : si une clé privée d'un technicien est connue de quelqu'un d'autre, cette personne peut changer le fichiers et changez également la signature en une signature qui sera valide. Ce problème peut être atténué en demandant à plusieurs personnes de signer chaque fichier de résultats. Un attaquant aurait besoin de toutes clés pour remplacer toutes les signatures par des signatures valides.

Solution alternative low-tech: Imprimer chaque fichier de résultat, demandez au technicien de le signer à l'ancienne (avec un stylo) et déposez le fichier dans une archive physiquement sécurisée.

Au fait: Ne présumez pas que le format binaire spécifique au fournisseur offre plus de sécurité contre la falsification que XML. Ce n'est pas parce que vous ne pouvez pas le lire et le modifier lorsque vous l'ouvrez avec un éditeur de texte que personne d'autre ne peut procéder au reverse-engineering du format et créer un éditeur pour celui-ci.

Toute forme de signature numérique fera l'affaire. Voici quelques conseils:

• Pour les données XML, il existe un standard de signature numérique ( XMLSign). Malheureusement, cette norme est plutôt médiocre et présente une faille de sécurité importante (les documents doivent être normalisés via une transformation XML avant de pouvoir être signés. Ceci est extrêmement difficile à faire en toute sécurité car la transformation elle-même devient une partie importante de la signature).

• Vous pouvez également utiliser PGP ou S / MIME pour signer numériquement des documents, ceux-ci produiront de nouveaux, basés sur du texte et principalement des documents lisibles mais toujours infalsifiables.

• Enfin, vous pouvez utiliser des signatures détachées. En gros, c'est un autre fichier qui contient la signature numérique liée à un autre document et qui peut être utilisé pour valider les données d'origine (quel que soit le format d'origine).

Permettez-moi d'ajouter quelques infos supplémentaires ici:

• Le choix des bonnes propriétés pour la signature (algorithme, type et taille de clé, etc.) dépend fortement de la condition que vous définissez: combien de temps comptez-vous avoir les données sécurisées, contre quel type d'adversaire comptez-vous les protéger (quelle est la valeur d'un faux? quelle serait la valeur d'une attaque qui casserait tous les documents signés avec la même clé?), existe-t-il une exigence réglementaire? Cela signifie que vous devriez consulter un spécialiste qui peut traduire ces exigences commerciales et les traduire en exigences techniques.
• Je vous conseille vivement d'ajouter un horodatage sécurisé à votre signature. Cela vous permettra non seulement de prouver qu'un document n'a pas été falsifié, mais vous permettra également de prouver quand la signature a eu lieu.

Je vais décrire les trois options principales et les avantages / inconvénients de chacune.

Stockez les sauvegardes des fichiers dans un emplacement sécurisé

explicatif. L '«emplacement sécurisé» peut être un support en lecture seule (comme des CD), ou un lecteur réseau que tout le monde peut lire mais sur lequel seul le superviseur peut écrire, ou un service de stockage en ligne (par exemple Dropbox) qui rend raisonnablement difficile la falsification de fichiers dates de modification.

Avantages

• Vous devriez quand même avoir un système de sauvegarde

Inconvénients

• Si les fichiers sont volumineux, les télécharger pour vérification peut prendre du temps
• Si le faussaire s'introduit dans l'emplacement sécurisé, il peut couvrir ses traces

Stocker les hachages dans un emplacement sécurisé

Un hachage est une empreinte digitale d'un fichier qui ressemble à quelque chose comme 8f2e3f53aa90b27bda31dea3c6fc72f6 ; si deux fichiers sont légèrement différents, ils auront un hachage différent. Prenez un hachage du fichier d'origine et stockez-le en toute sécurité, puis pour vérifier qu'un fichier n'a pas été modifié, prenez-en un hachage et comparez-le au hachage stocké.

Avantages

• Vous devez stocker / vérifier en toute sécurité un code d'environ 32 chiffres au lieu d'un fichier entier

Inconvénients

• Vous devez toujours accéder à une ressource externe pour vérifier le fichier
• Si le faussaire s'introduit dans l'emplacement sécurisé, il peut couvrir ses traces

Signatures cryptographiques

Dans ce cas, une ou plusieurs personnes peuvent "signer" le fichier et si des modifications sont apportées, ces signatures seront invalides. Bien sûr, si tous ceux qui ont besoin de signer le fichier sont prêts à (ou trompés) signer un fichier falsifié, vous pouvez vous en sortir avec le fichier falsifié.

Avantages

• Les informations de sécurité peuvent être conservées dans le fichier lui-même , ou autrement sur le même lecteur, ce qui signifie une vérification plus facile.

Inconvénients

• Toute personne qui signe des fichiers doit être très attentive à empêcher quelqu'un de voler sa clé privée.
• Toute personne qui signe des fichiers doit faire très attention à savoir quoi ils signent.

Prenez votre fichier xml et votre photo de vacances préférée. Concaténez les fichiers et calculez plusieurs valeurs de hachage du fichier résultant.

L'image de vacances garantit qu'il est extrêmement difficile de produire une collision, même si le fichier de photo de vacances est public. De plus, si vous utilisez plusieurs algorithmes de hachage, il est peu probable que tous ceux-ci soient interrompus sous 10 ans.

Aborder la sécurité du format de fichier du fournisseur, en développant ce que @Philipp dit dans les commentaires.

J'ai eu une fouille autour d'un format de fichier de fournisseur (pas une spécification de masse mais assez proche à ces fins). Cela a été beaucoup plus facile grâce à l'installation du logiciel, mais je ne suis pas un expert en la matière. Je pourrais facilement changer les métadonnées (extraire les métadonnées était mon objectif en premier lieu) des données réelles auraient été plus difficiles mais en aucun cas impossibles à modifier. Étant donné que les métadonnées incluent des éléments tels que l'ID de l'échantillon et la date du test, il s'agit d'une vulnérabilité suffisamment importante pour des éléments tels que "dont l'échantillon a été nettoyé et quand? " comme vous semble pertinent, ou "qui a découvert pour la première fois ce médicament? " dans d'autres domaines.

Certains logiciels fournissent certaines fonctionnalités anti-falsification (par exemple, utilisation interne de hachages - pas nécessairement de qualité cryptographique -; autorisations utilisateur lors de l'édition en utilisant leur logiciel ). L'ingénierie inverse ne serait guère plus que triviale pour quelqu'un avec un peu de compétence décente dans la plupart des cas. Avec le logiciel installé, même contourner les fonctionnalités intégrées pourrait être aussi simple que d'écrire un frontal pour appeler les DLL du fournisseur, car ces fonctionnalités anti-sabotage sont normalement des modules complémentaires facultatifs (dans de nombreux domaines, ils ne sont pas obligatoires ou obsolètes. ).

(Cela aurait pu être une séquence de commentaires, mais comme mon objectif était de clarifier le problème du fichier fournisseur, il semblait préférable de l'écrire correctement).

Que diriez-vous de faire en sorte que les techniciens publient des paires d'identifiants de fichiers uniques et leurs hashs sur Twitter en utilisant leurs propres comptes?

Cela prouvera que:

• Fichier de données avec L'identifiant et le hachage existaient au moment de la publication
• La personne qui a accès au compte fait confiance au contenu du fichier à ce stade
• Le fichier n'est pas modifié après coup en tant que Twitter ne permet pas de modifier les tweets

Cette méthode offre au moins une sécurité comparable à de nombreuses réponses basées sur la signature numérique et des avantages tels que:

• Beaucoup plus simple à apprendre et à utiliser (pas de procédure compliquée de génération, d'ouverture ou de sauvegarde de clé privée)
• Haute redondance (via les sauvegardes de Twitter et les sites de scraping Twitter tiers)
• Horodatage intégré ( qui restera probablement dans une procédure judiciaire sans beaucoup d'explications)

Je recommande d'utiliser au moins SHA256 comme algo de hachage.

L'un des moyens les plus simples est de créer un hachage du fichier et de le stocker ailleurs afin de savoir s'il est modifié. Les programmes de détection d'intrusion utilisent cette technique en permanence pour vérifier l'intégrité (ou au moins indiquer si un attaquant a manipulé des fichiers système).

Regardez un programme tel que AIDE , vous pouvez l'exécuter sur le répertoire contenant les fichiers (et éventuellement l'exécuter à la demande lorsqu'un fichier est ajouté) pour mettre à jour sa base de données de hachages. Tous les soirs, exécutez-le pour vérifier et vous envoyer par e-mail un rapport indiquant toutes les modifications apportées aux fichiers.

Si vous avez besoin de connaître l'original, un système de fichiers versionné pourrait être une bonne idée. Chaque modification apportée à un fichier est enregistrée et les anciennes versions peuvent être extraites. Alternativement, un système de sauvegarde qui détecte les nouveaux fichiers et les sauvegarde dans un emplacement sécurisé peut être utilisé (et conserve toutes les anciennes versions - ou un attaquant pourrait simplement modifier le fichier à plusieurs reprises jusqu'à ce que l'original soit supprimé).

les formats ouverts sont très utiles pour donner accès aux données sur des échelles de temps d'archivage, mais la sécurité est un problème

Grande question: comment les archives sont-elles accessibles?

Le problème avec le hachage d'un fichier de texte brut est que le hachage est précis aux caractères. Changez un caractère et le hachage sera complètement différent. Fonctionne très bien pour les fichiers binaires comme les programmes exécutables (où un octet déplacé est généralement désastreux) mais échoue sur des choses comme les fichiers de balisage - la normalisation (ou le compactage) de l'espace blanc changera le hachage mais n'aura aucun effet sur les données.

Si vous transférez les fichiers par e-mail ou par partage réseau en lecture-écriture, vous devrez disposer d'un stockage sécurisé pour le hachage, ou toute personne ayant un demi-cerveau peut modifier le fichier puis mettre à jour le hachage. Si vous disposez d'un stockage sécurisé pour le hachage, pourquoi ne pas stocker le fichier de données au même endroit et oublier le hachage?

Cela va sembler étrange au début, mais regardez à télécharger le fichier et la description sur une installation locale de quelque chose comme wordpress ou mediawiki. L'accès peut être aussi ouvert ou sécurisé que vous le souhaitez, et les plates-formes disposent de contrôles de téléchargement de fichiers spécifiques à l'utilisateur. Une fois que le service informatique l'a correctement configuré, l'accès en écriture aux fichiers peut être verrouillé aussi étroitement que nécessaire.