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 sera disponible en téléchargement et installation gratuitement mais en version très limitée. Pour accéder à toutes les fonctionnalités, l'utilisateur doit payer une redevance 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-ci est un peu habituel, je me demande:

1. Comment est-ce généralement résolu?
2. Comment générer la clé et comment la valider par l'application?
3. Comment puis-je également éviter qu'une clé ne soit publiée sur Internet et utilisée par d'autres qui n'ont pas payé la licence (une clé qui n'est pas "la leur")?

Je suppose que je devrais également lier la clé à la version de l'application afin qu'il soit possible de facturer de nouvelles clés dans les versions de fonctionnalité.

Autre chose à laquelle je devrais penser dans ce scénario?

Attention: vous ne pouvez pas empêcher les utilisateurs de pirater, mais seulement permettre aux utilisateurs honnêtes de faire la bonne chose.

En supposant que vous ne voulez pas faire 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 de l'utilisateur, la clé secrète et le hachage avec (par exemple) SHA1
• Décompressez le hachage SHA1 en tant que chaîne alphanumérique. Il s'agit de la "clé de produit" de l'utilisateur individuel
• Dans le programme, faites le même hachage et comparez avec la clé de produit. Si égal, OK.

Mais, je le répète: cela n'empêchera pas le piratage

J'ai récemment lu que cette approche n'est pas très fiable d'un 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 ), donc je ne pense pas que cette découverte invalide la solution dans la mesure où elle va.

Je pensais juste que je devrais vraiment mentionner cela, cependant; si vous prévoyez d'en tirer autre chose, méfiez-vous.

Il existe de nombreuses façons de générer des clés de licence, mais très peu de ces méthodes sont vraiment sécurisées. Et c'est dommage, car pour les entreprises, les clés de licence ont presque la même valeur que l'argent réel.

Idéalement, vous souhaitez que vos clés de licence aient les propriétés suivantes:

1. 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 rétro-ingénierie complète de vos produits (ce qui arrivera, je parle d'expérience). Obscurcir l'algorithme ou masquer une clé de chiffrement dans votre logiciel est vraiment hors de question si vous êtes sérieux au sujet du contrôle des licences. Si votre produit réussit, quelqu'un créera un générateur de clés dans les jours qui suivent sa sortie.

2. Une clé de licence doit être utilisable sur un seul ordinateur (ou au moins vous devriez pouvoir contrôler cela très étroitement)

3. Une clé de licence doit être courte et facile à saisir ou à dicter par téléphone. Vous ne voulez pas que chaque client appelle le support technique car il ne comprend pas si la clé contient un "l" ou un "1". Votre service d'assistance vous en remerciera et vous bénéficierez de coûts inférieurs dans ce domaine.

Alors, comment résolvez-vous ces défis?

1. 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 façon, même si quelqu'un a un accès complet à la logique de votre produit, il ne peut pas générer de clés de licence car il n'a pas la clé privée. Une clé de licence ressemblerait à ceci: BASE32 (CONCAT (DATA, PRIVATE_KEY_ENCRYPTED (HASH (DATA)))) Le plus grand défi ici est que les algorithmes de clé publique classiques ont de grandes tailles de signature. RSA512 a une signature 1024 bits. Vous ne voulez pas que vos clés de licence contiennent des centaines de caractères. L'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 comme l'algorithme de signature numérique Schnorr (brevet expiré en 2008 - bon :))

