Comment puis-je savoir si un fichier a été modifié dans .NET C#?

Question

J'ai une application qui nécessite un moyen sécurisé pour stocker sa configuration. Il y a des utilisateurs qui peuvent changer la configuration. J'ai besoin d'une sorte de schéma de signature où je peux vérifier que le fichier de configuration n'a pas changé avec un utilisateur valide. J'avais pensé à utiliser RSA, où la clé privée est cryptée avec le mot de passe des utilisateurs, et la clé publique est utilisée pour signer la configuration. Cependant, rien n'empêche quelqu'un de changer le fichier utilisateur et d'ajouter sa propre clé publique, contournant ainsi ma sécurité. Des idées?

Answer 1

Vous pouvez simplement garder le fichier crypté, et ne permettre que la modification à partir de votre application. Cela empêcherait les utilisateurs d'éditer la configuration à partir de n'importe quel outil autre que le vôtre, qui pourrait faire l'authentification pour vérifier que l'utilisateur est un "utilisateur valide".

Answer 2

Il n'existe aucun moyen de sécuriser entièrement une application client autonome. Le seul moyen serait de faire une somme de contrôle sur le fichier et de le valider sur un/le serveur. La méthode de signature du fichier est moins importante que la façon dont vous vérifiez ce qui est effectivement signé.

Un début de la sécurisation de l'application client est avec Obfuscation. Par la suite, votre cryptage est le suivant. Pour la signature réelle, même une série de hash SHA devrait faire le travail pour vous. Un exemple en utilisant SHA512 est la suivante:

FileStream fs = new FileStream(@"<Path>", FileMode.Open); 

using (SHA512Managed sha512 = new SHA512Managed()) 
{ 
    byte[] hash = sha512.ComputeHash(fs); 

    string formatted = string.Empty; 

    foreach (byte b in hash) 
    { 
     formatted += b.ToString("X2"); 
    } 
} 

Answer 3

Ces contredit:

• « Je peux vérifier que le fichier de configuration n'a pas changé avec un utilisateur valide »
• « il n'y a rien pour empêcher quelqu'un de changer le fichier utilisateur "

Vous devriez juste trouver un moyen de protéger votre" fichier utilisateur "en premier. En le chiffrant avec une clé personne ne peut éditer (sauf les crackers déterminés) ou autrement. Et puis votre système RSA fonctionnera.

Notez cependant qu'il existe NO pour protéger une application qui s'exécute entièrement sur le client à partir d'un pirate déterminé.

Pour la plupart des applications, cependant, vous NE DOIT PAS besoin d'une sécurité parfaite. Peut-être que vous devriez penser à combien de sécurité est réellement "assez" pour votre application d'abord.

---

Si vous, cependant, besoin de sécurité parfaite, alors vous pourriez avoir besoin d'ajouter un composant côté serveur OU add-intervention humaine dans le processus, comme ayant un administrateur contrôle le fichier utilisateur.

Crypte le "fichier utilisateur" avec les mots de passe de l'administrateur. Et puis chaque fois que quelqu'un veut changer le fichier utilisateur, le consentement de l'administrateur est alors nécessaire.

Answer 4

Je pense que je vais garder une clé privée (A) au bureau. Je vais expédier l'application avec une paire privée publique (B), signée avec le privé (A) que je connais. J'utiliserai la paire privée publique (B) que j'expédie pour signer tout sur les fichiers de configuration. Ainsi, il y aura un ensemble vérifiable de clés RSA (B), qui ne peut pas être modifié, car la clé privée (A) utilisée pour les vérifier est dans le bureau, et la clé publique (A) est codée en dur.

Answer 5

Parmi toutes les méthodes répertoriées, la gestion des clés est la véritable faiblesse d'une machine client. La clé est nécessaire pour déchiffrer. L'utilisation d'une autre clé pour chiffrer cette clé n'est pas plus forte. L'obscurcissement est un début.

Ce que j'utilise est un assembly séparé qui contient notre code de chiffrement. La clé est ensuite stockée via une technique appelée Steganography. Je code la clé dans le logo de l'application. Cette clé est ensuite cryptée en utilisant une valeur connue du logiciel. Dans un cas, il peut s'agir de la somme de contrôle d'un assemblage spécifique. Ainsi, toute personne qui apporte des modifications à ce fichier va casser le système. Ce n'est en aucun cas plus sûr, mais il s'agit de cacher des détails. et élever le niveau de difficulté de décontracté à déterminé. De là, je lance ensuite l'assemblage à travers un obfuscator et un chiffreur de chaînes. Cela casse Reflector avec un plantage lorsque vous essayez de voir l'assemblage et rend ainsi plus difficile d'apprendre ce qui se passe. Le problème avec ces stratégies, est que si vous attachez un débogueur, vous obtenez les données en clair, car vous pouvez stocker les valeurs dans une chaîne après le processus de chiffrement/déchiffrement. Pour lutter contre cela, mais pas éliminer, j'utilise la classe System.Security.SecureString et ne conserve pas les données en clair. Le but est de casser le réflecteur, d'arrêter les attaques simples d'utiliser simplement le .NET Framework pour décrypter les données, d'arrêter les attaques de dictionnaire en employant un sel aléatoire, de gérer facilement les chaînes par URLEncodant le tampon crypté, d'utiliser correctement une initialisation Vecteur.