Comment générer et valider une clé de licence logicielle?
Je suis actuellement impliqué dans le développement d'un produit (développé en C #) qui pourra être téléchargé et installé gratuitement, mais dans une version très limitée. Pour avoir accès à toutes les fonctionnalités, l'utilisateur doit payer des droits de licence et recevoir une clé. Cette clé sera ensuite entrée dans l'application pour "déverrouiller" la version complète.
Comme utiliser une clé de licence comme celle-là est un peu habituel, je me demande:
- Comment cela est-il généralement résolu?
- Comment puis-je générer la clé et comment peut-elle être validée par l'application?
- Comment puis-je aussi éviter qu'une clé soit publiée sur Internet et utilisée par d'autres personnes qui n'ont pas payé la licence (clé qui n'est pas "la leur").
J'imagine que je devrais également relier la clé à la version de l'application afin qu'il soit possible de facturer de nouvelles clés dans les versions fonctionnelles.
Y a-t-il autre chose auquel je devrais penser dans ce scénario?
Mise en garde: vous ne pouvez pas empêcher les utilisateurs de pirater, mais vous permettez aux utilisateurs honnêtes de faciliter la tâche.
En supposant que vous ne souhaitiez pas créer de build spécial pour chaque utilisateur, alors:
- Générez vous-même une clé secrète pour le produit
- Prenez le nom de l'utilisateur
- Concatentez le nom des utilisateurs et la clé secrète et hachez-les avec (par exemple) SHA1
- Décompressez le hachage SHA1 sous forme de chaîne alphanumérique. Ceci est la "clé de produit" de l'utilisateur individuel
- Dans le programme, faites le même hachage et comparez-le avec la clé de produit. Si égal, d'accord.
Mais, je répète: cela n'empêchera pas le piratage
J'ai récemment lu que cette approche n'est pas très solide du point de vue cryptographique. Mais cette solution est déjà faible ( car le logiciel lui-même doit inclure la clé secrète quelque part ), je ne pense donc pas que cette découverte invalide la solution à fond.
Juste pensé que je devrais vraiment mentionner cela, cependant; si vous envisagez de tirer quelque chose d'autre, méfiez-vous.
Il existe de nombreuses manières de générer des clés de licence, mais très peu d'entre elles sont réellement sécurisées. Et c'est dommage, car pour les entreprises, les clés de licence ont presque la même valeur que de l'argent réel.
Idéalement, vous voudriez que vos clés de licence aient les propriétés suivantes:
Seule votre entreprise devrait être en mesure de générer des clés de licence pour vos produits, même si quelqu'un procède à une ingénierie inverse des ingénieurs (ce qui se passera, je parlerai d'expérience). Il est vraiment hors de question de masquer l’algorithme ou de cacher une clé de chiffrement dans votre logiciel si vous tenez vraiment à contrôler les licences. Si votre produit a du succès, quelqu'un créera un générateur de clé dans les jours qui suivront.
Une clé de licence ne devrait être utilisable que sur un seul ordinateur (ou au moins vous devriez pouvoir le contrôler très étroitement)
Une clé de licence doit être courte et facile à saisir ou à dicter au téléphone. Vous ne voulez pas que chaque client appelle le support technique parce qu'il ne comprend pas si la clé contient un "l" ou un "1". Votre service d’appui vous en remerciera et vos coûts seront moindres dans ce domaine.
Alors, comment résolvez-vous ces défis?
La réponse est simple mais techniquement difficile: les signatures numériques utilisant la cryptographie à clé publique. Vos clés de licence doivent en fait être des "documents" signés, contenant des données utiles, signés avec la clé privée de votre entreprise. Les signatures doivent faire partie de la clé de licence. Le produit doit valider les clés de licence avec la clé publique correspondante. De cette manière, même si quelqu'un a un accès complet à la logique de votre produit, il ne peut pas générer de clé de licence car il ne possède pas de clé privée. Une clé de licence ressemblerait à ceci: BASE32 (CONCAT (DATA, PRIVATE_KEY_ENCRYPTED (HASH (DATA))))) Le plus gros défi ici est que les algorithmes de clé publique classiques ont des tailles de signature importantes. RSA512 a une signature de 1024 bits. Vous ne voulez pas que vos clés de licence contiennent des centaines de caractères ... Une des approches les plus puissantes consiste à utiliser la cryptographie à courbe elliptique (avec des implémentations soigneuses pour éviter les brevets existants). Les clés ECC sont 6 fois plus courtes que les clés RSA, pour la même force. Vous pouvez réduire davantage la taille des signatures en utilisant des algorithmes tels que l'algorithme de signature numérique Schnorr (le brevet a expiré en 2008 - bien :))
Ceci est réalisable par l'activation du produit (Windows en est un bon exemple). Fondamentalement, pour un client avec une clé de licence valide, vous devez générer des "données d'activation" qui sont un message signé incorporant l'identifiant matériel de l'ordinateur en tant que données signées. Cela se fait généralement par Internet, mais seulement UNE FOIS: le produit envoie la clé de licence et l'identifiant matériel de l'ordinateur à un serveur d'activation, lequel renvoie le message signé (qui peut également être abrégé et facile à dicter via le téléphone). À partir de ce moment, le produit ne vérifie pas la clé de licence au démarrage, mais les données d'activation, qui exigent que l'ordinateur soit identique pour être validé (sinon, les DONNÉES seraient différentes et la signature numérique ne validerait pas). Notez que la vérification des données d'activation ne nécessite pas de vérification sur Internet: il suffit de vérifier la signature numérique des données d'activation avec la clé publique déjà intégrée au produit.
Eh bien, éliminez simplement les caractères redondants tels que "1", "l", "0", "o" de vos clés. Divisez la chaîne de clé de licence en groupes de caractères.
Réponse simple - Peu importe le schéma que vous utilisez, il peut être craqué.
Ne punissez pas les clients honnêtes avec un système destiné à empêcher les pirates, car les pirates le craqueront malgré tout.
Un simple code haché lié à leur email ou similaire est probablement suffisant. Les identifiants matériels deviennent toujours un problème lorsque des personnes doivent réinstaller ou mettre à jour du matériel.
Bonne discussion sur le problème: http://discuss.joelonsoftware.com/default.asp?biz.5.82298.34
Lors de la génération de la clé, n'oubliez pas de concaténer la version et le numéro de build avec la chaîne sur laquelle vous calculez le hachage. De cette façon, il n'y aura pas une seule clé qui déverrouille tout ce que vous avez déjà publié.
Une fois que vous avez trouvé des clés ou des correctifs flottant dans astalavista.box.sk , vous saurez que vous avez réussi à créer quelque chose de suffisamment populaire pour que quelqu'un se donne la peine de craquer. Réjouir!
Outre ce qui a déjà été dit ....
Toute utilisation d’applications .NET est intrinsèquement cassable en raison de problèmes de langage intermédiaire. Un simple démontage du code .NET ouvrira votre produit à quiconque. Ils peuvent facilement contourner votre code de licence à ce stade.
Vous ne pouvez même plus utiliser les valeurs matérielles pour créer une clé. Les machines virtuelles permettent désormais à quelqu'un de créer l'image d'une machine "sous licence" et de l'exécuter sur la plate-forme de son choix.
Si c'est un logiciel coûteux, il existe d'autres solutions. Si ce n'est pas le cas, rendez-le suffisamment difficile pour le pirate informatique occasionnel. Et acceptez le fait qu’il y aura éventuellement des copies sans licence.
Si votre produit est compliqué, les problèmes de support inhérents créeront une certaine protection pour vous.
Le moteur C #/.NET que nous utilisons pour la génération de clés de licence est maintenant maintenu en open source:
https://github.com/appsoftware/.NET-Licence-Key-Generator .
Il est basé sur un système de "vérification partielle de la clé", ce qui signifie qu'un seul sous-ensemble de la clé utilisée pour générer la clé doit être compilé dans votre distribution. Vous créez vous-même les clés, l'implémentation de la licence est donc unique pour votre logiciel.
Comme indiqué ci-dessus, si votre code peut être décompilé, il est relativement facile de contourner la plupart des systèmes de licence.
J'ai déjà utilisé Crypkey dans le passé. C'est l'un des nombreux disponibles.
Vous ne pouvez protéger les logiciels que jusqu'à un certain point avec n'importe quel système de licence.
Je ne sais pas à quel point vous voulez être élaboré
mais je crois que .net peut accéder au numéro de série du disque dur.
vous pourriez avoir le programme vous envoyer cela et quelque chose d'eles (comme le nom d'utilisateur et l'adresse mac du nic)
vous calculez un code basé sur cela et envoyez-leur la clé par courrier électronique.
ils les empêcheront de changer de machine après avoir eu la clé.
La seule façon de faire tout ce que vous avez demandé est de demander un accès Internet et une vérification avec un serveur. L'application doit se connecter au serveur avec la clé, puis vous devez stocker les détails de la session, tels que l'adresse IP. Cela empêchera l'utilisation de la clé sur plusieurs machines différentes. Cela n’est généralement pas très populaire auprès des utilisateurs de l’application, et à moins qu’il s’agisse d’une application très coûteuse et compliquée, cela n’en vaut pas la peine.
Vous pouvez simplement avoir une clé de licence pour l'application, puis vérifier côté client si la clé est bonne, mais il est facile de distribuer cette clé à d'autres utilisateurs et, avec un décompilateur, de nouvelles clés peuvent être générées.
J'ai implémenté l'activation ponctuelle basée sur Internet sur le logiciel de ma société (C # .net) qui nécessite une clé de licence faisant référence à une licence stockée dans la base de données du serveur. Le logiciel frappe le serveur avec la clé et reçoit les informations de licence qui sont ensuite cryptées localement à l'aide d'une clé RSA générée à partir de certaines variables (une combinaison de CPUID et d'autres éléments qui ne changeront pas souvent) sur l'ordinateur client le registre.
Cela nécessite un certain codage côté serveur, mais cela a très bien fonctionné pour nous et j'ai pu utiliser le même système lorsque nous avons étendu le logiciel à un navigateur. Il fournit également à vos commerciaux de bonnes informations sur qui, où et quand le logiciel est utilisé. Tout système de gestion de licences géré localement est totalement vulnérable à l’exploitation, en particulier si elle est reflétée dans .NET . Mais, comme tout le monde l’a dit, aucun système n’est totalement sécurisé.
À mon avis, si vous n'utilisez pas de licence Web, il n'y a aucun intérêt à protéger le logiciel. Avec les maux de tête que les DRM peuvent causer, ce n’est pas juste pour les utilisateurs qui en ont réellement payé le prix.
Je suis l'un des développeurs à l'origine de la plate-forme de licences logicielles Cryptolens et je travaille sur les systèmes de licences depuis l'âge de 14 ans. Dans cette réponse, j'ai inclus quelques astuces basées sur l'expérience acquise au fil des ans.
Le meilleur moyen de résoudre ce problème consiste à configurer un serveur de clé de licence que chaque instance de l'application appellera afin de vérifier une clé de licence.
Avantages d'un serveur de clé de licence
Les avantages d'un serveur de clé de licence sont les suivants:
- vous pouvez toujours mettre à jour ou bloquer une clé de licence avec effet immédiat.
- chaque clé de licence peut être verrouillée sur un certain nombre de machines (ceci aide à empêcher les utilisateurs de publier la clé de licence en ligne pour que d'autres puissent l'utiliser).
Considérations
Bien que la vérification des licences en ligne vous permette de mieux contrôler chaque instance de l'application, la connexion Internet n'est pas toujours présente (en particulier si vous ciblez de grandes entreprises). Nous avons donc besoin d'un autre moyen d'effectuer la vérification de la clé de licence.
La solution consiste à toujours signer la réponse de clé de licence du serveur à l'aide d'un cryptosystème à clé publique tel que RSA ou ECC (éventuellement préférable si vous envisagez de l'exécuter sur des systèmes intégrés). Votre application ne doit disposer que de la clé publique pour vérifier la réponse de la clé de licence.
Donc, dans le cas où il n'y a pas de connexion Internet, vous pouvez utiliser la réponse de clé de licence précédente à la place. Assurez-vous de bien enregistrer les identifiants date et machine dans la réponse et vérifiez qu’il n’est pas trop ancien (par exemple, vous autorisez les utilisateurs à être déconnectés au plus 30 jours, etc.) et que la clé de licence La réponse appartient au bon périphérique.
Remarque vous devez toujours vérifier la réponse du certificat de licence, même si vous êtes connecté à Internet), afin de vous assurer qu'elle n'a pas été modifiée depuis sa sortie du serveur (ceci reste à faire même si votre API sur le serveur de clé de licence utilise https)
Protéger les algorithmes secrets
La plupart des applications .NET peuvent être assez facilement désossées (il existe un diassembleur fourni par Microsoft pour obtenir le code IL et certains produits commerciaux peuvent même extraire le code source, par exemple, C #). Bien sûr, vous pouvez toujours masquer le code, mais ce n’est jamais sécurisé à 100%.
Dans la plupart des cas, l’objectif de toute solution de licence logicielle est d’aider les personnes honnêtes à être honnêtes (c’est-à-dire que les utilisateurs honnêtes qui sont disposés à payer n'oublient pas de payer après l’expiration d’un essai, etc.).
Cependant, il se peut que vous ayez encore du code que vous ne voulez absolument pas divulguer au public (par exemple, un algorithme permettant de prévoir le prix des actions, etc.). Dans ce cas, la seule solution consiste à créer un noeud final API que votre application appellera chaque fois que la méthode doit être exécutée. Cela nécessite une connexion Internet mais garantit que votre code secret ne sera jamais exécuté par la machine cliente.
La mise en oeuvre
Si vous ne voulez pas tout implémenter vous-même, je vous conseillerais de jeter un œil à ce tutoriel } _ (élément de Cryptolens )
Il n'est pas possible d'empêcher complètement le piratage de logiciels. Vous pouvez empêcher le piratage occasionnel et c'est ce que font toutes les solutions de licence.
Les licences verrouillées par nœud (machine) sont préférables si vous souhaitez empêcher la réutilisation des clés de licence. J'utilise Cryptlex depuis environ un an pour mon logiciel. Il a également un plan gratuit. Par conséquent, si vous ne vous attendez pas à trop de clients, vous pouvez l’utiliser gratuitement.
Je crois fermement que seul un système de licence basé sur la cryptographie à clé publique est la bonne approche, car vous n'avez pas à inclure les informations essentielles requises pour la génération de la licence dans votre code source.
Dans le passé, j'ai utilisé la bibliothèque de licences de Treek plusieurs fois, car elle répond à ces exigences et offre un très bon prix. Il utilise la même protection de licence pour les utilisateurs finaux et pour lui-même et personne ne l'a craqué jusqu'à présent. Vous pouvez également trouver de bons conseils sur le site Web pour éviter le piratage et les piratages.
Vous pouvez utiliser une solution tierce gratuite pour gérer cela pour vous, telle que Quantum-Key.Net. Elle est gratuite et gère les paiements via Paypal via une page de vente Web créée pour vous, l’émission des clés par courrier électronique et le verrouillage de l’utilisation de la clé sur un ordinateur spécifique. prévenir le piratage.
Vous devez également veiller à obscurcir/chiffrer votre code, sinon il peut facilement être désossé à l’aide de logiciels tels que De4dot et .NetReflector. ConfuserEx est un bon obfuscateur de code gratuit, rapide, simple à utiliser et plus efficace que les alternatives coûteuses.
Vous devez exécuter votre logiciel fini via De4Dot et .NetReflector pour le désosser et voir ce qu’un pirate informatique verrait s’il faisait la même chose et s’assurer que vous n’avez pas laissé de code important exposé ou non dissimulé.
Votre logiciel sera toujours craquable, mais pour le craqueur occasionnel, il sera peut-être suffisant de le retarder. Ces étapes simples permettront également d’éviter que votre code soit extrait et réutilisé.
https://github.com/0xd4d/de4dot
https://www.red-gate.com/dynamic/products/dotnet-development/reflector/download