Chiffrement des clés de produit: chiffrement à clé publique et privée

Question

Je dois générer et valider des clés de produit et j'ai envisagé d'utiliser un système de clé publique/privée.

je produis nos clés de produit basé sur

• un nom de client (qui pourrait être une chaîne de longueur variable)
• un numéro de 6 chiffres.

Il serait bon que la clé de produit serait d'une longueur raisonnable (16 caractères environ)

Je dois les chiffrer à la base et distrubute le système de décryptage/validation. Comme notre système est écrit en code managé (.NET), nous ne voulons pas distribuer le système de cryptage, seulement le décryptage. J'ai besoin d'une clé privée publique qui me semble un bon moyen de le faire, crypter avec la clé que je garde et distribuer l'autre clé nécessaire pour la déchiffrement/vérification.

Qu'est-ce qu'un mécanisme approprié pour faire cela avec les exigences ci-dessus?

REMARQUE: il ne s'agit pas d'arrêter le piratage; c'est pour réduire la probabilité d'utilisateurs novices d'installer des composants dont ils n'ont pas besoin/non autorisés à utiliser.

Answer 1

.NET prend en charge le cryptage à clé publique de différentes manières, telles que http://msdn.microsoft.com/en-us/library/ms867080.aspx. Cela dit, tout ce que vous gagnez, c'est une certaine confiance que quelqu'un avec un accès complet au code libéré n'aurait pas la possibilité d'émettre ses propres clés de produit. Rien de tout cela ne les empêche de patcher le client pour accepter quoi que ce soit comme une clé valide. C'est là que l'obfuscation s'inscrit.

Answer 2

N'essayez même pas de vous faire plaisir avec l'antipiratage. Ça ne vaut pas le coup. J'ai craqué d'innombrables applications (hush) et celles de .NET sont de loin les plus faciles. Mais en réalité, ils sont tous relativement faciles avec suffisamment d'expérience. Si vous ne me croyez pas, consultez isohunt un certain temps.

tl; dr: C'est une bataille perdue. Ne le combat pas. Si vous voulez vraiment gagner, poursuivre les infractions - mais même cela vous fait perdre.

Answer 3

J'ai fait quelque chose de très similaire. Mais dans mon cas c'était un simple code d'autorisation téléphonique. L'utilisateur téléphonait à un numéro, donnait le nom de son entreprise et l'opération qu'il effectuait, obtenait un code, le tapait dans l'application et pouvait ensuite continuer.

Ce que j'ai fait était de sérialiser une donnée en binaire. Les données comprenaient le nom de l'entreprise hachée, le code d'opération/la date d'expiration et l'espace disponible pour les besoins futurs. J'ai ensuite dispersé les bits autour du tableau pour le confondre. Ensuite, j'ai cartographié chaque 5 bits du tableau binaire sur un alphabet de 32 caractères auth-code (0-9, a-z, excluant I/O/Q/S pour la lisibilité par téléphone).

Cela s'est traduit par un joli code d'authentification de 16 caractères, affiché en tant que blocs 4x4 (#### - #### - #### - ####). Il pourrait être facilement lu au téléphone, car l'utilisateur devait seulement écouter quatre caractères à la fois, ou même envoyer par SMS. Comme avec votre problème, il n'était pas destiné à arrêter les crackers de code à Bletchley Park, mais était suffisant pour empêcher l'employé de bureau moyen de faire quelque chose sans suivre la procédure de l'entreprise. Et, compte tenu de cette portée, a été très efficace.