2. Ceci est réalisable par l'activation du produit (Windows 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'ID matériel de l'ordinateur en tant que données signées. Cela se fait généralement sur Internet, mais seulement UNE FOIS: le produit envoie la clé de licence et l'ID du matériel informatique à un serveur d'activation, et le serveur d'activation renvoie le message signé (qui peut également être raccourci et facile à dicter sur 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 nécessitent que l'ordinateur soit le même pour valider (sinon, les DONNÉES seraient différentes et la signature numérique ne serait pas validée).

3. Eh bien, éliminez simplement les caractères redondants comme "1", "l", "0", "o" de vos clés. Divisez la chaîne de clé de licence en groupes de caractères.

Réponse simple - Quel que soit le schéma que vous utilisez, il peut être piraté.

Ne punissez pas les clients honnêtes avec un système destiné à empêcher les pirates, car les pirates le feront malgré tout.

Un simple code haché lié à leur e-mail ou similaire est probablement suffisant. Les ID basés sur le matériel deviennent toujours un problème lorsque les gens doivent réinstaller ou mettre à jour le matériel.

Bon fil sur la question: 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 à 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 publié.

Après avoir trouvé des clés ou des correctifs flottant dans astalavista.box.sk, vous saurez que vous avez réussi à rendre quelque chose suffisamment populaire pour que quelqu'un se donne la peine de craquer. Réjouir!

Outre ce qui a déjà été dit ...

Toute utilisation des applications .NET est intrinsèquement cassable en raison des problèmes de langage intermédiaire. Un simple démontage du code .NET ouvrira votre produit à n'importe qui. Ils peuvent facilement contourner votre code de licence à ce stade.

Vous ne pouvez même plus utiliser de valeurs matérielles pour créer une clé. Les machines virtuelles permettent désormais à quelqu'un de créer une image d'une machine «sous licence» et de l'exécuter sur la plate-forme de son choix.

S'il s'agit d'un logiciel coûteux, il existe d'autres solutions. Si ce n'est pas le cas, rendez-le assez difficile pour le pirate 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 de clé partielle", ce qui signifie que seul un sous-ensemble de la clé que vous utilisez pour générer la clé doit être compilé dans votre distribuable. Vous créez vous-même les clés, la mise en œuvre de la licence est donc unique à 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 licences.

Je suis l'un des développeurs de la plate-forme de licence logicielle Cryptolens et je travaille sur les systèmes de licence depuis l'âge de 14 ans. Dans cette réponse, j'ai inclus quelques conseils basés sur l'expérience acquise au fil des ans.

La meilleure façon de résoudre ce problème est de configurer un serveur de clés de licence que chaque instance de l'application appellera afin de vérifier une clé de licence.

Avantages d'un serveur de clés de licence

Les avantages d'un serveur de clés de licence sont les suivants:

1. vous pouvez toujours mettre à jour ou bloquer une clé de licence avec effet immédiat.
2. chaque clé de licence peut être verrouillée sur un certain nombre de machines (cela empêche 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 donne plus de contrôle sur chaque instance de l'application, la connexion Internet n'est pas toujours présente (surtout si vous ciblez de plus grandes entreprises), nous avons donc besoin d'une autre façon d'effectuer la vérification de la clé de licence.

La solution consiste à toujours signer la réponse de la clé de licence du serveur à l'aide d'un cryptosystème à clé publique tel que RSA ou ECC (peut-être mieux si vous prévoyez de fonctionner sur des systèmes embarqués). Votre application ne doit avoir que la clé publique pour vérifier la réponse de la clé de licence.

Donc, s'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 stocker à la fois la date et l' identifiant de la machine dans la réponse et vérifiez qu'elle n'est pas trop ancienne (par exemple, vous autorisez les utilisateurs à être hors ligne au plus 30 jours, etc.) et que la réponse de la clé de licence appartient au périphérique approprié.

Notez que vous devez toujours vérifier la réponse de la clé du certificat de licence, même si vous êtes connecté à Internet), afin de vous assurer qu'il n'a pas été modifié depuis qu'il a quitté le serveur (cela doit toujours être fait même si votre API à la le serveur de clé de licence utilise https)

Protéger les algorithmes secrets

La plupart des applications .NET peuvent être rétroconçues assez facilement (il existe à la fois un diassembleur fourni par Microsoft pour obtenir le code IL et certains produits commerciaux peuvent même récupérer le code source, par exemple en C #). Bien sûr, vous pouvez toujours masquer le code, mais il n'est jamais sûr à 100%.

Dans la plupart des cas, le but de toute solution de licence logicielle est d'aider les gens honnêtes à être honnêtes (c'est-à-dire que les utilisateurs honnêtes qui sont prêts à payer n'oublient pas de payer après l'expiration d'un essai, etc.).

Cependant, vous pouvez toujours avoir du code que vous ne voulez en aucun cas divulguer au public (par exemple, un algorithme pour prédire les cours des actions, etc.). Dans ce cas, la seule solution consiste à créer un point de terminaison API que votre application appellera à chaque exécution de la méthode. Il nécessite une connexion Internet mais il garantit que votre code secret n'est jamais exécuté par la machine cliente.

la mise en oeuvre

Si vous ne voulez pas tout implémenter vous-même, je vous recommande de jeter un œil à ce tutoriel (partie de Cryptolens )

J'ai 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 schéma de licence.

Je ne sais pas à quel point tu veux être élaboré

mais je crois que .net peut accéder au numéro de série du disque dur.

vous pourriez demander au programme de vous envoyer cela et quelque chose d'autre (comme le nom d'utilisateur et l'adresse mac du nic)

vous calculez un code basé sur cela et leur renvoyez la clé par e-mail.

ils les empêcheront de changer de machine une fois qu'ils auront la clé.

La seule façon de faire tout ce que vous avez demandé est d'exiger 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, comme l'adresse IP. Cela empêchera la clé d'être utilisée sur plusieurs machines différentes. Ce n'est généralement pas très populaire auprès des utilisateurs de l'application, et à moins qu'il ne 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é une activation unique basée sur Internet sur le logiciel de mon entreprise (C # .net) qui nécessite une clé de licence qui fait 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 des 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, puis les stockent dans 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 sommes passés à un logiciel basé sur un navigateur. Il donne également à vos vendeurs de bonnes informations sur qui, où et quand le logiciel est utilisé. Tout système de licence qui n'est géré que localement est entièrement vulnérable à l'exploitation, en particulier avec la réflexion 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 le mal de tête que le DRM peut causer, ce n'est pas juste pour les utilisateurs qui ont réellement payé pour en souffrir.

Je crois fermement que seul le système de licences basé sur la cryptographie à clé publique est la bonne approche ici, car vous n'avez pas à inclure les informations essentielles requises pour la génération de licences dans votre code source.

Dans le passé, j'ai utilisé la bibliothèque de licences de Treek à plusieurs reprises, car elle remplit ces conditions 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 le craquage.

Comme quelques autres l'ont mentionné, je suis un énorme opposant à l' hostilité des clients par défaut, ce qui fait la renommée de l'industrie des licences. Je vais donc développer une bonne solution pour votre problème qui offre également un bon UX client .

Pour commencer, vous avez mentionné que vous disposez d'une version "limitée" de votre logiciel que vous utilisez pour essayer de convertir les clients en "mise à niveau" pour des fonctionnalités supplémentaires. Vous recherchez donc des licences de fonctionnalités pour votre produit, par exemple, un client peut acheter une licence pour la fonctionnalité X ou fonction-Y .

J'ai construit Keygen avec ce type de licence à l'esprit. Keygen est une API REST de licence qui vous permet de gérer les comptes d'utilisateurs, les licences et également de suivre l'utilisation / les associations des machines.

Ce que je ferais, c'est configurer 2 types de licences (une politique au sein de Keygen) où l'un est une politique de base pour la version gratuite limitée, et l'autre est une politique pour la version payante.

Je ne sais pas ce que vous utilisez pour les paiements, mais supposons que vous utilisez quelque chose comme Stripe (assez standard de nos jours) qui propose des webhooks . Keygen a également des webhooks (que vous l'utilisiez ou non, tout cela est toujours applicable). Vous pouvez intégrer Keygen pour parler avec votre fournisseur de paiement en utilisant des webhooks des deux côtés (pensez: customer.created-> créer une licence de base pour le client,license.created -> facturer au client la nouvelle licence).

Ainsi, en utilisant des webhooks, nous pouvons automatiser la création de licences pour les nouveaux clients. Qu'en est-il de la validation des licences dans l'application elle-même? Cela peut être fait de différentes manières, mais la manière la plus populaire consiste à demander à votre client d'entrer une longue clé de licence dans un champ de saisie que vous pouvez ensuite valider; Je pense que c'est terrible façon de gérer la validation des licences dans votre application.

Pourquoi je pense ça? Tout d'abord, vous demandez à votre client de saisir une clé de licence fastidieusement destinée à la consommation de la machine, et deuxièmement, vous et votre client devez suivre cette clé de licence fastidieusement longue .

D'accord, alors quelle est une alternative? Je pense que la meilleure alternative est de faire quelque chose auquel tous vos clients sont habitués: leur permettre de créer un compte pour votre produit en utilisant un e-mail / mot de passe . Vous pouvez ensuite associer toutes leurs licences et leurs machines à ce compte. Alors maintenant, au lieu de saisir une clé de licence, ils peuvent simplement se connecter en utilisant leurs informations d'identification.

Quel avantage cela vous donne-t-il? Premièrement, il supprime la nécessité pour vous et vos clients de garder une trace des clés de licence, car tout est géré en arrière-plan à l'intérieur de leur compte d'utilisateur et surtout: vous pouvez maintenant offrir à vos clients une licence et une machine libre-service. Activation! c'est-à-dire que toutes leurs licences et machines sont associées à leur compte utilisateur, vous pouvez les inviter à acheter une licence lorsqu'ils lancent votre application sur une machine non reconnue.

Maintenant , sur la validation de la licence : chaque fois que votre client se connecte dans votre application avec leur e - mail / mot de passe, vous pouvez interroger leur compte utilisateur pour les licences dont ils sont propriétaires pour déterminer si elles peuvent utiliser fonction-X ou fonction-Y . Et puisque votre application est désormais en libre-service , vous pouvez permettre à vos clients d'acheter des fonctionnalités supplémentaires directement depuis votre application!

Nous avons donc introduit une tonne d'automatisation dans notre système de licences, nous pouvons octroyer des licences pour des fonctionnalités individuelles (c'est-à-dire une version limitée par rapport à la version complète), nous avons offert une expérience utilisateur impressionnante à nos clients et nous avons également atténué l'une des principales raisons pour les demandes d'assistance: récupération de clé de licence.

Quoi qu'il en soit, cela est devenu long mais j'espère que cela aide quelqu'un!

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.

La licence verrouillée par nœud (machine) est préférable si vous souhaitez empêcher la réutilisation des clés de licence. J'utilise Cryptlex depuis environ un an maintenant pour mon logiciel. Il a également un plan gratuit , donc si vous n'attendez pas trop de clients, vous pouvez l'utiliser gratuitement.

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 qu'elle crée pour vous, la délivrance des clés par e-mail et verrouille l'utilisation des clés sur un ordinateur spécifique pour prévenir le piratage.

Vous devez également prendre soin de brouiller / crypter votre code ou il peut facilement être rétro-conçu à l'aide de logiciels tels que De4dot et .NetReflector. Un bon obfuscateur de code gratuit est ConfuserEx qui est rapide et simple à utiliser et plus efficace que des alternatives coûteuses.

Vous devez exécuter votre logiciel fini via De4Dot et .NetReflector pour le désosser et voir ce qu'un pirate verrait s'il faisait la même chose et pour vous assurer que vous n'avez laissé aucun code important exposé ou non déguisé.

Votre logiciel sera toujours craquable, mais pour le pirate occasionnel, il pourrait bien suffire de le désactiver et ces étapes simples empêcheront également l'extraction et la réutilisation de votre code.

https://quantum-key.net

Comment utiliser ConfuserEx?

https://github.com/0xd4d/de4dot

https://www.red-gate.com/dynamic/products/dotnet-development/reflector/download