Algorithme de numéro de série (clé d'enregistrement) dans .NET [fermé]

Question

Il y a eu quelques articles d'actualité sur la sécurité IP, etc., mais aucun que je puisse trouver qui traite spécifiquement d'un algorithme. Dans l’un de mes projets en cours, nous avons décidé de choisir un système de clé d’enregistrement hors ligne.

J'imagine que la plupart de nos utilisateurs éventuels seront honnêtes. Je ne pense donc pas que nous ayons trop de quoi nous inquiéter. Par ailleurs, je préférerais que le cracker occasionnel n’y ait pas accès sans beaucoup de sueur et de larmes.

Alors, quelles sont les options pour générer (et vérifier) ??la clé? La clé matérielle est probablement hors service car le modèle d'installation doit être exécuté à partir d'un partage Samba sur un serveur intranet. Aussi, combien de temps la clé devrait-elle être?

Deuxièmement, quel est le danger que l’algorithme de vérification soit simplement réfléchi, même s’il est obscurci? Serait-il préférable d'écrire l'algorithme en code non géré à la place?

Answer 1

À mon avis, le principal problème que vous rencontrerez n’est pas votre algorithme d’enregistrement et votre niveau (ou votre manque) d’obscurcissement.

Il s’agit plutôt de ceci: à un moment donné dans votre code, il s’agit d’une simple décision binaire: exécuter ou quitter. Pirater votre système nécessite seulement de trouver et d'ajuster ce point de décision.

Tout le reste - obscurcissement, signature forte, détection de sabotage - est conçu pour rendre la tâche plus difficile, mais cela ne peut pas rendre plus difficile .

Answer 2

Généralement, vous souhaitez sélectionner certaines données que vous souhaitez inclure dans la clé, telles que son propriétaire et son délai de validité, éventuellement même de petits morceaux de code dont votre application a besoin pour fonctionner correctement (ce qui rend difficile la création ça marche sans la clé). Utilisez ensuite un schéma de signature numérique tel que RSA pour signer numériquement la clé avec la clé privée de votre entreprise. Distribuez la clé publique avec l'exécutable de l'application. Ensuite, lorsque vous chargez la clé, vérifiez que la signature est valide, puis utilisez les données contenues dans la clé. Une clé de 1024 ou 2048 bits devrait suffire.

Bien sûr, quel que soit le niveau de sophistication de votre code, quelqu'un sera toujours capable de le casser ou de le contourner. Donc, la question que vous devez vous poser est la suivante: à quel point voulez-vous le rendre difficile (sachant que les schémas plus difficiles sont plus difficiles à coder et à maintenir pour vous)? Il y a un point de rendement décroissant, généralement assez faible. Tant que le programme ne fonctionnera pas sans clé et que la clé est suffisamment compliquée pour que vous ne puissiez pas en simuler (ou modifier la date d'expiration, etc.) avec un éditeur hexadécimal, vous êtes probablement satisfait.

Answer 3

Pour ce qui est de refactoriser la clé, l'écrire en mode non géré peut ne pas être utile s'il supprime le site d'appel géré de géré en non géré. Une option que vous avez avec l'obscurcissement si vous utilisez Dotfuscator Professional consiste à activer leur "Détection de sabotage". essentiellement, ils taguent votre assemblage et si quelqu'un modifie, vous pouvez demander à votre code de faire diverses choses. Bien sûr, le pirate informatique peut le supprimer, mais sa sueur et ses larmes sont bien plus nombreuses.

Answer 4

Je n'ai trouvé qu'un moyen de verrouiller le code très bien. Presque toutes les formes de validation en série peuvent être facilement analysées par votre programmeur moyen de deuxième année.

Pour ce faire, j'ai utilisé un objet License dans .NET. Dans mon objet de licence développé localement, il lit une "licence". fichier pour savoir où " home " est. Cette licence est une chaîne cryptée. La clé privée de la chaîne se trouve dans l'objet Licence.

L'objet Licence appelle ensuite la maison avec un mot de passe secret, également crypté. Le serveur décrypte le mot de passe et le valide ... en enregistrant également l'adresse IP et le nom d'utilisateur en cas d'enquête de fraude. Si le serveur peut valider le mot de passe, il répond par une réponse secrète, chiffrée à nouveau afin d'éviter toute usurpation d'identité. S'il ne peut pas être validé, la connexion est interrompue. Aucune réponse n’est envoyée. L’objet Licence situé à l’autre extrémité échoue.

Lorsque l'objet de licence intégré échoue, il lève automatiquement une exception, ce qui oblige l'application à échouer et se termine au moment où la licence est appelée.

Il m'a fallu environ deux jours de travail pour écrire le serveur et l'objet License. Il s'agit donc d'un peu d'entraînement, mais pas d'une science fulgurante.

Si vous souhaitez des exemples de source ou plus d’informations, faites-le moi savoir. Je serai heureux de vous obtenir ce que je peux.

Answer 5

Vous pouvez consulter les réponses à cette question