Comment les clés de licence logicielles sont-elles générées?
Les clés de licence sont la norme de facto en tant que mesure anti-piratage. Pour être honnête, cela me semble être in) Security Through Obscurity , bien que je ne sache vraiment pas comment les clés de licence sont générées. Qu'est-ce qu'un bon exemple (sécurisé) de génération de clé de licence? Quelle primitive cryptographique (le cas échéant) utilisent-ils? Est-ce un message condensé? Si oui, quelles données seraient-ils en train de hacher? Quelles méthodes les développeurs utilisent-ils pour rendre difficile la tâche des pirates pour créer leurs propres générateurs de clés? Comment sont fabriqués les générateurs de clés?
Pour les clés de CD de la vieille école, il s’agissait simplement de créer un algorithme pour lequel les clés de CD (qui peuvent être n’importe quelle chaîne) sont faciles à générer et à vérifier, mais le rapport entre les clés de CD valides et les CD non valides. -keys est si petit qu'il est peu probable que les clés de CD soient devenues aléatoires.
Manière incorrecte de le faire:
Starcraft et Half-life utilisaient tous les deux la même somme de contrôle, où le 13 digit vérifié les 12 premiers. Ainsi, vous pouvez entrer n'importe quoi pour les 12 premiers chiffres et deviner le 13 (il n'y a que 10 possibilités), ce qui conduit au tristement célèbre 1234-56789-1234
L'algorithme de vérification est public et ressemble à ceci:
x = 3;
for(int i = 0; i < 12; i++)
{
x += (2 * x) ^ digit[i];
}
lastDigit = x % 10;
Façon convenable de le faire
Windows XP prend pas mal d’informations, les chiffre, et place le codage lettre/chiffre sur un autocollant. Cela a permis à MS de vérifier votre clé et d'obtenir le type de produit (Home, Professional, etc.) en même temps. De plus, cela nécessite une activation en ligne.
L’algorithme complet est plutôt complexe, mais décrit joliment dans le document this (complètement légal!), Publié en Allemagne.
Bien sûr, peu importe ce que vous faites, à moins que vous n'offriez un service en ligne (comme World of Warcraft ), tout type de protection contre la copie n'est qu'un blocage : malheureusement, si le jeu vaut la peine, quelqu'un cassera (ou au moins contournera) l'algorithme CD-key, ainsi que toutes les autres protections de copyright.
REAL CORRIGER FAIRE:
Pour les services en ligne, la vie est un peu plus simple, car même avec le fichier binaire, vous devez vous authentifier auprès de leurs serveurs pour pouvoir l'utiliser (par exemple, avoir un compte WoW). L'algorithme clé de CD pour World of Warcraft - utilisé par exemple lors de l'achat de cartes de jeu - ressemble probablement à ceci:
- Générez un très grand nombre aléatoire cryptographiquement sécurisé.
- Stockez-le dans notre base de données et imprimez-le sur la carte.
Ensuite, lorsque quelqu'un entre un numéro de carte de lecture, vérifiez s'il est dans la base de données et, le cas échéant, associez ce numéro à l'utilisateur actuel pour qu'il ne puisse plus jamais être utilisé.
Pour les services en ligne, il n'y a aucune raison de ne pas utiliser le schéma ci-dessus; utiliser n'importe quoi d'autre peut causer des problèmes .
Lorsque j'ai initialement écrit cette réponse, elle supposait que la question concernait la validation "hors ligne" des clés de licence. La plupart des autres réponses traitent de la vérification en ligne, qui est nettement plus facile à gérer (la majeure partie de la logique peut être réalisée côté serveur).
Avec la vérification hors ligne, le plus difficile est de vous assurer que vous pouvez générer un grand nombre de clés de licence uniques tout en maintenant un algorithme puissant qui ne soit pas facilement compromis (comme un simple chiffre de contrôle).
Je ne connais pas très bien les mathématiques, mais cela m’a frappé de penser qu’une façon de le faire est d’utiliser une fonction mathématique qui trace un graphique.
La ligne tracée peut avoir (si vous utilisez une fréquence suffisamment fine) des milliers de points uniques. Vous pouvez donc générer des clés en sélectionnant des points aléatoires sur ce graphique et en codant les valeurs d'une manière ou d'une autre.
À titre d’exemple, nous allons tracer ce graphique, choisir quatre points et encoder une chaîne comme suit: "0, -500; 100, -300; 200, -100; 100,600"
Nous allons chiffrer la chaîne avec une clé connue et fixe (horriblement faible, mais cela sert à quelque chose), puis convertirons les octets obtenus en Base32 pour générer la clé finale.
L’application peut alors inverser ce processus (base32 en nombre réel, décrypter, décoder les points), puis vérifier chacun de ces points sur notre graphe secret.
C'est une assez petite quantité de code qui permettrait de générer un grand nombre de clés uniques et valides
C'est cependant beaucoup de sécurité par obscurité. Toute personne prenant le temps de désassembler le code serait en mesure de trouver la fonction graphique et les clés de cryptage, puis de simuler un générateur de clé, mais est probablement très utile pour ralentir le piratage occasionnel.
Consultez cet article sur Vérification partielle de clé qui couvre les conditions suivantes:
Les clés de licence doivent être assez faciles à saisir.
Nous devons être en mesure de mettre sur liste noire (révoquer) une clé de licence en cas de rétrofacturation ou d'achat avec des cartes de crédit volées.
Pas de "téléphoner à la maison" pour tester les clés. Bien que cette pratique soit de plus en plus répandue, je ne l’apprécie toujours pas en tant qu’utilisateur, je ne demanderai donc pas à mes utilisateurs de l’accepter.
Un pirate informatique ne devrait pas pouvoir désassembler notre application publiée et en produire un "keygen" fonctionnel. Cela signifie que notre application ne testera pas complètement une clé pour la vérification. Seule une partie de la clé doit être testée. En outre, chaque version de l'application doit tester une partie différente de la clé, de sorte qu'une clé fictive basée sur une version antérieure ne fonctionne pas avec une version ultérieure de notre logiciel.
Important: il ne devrait pas être possible pour un utilisateur légitime de taper accidentellement une clé non valide qui semblera fonctionner mais échouera sur une version future en raison d’une erreur typographique.
Je n'ai aucune expérience de ce que les utilisateurs font réellement pour générer des clés de CD, mais (en supposant que vous ne souhaitiez pas vous engager sur la voie de l'activation en ligne), voici quelques moyens de créer une clé:
Exigez que le nombre soit divisible par (par exemple) 17. Trivial à deviner, si vous avez accès à plusieurs clés, mais la majorité des chaînes potentielles seront invalides. De même, il faudrait exiger que la somme de contrôle de la clé corresponde à une valeur connue.
Exigez que la première moitié de la clé, lorsqu'elle est concaténée avec une valeur connue, soit hachée jusqu'à la seconde moitié de la clé. Mieux, mais le programme contient toujours toutes les informations nécessaires pour générer des clés ainsi que pour les valider.
Générez des clés en chiffrant (avec une clé privée) une valeur connue + nonce. Cela peut être vérifié en décryptant à l'aide de la clé publique correspondante et en vérifiant la valeur connue. Le programme dispose maintenant de suffisamment d'informations pour vérifier la clé sans pouvoir générer de clés.
Ceux-ci sont toujours ouverts à l'attaque: le programme est toujours là et peut être corrigé pour contourner la vérification. Cleverer pourrait être de chiffrer une partie du programme en utilisant la valeur connue de ma troisième méthode, plutôt que de la stocker dans le programme. De cette façon, vous devez trouver une copie de la clé avant de pouvoir déchiffrer le programme, mais il est toujours vulnérable d’être copié une fois déchiffré et d’avoir une personne qui prend sa copie légitime et l’utilise pour permettre à tous les autres d’accéder au logiciel.
Les clés CD ne constituent pas vraiment une sécurité pour les éléments non mis en réseau, donc techniquement, elles n'ont pas besoin d'être générées de manière sécurisée. Si vous êtes sur .net, vous pouvez presque utiliser Guid.NewGuid ().
De nos jours, leur utilisation principale est le composant multijoueur, où un serveur peut vérifier la clé du CD. Pour cela, la sécurité de la génération est sans importance puisque cela revient à "Rechercher tout ce qui est transmis et à vérifier si quelqu'un d'autre l'utilise déjà".
Cela dit, vous pouvez utiliser un algorithme pour atteindre deux objectifs:
- Avoir une somme de contrôle de quelque sorte. Cela permet à votre installateur d’afficher le message "La clé ne semble pas valide", uniquement pour détecter les fautes de frappe (Ajouter une telle vérification dans le programme d’installation signifie en réalité que l’écriture d’un générateur de clé est triviale, car le pirate informatique dispose de tout le code dont il a besoin. vérifier et se fier uniquement à la validation côté serveur désactive cette vérification, au risque de gêner vos clients légaux qui ne comprennent pas pourquoi le serveur n'accepte pas leur clé de CD car ils ne sont pas conscients de la faute de frappe)
- Travailler avec un sous-ensemble limité de caractères. Essayer de taper une clé de CD et de deviner "Est-ce un 8 ou un B? Un 1 ou un I? Un Q ou un O ou un 0?" - en utilisant un sous-ensemble de caractères/chiffres non ambigus, vous éliminez cette confusion.
Cela dit, vous voulez toujours une grande distribution et un peu de hasard pour éviter à un pirate de deviner une clé valide (valable dans votre base de données mais toujours dans une boîte sur une étagère d'un magasin) et de bousiller un client légitime qui achète cette boîte. .
Si vous n'êtes pas particulièrement préoccupé par la longueur de la clé, une méthode assez éprouvée consiste à utiliser le chiffrement à clé publique et à clé privée.
Avoir essentiellement une sorte de nonce et une signature fixe.
Par exemple: 0001-123456789
Où 0001 est votre nonce et 123456789 votre signature fixe.
Puis chiffrez-le en utilisant votre clé privée pour obtenir votre clé de CD, qui ressemble à quelque chose comme: ABCDEF9876543210
Distribuez ensuite la clé publique avec votre application. La clé publique peut être utilisée pour déchiffrer la clé de CD "ABCDEF9876543210", dont vous vérifiez ensuite la partie de signature fixe.
Ceci empêche alors quelqu'un de deviner ce qu'est la clé de CD pour le nonce 0002 car il ne possède pas la clé privée.
Le seul inconvénient majeur est que les clés de votre CD seront assez longues si vous utilisez des clés privées/publiques de 1024 bits. Vous devez également choisir un nonce suffisamment long pour ne pas chiffrer une quantité infime d'informations.
L'aspect positif est que cette méthode fonctionnera sans "activation" et vous pouvez utiliser des éléments tels qu'une adresse électronique ou un nom de titulaire de licence comme nonce.
Le système de clé doit avoir plusieurs propriétés:
- très peu de clés doivent être valides
- les clés valides ne doivent pas être dérivables, même avec tout ce que l'utilisateur a.
- une clé valide sur un système n'est pas une clé valide sur un autre.
- autres
Une solution qui devrait vous les donner serait d'utiliser un schéma de signature à clé publique . Commencez avec un "hachage système" (par exemple, saisissez les macs de toutes les cartes réseau, triez-les et donnez-leur des informations sur l'ID de l'UC, ainsi que d'autres éléments, concaténez le tout et prenez un MD5 du résultat (vous ne voulez vraiment pas traitement informations personnellement identifiables si vous n'avez pas à le faire)) ajoutez le numéro de série du CD et refusez de démarrer sauf si une clé de registre (ou un fichier de données) possède une signature valide pour le blob. L'utilisateur active le programme en vous envoyant le blob et vous renvoyez la signature.
Les problèmes potentiels incluent le fait que vous proposiez de signer pratiquement n'importe quoi, vous devez donc supposer que quelqu'un exécutera une attaque texte brut choisi et/ou texte crypté choisi . Cela peut être atténué en vérifiant le numéro de série fourni et en refusant de traiter les demandes des personnes non valides, ainsi qu'en refusant de traiter plus d'un nombre donné de requêtes d'un s/n donné dans un intervalle (disons 2 par an).
Je devrais signaler quelques points: Tout d’abord, un attaquant compétent et déterminé sera en mesure de contourner toute sécurité dans les parties auxquelles il a un accès illimité (, c’est-à-dire tout sur le CD), le mieux que vous puissiez faire pour ce compte est de rendre plus difficile l’obtention d’un accès illégitime que l’obtention d’un accès légitime. Deuxièmement, je ne suis pas un expert et le régime proposé pourrait donc comporter de graves lacunes.
Il existe également des comportements DRM qui intègrent plusieurs étapes dans le processus. L'un des exemples les plus connus est l'une des méthodes utilisées par Adobe pour vérifier l'installation de sa suite Creative. La méthode de clé de CD traditionnelle décrite ici est utilisée, puis la ligne d'assistance d'Adobe est appelée. La clé du CD est remise au représentant Adobe qui lui redonne un numéro d’activation à utiliser par l’utilisateur.
Cependant, bien qu’il soit divisé en étapes, il est soumis aux mêmes méthodes de fissuration que le processus normal. Le processus utilisé pour créer une clé d'activation vérifiée par rapport à la clé de CD d'origine a été rapidement découvert et des générateurs intégrant les deux clés ont été créés.
Cependant, cette méthode existe toujours pour permettre aux utilisateurs sans connexion Internet de vérifier le produit. À l'avenir, il est facile de voir comment ces méthodes pourraient être éliminées à mesure que l'accès à Internet devient omniprésent.
Tous les algorithmes de protection contre la copie sur CD seulement dérangent les utilisateurs honnêtes tout en ne fournissant aucune protection contre le piratage.
Le "pirate" n'a besoin que d'avoir accès à un cd légitime et à son code d'accès, il peut alors en faire n copies et les distribuer.
Peu importe le niveau de sécurité cryptographique que vous créez avec le code, vous devez le fournir avec le CD en texte brut ou un utilisateur légitime ne peut pas activer le logiciel.
La plupart des systèmes sécurisés impliquent soit l’utilisateur qui fournit au fournisseur de logiciel des détails sur la machine qui exécutera le logiciel (numéros de série du processeur, adresses mac, adresse IP, etc.), ou qui nécessite un accès en ligne pour enregistrer le logiciel sur le site Web du fournisseur et en retour, recevez un jeton d'activation. La première option nécessite beaucoup d’administration manuelle et ne vaut que pour les logiciels de très grande valeur. La deuxième option peut être usurpée et est absolument exaspérante si vous avez un accès réseau limité ou si vous êtes bloqué derrière un pare-feu.
Dans l’ensemble, il est beaucoup plus facile d’établir une relation de confiance avec vos clients!