Comment puis-je m'assurer que quelqu'un n'envoie pas de fausses données?

Question

Je lis Stack Overflow depuis un certain temps, mais c'est ma première question postée.

J'ai ce programme de suivi écrit en C# qui recueille des informations sur l'utilisation de l'ordinateur local et les envoie à un serveur. Les données sont au format XML, envoyées une fois par ~ 10 minutes. Mon problème: peu importe comment je crypte les données XML (symétriques ou asymétriques), quelqu'un peut toujours décompiler mon programme de suivi C#, déterminer les conventions clé/certificat/cryptage que j'utilise et écrire un autre programme qui envoie de faux rapports au serveur.

Le programme de suivi fonctionne sous l'hypothèse que l'utilisateur qui l'exécute peut être intéressé par l'envoi de faux rapports. 1) Comment puis-je m'assurer (aussi sûrement que possible) que les données sont envoyées par le vrai tracker au lieu d'un clone/faker? 2) comment est-ce que je peux assez obscurcir le code assez pour que la récupération de clés/certificats/conventions de chiffrement devienne un enfer/presque impossible?

Je veux passer peu ou, de préférence pas d'argent sur la solution (donc 500 $ obfuscators sont hors de question. Je suis un étudiant à l'université et je suis pas cher :)

Merci à l'avance.

Answer 1

1.Une autre approche: En supposant que vous ne changiez pas souvent votre exécutable. faites un DigSig de votre (HASH + Encrypt) votre image de fichier exécutable client et envoyez-le avec, cela authentifierait votre client en tant que vrai client et non une version modifiée. Mais cela ne peut empêcher l'envoi de données par un client totalement différent qui peut acquérir le Digsig de votre image exécutable.

Answer 2

En théorie, une application ne peut tout simplement pas se protéger lorsqu'elle s'exécute dans un environnement non approuvé. Donc, la réponse à la première question est: "Vous ne pouvez jamais être sûr que les données sont envoyées par le vrai tracker."

En pratique, l'obfuscation va contrecarrer les attaquants jusqu'à un certain point. Le point est déterminé par la qualité de l'obfuscation et la motivation de l'attaquant. Ainsi, la réponse à la deuxième question dépend de l'identité de l'attaquant, de sa capacité et des ressources qu'il peut appliquer à ce problème. Obfuscation qui est "enfer/next-to-impossible" pour un profane démotivé à démêler peut être triviale pour un expert, ou quelqu'un qui peut embaucher un expert.

Here is a list de certains obturateurs C#.

Answer 3

L'utilisateur client aura-t-il des droits d'administrateur sur la machine? Cela ressemble au type d'application qui serait installé par un administrateur, mais utilisé par des utilisateurs non-administrateurs. Si c'est le cas, vous pouvez peut-être stocker votre clé ou votre hachage à l'abri des utilisateurs normaux et exécuter l'application dans le contexte de l'utilisateur administrateur. Je ne connais pas vraiment le magasin de clés, mais je m'attendrais à ce que toutes les versions de Windows (au moins XP +) aient cette fonctionnalité disponible. Si ce n'est pas le magasin de clés, alors peut-être un fichier situé dans un répertoire crypté appartenant à l'utilisateur admin.

Si votre utilisateur cible a des droits d'administrateur local, alors je ne vois vraiment pas comment vous pouvez les arrêter.

Answer 4

Cela semble assez désespéré.Votre outil de suivi s'appuie probablement sur Windows pour fournir les métriques, par exemple en appelant finalement GetUserName()/GetTickCount()/CollectPerformanceData()/etc. Donc, un méchant doit juste piéger votre code (peu importe comment il est obscurci et sans se soucier de décompiler) à n'importe quel point d'entrée Windows, remplacer les données fausses, et laisser votre code continuer sur sa voie joyeuse.

La vie est trop courte pour vous battre la tête contre ces murs de briques.

Answer 5

Nous avons utilisé une solution matérielle pour fournir cette fonctionnalité requise.

J'ai travaillé avec un produit appelé IronKey, c'est un périphérique matériel capable de générer des signatures numériques. Lorsque nous émettons l'appareil, nous stockons la clé publique sur notre serveur. Lorsque notre application client soumet des données, nous générons une signature en utilisant la clé privée, une fois que nous recevons les données, nous pouvons vérifier qu'il a été envoyé à partir du bon client en utilisant la clé publique.

Answer 6

Comme Raph Koster once put it, écrit au sujet de la lutte contre les pirates dans les jeux en ligne client-serveur,

Ne faites jamais confiance au client. Ne mettez jamais rien sur le client. Le client est entre les mains de l'ennemi. N'oublie jamais jamais cela.

Malheureusement, pour à peu près toutes les applications du monde réel qui exige que la puissance de traitement du client est utilisé, quelque chose doit être mis sur le client, et donc parce que la disposition d'un attaquant malveillant. La question qui doit être posée - comme pour toute mesure de sécurité - est de savoir combien de temps et d'argent êtes-vous prêt à dépenser pour atténuer ce risque? Certaines personnes aiment attirer l'attention des gens qui se posent des questions sur l'obscurcissement ou les mécanismes d'octroi de licences côté client: «Oh, ça ne sert à rien, ça finira par être brisé». Mais c'est manquer le point: que le but de telles mesures est de repousser cette 'future' dans le futur, au point que pour un attaquant insuffisamment déterminé, ce sera 'jamais'. Par exemple: si votre application envoyait ses données par courrier électronique en clair, cela éliminerait environ zéro attaquant. L'envoyer dans l'email rot13 pourrait vaincre peut-être 5% des attaquants. L'envoyer crypté en utilisant le nom d'utilisateur comme une clé serait vaincre plus. Obfusciter le code d'envoi avec un obfuscator libre serait vaincre plus. Obfusciter avec un obfuscator de qualité commerciale serait plus vaincre. Obliger chaque client à avoir un dongle matériel permettrait de vaincre tous les attaquants, sauf les plus déterminés, comme les gens aiment le dire, mais ce serait probablement un coût insupportable. De «Je suis étudiant à l'université», je suppose que ce projet n'est pas le plus sensible de tous les temps. Utilisez un obfuscator gratuit et cryptez les données envoyées en utilisant certaines informations spécifiques à l'utilisateur comme clé. Ça va probablement faire.